Engineering teams routinely get blamed for slow shipping. In most cases, they're not the source of the slowness — they're the last place it becomes visible.
The actual constraints are usually upstream: product decisions that aren't made, designs that haven't been finalized, specs that leave critical behavior undefined, requirements that change after engineering has started, ownership that isn't clear at the boundaries between functions.
Engineering is the last link in a chain. When the chain is weak upstream, it shows up as slow downstream.
The Waterfall Assumption in "Agile" Teams
Most teams that call themselves agile have imported agile ceremonies without agile assumptions.
The agile assumption is that product, design, and engineering are co-creating continuously — that discovery and delivery happen together, that feedback loops are short, and that the team shares a clear picture of what success looks like in every moment.
What many "agile" teams actually do: product writes requirements in a vacuum, hands them to design at the end of discovery, design hands to engineering at the end of design, and engineering builds in a vacuum. The sprint ceremonies happen, but the fundamental handoff model is waterfall with stand-ups.
Melissa Perri's Escaping the Build Trap is the clearest diagnosis of this pattern: when teams optimize for output (features shipped) rather than outcome (problems solved), they build more and learn less. The trap is that more building feels like progress. It isn't.
Who Owns the Interface
One specific failure mode worth naming: when work crosses a functional boundary, ownership gets ambiguous.
Design owns the interaction model but engineering owns the implementation. Product owns the feature but engineering owns the API. The interface between them — the API contract, the behavior at the boundary, the error handling for unexpected states — is nobody's explicit job until it becomes everyone's problem. A checkout example: product owns the discount policy, design owns how errors are shown, and engineering owns the payment API. But if nobody names who decides what happens when a coupon is valid for the cart but rejected by the payment provider, the team will discover that seam late and expensively.
The fix is simple and rarely done: at the start of any significant work, someone explicitly defines the interface. Not the entire spec — just the seams. What does design need from engineering? What does engineering need from design? What does product need from both? Write those down. Assign them to names.
The seam problem is a design problem. Treat it like one.
