Engineers hate process. Or rather, engineers hate bad process, and most process they encounter is bad. It’s imposed from above without understanding the problem it’s meant to solve. It adds overhead without adding value. It treats every situation the same regardless of risk or complexity. No wonder the word “process” makes people flinch.

But the absence of process isn’t freedom, it’s chaos. Having worked in both process-light start-ups and process-heavy corporates, I’ve seen both failure modes up close. The start-up where nobody knew how deployments worked because there was no documented process. The corporate where deploying a one-line change required three approvals and a change advisory board meeting. Neither extreme serves the team.

The question isn’t whether to have process. It’s how to have the right amount of the right kind.

Evolved, Not Designed

Will Larson’s principle resonated with me the first time I read it: good process is evolved, not designed. The algorithm he suggests is straightforward:

1. Identify the problem. Not “we need a process for X” but “what specific problem are we trying to solve?” Bad process usually starts with the wrong problem statement.
2. Document approaches. Look at how other teams or organisations have solved similar problems. Don’t reinvent from scratch.
3. Test narrowly. Try the process with one team or one project before rolling it out broadly.
4. Iterate. Gather feedback, adjust, and repeat. Process that isn’t regularly reviewed becomes stale.

The key insight is that process should emerge from observed problems, not from theoretical concerns. “We should have a code review process” is a theoretical concern. “We shipped a bug last week because nobody reviewed the change” is an observed problem. The first leads to bureaucracy. The second leads to a targeted solution.

Proportional to Risk

Fournier makes a point about process that I think is underappreciated: process should be proportional to risk. Complicated processes for rare, high-risk activities make sense, you want rigorous review before a database migration that could take down production. Simple processes for frequent, low-risk activities also make sense, you don’t need a change advisory board for a CSS fix.

The mistake is applying the same level of process to everything. When every change requires the same approval chain regardless of risk, two things happen: high-risk changes don’t get enough scrutiny because the process is routine, and low-risk changes get delayed unnecessarily because the process is overhead.

I’ve found it useful to think about process in tiers. Tier one: changes that could cause significant damage get rigorous review. Tier two: changes with moderate risk get standard review. Tier three: low-risk changes get lightweight review or self-service deployment. The boundaries between tiers should be clear and documented, and the team should be empowered to classify their own changes.

Process as Infrastructure

The best teams I’ve worked with treat process as infrastructure, something that enables speed rather than constraining it. A good CI/CD pipeline is process. A clear incident response runbook is process. A well-designed code review workflow is process. None of these feel like bureaucracy because they’re solving real problems and making the team faster.

The difference between process-as-infrastructure and process-as-bureaucracy is whether the people using it understand why it exists and agree that it’s valuable. If you have to enforce a process through compliance checks and management oversight, it’s probably not solving a problem the team recognises. If the team would reinvent the process themselves if you removed it, it’s infrastructure.

Ron Lichty makes the connection to agile explicitly: agile is incompatible with command-and-control. Self-organising teams need psychological safety, autonomy, and trust, and that extends to process. The team should have a voice in what processes they follow and how those processes work. Imposed process breeds resentment. Co-created process breeds ownership.

When to Add and When to Remove

Adding process is easy. Removing it is hard. Every process has a constituency, someone who created it, someone who benefits from it, someone who’s built their workflow around it. Removing process requires the same rigour as adding it: identify what problem it was solving, determine whether that problem still exists, and assess whether the cost of the process exceeds its benefit.

I make it a practice to review processes at least annually and ask: if we didn’t have this, would we create it today? If the answer is no, it should go. If the answer is “yes, but differently,” it should be updated. If the answer is “yes, exactly as it is,” it stays.

Seth Dobbs makes a related point: don’t elevate means beyond ends. Technologies, methodologies, and processes are tools, not goals. Microservices aren’t a goal. Agile isn’t a goal. Code review isn’t a goal. They’re means to ends, reliability, speed, quality, and if they’re not serving those ends, they should be questioned.

The Goldilocks Zone

The right amount of process is the minimum needed to solve the problems you actually have. Not the problems you might have someday. Not the problems another company has. The problems your team, in your context, is experiencing right now.

That amount will change as your team grows. A five-person start-up needs almost no formal process, communication happens naturally, everyone knows what everyone else is doing, and decisions can be made in a hallway conversation. A fifty-person engineering organisation needs more structure, communication doesn’t happen naturally at that scale, and decisions need to be documented and distributed.

The art is in adding process at the right time, not too early (overhead without benefit) and not too late (chaos that could have been prevented). Pay attention to the signals: repeated mistakes, duplicated effort, communication breakdowns, decisions that don’t stick. These are the problems that process should solve.

And when you add process, add the lightest version that addresses the problem. You can always add more later. Removing process that’s already entrenched is much harder than not adding it in the first place.