Design and engineering don't have a communication problem. They have a trust problem.

By Mateo Benitez

More documentation doesn't fix what's actually broken. It just moves the same disagreement somewhere slower.

The fix everyone recommends

Every retro on a rough handoff ends up recommending the same fix: better documentation, clearer specs, an extra sync before the sprint starts. None of it addresses what was actually wrong, because the friction was never really about information.

What more documentation actually buys you

A spec that anticipates every edge case is genuinely valuable, and it's also never actually complete, because the list of things that could go wrong in an implementation is longer than any document has time to cover before a deadline. Teams with unresolved trust respond to that gap by trying to write more: catching one more edge case, annotating one more state, closing one more loophole an engineer might interpret differently than intended. It never actually closes, because the real gap wasn't a missing detail. It was that nobody in the exchange trusts the other person's judgment on the details that weren't written down.

What trust actually replaces

A team with real trust handles the exact same gap differently: the spec covers the important cases, and the engineer who hits something it doesn't cover makes a reasonable call and moves on, because everyone involved has enough history with everyone else's judgment to believe the reasonable call will actually be reasonable. The documentation is the same length in both scenarios. What's different is whether an undocumented edge case is a five-minute decision or a two-day back-and-forth about who should have specified what.

Where the trust actually comes from

It's not built by a better process, a new tool, or a more detailed template, the same way authority in a room doesn't come from a title. It comes from a specific kind of track record: an engineer who's watched a designer's calls hold up in practice enough times stops needing every call justified in writing, and a designer who's watched an engineer's judgment calls protect the intent of a design enough times stops needing every implementation detail specified in advance. Neither side can shortcut that by producing more documentation faster. The documentation was never really the layer where the problem lived.

The friction gets blamed on the artifact because the artifact is the visible part. The actual fix isn't a better one. It's enough shared history that the artifact stops needing to do all the work by itself.

Follow me to keep in touch

Where I share my creative journey, design experiments, and industry thoughts.

Create a free website with Framer, the website builder loved by startups, designers and agencies.