Principles for building effective processes.
A better process for building systems and getting people on board.
The word Process has a lot of connotations, most of them bad. When I want to talk about process, usually it evokes bad memories for coworkers who spent time at dysfunctional companies that had endless hoops to jump through and layers of management that had to sign off on every small thing. Or some people think of process as bureaucracy, where you have to go in person to the DMV with a form you filled out online, only to be given another form and a second line, only to find out you didn’t need to be there in the first place. Or maybe it evokes the ineffable ‘creative process’ which is so ethereal and undefined that it might involve meditation and doing headstands to get the juices flowing.
All these interpretations of process are real. Which make it understandable when some people might not want to build a process driven business. There is a perception that if you’re a small company or fast growing, process will prevent progress. In reality, process exists whether you like it or not. Process is just the series of steps that it takes to get something done. Your ‘process’ might involve putting a post-it note on your monitor to remind you to take out the trash—but it’s still a step towards your end goal.
Today I want to talk about how to design effective processes and hopefully give some of the skeptics hope that there might be a purpose to building good processes. I have built a lot of great processes in my career and implemented some terrible ones (which have taught me a lot about how not to do it). Here are a few principles to keep in mind when designing processes for your company.
Start with the end in mind.
There’s nothing that people hate more than process for process’ sake. If something is already working well for the size and scale that you’re at, don’t implement a new process just to be more organized or because you’re ‘supposed to’. There should be a purpose and a direction to the decision to implement a new process. If your hiring process has been successfully bringing in the right people to the company, but has been loose and unstructured, don’t change it! Or, if you have to change it for some growth or compliance reason, start by thinking about your goal. If your improvised process is already working, figure out why and keep those parts of the process.
Process building has to be for a purpose, and it has to keep the goal in mind. Sharing with the team the purpose of the process can go a long way towards getting buy in. When designing processes at companies, it’s easy to get wrapped up in the logistics of how each step progresses, who is responsible, and when it needs to happen. But each of those steps has to be aligned with the end goal. If we take our hiring example, the end goal is simple: find and close the right candidates for open roles efficiently. It’s tempting to design for other secondary goals: let’s save the hiring manager’s time or let’s automate resume screens to get to better candidates faster. Those aren’t necessarily bad ideas, but if implementing parts of the process detract from the end goal, then they’re missing the point. A process should be implemented for a specific purpose, once it accomplishes that successfully then you can always go back and streamline (see point 5: Measure the process as well as the outcome).
Function over Form.
For process-driven people, there’s a strange pleasure that comes from building a beautiful flowchart of steps, stakeholders, and timelines on a virtual canvas that brings together every piece of the puzzle in harmony. They will have each step color coded and a handy numbering system that ties a clear code to each part of the process, clarifying the owner, timeliness, and status of the project.
For people that aren’t naturally process driven, those flow charts look like vivid hallucinations that don’t come close to reflecting reality. They know what it takes to get the job done and don’t need to waste their time moving cards on a Kanban board or attending status meetings to make things happen.
The reality is, they’re both right (and wrong). Beautiful processes that have no compliance are ugly because they’re fictional. Teams that operate with zero process lose productivity to coordination costs, spending time playing telephone with one another to stay on the same page. To build a great process, don’t start with a pretty theoretical chart, start with the process that currently exists. Try to map out how the team does things today. It’s okay if it looks like Step 3: Joe asks Stephanie what she thinks on Tuesdays over coffee. Once you understand the current state of how things are or aren’t working, then you can mold the process towards something that is both realistic and functional.
Give people a reason to participate.
One of the biggest mistakes I’ve seen as companies grow is implementing cross-functional processes that only benefit half the stakeholders. All too often, executives see an opportunity like the Customer Support team should be aggregating and sorting customer complains to deliver a handy report to Product to help them adjust. Wouldn’t that be great?! You know who doesn’t think that’s great? The Customer Support team. They’ve just been asked to create and implement a new process in service of another team. It’s a new layer of work that doesn’t help them be better at their jobs and isn’t going to impact their critical KPIs. Three months later, leadership is frustrated and confused as to why these reports keep getting delayed and deprioritized.
When designing processes for teams, make sure that everyone who is participating understands their role, and ideally gives them a clear incentive to participate. This doesn’t have to be big, but it can go a long way towards getting traction with new processes. Maybe the Product team in return will write up new user guides based on customer feedback to try and limit the number of complaint emails the Customer Support team gets. Adding a small piece to the process that ensures that everyone buying into the process gets something out of it can be a huge motivator. Sure, everyone at the company is on the same team and wants the company to succeed, but processes that aren’t helping someone’s core responsibilities are always the first tasks to get dropped. Make processes relevant and useful to those involved.
Design for the next step, not for scale.
Early in my career, I ran a Customer Support (CS) team at one of the companies I was at where we used a single shared email inbox for all customer communications. That works okay when you only have one person working at a time, but as we grew multiple people needed to access it at the same time, leading to a lot of confusion and problems. It was clear we needed not just a better CS process, but also better software. The team had grown from two to nine people very quickly and I wanted to build a process that would last as long as possible, because none of us wanted to go through the pain of redefining everything again in six months.
I spent hours writing documentation on how to respond to different kinds of customer inquiries from complaints to special requests to compliments. And then I implemented Zendesk, a best-in-class, enterprise, customer support platform made by a massive company, and built exhaustive documentation to go with it. It was amazing how many automated answers, cool workflows, and permissions systems there were—I was excited by the possibilities of scale. My team was not.
The new system was much harder to use than email and we struggled to connect the phone numbers correctly and the learning curve for the new highly sophisticated software was much larger than anticipated. A few months after I moved to another role, the company switched software again to a smaller, leaner software that was simple to use. I had made the mistake of trying to build a process that would work forever. Even at slower-growing companies, no process is likely to last forever. In a fast-paced environment, this is guaranteed not to be true. I learned I needed to build for the next step, if I had to do it again, I would’ve just implemented a process that would get us from nine to 50 team members, with the knowledge that I’d likely have to rebuild the process at that point again anyways. Build for a stepwise growth function, knowing that most processes will have to change anyways every 18-36 months at a fast-growing company.
Measure the process as well as the outcome.
This is a huge point that I think many people forget. Processes are towards an outcome, but not all processes are created equal. There can be effective but highly inefficient processes (hello, DMV). As you build your processes, set key input and process metrics as well as output metrics. How many hours is the team spending on it? What percent of the team is actually following the process? Which steps are people most likely to skip or ignore? What parts of the process are most important to getting the outcome?
The first time I designed a performance review process, I wanted to create a robust system that really evaluated people holistically. I had worked places where performance reviews were opaque and unclear, and getting people good feedback was part of the culture of the company I was then at. I built a process that involved getting upwards, downwards, and lateral feedback from peers, and then the managers synthesized all the feedback to ensure it was delivered in an anonymized but useful way. In the end, everyone loved the results, but hated the process. Everyone agreed it was nice to have written comments and feedback from a large cross section of their coworkers, but it just took too long. A manager had to go through 3-5 written evaluations, synthesize them, and share the feedback. If they had a team of five people, it was a full-time job for almost two weeks—and that was unacceptable for a new and growing company.
We pared back the process for the next cycle and still got 80% of the value out of it, and I learned a valuable lesson about measuring inputs. It’s not just about getting results, it’s about getting results efficiently, and efficiency is a critical part of building processes that work. Otherwise you just end up running your own DMV, which nobody wants to be a part of.
Takeaways
Building processes is time consuming and can be painful to implement. But if done correctly with intention and care, they can make teams far more productive, communicative, and happy. Think about a process that you love or hate at your current company: which of these principles would they embody? How can you participate in the shifting of your own processes to be more useful or efficient? And remember, this is something that will not always go right, so be prepared to make changes, and respond to feedback from the team. After all, it’s a learning process.