The Design Review That Reviews Nothing

The meeting room smelled like dry-erase markers and Thai iced bubble tea — that particular staleness you get when the same air has been circulating past the same twelve people since ten in the morning. An architecture diagram glowed on the projector screen, boxes and arrows in four colours, and the argument had been going for forty minutes about whether one of those arrows should point left or right. I shifted in my chair and felt the vinyl stick to the back of my arms. The presenter clicked to a slide titled “Proposed Approach” that looked identical to the previous slide titled “Current State.” Nobody seemed to notice.

I looked around the room. Three principal engineers. Two engineering managers. A director who’d been pulled out of another meeting. All of them debating the placement of a single service boundary in a system that handled — at most — a few hundred requests a minute. This wasn’t a platform migration. It wasn’t a data centre failover strategy. It was a minor change that two engineers could have shipped in a month.

So why were we here?

It hit me somewhere around minute forty-five, when the third principal engineer started drawing a counter-proposal on the whiteboard. We weren’t here because the decision was hard. We were here because the engineers who owned this change didn’t feel they had permission to make it. And when you put a minor decision in front of six senior technical people, they’ll happily argue about it — especially if they have opposing views. Give smart people a whiteboard and a disagreement and they’ll fill an hour without breaking a sweat. But the real question wasn’t which arrow was right. It was why anyone felt the need to raise this in the first place.

That’s not a design review. That’s a permission slip dressed up as engineering process.

The Approver Industrial Complex

You’ve seen the RFC document. Not the content — nobody reads the content. I mean the header. The part with fourteen names under “Approvers,” arranged like a wedding seating chart where everyone’s a stakeholder and nobody’s actually accountable for a decision.

As the management thinker Peter Drucker once observed, “Wherever you see a successful business, someone once made a courageous decision.” He wasn’t talking about getting sign-off from three directors, two principal engineers, and a CTO before choosing a database. He was talking about someone deciding and moving.

But that’s what we’ve built, isn’t it? A culture where the act of seeking consensus has replaced the act of making decisions. Where an engineer’s first instinct when facing a design choice isn’t “what’s the right answer?” but “who do I need to approve this?” Long RFC approver lists. Slack threads that stretch across time zones with no resolution. The quiet, corrosive belief that if enough people agree, nobody can be blamed.

That’s not collaboration. That’s fear wearing a process badge.

“Did the CTO Approve That?”

I was in a meeting a while back, discussing a design with some engineers. I mentioned something we’d built — a bit unconventional, but nothing radical. Just a pragmatic solution to a real problem. The response I got was immediate: “Did the CTO approve that?”

I was taken aback. It wasn’t a large architectural decision. It wasn’t the kind of thing you’d put in front of a CTO — he’s got better things to do than review every micro-decision in every API across the organisation. But the reflex was there, automatic and unexamined: surely someone higher up must have sanctioned this.

Some business cultures are deeply hierarchical. You never do anything that might upset the chain of command. Decisions flow down, never up, and the safest move is always to wait for instruction. I try to filter for this in hiring — unless the candidate comes in essentially saying “get me out of here,” recognising the dysfunction they’ve been operating in. Those people are gold. They’ve seen what doesn’t work and they’re hungry for something better.

But the “did the CTO approve that?” question reveals something deeper than individual culture. It reveals an organisation that has trained its people to believe that acting without explicit top-down blessing is dangerous. And when that belief takes root, you don’t get careful engineering. You get paralysis.

As Ben Horowitz wrote in The Hard Thing About Hard Things, “Every time you make the hard, correct decision you become a bit more courageous, and every time you make the easy, wrong decision you become a bit more cowardly. If you are CEO, these choices will lead to a courageous or cowardly company.” And here’s the thing — if you’re the lead or senior on your team, you are the CEO of that team. Every time you escalate a decision you could have made, every time you add another name to the approver list instead of just calling it, you’re choosing the easy path. Do that enough times and you won’t just build a cowardly team. You’ll build a team that doesn’t even realise it’s afraid.

Somchai and the Slack Thread That Went Nowhere

