A production deploy breaks the system.
The person who shipped it made a reasonable call with incomplete context. The incident hurts customers anyway. The postmortem asks how the change reached production. A new deployment process appears: review, staging validation, approval, sign-off, post-deploy monitoring.
The next failure has more names attached to it. The code was reviewed. The tests passed. The approval happened. The process was followed.
That is one reason process exists. It prevents some failures. It also makes failures harder to attach to a single person’s judgment.
Organizations complain about process while continuously creating more of it because process solves problems they do not like naming directly: scale, distrust, coordination, risk, and blame.
Process Is Scar Tissue
Most process forms where something hurt.
An intern deletes data, so database changes require approval. A vendor runs late and over budget, so procurement adds bids, legal review, and executive sign-off. A campaign creates public backlash, so external messaging now needs brand and leadership approval.
Each rule remembers a specific failure. It may not prevent the whole class of failures. It prevents the organization from being unable to explain why that old failure happened.
The rule then survives. Removing it means accepting the risk that the failure could recur, and the person removing it would own that recurrence. Keeping it is safer.
This is how organizations end up with 2026 work constrained by incidents from 2018 that few people can still explain.
Quality Is Often the Public Story
Organizations describe process with clean language: quality, consistency, reliability, risk management, compliance.
Those functions can be real. Code review can catch bugs. Procurement can prevent bad spend. Architecture review can preserve coherence. Performance reviews can force difficult conversations.
The private function is often different. Code review distributes knowledge and creates an audit trail. Procurement documents why the vendor was chosen. Architecture review gives senior technical people veto power over choices outside their reporting line. Performance review creates a defensible record for compensation and termination decisions.
The stated purpose is usually more flattering than the operating purpose.
That gap matters because process gets optimized against the wrong goal. A process built for defensibility may be criticized for being slow. A process built for political alignment may be redesigned for efficiency and then fail the next time someone needs cover.
Scale Makes Judgment Risky
Small organizations can run on individual judgment. The blast radius is limited. Context is shared. Trust is personal.
Scale changes the math.
A small decision now affects thousands of customers, revenue commitments, compliance exposure, or several teams downstream. The person closest to the problem may not know all the constraints. The organization may not trust that they know them. Process appears to make the decision visible before it causes damage.
No executive wants to announce, “we added this workflow because we no longer trust independent judgment at this scale.” So the workflow becomes a best practice.
The cost is autonomy and speed. Decisions that once took one person now take five people, a template, a queue, and a record. Sometimes that is the right cost. Pretending the cost is about pure quality prevents honest design.
Process Coordinates Independent Actors
A lot of process exists because independent teams make coherent local decisions that conflict globally.
Three teams decide to change the same shared library. Each change is sensible. Together they break compatibility. The organization adds a notification and approval process for shared components.
The process does not make any individual refactor smarter. It makes collisions visible before they reach production.
That coordination function is legitimate. At small scale, people just talk. At larger scale, people do not know who needs to be told. Process becomes the substitute for ambient awareness.
The frustration comes from the tax. Coordination process slows people who would rather move. But removing the process without replacing the coordination mechanism usually brings back the collisions.
People Pretend the Process Is Incidental
Engineers say they write code. The code goes through linting, review, tests, security scanning, staging, approval, deployment, monitoring, and validation.
Product managers say they ship features. The feature goes through prioritization, specification, design review, technical review, QA, launch planning, documentation, rollout, and analysis.
Executives say they make decisions. The decision goes through data gathering, narrative building, stakeholder alignment, board framing, communication planning, and implementation tracking.
The process is a large part of the work.
People pretend otherwise because it is more satisfying to identify with craft, vision, or judgment than with coordination, compliance, and approval. Admitting how much of the job is process makes the organization feel heavier than its self-image.
Process Gets Blamed for Its Symptoms
When execution is slow, people blame process. Sometimes they are right. Sometimes process is only the visible form of a deeper coordination cost.
An approval chain may be slow because authority is unclear. A review gate may be painful because incentives reward risk avoidance. A documentation requirement may be heavy because the organization lacks shared context. A status process may exist because leaders do not trust teams without continuous visibility.
Removing the visible process can make work faster briefly and worse later. The old need returns through meetings, escalations, confusion, rework, or informal gatekeeping.
This is why process-improvement efforts often disappoint. The template gets shorter. The approval chain gets streamlined. The meeting is renamed. The authority problem remains.
Process Optimizes for Defensibility
Defensibility is not a fake need.
Regulators ask what review occurred. Customers ask how an incident happened. Boards ask who approved the spend. Employees ask why one person was promoted and another was not. The organization needs records, consistency, and evidence that decisions followed a recognizable path.
Process creates that path.
The trouble starts when defensibility is sold as speed, quality, or empowerment. People then try to optimize the process for the public story while the private requirement keeps reasserting itself.
If the purpose is defensibility, design the process honestly for fast records, clear ownership, and appropriate review. If the purpose is quality, measure defects prevented. If the purpose is coordination, measure collisions avoided and wait time introduced.
A process with an unnamed purpose cannot be improved cleanly.
Why It Rarely Goes Away
Adding process after failure is safe. Removing process before failure is risky.
The person who adds an approval gate can say they are managing risk. The person who removes it has to explain the next incident if the old failure mode returns. The benefit of removal is usually diffuse: faster work, less frustration, fewer small delays. The downside is concentrated and easy to blame.
So process accumulates.
Crisis can cut it. When the organization is under existential pressure, it suddenly discovers which approvals, reports, and gates can be bypassed. Some return afterward because the crisis logic fades and institutional risk returns.
The durable answer is designing process with explicit purpose, ownership, sunset reviews, and honest accounting of the cost.
Process is what organizations build when judgment, trust, and informal coordination are no longer enough. Pretending otherwise only makes the process harder to understand, harder to remove, and easier to keep growing.
