Process is comfortable. It gives us checklists, meetings, and the satisfying feeling that we're being rigorous. But here's the uncomfortable truth: most process exists to make us feel like we're solving problems, not to actually solve them. The real leverage comes from mechanisms, systems designed so thoroughly that the right outcomes happen by default, not by heroic effort or perfect compliance.

The Difference That Matters

Jeff Bezos famously said, "Good intentions don't work. Mechanisms do." It's a deceptively simple idea that takes time to fully appreciate. Process tells people what to do. Mechanisms make the right thing happen automatically.

Consider code review. A process approach says "all code must be reviewed before merging" and trusts everyone to comply. A mechanism approach configures your repository so that merging without approval is literally impossible. The outcome is the same, but one relies on discipline and memory, while the other removes the possibility of failure entirely.

This distinction matters enormously at scale. Every piece of process you introduce is a tax on your team's cognitive load. Every mechanism you build is an investment that pays dividends without ongoing attention. When you're leading a team of five, process might feel fine. When you're leading a hundred engineers across multiple time zones, the accumulated weight of "things people need to remember to do" becomes crushing.

Recognising Process Disguised as Progress

The worst kind of process is the kind that feels productive but drives no real outcomes. Status meetings where everyone reports what they did. Documentation that exists because documentation should exist. Approval workflows that add latency but no insight.

These emerge with good intentions. Someone notices a problem, and the natural instinct is to add a step, a meeting, or a form. But each addition carries hidden costs: the time spent complying, the friction that slows down motivated people, and the false confidence that comes from believing the process is handling things.

A simple question cuts through this: "If everyone stopped doing this tomorrow, what specific outcome would suffer?" If the answer is vague or amounts to "we'd feel less informed," that's a warning sign. If removing it would cause a concrete, measurable problem, you've found something worth keeping, or better yet, worth encoding into a mechanism.

Building Mechanisms That Work

Good mechanisms share a few characteristics. They're automated where possible, removing human memory from the equation. They provide feedback loops that make problems visible immediately rather than in retrospective meetings weeks later. And they're designed around outcomes, not activities.

Deployment pipelines are a perfect example. Rather than a process document listing all the checks someone should perform before releasing, a well-designed CI/CD pipeline runs tests, validates configurations, performs security scans, and gates deployment automatically. The engineer's job becomes writing good code, not remembering a checklist.

Similarly, on-call rotations work better as mechanisms. Automatic alerting based on defined thresholds, runbooks that surface alongside incidents, and escalation paths that trigger without human intervention all remove the burden of vigilance from individuals and embed it into the system itself.

The Hard Part

Building mechanisms requires more upfront investment than writing process documentation. It demands clarity about what outcomes actually matter and the discipline to encode that understanding into systems. It also requires the humility to admit that relying on people to consistently follow instructions is a fragile foundation for any organisation.

The payoff is freedom. When mechanisms handle the routine decisions and safety checks, your team's energy goes toward genuinely creative and strategic work. People aren't exhausted by compliance; they're empowered by systems that have their back.

Engineering leaders don't exist to create more process. They exist to build organisations where success happens by default, where doing the right thing is easier than doing the wrong thing, and where outcomes are driven by design rather than discipline alone.