6 lessons for building team operations from scratch

This is Part 1 of a three part series. (Part 2 on defining company culture here; Part 3 on tracking team goals is here.) In this piece, I describe lessons learned from the first year in my role building team operations and partner support systems.

When I transitioned into my current role at Minerva Project, I was thrilled to have the opportunity to build a team for the first time. As a relatively new manager I had ideas for what needed to happen – how I would hire, lead, and support – and I was excited to bring those ideas to life. Now two years into this role, I understand what’s required beyond hiring the right people. That first step is important, but the ways I helped my team work together have ultimately led to our success and continued to pay off.

I have broken down my insights across three articles that each focus on a topic: operations, culture, and goal-setting. I hope as a new (or even seasoned) manager, you will find lessons in here that improve how you work with your team.

________________________________________________________________

When aligned to corporate priorities and done well, a solid operational foundation can accelerate a company’s success. Joining as Minerva’s first Director of Program Success, I prioritized setting up our protocols for supporting partners before all else. Why? (1) We were early enough in our startup life that establishing good practices would make us more efficient in the long run, and (2) A sense of order would allow the team to focus on what matters.

Our team had a few key resources to start – an Asana board with a list of setup tasks, a customer support team, a Slack channel for our account managers, and… that’s it. A short list but it gave me just enough information about how we worked with partners to understand where I could start.

I also had a limited budget (there were more important places for us to spend our resources until we understood exactly what we needed operationally) but this was perfect: the lack of processes and a nonexistent budget bred the creativity I needed to imagine how to provide high-quality support with whatever we had available.

While I won’t share every resource I created for my team, I am sharing the lessons that would have given me a boost I needed in my thinking at the earliest stages.

1. Learn what your team needs before starting.

Building without a plan is pointless. Your first step should be to understand what informal or tacit systems already exist that help your team function and to figure out what’s worth keeping or replacing.

As someone who worked in partnerships for several years, I thought I knew what our team of account managers needed in the field. I was wrong. Context matters, and I needed to take the time to understand how we talked to partners and worked with them on program setup.

I fixed that by speaking with each account manager about his or her work: Where were the pain points? What resources or talking points they use in their conversations? What ate up valuable time?

I discovered the following:

(1) Program implementation demands a lot of partners, so we had to make the process feel simple and easy to manage.

(2) Project management requires both sides to stay constantly in touch to hash out a complicated and overlapping list of details. We have to be experts at knowing what information is required, what questions to ask, who needs to be brought into discussions, and when decisions need to be made.

I now had direction: to focus first on documents that supported the onboarding and setup process. The result was our Partner Onboarding Guide, which included a page of the key meetings and draft agendas along with an overview of everything required with deadlines. Had I not taken the time to speak to my team, I would have skipped the stage with the greatest impact for partners.

A page from our Onboarding Guide detailing suggested meetings and topics for discussion.

2. You don’t need an expensive CRM right away.

I was needlessly stubborn in learning this lesson. I thought a CRM was a standard part of any operational arsenal, something an account management couldn’t live without. Knowing that we would not be pursuing one in the near-term put me in the difficult position (I thought) of finding another way to cleanly track all partner information. So I opened up Google Sheets and built a resource – the Partner Management Plan – that was meant to be temporary but has now become a permanent part of how we catalogue partner information.

The first tab of the Partner Management Plan, which contained all of the most frequently requested details from Minerva teams.

The beauty of creating something from scratch was being able to imagine and manifest my perfect CRM. It fit our needs exactly and cost nothing but my development time. Even after adopting a CRM, our team has continued to use the Partner Management Plan because it is easy to read, simple to share, and quick to modify without needing assistance from a CRM administrator.

3. Rough drafts lead to great lessons.
In an effort to create the “right” assets, I created plenty that missed the mark. Taking a creative approach can pretty much guarantee you are not going to get it right 100 percent of the time. Rather than throw anything away, pull out the elements that do work and try to fit them into another tool. A couple of my early misses turned lessons:

1. An early (admittedly uglier) version of the Partner Management Plan built in Google Docs that became the basis of the current version in Google Sheets after I realized that the tool needed to feel like a CRM even if it was not one.
2. A partner FAQ that addressed the questions we often heard in the first few weeks of the partnerships. We ignored the common sense that busy university admins did not want to be burdened with one more document to read and transitioned to using video demos, which did a much better job of allowing the prospective partner to experience Forum.

Had I not created these, we might never have learned what could work with our audiences.

4. Don’t build walls in your system.
Team operations should enhance visibility into one another’s work and break down silos. The best resources and processes are those that recognize the reality of cross-functional work and improve it. (Of course, there are times when security and privacy prevent full transparency, so take time to recognize where the appropriate limits are in your organization.)

To do this well you need to recognize the patterns that surface from your early conversations with teams (see Point #2). Some questions to consider:

1. Where are teams handing work off to other teams?
2. Where do individuals or teams work together to complete something?
3. What leads to effective collaboration when teams do work together?
4. Where might the work of one team directly or indirectly impact another team?
5. Where should information be shared to avoid an error further down the line?

Taking the time to figure out ways for people to work together will only lead to better knowledge management and collaboration.

5. Iterate, iterate, iterate.
This lesson is an extension of Lesson #3: Rough drafts will lead to great lessons. Sure, throw some stuff out. What I did not mention was what to do with all of the resources that do work. Everything you create is subject to reworking and should be revised to keep up with the team’s needs as the company grows. I ask myself three questions when revisiting something:

1. What do I need to adjust because I see that it isn’t working?
2. What is missing that would be useful to the user?
3. What do I notice is not being used and do I know why?

Rarely can I answer these questions alone. I may have sketches of information from my interactions with colleagues who are using the tools but it’s better to ask for feedback directly.

6. Offer training right away and often.
Everything covered in this piece is for naught unless people understand what they should be doing and how to do it. This means they know where to find your resource, they understand how to use it, and they recognize the value it brings to their work.

When introducing something new to a team, I create a short, illustrated how-to guide and schedule training for anyone who will be using it. I make a point to share the how-to guide ahead of time and update the team any time I make changes. Chances are you’ll need to re-train or share reminders on the correct use of some resources. When this happens, focus on the progress that’s been made and try to understand what challenges your team may be facing so that you can figure out what isn’t working and iterate.

If you’re just starting out, I suggest first writing a list of who to speak with to draw a picture of your current operations setup. Who has the right knowledge of the existing systems to help you figure out where you can build bridges or tear down walls? Where is there friction?

It’s easy to feel accomplished once you have systems in place and running. As one should: operational setup requires one to understand the big picture and translate that into daily tasks where no one feels like a cog. Yet they are only one half of the operational success an organization can have. In the next piece, I look at how I worked with our senior leadership to strengthen company culture in an effort to continue improving how we work together.