What to do when engineering keeps building the wrong thing

The diagnosis that comes out of most post-mortems when engineering builds the wrong thing is "communication breakdown." The design didn't get communicated clearly. The handoff was insufficient. If we'd had better specs, this wouldn't have happened.

That's sometimes accurate. But the communication diagnosis is often a polite way of avoiding the more uncomfortable question: were the design decisions sound enough that engineering should have been building from them in the first place?

What actually goes wrong

There are a few different failure modes that produce "engineering built the wrong thing," and they have different causes.

The first is spec drift: the design was right, but engineering made judgment calls during implementation that shifted the outcome. This is the case where better documentation helps. Redlines, explicit callouts of the details that matter, and a process for checking implementation before it ships can all address this. It's a real problem and a solvable one.

The second is direction change without design update: a product decision got made after the design was finalized, someone told engineering about it, and engineering built toward the new direction without a corresponding design revision. The design became stale and nobody flagged it. This is a process problem between product and design, not a design-engineering communication problem.

The third is the most awkward: the design was used as a starting point rather than a specification, because the design left too many questions open. Engineering made the open decisions themselves. The design was treated as directional because it functionally was. It hadn't answered the edge cases, the error states, the responsive behavior, the empty states. Engineering built something. It wasn't quite what the designer had in mind.

Why the third case is hard to talk about

The third failure mode is uncomfortable because it implies the design was incomplete. Most design teams would rather attribute the gap to implementation error than to incomplete design decisions. Both things can be true, but the instinct to protect the design work can prevent an honest conversation about whether the work was actually ready to build from.

A useful test: could an engineer who had never talked to the designer look at the spec and make every decision needed to implement it correctly? If the answer is no, there were decisions left to interpretation. Those decisions will get made by whoever is in front of the code. Sometimes they'll get made well. Often they won't.

The relationship question

Underneath the spec problem is usually a relationship problem. Engineering builds the wrong thing, in part, because the feedback loops during implementation are either absent or broken.

If engineering doesn't flag divergence from the design as they encounter it (because they don't know the design intent, because raising it feels like criticism, or because the process doesn't create space for it), the gap doesn't surface until QA or launch. At that point, it's expensive to fix and someone has to decide whether to ship it anyway.

The teams where this happens less frequently are the ones where the designer is present during implementation: in standups, available for questions, actively reviewing work in progress rather than only doing a formal handoff review at the end. Not to supervise, but to catch the moment when something is being implemented that doesn't match the intent, before that moment becomes expensive.

What I've seen work

Making design review part of the development workflow, not just the pre-development workflow, is the biggest lever. A quick async design review when a component is at 70% is more useful than a thorough one when it's at 100%.

Beyond that: create explicit space for engineering to raise design questions without it feeling like a complaint. "The spec doesn't cover this state. What should happen?" is a question that's easy to answer and prevents a bad guess. The teams where that question gets asked are the ones where the designer is approachable and where asking is seen as due diligence, not incompetence.

The last thing: decide in advance which design decisions are non-negotiable and which ones engineering can make themselves within defined constraints. Not every detail is equally important. If the designer communicates which calls matter most, engineering can apply judgment elsewhere without risk of getting it wrong.

The thing that almost never works is more documentation in isolation. Documents don't ask questions. They don't catch the case that wasn't covered. A process that keeps design and engineering in contact during implementation will outperform any spec, however thorough.