I was sitting with one of my engineers, Somchai, during Acceleration Week. We’d made a call that the feature he was building should live in a new system. This was fine — we have a new system template. Naming it was the hard part, so I sat with him and spent a good twenty minutes chatting to my mate Claude about the right name. LLMs are genuinely great at helping you solve one of the two hardest problems in engineering. We nailed it. I gave him the name and said off you go.

The desk next to him was spare, so I sat there doing my own work for about an hour. In that hour, he hadn’t written a single line of code. He was deep in a Slack thread with his team — a long, branching, inconclusive thread about whether he should build a new system at all. The engineers on his team were divided. Nobody could reach consensus. And a Slack thread is no place to resolve an architectural decision, nor is an Acceleration Week the time to be debating whether to start.

I told him, “Somchai, you are thinking about this too much.”

He said, “Joel, I think I do that a lot.”

He was nervous, lacked confidence — I get it. He was young, and he had a lot of senior people on his team, none of whom were at the Acceleration Week. In my book, that meant they didn’t need to be involved in this decision right now.

I told him, “Mate, some day you are going to have to stop thinking too much about things and start doing at some point in your life. Why not make that day today?”

He said, “OK.”

I told him, “Here, I’ll make it easier for you.” I jumped into the Slack thread and said: “We are building a new system. It’s going to be called X. You guys can regroup after this week as a team and decide whether it was a good solution or not. Have a nice day.”

Was he going to fail? Was building a new system the wrong idea? Maybe. But even if it was, there would have been a lot of code written that we could merge back into another system. Even if there wasn’t, that’s four days of learning for him. In the end, the team decided it was a good decision and the system stayed.

As the basketball coach John Wooden put it, “If you’re not making mistakes, then you’re not doing anything.” Bias to action — that’s what you want to encourage. But don’t go too far without regrouping. Four days’ work isn’t too much to risk. Weeks or months wasted — that is too much, for sure. The trick is bounded risk: move fast enough to learn, slow down enough to not burn the house down.

The Baptism of Fire (And Why We Replaced It)

A lot of our new engineers that come from smaller companies don’t think about scale. This becomes painfully evident when they do their first design review. They present a clean, logical architecture — and then one of our infrastructure engineers would drop the questions that nobody at their previous company ever asked: “How many nodes will you have? How many data centres do you need this in? How will you replicate data?”

All questions that someone doing high-level application design without web-scale experience doesn’t think about. This baptism of fire in the early days was how new joiners learnt about scale. It was brutal, but it was a lesson not forgotten.

These days we run system design and architecture workshops. I see far fewer people getting destroyed in design reviews. And we’ve also built a private cloud environment now which, through creating the YAML or even reading the docs, forces you to think about and answer some of these questions upfront. The review, in effect, happens before anyone opens a slide deck.

Which brings us to a question worth sitting with: what if the most effective design review doesn’t look like a review at all?

Golden Paths: The Review That Happens Before You Write Code

Let me be honest about the governance mechanisms I’ve seen over the years.

The Spotify model — the one everyone references from that famous blog post — was undone about six months after they published it. It lives on as a conference talk zombie, cited by organisations that have never actually spoken to anyone who worked there during the rollout.

ADRs — Architecture Decision Records — are a pipeline dream. They’re like Confluence pages: the only time anyone reads them is when they’re doing code archaeology, trying to decipher why the hell something is the way it is.

Tech radars help, but you need self-motivated people to build them, maintain them, and argue about them. That’s harder than it sounds.

But golden paths — those actually worked for us. We put them into new project quick-start templates. Engineers get a project scaffold that already encodes our architectural decisions, our patterns, our standards. And here’s the part that surprised me: engineers actually keep the golden path updated. They’re invested in it because it’s theirs. It’s not a governance document handed down from an architecture board; it’s a living template that represents how we actually build things.

More recently, we’ve been using LLMs with Sourcegraph for gap analysis — pointing Cursor or an LLM with the Sourcegraph MCP at our codebase to identify where existing systems have drifted from the golden path. It’s not perfect, but it’s remarkably good at surfacing the kind of inconsistencies that a thirty-minute design review would never catch.

Golden paths are essentially design review baked into templates and tooling. The review happens before anyone writes code, not after. It involves way fewer slides, zero approver lists, and produces better architectural consistency than any committee I’ve ever sat on.

Acceleration Week: What Happens When You Front-Load Collaboration

