Building Processes That Don't Stifle Opportunity
What they are, why they're important, and how to make sure they serve the end goal
Happy Sunday, Friends đ
This weekâs newsletter is all about processes. Itâs inspired by some of the content from the HBS Disruptive Strategy course, but itâs also top of mind as Iâm thinking through processes within the Support org at Ness.
One of the exciting aspects of working at an early startup is working with a blank slate. There are no historical norms of âHow we do XYZ.â You get to build from the ground up! So, letâs talk about that process and address what they do, why theyâre important, and some ideas on how to build âem to make sure they serve the end goal.
Hope you have an amazing week!
Jeremey
Thanks for being a part of this newsletter. Every Sunday evening, I send a note about solving problems and wowing customers.
Please say hi (reply here or at jeremeylduvall@gmail.com). Iâd love to hear from you.
Processes as an Under-Valued Asset
What Are Your Processes?
To set some context, letâs pretend youâre leading a Support team at Superordinary Co selling an established SaaS offering with tens of thousands of customers. Each month, you compile a customer feedback report surfacing trends youâre seeing in the queue, details you are hearing from customers, and notes from cancellation surveys.
Whether you explicitly state it or not, thatâs a process. Itâs a set of steps meant to take an input (data) and generate an output (summary).
Processes take an input and turn it into a specific output reliably.
In the best cases, processes are deliberately set. Someone is faced with a specific problem for the first time. They generate a series of steps that takes inputs and creates an output. They then compare their output to the ideal scenario and tweak the process moving forward.
This is when processes become insanely valuable. Theyâre tailored to a specific problem, tweaked to generate the right outcome, documented for everyone to see, and scaled up as the organization grows.
Hereâs the kicker - often times, processes are created ad hoc, and they can become invisible and antiquated.
In these scenarios, someone is again faced with a specific problem for the first time. They again generate a series of steps that solves their particular issue; maybe they even document some details in an internal knowledge base. But, they never stop to consider if thereâs a better way to achieve a more desirable outcome.
That second scenario is how you end up responding to questions of âWhy do we do XYZ like this?â with âThatâs just how we do it.â
Now, letâs talk about why these ad hoc processes can be dangerous.
When Processes Become Dangerous
We talked about one reason above. These processes can become largely invisible. Everyone takes it for granted that we do things like âthis.â New hires stop asking questions because the processes become part of the culture.
Processes can also become rigid over time, especially as youâre scaling a team. By nature, processes arenât meant to change much. Again, theyâre meant to take a specific input and generate a certain output reliably. As you teach more people a specific process, the outputs become more reliable (good!), but it becomes much harder to adapt that process down the road (potentially bad).
Finally, if youâre not careful, processes can constrain progress. Hereâs a line from the HBS course:
Many problems in innovation occur when we ask a process to do a task it wasn't meant to do.
Letâs go back to our Superordinary Co example. Assume you built your feedback process in Support to deliver reports every month. The underlying purpose of this process was to keep development teams up-to-speed with customer feedback.
Now, letâs suppose your company spins off a new fledgling product. This product only has a hundred customers, but it seems promising. The team working on this new product asks if you can generate a specific feedback report each month specifically for them. Sure! You can just use the same process youâve been using, right? đ
The problem is that youâre relying on a process that was meant to solve an entirely different problem. You might deliver a summary every month, but it wonât be nearly as useful for the new product team.
Where Do We Go From Here?
How do we build bulletproof processes that are highly visible, flexible when necessary, and tailored towards the unique situation? A few ideas:
Pencil it in. My favorite of our core values at Ness is this concept of âpencil it in.â Donât get stuck when presented with a problem. Try something, but be flexible and adapt based on the outcome. The same thinking can be applied to building processes. If the process is no longer serving the end goal, itâs time to change.
Create an expectation. In your onboarding documentation, make it clear that new hires are expected to ask questions when something is unclear and make at least one change that leaves the training and documentation better for the next person. Setting this expectation early creates a persisting feeling of ownership later on.
Make it visible. Processes become invisible when theyâre not documented anywhere explicitly. Theyâre effectively a form of âghost knowledgeâ passed from person to person. Write them down to ensure everyone has the same level of info and to encourage scrutiny. GitLabâs OKR page is such a stunning example here.
Refine and reflect. Whenever you follow a process, it pays to take a moment and reflect on the outcome. Should tweaks be made? Is this process still serving the intended purpose? This isnât necessary every single time, but itâs helpful, especially for long-standing processes that havenât been updated in months or were created when a company was in a much different stage.
Donât copy/paste. After I left Automattic and arrived at Zapier, I felt the urge to copy/paste many of the things I was doing on my previous team. Iâm not alone. Itâs incredibly tempting to assume that what worked over here will work similarly over there. When presented with a new problem, donât just assume you can copy/paste with some minor tweaks. Treat the problem as a new one. Draw inspiration, but donât just lift and drop.
Over to You
What did I miss? Thoughts encouraged!