Minimum Viable Process

Apply now to join Glue Club, the home base where the strongest startup leaders in the world come together to find sanity, opportunity, and growth amidst the chaos of building a company. I pour all my mentorship and coaching energy in to Glue Club, in case you’re looking for something more than a blog post… Head over here to learn more.

---

I’ve been talking to a few people lately about Process. As you start to grow the number of employees in a startup, adding process can be one of the scariest things — how much is too much? how much is not enough? can process kill your culture? can it kill your speed? how do you know when to take it away?

First, since we all know I hate Black Hole Words, let’s define “process”. What I mean is creating a system for doing something or getting things done that generally makes things either more efficient, more transparent, or more fair. Process can show up in the form of recurring meetings, forms, memos, months-long experiences that everyone does together (performance reviews, planning processes), etc.

In my opinion, adding process is necessary and healthy, AND I think being wary of process is smart. I have been amazed to find that it is completely possible to make a 50-person company feel bureaucratic. It turns out that speed and agility have much more to do with how you do things than what size you are. I’ve seen 5,000-person companies that remained relatively agile and 300-person companies that felt like the federal government.

Here are a couple of examples of necessary and healthy places where you need process when you’re growing past 50 employees: 

• How do we make decisions and who gets to decide what?

• How do people find out what we’re doing as a company and why?

• How do we decide what to invest our time in?

• How do we decide when someone should be paid more or take on a different role?

There are so many more, but hopefully, these examples make it clear that you can’t run a company past a certain size without process. It is a fundamental part of how you organize larger groups of people to efficiently solve problems.

Despite writing this post, I am actually a low-process person. I generally believe that you should only add process when you or a significant number of people on your team are feeling pain. I definitely do not believe in process for the sake of process; I believe in intentional design. “If it ain’t broke, don’t fix it”-type philosophy. And when you find pain, I am a huge believer in implementing the Minimum Viable Process. What is the smallest, most lightweight thing you can try and see if it fixes the problem? I strongly believe that in startups, Minimum Viable Process is good process.

So what is Minimum Viable Process? How do you know when you need a system versus just letting things happen organically?

Minimum Viable Process starts with first principles: Good process is not just copied and pasted from another company. It starts and ends by building what is right for YOUR company. Other people’s processes usually go too far or not far enough. Bad process can absolutely kill speed and agility. First principles imply that you start with questions like “what problem are we trying to solve?” and keep asking questions until you have a clear, simple, and important objective for what you are designing. If you export the process that works at a 10,000+ employee company and do not modify or adjust it at all for a 50+ person company, it is almost always a mistake (see my post about why I hate OKRs…). It is GREAT to take learnings from bigger companies — things that worked at scale, things that helped with scale, things that break at scale — but small companies usually need 1/10th or less of the process of big ones. When you are deciding to add process, you HAVE to start with a clear understanding of the problem you are trying to solve and why that problem is important. Without those first principles, you are very likely to add bureaucracy or waste a lot of people’s time. 

Minimum Viable Process solves real pain: Process is only useful if it solves a real problem. One of the mistakes that I see operators make A LOT is implementing things and then becoming frustrated with other folks either not buying into the process or not following the process. Usually, this happens when there isn’t enough pain. If people don’t feel pain, they won’t follow a process, particularly in startups. I implemented the first real performance management system at Facebook and we had 500 employees. Prior to that process, trying to get promoted or get a raise or find out how you were doing was like the wild west — it mattered who your manager was and who you knew, so nothing felt systematic or fair. It is literally the only time I have seen people be SO GRATEFUL for a performance management process. There was so much pain from feeling stuck or feeling like things were unfair that people were actually happy to have to deal with writing reviews and sitting through calibrations. The only process that makes sense to implement is process that solves real, clear problems that are causing a relatively large number of people pain.

Minimum Viable Process process is iterative: Your company is growing and changing, and your processes need to do that too. If you have an important problem, then try implementing something to solve it. Learn from the first couple of times you go through the process, and then adapt the process based on feedback. Generally speaking, you should re-evaluate major processes — goal setting, business reviews, etc. — every 6-12 months. Usually, your company has evolved enough that something needs to change. 

At Lambda School, we were constantly iterating on our business review and decision-making processes. It is a very complicated business so it took a lot of work and iteration to find systems that worked for us to ensure that as leaders, we were staying up to date on what was going on in different parts of the business. It was also a delicate balance of ensuring we were looking at the data on the right cadence but not having our team leaders spend all their time creating updates for us versus working on the business. We adjusted the timing of the reviews, the length of the meetings, the format (have people present and do Q&A live, reviews looms and just do Q&A live, etc), adding extra deep dive meetings, taking them away, etc. This is an important dance in any company and with any process: What is the right amount of process? What is the right cadence? How do we solve the pain but not slow things down too much?

Minimum Viable Process means removing things as much as adding them: Building good process does not always mean adding something. It often means taking something away. Part of the iteration is outgrowing process or trying something and finding out it doesn’t work.

As an example, one of the very common patterns you see in early-stage startups is that when teams are small they’ll have a whole-team weekly stand-up once a week. This is an easy way to find out what everyone is working on and ensure it aligns with the highest priorities, and it also creates connection between folks on the team. It is part communication, part alignment, and part bonding. I am always amazed when I find 50-100 person companies still doing the weekly stand-up, but it happens all the time. This is a process that needs to evolve and a meeting that needs to be removed. It is super effective for teams of 5-10 and a huge waste of time — could easily be an email or Slack updates or many other things — for teams that are 30+.

Here are some examples of Minimum Viable Process:

• Having trouble feeling disconnected from what people on the team are working on? Try implementing weekly individual updates in Slack where people list the top 3 things they spent time on in the last week. 

• Do we need a tool to manage our goal-setting process? DEFINITELY NOT. Your goal-setting process is going to change 35 times in the first 5 years you do it — spreadsheets, docs, and slides are perfect for iterative design. 

• Don’t know why we still have the meeting that has 35 people in it and it feels slow and ineffective? Cancel it and see what breaks. 

• Can’t remember what all the letters mean in your decision-making framework (RAPID or RACI or whatever)? Stop using it and just focus on the most important part which is the “R” – who is responsible for the decision? Let the R person sort the rest of the letters out. 

Like I said, always start with the smallest, simplest change, see how it goes, and then iterate from there. And a good rule of thumb: If no one remembers why you have the process in the first place (this includes meetings), just get rid of it and see what breaks!

Final point: it’s ok to let things be shitty. 

As operators or perfectionists, startup life can be challenging. We see things that are broken every day and we feel like it’s our job to fix them. But living the startup life is all about prioritizing mess. Which mess matters the most? Which one do you have to clean up first? And, importantly, what mess are you just going to leave on the floor and consciously walk away? 

I have no idea who gave me the phrase “It’s ok to let things be shitty” but ever since it has given me a sense of freedom to prioritize what is most important. It helped me realize that I cannot control everything and that it is not my job to make everything smooth and perfect. As an operator – someone who tries to build well-run companies – it is my job to see around corners and to prioritize. It is not my job to solve every problem; it’s my job to pick the problems to solve. Prioritizing means deciding that some things will be a mess. So, repeat to yourself: it’s ok to let things be shitty sometimes. 

Process is essential once you decide what problems to solve, but every problem does not deserve to be solved, and adding the wrong process or too much process can create as many problems as it solves.