Twenty-five engineers from four companies. Five days co-located. No slide decks. No approval workflows. Just people in a room solving problems together.

During one of our Acceleration Weeks, we replaced the legacy asset serving architecture that had caused a large production incident — and we did it during the same week the incident happened. Nobody presented slides about the new Nginx sidecar caching layer. They built it together.

The philosophy behind it is simple: walk up and talk to someone. Don’t just post in a chat channel. Since work from home became the norm during COVID, we got into the habit of too much asynchronous work. Too many Slack threads. Too many documents that ask for feedback from people who won’t read them for three days.

Acceleration Week is what happens when you front-load collaboration instead of back-loading review. The architecture emerged from the work, not from a committee. And because people were sitting next to each other, disagreements got resolved in minutes instead of festering across sprints.

That said, this format has its limits. You can’t sustain it for more than a week or two at most — it’s intense, and it’s draining. You certainly can’t run them every sprint. But when you need to break through a coordination problem, especially when you’re working across teams or with third parties, there’s nothing more effective than putting everyone in the same room and letting them build together.

Peer Review: Guidance, Not a Rubber Stamp

None of this means you should abolish review entirely. Peer review has real value — but its value is guidance, not approval. It’s the difference between a mentor saying “have you thought about this?” and a gatekeeper saying “you may not proceed.”

Peer review can help you fine-tune things, but it’s seldom that peers outside your immediate area will understand your business domain enough to give you specific guidance. It’ll be up to you to answer questions about domain boundaries and aggregates — this is important for understanding where transactions need to be done, where we can cope with eventual consistency, and how to plan replication and scaling. In the earlier example, the infrastructure engineer could tell you what’s available and how to scale. But your domain requirements decide which path to take on the available tech.

There’s a nuance here that matters. Engineering leaders should have veto power — but refrain from using it unless absolutely necessary. Give your people autonomy. Don’t let them break the business, but don’t stand over their shoulder either. If you’ve invested in education, shared taste, and golden paths, you’ll find that what your engineers decide is generally aligned with what your feedback would have been anyway.

As the pilot and author Antoine de Saint-Exupéry wrote, “If you want to build a ship, don’t drum up the men to gather wood, divide the work, and give orders. Instead, teach them to yearn for the vast and endless sea.” You can’t review your way to great architecture. But you can build a culture where great architecture is the natural outcome of well-aligned, confident engineers.

The Cultural Dimension You Can’t Process-Fix

Here’s the uncomfortable truth that no framework diagram will solve: some of this is about culture. National culture. Organisational culture. The deeply ingrained beliefs people carry about hierarchy, authority, and the consequences of being wrong.

You can install golden paths. You can run workshops. You can tear up every RFC template in the building. But if your engineers still believe — in their bones — that making a decision without explicit authorisation is career-threatening, none of it matters.

Freedom without alignment is chaos. Spotify proved that. But alignment without freedom is bureaucracy — and that’s what most design review processes have become. The goal isn’t either extreme. It’s engineers who are pre-aligned enough to act confidently, with lightweight checkpoints rather than heavyweight gates.

You build that through hiring people with the right mindset. Through education that gives them the vocabulary and patterns to make good decisions. Through golden paths that encode your standards into the tools themselves. Through leadership that demonstrates — not just permits — a bias to action.

The Bottom Line

We keep building review processes to protect ourselves from bad decisions. But the review process itself has become the bad decision — a slow, consensus-seeking, permission-granting machine that produces architecture documents nobody reads and approvals nobody remembers giving.

The teams I’ve seen move fastest and build the best systems don’t have better review processes. They have better pre-alignment. They invest in education, golden paths, shared taste, and the kind of trust that comes from sitting next to someone and building something together. Their “review” is embedded in templates, tooling, and culture — not in a calendar invite with fourteen attendees and a slide deck.

As the jazz musician Miles Davis said, “Do not fear mistakes. There are none.” He was talking about improvisation, but the principle translates: if your engineers are well-trained, well-aligned, and operating within sensible guardrails, the decisions they make without asking permission will be better than the ones a committee would have produced in twice the time.

Now, if you’ll excuse me, I need to go delete about thirty names from an RFC approver list. I’m pretty sure half of them don’t even work here anymore.