back
Designing Good Processes
26.05.2021
The quality of the processes your company runs on will dictate how it feels to get the work done. And the difference between a good one and a bad one is significant. Good process makes the work more satisfying. Bad process bogs everyone done. And, really good processes can even establish norms that eliminate the need for process.
When you’re considering rolling out a process, here are some things to consider.
1. The best process is no process.
In an ideal state, it all just works. Inertia and osmosis do the trick. Everything flows. When and where that’s happening, get out of the way.
Here’s what Charlie Munger has to say on the topic (in his 2007 commencement speech at USC Law).
“The highest reach of civilization is a seamless system of trust among all parties concerned…The last idea that I want to give you as you go out into a profession that frequently puts a lot of procedure and a lot of precautions and a lot of mumbo jumbo into what it does, this is not the highest form which civilization can reach. The highest form which civilization can reach is a seamless web of deserved trust. Not much procedure, just totally reliable people correctly trusting one another. That’s the way an operating room works at the Mayo Clinic. If a bunch of lawyers were to introduce a lot of process, the patients would all die. So never forget when you’re a lawyer that you may be rewarded for selling this stuff but you don’t have to buy it. In your own life what you want is a seamless web of deserved trust. And if your proposed marriage contract has 47 pages, my suggestion is do not enter.”
2. Process is about controlling variance.
We treat process as a dirty word because when we think of process, our instinct is to think about the variance-reducing ones; reporting requirements, reviews of work, and performance reviews. But, process can also be variance-maximizing; carving out company time for a hackathon, having the “new product development” org operate on a different cadence than the longstanding ones, or hosting a brainstorm or product strategy session at the outset of work. Aim to have a thoughtful blend of these across your organization.
When designing process for an organization:
- incorporate variance-minimizing processes where stability, predictability, and consistency is required or valued (ex- security, product quality, HR matters)
- incorporate variance-maximizing processes where creativity, big-picture thinking, and innovative approaches are required or valued (ex- early phases of product development or design, longterm strategy, brand marketing campaign)
3. Motion <> Progress
One trap of processes is that they can make it easy to confuse motion for progress. When you’re writing the QBR or sending the weekly metrics update or preparing for All Hands, it *feels* like work is getting done because people are, in fact, doing work. But, a process that doesn’t drive, with focus and efficiency, towards an outcome is a bad process.
Note: Company planning is often a good time to take a broad view at the processes the organization is running on, and determine whether any updates are required.
4. Beware of neophilia
Organizations that are built on innovation are predisposed to orient towards what’s new and novel. But, the complexity that results from a piling one process on top of another without any gardening is the quickest way to slow you down. This is particularly dangerous for startups where speed of execution is often its greatest (and sometimes its only) advantage.
Have the discipline to remove process as often as you introduce it. Take as much care in extracting it as you do when you inject it. Celebrate what unships as much as what ships.
It might kill you if you don’t.
5. Processes require owners, too.
A process needs an owner just as much as any other company workstream needs one. When a process gets implemented, give it an owner to ensure that the desired outcomes are articulated (even if a bit squishy) and that the health of the process is not only upheld but also re-evaluated regularly. The process owner is also responsible for identifying when an evolution or removal of the process might be necessary.
This responsibility often defaults to the manager’s job, but it does not have to. In fact, it is often more efficient (and a boon to org-wide trust and connection) when a process is owned by people across the organization, not just managers.
6. Design for fault-tolerance.
The goal should not be no breaks or slips ever, ever, ever. That’s how you choke your organization and everyone on it. Think more bumpers and cushions.
In Boz’s words (from his iconic post, Antifragile):
“In engineering we often face a choice between trying to eliminate failures or making our systems handle them more gracefully. Both approaches are important but in my experience fault tolerance is the more valuable. The reason is simple: we can only eliminate failures we can imagine while fault tolerance adds some resilience to failures we could not imagine.”
7. Rubbish in. Rubbish out.
If the raw data is bad, the analysis of it won’t be useful. In fact, it might be worse than useless because it could point you in the wrong direction entirely. A good way to create process that only slow you down or steers you wrong, is to implement them without thought and care.
If the goal of All Hands is to educate and dazzle your team with the great work going on all around the organization, but the presentations always fall flat, you’re wasting time. If the goal of the Quarterly Business Review is to evaluate the progress of a workstream, but the project owner doesn’t reflect on contributions to the right metrics, you’re wasting time. If the goal of the meeting is a key decision, but the attendees aren’t prepared to make it, you’re wasting time.
Be diligent about the rules of engagement. Be crisp about what goes in and what must come out.
8. Soul where you can
When you can, give your process a bit of soul. Do the things only your team, with your mission, and your users, and your tastes, would do. Give them special names. Create special artifacts out of them. Make their participants feel like they’re part of something special.
Don’t just call company-wide planning, planning. Call it OP-1 and OP-2 for Operating Plan (Amazon) or VTFM for Vision, Theme, Focus, Measure (Atlassian) or OKRs for Objectives and Key Results (Intel, popularized by Google) or URPs for User Release Plan (Stripe). It may not sound like these naming conventions would inspire soul with their corporate-leaning terminology, but having your own special way of doing things does.