Process is one of those topics that reliably creates tension in growing engineering organizations. Too little of it and everything feels chaotic. Too much of it and nothing moves. Most teams I work with aren’t confused about whether process matters. They’re struggling with when to add it, how much to add, and how to tell when it’s gone too far.
Process is almost always introduced as a solution to a problem. What’s less obvious is that process also creates its own problems. Every new rule, gate, or ceremony adds coordination overhead. Sometimes that overhead is worth it. Sometimes it quietly becomes the thing slowing you down.
The hard part isn’t deciding whether you need a new process. It’s understanding what problem you’re actually trying to solve.
Why Process Exists (and Why It Backfires)
At its core, process exists to solve coordination problems.
When there’s too little process, you see the same patterns repeat:
- Teams duplicate work.
- Ownership is unclear.
- Quality varies wildly.
- Decisions get revisited because there’s no shared understanding.
- Production systems break in ways no one anticipated.
In small teams, this can be survivable. People talk. They improvise. They find and fix problems quickly. But as the organization grows, informal coordination stops scaling. You can’t rely on hallway conversations once dozens of teams are working in parallel.
That’s where process starts to help.
The failure mode comes when a process is copied wholesale from larger organizations or added reflexively in response to a single incident. What speeds up a 10,000-person company will slow a 500-person company to a crawl, and it can completely stall a 100-person startup.
A process that doesn’t match your size, culture, or problems doesn’t just fail to help; it actually harms. It actively makes things worse.
The Real Question Leaders Should Ask
The question isn’t “Do we need more process?”
The real question is: What coordination problem are we trying to solve, and what is the lightest-weight way to solve it?
Leaders tend to get this wrong in two predictable ways.
Some avoid adding process entirely, trying to preserve a sense of scrappiness long after the organization has outgrown it. Things that used to work stop working, but no one wants to acknowledge that the context has changed.
Others swing too far in the opposite direction, importing big-company processes because “that’s how it’s done at scale.” The result is unnecessary gates, approvals, and bottlenecks that strip teams of autonomy without actually improving outcomes.
Both paths lead to frustration, just for different reasons.
Process Is a Choice About Autonomy
Every process decision is a decision about autonomy.
Good processes increase autonomy by clarifying boundaries, reducing surprises, and preventing rework. Bad processes reduce autonomy by adding gatekeepers, slowing decision-making, and centralizing control.
A simple test helps here: Does this process let teams move faster, or does it make them wait on someone else?
Code review is a good example. Lightweight reviews prevent production issues and enable teams to move faster with confidence. Mandatory review meetings that require everyone to wait for a calendar slot are a very different thing. Same intent. Very different outcome.
A Simple Process Evolution Cycle
Over time, I’ve found it helpful to think about process in three phases.
First: chaos signals.
You don’t add process because it feels right. You add it because you’re seeing repeated friction—across teams, not just in one place. Rework, unclear ownership, inconsistent quality, inter-team conflict, and recurring bottlenecks are all signals worth paying attention to.
Be careful here. A disagreement between two people is not a process problem. Solving a people issue with an organization-wide process is one of the fastest ways to create unnecessary drag. Similarly, repeated friction between the same two teams may be more indicative of an organizational structure issue rather than a lack of process.
Second: deliberate addition.
Add the minimum process required to solve the specific coordination problem you’ve identified. Design it to enable autonomy, not replace it. And treat it as an experiment, not a permanent fixture.
Every bit of process takes away some autonomy by design. The goal is to take away as little as possible while still solving the problem.
Feel free to learn from other companies’ processes, but ensure the components you implement are scaled to your organization’s size and the problem you are trying to address, and aligned with your culture.
Third: monitoring and pruning.
Process ages. What helped at 50 people often slows you down at 200. What worked at 200 creates friction at 500.
If you aren’t actively removing processes, you’re accumulating them. Regular retrospectives, not just within teams, but across projects and the organization, are one of the best ways to surface what processes are no longer pulling their weight.
If a process no longer serves you, remove it. Don’t keep it out of habit.
One Practical Example
One lightweight process I’ve used successfully in multiple organizations addresses a common bottleneck: cross-team changes.
Team A is working on a feature or fix that requires a change in code that Team B is responsible for. Instead of Team A filing a ticket and waiting weeks for Team B to prioritize and make the change, Team A makes the change itself. Team A notifies Team B of their intent, in case there are important gotchas they should be aware of. Team A submits a pull request, and Team B reviews it. Once merged, ownership of the new code transfers to Team B.
The result is fewer queues, faster delivery, and greater transparency in accountability, with very little added overhead. Same coordination problem. A very different solution from a backlog and a waiting line. This straightforward process helped one of my organizations avoid a new heavyweight quarterly planning process (so many meetings!), which was proposed to address increasing cross-team dependencies
How Process Goes Wrong
Most process failures fall into a few buckets:
- Copying another company’s process wholesale.
- Using process to compensate for poor communication or a lack of trust.
- Adding controls to feel safer after an incident, without considering the cost.
- Creating a process for the whole organization to address friction between two individuals or teams,
- Never revisiting what you’ve added.
In the incident example, leaders sometimes add new processes in response to unexpected fragility, which leaves them fearful about what else they do not know. Process as fear-driven control kills speed and erodes trust. Guardrails like automation, testing, and monitoring usually achieve better outcomes with less friction.
Bringing People Along
People tolerate a new process when they understand the problem it solves.
Be explicit about the why. Involve teams in the design. Ask for the lightest-weight solution. And commit publicly to revisiting it. Most teams are willing to try something if they know they won’t keep living with it if it doesn’t work.
The fastest way to create resistance is to impose a decree from above without context.
The Point Isn’t Less Process
Early in my career, I thought that process was the enemy of speed. Experience taught me something more nuanced.
Process isn’t good or bad. It’s a tool. And like any tool, it has to fit the problem.
Clear ownership boundaries can increase freedom. Lightweight coordination can make teams faster. Thoughtful pruning can restore momentum that’s been quietly lost.
The goal isn’t less process. The goal is fit-for-purpose processes, deliberately added, designed to protect autonomy, and removed when they stop helping.
That’s how you scale without losing what made your team effective in the first place.
To hear an extended discussion of this topic, please listen to my podcast episode: The Right Amount of Process: Finding the Balance Between Chaos and Bureaucracy
Originally published in my newsletter at https://kevingoldsmith.substack.com/p/process-is-a-tool-not-a-virtue