You rarely get told that product and engineering have stopped trusting each other. You get told that estimates have gotten conservative, or that a project is taking longer than expected, or that the teams need to communicate better. The underlying condition shows up in behavior long before anyone names it.
The signals
- Estimates grow padding. Not because the work got harder, but because engineering has learned that a stated estimate will be treated as a commitment and then compressed.
- Engineering builds beyond the spec. Extra generality, extra abstraction, quiet refactors folded into feature work. Usually this is a rational hedge against a roadmap that keeps changing under them.
- Product starts writing tickets in engineering's language. When a PM specifies implementation, it is often because a previous outcome-level request came back as something that did not solve the problem.
- Side channels appear. Decisions get made in a DM between two leads and surface later as a fait accompli.
- Commitments get soft. "We'll take a look" replaces "yes, by Thursday." Ambiguity is a defense mechanism.
What usually caused it
In my experience it is almost never a personality problem, which is why treating it as one fails. It is a history of broken promises, running in one or both directions.
Common origins: scope was added after a commitment was made, more than once. A date was set with a customer or the board without engineering in the room. A request for time to address platform debt was declined without an explanation, so it read as being overruled rather than deprioritized. A product decision was reversed and the team learned about it from a Slack thread.
Each of these is individually survivable. Three or four of them in a quarter teach both sides that the other's words are not reliable, and after that everyone starts protecting themselves — which is what the symptom list above actually is.
The repair sequence
Name it out loud, without assigning fault. "We've gotten into a pattern where commitments move after they're made, and I think that's making everyone hedge." Most teams are relieved someone said it. Skip the retrospective that turns into a grievance inventory — you are looking for the pattern, not the ledger.
Then go one full cycle without changing committed scope. This is the entire intervention and it is harder than it sounds, because something urgent will arrive in week two. Hold the line anyway, and let the team watch you hold it. One kept promise is worth more than any amount of stated intent.
Make the tradeoff visible. When something genuinely must come in mid-cycle, do the swap in the open: here is what is coming in, here is what is coming out, here is who decided. The problem was never that priorities change. It was that they changed invisibly and the cost landed on one team.
Put engineering into discovery, not just delivery. An engineer in customer conversations argues about scope differently afterward, because the constraint stops being an arbitrary demand from another department and becomes a shared problem. This is also the cheapest way to get better technical options on the table early, when they are still free.
Close the loop on debt. If platform work keeps losing, say why and say when it wins. A dated answer is survivable; silence is not.
What does not work as a first move: an offsite, a new ceremony, or a reorg. Those are answers to a coordination problem. This is a credibility problem, and credibility is repaired by a sequence of kept commitments and nothing else.
How long it takes
Two to three delivery cycles before behavior changes. The padding comes out of estimates last, because it is the most expensive thing for engineering to give up if you turn out to be unreliable after all. When estimates start getting tighter without being asked, the repair has taken.
This is frequently what an incoming fractional leader finds in the first month — it shows up in the diagnosis whether or not anyone flagged it. The first ninety days piece covers where it usually surfaces and how it gets sequenced against everything else.