The Taste Gap: Why Your Engineering Teams Keep Solving the Same Problems Differently

There’s a moment in every engineering leader’s career when they look across their organisation and realise something uncomfortable: everyone is solving the same problems differently. Not creatively differently — chaotically differently. One team swears by repository patterns, another treats them as antipatterns. Someone’s building microservices while the team next door is quietly re-inventing the monolith. Your codebase isn’t a cathedral or a bazaar — it’s an architectural fever dream designed by a committee that never met.

The problem isn’t competence. You’ve hired smart people. The problem is taste — that ineffable shared understanding of what “good” looks like. Without it, code reviews become theological debates, architectural decisions get relitigated endlessly, and every project feels like it was built by a different company.

So how do you build shared taste across dozens — or hundreds — of engineers?

I’ve spent considerable time researching this question, and I’ve learned something important: most of the popular answers are wrong.

What Doesn’t Work (Despite What LinkedIn Tells You)

The Spotify Model

Ah yes, squads and tribes and guilds. The Spotify model is the “we should do microservices” of organisational design — everyone references it, few understand it, and the company that invented it abandoned it roughly six months after publishing that famous whitepaper everyone cites.

The model assumed that engineers would voluntarily gather in guilds to share knowledge and align on practices. In reality, guilds become yet another meeting that busy people skip. They work when you have intrinsically motivated people with spare capacity and a culture that genuinely values cross-pollination. In other words, they work when you already have shared taste — they don’t create it.

Architecture Decision Records

ADRs are the Confluence of technical documentation: a beautiful idea in theory, a graveyard of good intentions in practice.

The pitch is compelling: document every significant decision with its context, alternatives considered, and rationale. Future engineers will understand why things are the way they are! Knowledge will be preserved!

The reality: ADRs are written once and read never, except by code archaeologists desperately trying to understand why the authentication service makes three redundant API calls on every request. By the time someone needs the ADR, the context has shifted, the authors have left, and the “decision” was actually a compromise made at 5 PM on a Friday before a long weekend.

As the philosopher Michael Polanyi observed, “We know more than we can tell.” He was describing tacit knowledge — the kind that resists documentation because it lives in practice, in muscle memory, in shared experience. ADRs try to capture something that is fundamentally uncapturable. They work in small teams with strong documentation cultures. At scale, they become an exercise in performative governance — a way to pretend decisions were made thoughtfully without actually building the muscle for thoughtful decision-making.

Guilds and Communities of Practice

“We’ll create a backend guild where all the backend engineers share best practices!”

Six months later: three people show up consistently, two of whom are the organisers. The rest are “too busy with sprint work” — which is technically true but also a polite way of saying “I don’t see the value.”

The fundamental problem is incentives. Guild participation is typically optional and unrewarded. Sprint velocity is measured and rewarded. Guess which wins?

What Actually Works

Golden Paths That Are Actually Golden

Here’s what we found works: invest heavily in making the right way the easy way.

We built new project quick-start templates that encode our collective taste. Not as documentation, but as working code. Want to start a new service? Run the generator. You get our preferred structure, our logging patterns, our testing setup, our CI/CD configuration — all the decisions that should be boring, already made for you.

The French writer Antoine de Saint-Exupéry captured this elegantly: “Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.” A good golden path isn’t about adding more rules — it’s about removing decisions engineers shouldn’t have to make in the first place.

The key insight: engineers don’t resist best practices because they disagree with them. They resist because following them takes more effort than not following them. Flip that equation.

Our engineers actually want to keep the golden project updated. It’s become a point of pride — a living embodiment of “this is how we do things here.” When someone discovers a better pattern, they propose it to the template. The template becomes the canonical expression of our evolving taste.

The challenge, of course, is existing projects. Your golden path only paves the road for new journeys. The legacy services — the ones that actually matter — remain stubbornly off-path.

LLMs as Taste Radar (Yes, Really)

This is where things get interesting. We’ve been experimenting with Cursor and LLMs connected to Sourcegraph MCP for gap analysis on existing codebases.

The workflow: point the LLM at your golden project, then at an existing service. Ask it to identify the divergences. Where does Service X deviate from the blessed patterns? What’s missing? What’s different?

Note that I said “divergences,” not “violations.” Sometimes divergence is exactly what you want — that’s how you innovate. A team might have discovered a better pattern that should flow back into the golden path. The point isn’t blind compliance; it’s visibility. You can’t have a useful conversation about whether a divergence is innovation or drift if you don’t know the divergence exists.

The LLM gives us that visibility at scale. It produces a prioritised list of “here’s where this service differs from the standard,” and suddenly we can ask the right questions: Is this intentional? Did we learn something here? Or did we just forget to update this service when our practices evolved?

