Good process is evolved, not designed.

Time management is an ongoing challenge for managers: so much to do, so little time. The early-career manager, learning to balance being pulled in so many directions, is a sympathetic figure. Empathy for senior managers, dashing between back-to-back meetings and five minutes late to each, can be harder to summon.

While there can be a certain heady rush to being relentlessly busy, I’m convinced that far more senior managers are overwhelmed with work than want to be, and what’s a bit scary to contemplate is that they’re overwhelmed by work generated from processes that they themselves were heavily involved in designing.

Process design is a foundational skill for well-run organizations, yet is often treated as an afterthought. Individual processes get a great deal of attention, but we rarely speak about how to create process effectively. The good news is that success here doesn’t require innovation or novelty: adopt a structured approach and you’ll quickly become an effective process designer.

How to evolve process

When we talk about creating a process, we almost always say that we designed a process. Design is a great word, because it implies the kind of careful thoughtfulness that great process does indeed possess. However, it’s also a misleading word, because great process never emerges from the Feynman algorithm (“write down the problem, think very hard, write down the solution”), but instead derives from guided evolution.

The algorithm that I’ve found effective is:

1. Identify problem statement. There is a problem that either you have identified or folks you support have raised. Refine this into a problem statement that captures the problem you want to solve (“we want everyone to have the opportunity to apply to lead special projects”) along with the constraints you want to respect while doing so (“we want to retain our ability to select project leads quickly”).
2. Look for alternatives. Process is so expensive to maintain that we want to start out spending some time trying to avoid creating a new process. It’s quite possible that the problem statement is really feedback to improve your existing processes, not evidence that you need a new policy. If you can identify an existing process to improve instead of creating a new process, generally prefer to do so.
3. ̉Document approaches. It’s easy to simply apply the approaches you’re most familiar with, so easy that it’s the most prevalent failure mode of leaders who join a new company. Take some time to reach out to folks at other companies and learn how they approach the same problem.
4. Consider cohorts. One aspect that’s essential and easy to overlook is to ensure you test with different cohorts of folks who will have different perspectives and needs: remotes, folks with significant family obligations, early-career folks, long-tenured folks, folks in a variety of job functions, and so on.
5. Test approach. Identify a reasonable approach, not necessarily an amazing one, and give it a limited test run. The best test run is cheap and narrow, optimizing for rapid feedback over a perfect approach. Trialing process within a small team is surprisingly effective, because it allows you to learn if a process works before you start advocating for wide adoption. Companies have limited bandwidth to adopt and maintain process, so it’s helpful to weed out ineffective processes early. Small rollouts make it cheap to iterate and improve.
6. Refine problem statement. When an approach ends up not working well, I find that it’s almost always because your problem statement is missing a constraint. For example, it may be that some teams need to select project leads every day, so a multi-day process is too much overhead for them. In that case, you might want to extend the problem statement to only cover assigning project leads for scarce opportunities, not for all opportunities. Incorporating the newly discovered constraints into your problem statement is the most direct path to effective process.
7. Iterate approach. With your updated problem statement, adapt or replace your approach with another reasonable idea. Then return to testing it! It’s generally the case that once you’ve identified the proper problem statement, the approach will be almost disappointingly simple. That’s a good thing.
8. Practice. Once you find an approach that works reasonably well, folks often want to start evaluating it immediately, but that’s often ineffective. The first time an organization uses a new process almost never goes super well, it takes time to learn new things, particularly when you need hundreds of folks to change at the same time. Run practice sessions, publicly describe success stories, and ensure everyone builds experience using it.
9. Evaluate. Now that you’ve practiced the process to an extent where folks are comfortable running it, it’s time to evaluate whether it’s effective. If ̉it’s not working out, go back to refining your problem statement. Evolving process is time intensive, and sometimes you just don’t have enough time to do it well. In those cases, it’s a success to discard a process that doesn’t work. Don’t hold on to bad process that you don’t have time to fix, let it fly free. Some of my best process work has been canceling bad processes, and sometimes without providing any replacement at all.

So now we have an algorithm for designing process, but honestly you already knew this was the right way to design process. That’s the most interesting discovery when chatting with folks about how to design process: they already know how.

Why, in that case, do we keep making ineffective processes?

Why good people make bad process

Every bad process I’ve encountered had one of these three problems:

1. Process is unmaintained. It was essential to have a process to address a given problem, and someone stepped up to design it. They designed it, handed it off for enforcement, often implicitly, and it stagnated or fell into disuse. This is especially common in growing companies, where processes like calibration decay quickly without ongoing adaptation.
2. Problem statement is wrong. A malformed problem statement is treated as a constant, which leads to solving the wrong problem (or solving no problem at all). This leads to inert processes for scenarios that don’t exist.
3. Problem statement omits key constraint. Often there are unstated constraints in a problem statement which lead to seemingly bizarre approaches until you realize there is a missing constraint. Typically these are the result of value conflicts between groups that some party is heavily incentivized not to acknowledge. A common example in Silicon Valley companies is wanting to manage operations teams with a “churn and burn” mentality, but also wanting to be a company that inspire loyalty and high retention. This can lead to statements emphasizing ongoing education and career mobility, coupled with processes that hinder most such development.

Designing great process requires honest alignment on goals, methodical approach, and a great deal of thoughtful attention. Without all three, you’ll rarely enact great process, and in the rare case where you do, it’ll decay quickly across context changes.

That’s the bad news, but the good news is that great process builds momentum for more great process. The time you spend evolving it will come back to you; I increasingly suspect evolving good process is the single highest leverage act of management.