Ops is Engineering Yourself Out of a Job

In recent years, the term Operations has been applied to everything. Design co-oped it from Dev, Research grabbed it from Design, and now Product has gotten in on the action. As per usual, there is a lot of confusion as to what constitutes “Ops.” This is a very timely question for me because after three amazing, exciting years building the Training Business and all the operations around it at Mind the Product, I’m transitioning out of my role as Director of Training Products.

More my transition later, let’s focus on the lessons I’ve learned about Operations in the 3 years that it took to build the training team from myself to a 5 person team, 80+ trainers and a global business functioning on 3 continents. As with most things to do with Product stuff, Operations, theoretically, are simple, but putting them into practice is difficult. Operations, in theory, means that thought and intention have been put into building processes so that they are clear, transparent, accessible, repeatable and scalable, by anyone that happens to be implementing them. Getting operations right has proved to be so complex that an entire global movement as risen around it, led by various factions of Design and Research thinkers.

Now, don’t get me wrong, I think these communities are really doing great work because the more Product folks understand about setting up and running operations the better, but I worry that it creates a perception that operations are a rarified skill set that only some people can do it.

As I’ve examined all of the great thinking that is going into Operations, I considered my own approach to implementing Ops. As a Builder PM, I’ve landed on Operations being the practice of trying to engineer myself out of a job. My driving question as I’m working on building a product/service is, “Are the processes and systems that I’m building going to continue to help the team and support a good process after I’m gone?” This perspective is crucial for PMs because anyone can hold a badly organized process together if they are the only ones who have to deal with it. I challenge you to reflect: if you disappeared tomorrow, would the processes you have put into place be accessible and understood by someone else? If the answer is no, then you need to rethink your approach to Ops.

*****

Lessons on Operations

Operations is a complex eco-system of tools, systems, and processes and it should take many forms depending on the project. I’m not going to outline Ops below, rather tell you the practices that I feel help me find the best operations systems for the team I’m building. If you want to check out some cool resources to get a grip on Ops in these disciplines actually entails, check out this cool visual on Research Ops from the Re+Ops community, this article on Design Ops and this blog on Product Ops from the ever-insightful Melissa Perri.

Hold a self-service mentality

From Square Zero, the thought you have to hold in your head is that everyone who currently does, or eventually will work on your team should be able to easily navigate and locate resources. One of the greatest examples of a self-service mentally is Google’s approach to customer service. For our 80+ trainers who are globally distributed, we want them to be able to get any answer they need at the drop of a hat, so we implemented a Notion, and created an arsenal of materials that helps them answer questions on content and logistics immediately.

Transparency is key

One of my biggest pet peeves is when I hear someone on my team say “I didn’t know that document existed,” or “I didn’t know we had a process for tool for that.” Transparency is created through alignment activities liking mapping, just enough documentation, and consistent communication. We have a Slack community and we share our process thoroughly, calling out when we are in a BETA stage with a new process and are uncertain about what the results will be. This creates a sense of shared endeavor. Treat people like responsible, contributing adults, and they help you create a better business.

With tooling, less is always more

Tooling, when done correctly, enables Self-Service and Transparency, but it can quickly get too heavy and garbled, and start disabling those two aims. I tend to start with a really well-organized drive system. My motto is that every document should have a home. I use a numbering system that the most important folders are on top. Generally, Drives seem to fall over when the team reaches 5+ people, but this time affords you the ability to understand the most important documents that everyone needs to access and update regularly. With this hierarchy in mind, you can invest in a tool like Notion, or a well structured Trello board to help surface both knowledge and process.

Map, re-map and then map some more

As mentioned above, I’ve found the best way to create transparency and alignment about process and operations is to map out how things work with the full-team, as it grows. Whenever a new team member joined, it was a great opportunity to do a service blueprint mapping exercise. The benefit of this is that the new team member gets an overview of the current process, and the whole team gets a view on where there are current friction and brainstorms about how to make improvements. (Learn about maps at Mapping for Product.)

Cultivate shared responsibility

Regularly mapping out processes and operations and surfacing areas of friction is an excellent way of letting your team know that they don’t have to deal with a crappy situation. At the end of a mapping session, you should have a good list of action items and they should be assigned to team members. More generally, you want to cultivate an attitude that process is never “done” and that how operations work at any given moment is only ever a test.

Reflect, reflect, reflect

I always recall an old cartoon I saw many years ago. In it, a man is trying to cut down a tree with a butter knife, and a man behind him is trying to hand him a chainsaw. The caption reads, “Stop interrupting me! Can’t you see I’m trying to cut down this tree?!” This is very like teams that are struggling with a bad process. PMs on these teams need to stop trying to cut down the tree and take the time to pick up the chainsaw. If your team is struggling, institute weekly retros immediately.

**********

I know that in a year a lot of processes that I will have instituted will have changed due to necessity. I’m not afraid of killing my darlings, and I hope that the team will do what’s right for the business on every new day. What I hope will stay behind me is the culture of constantly questioning if anything can be made better and more efficient. Luckily for me, my days at Mind the Product are not over. I will be working on different discovery projects for new opportunities that the org wants to get off the ground, additionally, I’ll be coaching on practice and helping MTP stay a product-led organization. I will also be getting back to my passion for working on developing software and with product teams. I’m so excited to understand where the practice has moved, to refresh and reapply my skills and processes to new problems and challenges.