Writing
When Process Helps and When It Becomes the Problem
Process isn’t good or bad on its own. The useful questions are when to add it, what problem it solves, whether it builds trust, and when it has become overhead nobody needs.
By Ka Lun Chan · Engineering leadership · Leadership / Delivery / Engineering judgment
When should a company introduce process?
With five engineers, most process lives in one chat channel. Everyone knows who is changing the billing code, who is on call, and who to ask when a deploy looks strange. Add twenty-five people, a second time zone and a customer contract with security terms, and the same informal habits start dropping things.
I’ve worked on both sides of that line: early startups, the global team of more than 30 engineers, VoIP specialists and designers at the company I co-founded, and government systems where some controls are written into the requirements. The question of when to add process has come up in every one of them.
Companies should introduce process when a specific, recurring problem costs more than the process would: unclear ownership, missed handoffs, unpredictable delivery, repeated quality failures, or a security or regulatory requirement. Growth makes those problems more likely, but headcount on its own is not a reason. The best process also builds trust, and the supervision it adds should shrink as that trust is earned.
Part of the pressure is arithmetic. Every pair of people who might need to coordinate is a possible conversation, and the number of pairs grows much faster than the team. Fred Brooks used the same count in The Mythical Man-Month to explain why adding people to a late software project tends to make it later.
- 5 people10 pairs
- 30 people435 pairs
- 100 people4,950 pairs
Nobody talks to all 4,950 pairs, of course. Informal communication just stops reaching everyone, and the gaps show up as recognizable problems. Two teams each assume the other owns the payment retry job. Delivery dates swing because nobody sees dependencies until the week they block. An outage repeats because the fix lived in one person’s head. A customer asks for evidence that every production change was reviewed, and nobody can produce it.
Each of those has a different cause and needs a different fix. “We’re bigger now” doesn’t say which one you have, so it can’t tell you which process would help.
Sometimes process is how trust gets built
Engineers often read new process as a message that leadership doesn’t trust them. Sometimes that reading is correct. Just as often, it’s how trust starts, especially between people who don’t work together every day.
Between engineering and leadership
An executive who hears three weeks early that a date is slipping, along with options, trusts the next estimate more. One who hears the day before stops trusting estimates and starts asking for daily updates. A short weekly written update with risks at the top is process. It also heads off a lot of heavier process later.
Between engineering teams
When the team that owns an orders service publishes a versioned contract and a named owner, the teams that depend on it can plan without a meeting. Without that, every change needs a conversation, and people start keeping defensive copies of data they don’t trust. I’ve written about why clear API boundaries matter for the systems. They matter for the people just as much.
Between individuals
A new engineer doesn’t know yet whether a teammate handles edge cases or tests the failure path. Code review, shared standards and clear expectations give them a reason to trust the code before they know the person. Good review is also how people learn the team’s judgment, which is why I think code review starts with the plan, well before the pull request.
Personal trust and institutional trust
Personal trust comes from knowing someone’s track record. Institutional trust is confidence in how the organization works: ownership is clear, risks get raised early, and changes are reviewed before they ship. Small teams run on personal trust. Growing organizations need institutional trust, because people depend every day on colleagues they have never met.
Process can’t manufacture trust by itself. If leaders say they want risks raised early and then punish the first person who raises one, the risk section of the weekly update goes quiet. If a review standard exists but senior engineers skip it, nobody believes the standard. People trust behavior they can predict, so a process helps only when the people running it behave consistently.
Why process works in one place and fails in another
The same process can work well on one team and fail on the next. The failures tend to follow a few patterns.
It solves the wrong problem
An illustration: a team has two outages caused by bad configuration changes. Leadership responds with a weekly change review meeting for every deploy. The meeting adds days to every change, and nobody in the room reads the configuration closely enough to catch the next mistake. The root cause was missing validation. A check in the deployment pipeline would have caught both outages and cost nobody a meeting.
It ignores how the work actually happens
A process designed by someone who doesn’t do the work tends to get satisfied on paper. Engineers fill in the release template after the release, because the template asks for information that only exists afterward.
Every change gets the same controls
A copy change on a marketing page and a change to authentication don’t carry the same risk. Giving them the same review slows the first and under-protects the second. I wrote about matching process to the risk of each change in more detail.
It stands in for leadership
One person keeps merging untested code, so everyone gets a new approval step. That is a conversation a manager avoided, turned into a cost the whole team pays.
Approvals have no decision owner
A request needs sign-off from five people. Any of them can block it and none of them can decide. It waits until someone escalates, which is the decision process the organization really has.
Nobody measures it or retires it
The process was added for a problem that went away a reorganization ago. Nobody checked whether it helped, and nobody owns removing it, so it stays.
The workload process adds
Process is never free, even when the calendar makes it look that way. A one-hour weekly meeting for eight engineers takes a full working day of engineering time every week, before counting the context switch on either side of it. Approval queues, status reports and documentation take hours too, and those hours never show up on a roadmap.
The costs also compound. An illustration: approvals slow releases down, so teams batch more changes into each release. Bigger releases fail more often and are harder to diagnose, so leadership adds another approval to fix a problem the first approval caused.
DORA’s research on change approval points the same way. It found that heavyweight approval by an external body, such as a change advisory board, was associated with lower software delivery performance, and it found no evidence that more formal external review lowered the rate of failed changes. DORA recommends peer review built into the development workflow instead. Controls still have a place. The question is which ones reduce a real risk and which only add work.
| Useful operational control | Bureaucracy | |
|---|---|---|
| Code review | A peer reviews every production change, more closely when the risk is higher | Two approvals from another team before a copy change can ship |
| Status reporting | A short written update with risks at the top, sent before anyone has to ask | A weekly meeting that reads the ticket board aloud |
| Approvals | One named decision owner and an agreed response time | Sign-off from every team lead, with nobody named to decide |
| Documentation | A decision record for choices that are hard to undo | Templates filled in after the work, for a review nobody runs |
| Compliance | Evidence collected by the pipeline as the work happens | Screenshots gathered by hand the week before an audit |
Engineering process becomes bureaucracy when it costs more than the risk it reduces, when nobody can say what problem it solves, or when people satisfy it on paper without changing how they work. A useful control is tied to a real risk, sized to that risk, owned by someone, and checked to see whether it still works.
Trust should earn autonomy
The right amount of process for a team should change as that team proves itself. A new team, a new leader or a team working in unfamiliar territory benefits from clear expectations, closer review and more frequent check-ins. That is how everyone learns what good looks like. As the team delivers consistently, leadership can delegate more decisions and judge the team on its results.
- 01Clear expectationsA new team, a new leader, or unfamiliar workAgreed standards, closer review, frequent check-ins.
- 02Delegated decisionsAfter a run of consistent deliveryThe team decides within agreed limits and reports outcomes and risks.
- 03Autonomy with accountabilitySustained, predictable resultsThe team owns decisions end to end. Leadership reviews results instead of each step.
Controls that stay regardless of trust
- Peer review on production changes
- Security review for authentication and permissions
- Audit trails and separation of duties where regulation requires them
- Extra care for changes that are costly and hard to undo
Trust should earn a team more autonomy while its accountability stays the same. As a team delivers consistently, leaders can delegate decisions and supervise less. The team still owns its outcomes, raises risks early and keeps the controls that protect production, security and regulated work.
Some controls stay no matter how much I trust the people involved. A second reviewer on a change to permissions or payments protects the author as much as the company, and it says nothing about the author’s competence. In regulated work, separation of duties is a requirement, and DORA notes that peer review recorded in the development platform can satisfy it. I’ve built government applications where those requirements shape the whole delivery process.
Trust can also move the other way. If a team misses commitments repeatedly or ships a run of incidents, adding expectations back for a while is reasonable, as long as everyone knows what would remove them again.
How to decide whether to add a process
When someone proposes a new process, I walk through roughly the same steps. The third one ends a lot of proposals, and that is a good result.
- 01Identify the recurring problemOne bad week is an incident. The same failure three times is a pattern.
- 02Find the root causeAsk why it keeps happening until the answer is something you can change.
- 03Decide whether process is the fixOften it isn’t.If not: fix the cause directly with an owner, a tool or a conversation, and stop here.
- 04Start with the smallest controlA checklist before a meeting, a meeting before a committee.
- 05Match the control to the riskLighter for changes that are cheap and easy to undo, heavier for the rest.
- 06Automate the repetitive checksA check that runs in the pipeline costs nobody’s attention.
- 07Measure outcomes and costDid the problem shrink, and how many hours a week does the control take?
- 08Review, simplify or retire itGive it an owner and a review date when it is created.Then go back to step 1 with whatever is still going wrong.
Give process a budget
Every recurring meeting, approval and report spends engineering capacity, and most organizations never add it up. I’d rather leaders treat it like a budget. Decide roughly how much of a team’s week coordination should take. When a new process comes in, ask what goes out to make room. Leaders who assume administrative work is free tend to find out otherwise in the delivery dates, a pattern that also shows up in sprint carryover.
Automation is the best way to stay inside that budget. Tests, linting, dependency scanning, policy checks on infrastructure code and evidence collection can all run in the pipeline, where they cost nobody’s attention and never skip a step on a busy day.
Process should change as the organization does
A small team with shared context needs very little: code review, a deploy checklist, and decisions written down when they are hard to undo. Once there are several teams, the needs shift toward ownership boundaries, API contracts, shared standards and planning around dependencies. A growing organization adds delivery reporting, an incident process and onboarding that doesn’t depend on one person’s memory. Large enterprises and regulated environments add audit trails, change records, access reviews and compliance evidence, and the ones that run well automate most of it.
Headcount alone doesn’t determine how much process a team needs. Complexity, risk, coordination requirements and organizational maturity matter more. A ten-person team building a payments product may need controls that a fifty-person team building an internal reporting tool never will.
The same logic applies to architecture, which is why I think team size should influence architecture as one input among several, never the only one.
Removing process is a leadership job
Adding a process is easy. It feels responsible, and nobody gets blamed for being careful. Removing one takes judgment, because someone remembers why it was added and removing it feels like accepting risk. That is why process tends to pile up, and why someone with authority has to own taking it away.
Before adding a process, I want to agree on the problem, its current cost and how we will judge whether the additional work helps.
I also look for a fix that avoids adding another recurring obligation. A clearer owner or a one-time change to the tooling may be enough.
An engineering leader answers for reliability and for speed at the same time, so they are the person who has to weigh one against the other. Protecting reliability with controls nobody questions is easy. So is protecting speed by removing everything. The job is keeping the controls that earn their cost and having the discipline to drop the rest.
Short answers
When should a company introduce process?
Introduce process when a specific problem keeps recurring and costs more than the process would: unclear ownership, missed handoffs, unpredictable delivery, repeated quality failures, or a security or regulatory requirement. Growth makes those problems more likely, but headcount alone is not a reason to add process.
What is the difference between engineering process and bureaucracy?
A useful engineering process is tied to a real risk, sized to that risk, owned by someone, and reviewed to see whether it still works. It becomes bureaucracy when it costs more than the risk it reduces, when nobody can say what problem it solves, or when people satisfy it on paper without changing how they work.
Can process build trust in an engineering team?
Yes. Consistent delivery updates, early risk reporting, clear API contracts, code review and shared standards give people a reason to trust colleagues they do not know well. Process cannot create trust on its own, though. If leaders punish bad news or senior people skip the rules, the process loses credibility.
How do you balance process and productivity?
Start from the recurring problem and its root cause, use the smallest control that works, match it to the risk, and automate repetitive checks. Treat meetings, approvals and reports as a budget of engineering time, measure whether each process still pays for itself, and simplify or retire the ones that do not.
Does more autonomy mean less accountability?
It shouldn’t. Autonomy changes how closely leaders supervise the steps. A trusted team makes more of its own decisions and still answers for delivery, reliability and raising risks early. Some controls, such as peer review on production changes and separation of duties in regulated work, stay regardless of trust.
Good process makes people more effective
Good process makes an organization more predictable without making the people in it less effective. People can see who owns what and how the work gets done, which gives leadership confidence and lets teams work on their own without someone checking each step. When a process stops doing those things, leadership should have the discipline to change it or remove it, even if it was a good idea when it started.
I want the team to know which decisions it can make on its own and when someone else needs to be involved. A process should make that easier to understand.