It doesn’t replace human judgment about what to do with the information. But it dramatically lowers the cost of getting the information. And that matters more than you’d think — half the reason legacy code stays legacy is that nobody wants to be the person who figures out how far off-path it actually is.

Internal Tech Talks

Here’s an unglamorous truth: sometimes building good habits requires persistence that some might perceive as annoying.

We have a PR team that ask our directors quarterly about getting engineers to do tech talks — both internal and external. Their goal is PR: external visibility, employer branding, conference presence. Our goal is something different: forcing engineers to articulate what they’ve learned in a way others can absorb.

The external talks are nice. The internal talks are where the magic happens.

When an engineer has to stand up and explain to fifty colleagues why they chose event sourcing for the booking service, they’re forced to crystallise their reasoning. The Q&A reveals assumptions they hadn’t examined. The follow-up conversations in Slack spread the knowledge further. Six months later, when another team faces a similar problem, someone remembers that talk and pings the original speaker.

The historian and philosopher Will Durant put it simply: “We are what we repeatedly do. Excellence, then, is not an act, but a habit.” The PR team’s quarterly follow-ups are, frankly, helping us to parrot train our engineers. Repeat the behaviour enough times and it becomes habitual. While some might perceive this persistence as annoying, keep encouraging engineers to present until presenting feels normal. Yes, we’d all prefer some enlightened approach that doesn’t treat engineers like birds with brains the size of peas. But repetition works. Once someone has done a few talks, the activation energy drops. They start volunteering topics. They start asking “has anyone talked about this before?” before reinventing wheels.

It’s not sophisticated, but it turns “I should share this” from an intention into a habit.

And here’s where it connects to tech radars: once you have a culture of regular internal sharing, you have the raw material for a radar. The talks reveal what technologies people are excited about, what’s working, what’s causing pain. The radar becomes a formalisation of conversations that are already happening — not a top-down mandate that nobody owns.

Tech radars need self-motivated people to build and maintain them. That’s hard to conjure from nothing. But if you’ve spent a year building the habit of internal sharing, you’ve already got those people. They’re the ones who keep volunteering to present.

Code Review as Apprenticeship (Not Gatekeeping)

Code reviews can build taste, but only if you treat them as teaching moments rather than approval gates.

The problem with most code review cultures is that they optimise for “does this code work and is it safe to merge?” That’s necessary but insufficient. The taste-building question is “does this code reflect how we want to build software here?”

This requires reviewers to explain why, not just request changes. “Please use the repository pattern here” teaches nothing. “We use the repository pattern here because it lets us swap data sources in tests — here’s an example from the payments service” transfers taste.

It also requires pairing and mobbing for complex work. Here’s the thing: engineers don’t easily converge on what “beautiful” code looks like — beauty is subjective and deeply tied to individual background and training. But they do converge on what “ugly” code looks like. Shared taste develops faster through collective rejection of anti-patterns than through collective embrace of ideals.

One of the philosophies we had when building our C# standards and static code analysis rules years ago what not to prescribe a strict way of coding, but letting engineers know what bad looks like, because what’s good depends heavily on context, this is a good way to start.

The Uncomfortable Truth

Building shared taste takes time. There’s no framework you can adopt, no tool you can buy, no reorg you can execute that creates it overnight.

It emerges from hundreds of small moments: a code review comment that explains the why, a template that makes the right thing easy, a celebration of someone who made the codebase simpler, a conversation in a PR that shifts someone’s mental model.

The Spotify model failed because it tried to create structure for something that’s fundamentally cultural. ADRs fail because they try to capture something that’s fundamentally tacit. Guilds fail because they try to make optional something that needs to be woven into daily work.

What works is less glamorous: golden paths that encode your taste in working code, LLMs that help identify gaps at scale, code reviews that teach rather than gatekeep, and visible celebration of the behaviours you want to see.

Your engineers already have taste. Your job is to help them develop shared taste — and that happens one interaction at a time.

As Ben Horowitz recounts in The Hard Thing About Hard Things, when he was searching for clever ways to outmanoeuvre Microsoft at Netscape, his engineering counterpart Bill Turpin told him: “There is no silver bullet that’s going to fix that. No, we are going to have to use a lot of lead bullets.”

Building shared taste is the same. There’s no framework, no reorg, no tool that magically creates alignment. Just a lot of lead bullets: another code review that explains the why, another tech talk that transfers knowledge, another engineer trained through repetition to share what they’ve learned.

Fire enough of them, and eventually you’ll hit the target.