Why Handoffs Fail

Stress Concentrations in the Workflow

In finite element analysis, a stress concentration is what happens when a load path hits a geometric discontinuity — a hole, a notch, a sharp corner — and the stress field spikes locally, often to multiples of the nominal stress. The part doesn't fail uniformly. It fails at the transition. Engineering teams fail the same way, and handoffs are the notches.

Most post-mortems chase the wrong failure mode. They look for the bug, the missed requirement, the underestimated ticket. What they rarely surface is the moment a context-rich mental model got compressed into a Jira ticket and handed to someone who had none of the surrounding geometry. The failure isn't at the steady-state work — it's at the boundary between people.

The FEA analogy is worth taking seriously because it reframes the problem architecturally. You don't fix a stress concentration by making the surrounding material stronger. You redesign the geometry of the transition. For teams, that means rethinking how knowledge, intent, and assumption transfer across boundaries — not just working harder on either side of the handoff.

The uncomfortable truth is that most engineering organizations have optimized the nodes and ignored the edges. Individual engineers are skilled, documentation tools are sophisticated, sprint ceremonies are well-attended. But the moment a feature moves from product to engineering, or from senior to junior, or from one squad to another, the load path hits a discontinuity and the stress spikes. That's where the cracks propagate.

The Knowledge Gap — What Context Loss Actually Costs

When a senior engineer hands off a service they've owned for two years, what gets transferred is almost never what actually matters. The Confluence page captures the architecture. The README covers deployment. What doesn't get written down is the six-month-old conversation with a PM that explained why the retry logic is intentionally aggressive, or the prod incident that made someone add that seemingly redundant validation check. That tacit knowledge is the load-bearing structure, and it's invisible in the handoff.

Context loss compounds asymmetrically. The person handing off doesn't feel the loss — they still have the context in their head. The person receiving doesn't know what they don't know, so they can't ask the right questions. This is the classic unknown-unknowns problem, and it's particularly brutal in software because the consequences are deferred. The new owner operates confidently for weeks before they hit the edge case that the previous owner had mentally flagged as 'never touch this without understanding X first.'

The cost isn't just the downstream bug or the rearchitecture that happens because someone didn't know why a constraint existed. The deeper cost is trust erosion. The receiving team looks incompetent to stakeholders. The handing-off team gets pulled back in to fix things they thought they'd delegated. Both sides end up with a narrative that the other team 'doesn't get it,' when the real failure was structural — the handoff geometry was wrong.

A concrete pattern that surfaces repeatedly in scaling engineering orgs: a platform team builds something, hands it to product teams, and within a quarter the product teams have worked around it in ways that break the platform team's assumptions. Nobody is malicious. The product teams are solving real problems with the information they have. But the platform team's mental model of 'how this should be used' never made it across the boundary. The workarounds are rational responses to context loss.

The fix isn't more documentation in the abstract. It's documentation of the right things — specifically, the decisions that felt obvious at the time and therefore weren't written down. The constraints that came from a conversation, not a ticket. The assumptions that were load-bearing but invisible. This is harder than it sounds because it requires the handing-off party to model what the receiving party doesn't know, which is cognitively expensive and rarely incentivized.

Transferring the WHY — The Hardest Part of Any Handoff

There's a clean hierarchy of what gets transferred in a handoff, and it roughly maps to how hard each layer is to communicate. The WHAT — what the system does, what the feature is — transfers easily. It's visible, testable, demonstrable. The HOW — the implementation, the architecture, the operational runbook — transfers with effort. It requires documentation discipline, but it's tractable. The WHY — the reasoning, the tradeoffs, the constraints that shaped every decision — almost never transfers, and it's the most important layer.

The WHY is where intent lives. When you understand why a decision was made, you can make good decisions in adjacent territory. You know which constraints are fundamental and which are artifacts of a particular moment in time. You know what the original author would have done differently given six more months. Without the WHY, every deviation from the documented path becomes a gamble. The receiving engineer either follows the pattern blindly into contexts where it doesn't fit, or deviates from it without understanding what they're trading away.

A useful forcing function that some engineering leaders have adopted: the 'decision log' as a first-class artifact. Not an ADR in the traditional sense — those tend to be written for posterity and end up formal and sanitized. A decision log that captures the live reasoning, including the options that were rejected and why, the constraints that were active at the time, and critically, the assumptions that would have to be false for this decision to be wrong. That last piece is what makes a handoff durable.

The challenge is that explaining the WHY requires the handing-off party to be vulnerable about uncertainty. Most engineering culture rewards confidence and decisiveness. Saying 'we chose this approach because we assumed X, and if X turns out to be wrong then this whole thing should be reconsidered' feels like admitting weakness. It isn't. It's the highest-fidelity knowledge transfer possible. It gives the receiving party the actual mental model, not just the output of the mental model.

Teams that consistently execute good WHY transfers share a cultural trait: they treat the handoff itself as a design problem. They ask 'what does the receiving party need to know to make good decisions in this space?' and work backward from that. They run pre-mortem exercises on the handoff itself — 'six months from now, this handoff will have failed because...' — and use the answers to identify what's missing from the transfer package. It's unglamorous work, but it's the difference between a handoff that holds and one that becomes a recurring incident.

The Geometry of the Transition — Redesigning the Boundary

Going back to the FEA analogy: the engineering solution to a stress concentration isn't to add material at the failure point — it's to smooth the transition. A fillet radius at a sharp corner distributes the load over a larger area and eliminates the spike. For team handoffs, the equivalent is an overlap period where both parties are active on the system simultaneously — not a brief walkthrough, but a real period of shared ownership where the receiving party makes decisions and the handing-off party is available to provide context on demand.

The overlap period works because it converts unknown unknowns into known unknowns in real time. The receiving engineer hits an edge case, asks a question, and gets not just the answer but the surrounding context that explains why the answer is what it is. This is tacit knowledge transfer through apprenticeship, which is slower than documentation but dramatically higher fidelity. The problem is that it's expensive — the handing-off party is effectively doing two jobs for a period — and most organizations underinvest in it because the cost is visible and the benefit is counterfactual.

There's a structural intervention that works at the organizational level: treating handoffs as explicit project phases with their own definition of done. A handoff isn't complete when the ticket is closed or the deployment is done. It's complete when the receiving party has demonstrated, through real decisions, that they have the mental model they need. This requires defining what 'demonstrated understanding' looks like in advance, which forces the handing-off party to articulate what the receiving party needs to know — which is itself a valuable forcing function.

The teams that handle handoffs best tend to have high psychological safety not as a cultural aspiration but as an operational reality. The receiving party needs to be able to say 'I don't understand why this exists' without it being interpreted as criticism of the previous owner. The handing-off party needs to be able to say 'honestly, this part is a mess and here's why' without it being used against them. When those conversations can't happen openly, the handoff goes underground — people pretend to understand more than they do, and the stress concentration stays hidden until it fails.

Write Down the Assumptions — The One Practice That Changes Everything

If there's a single intervention that has the highest leverage in handoff quality, it's this: before any significant handoff, the handing-off party writes down every assumption they're currently operating under. Not the facts about the system — the assumptions. The things they believe to be true that haven't been verified recently. The constraints they've internalized so deeply they've stopped questioning them. The implicit agreements with stakeholders that live in email threads from eighteen months ago.

This practice is uncomfortable precisely because it's valuable. Assumptions that get written down get examined. Some of them turn out to be outdated. Some of them turn out to be wrong. Some of them turn out to be load-bearing in ways nobody had explicitly acknowledged. All of that is better to discover before the handoff than after. The receiving party gets a map of the terrain, including the minefields, rather than having to rediscover them through failure.

The assumption-writing practice also has a secondary effect: it forces the handing-off party to confront what they don't know they don't know. When you try to enumerate your assumptions, you hit the edges of your own mental model. You find the places where you've been operating on intuition rather than explicit reasoning. Those are exactly the places where the receiving party is most likely to make bad decisions, because they won't have the intuition and they won't have the reasoning to replace it.

Engineering leaders who've institutionalized this practice report that it changes the handoff conversation qualitatively. Instead of 'here's how it works,' the conversation becomes 'here's how it works, and here's what I believe to be true about the world that made this the right way to build it.' That's a fundamentally different transfer. The receiving party isn't just getting a system — they're getting a perspective, a set of priors, a way of thinking about the problem space that took the previous owner months or years to develop.

Why Personality Science Belongs in This Conversation

Everything described above is a structural and process intervention. But there's a layer underneath the process that determines whether any of it actually works: the people doing the handoff, and specifically, how they're wired to communicate, trust, and handle ambiguity. A highly conscientious engineer who scores low on openness will write excellent documentation but may not think to capture the reasoning behind decisions they consider obvious. A highly agreeable engineer may give the impression of a complete handoff — the conversation feels smooth, both parties leave satisfied — when the receiving party actually absorbed far less than they signaled.

This is where HEXACO personality science becomes operationally relevant, not as a soft-skills afterthought but as a predictive tool. The HEXACO model, which adds Honesty-Humility to the traditional Big Five dimensions, is particularly useful for handoff dynamics because it surfaces traits that directly predict knowledge-transfer behavior. High Honesty-Humility correlates with willingness to acknowledge uncertainty and flag assumptions explicitly — exactly the behavior that makes handoffs durable. Low scores on this dimension predict the confident-but-incomplete handoff that looks clean and fails six weeks later.

LU Teams uses HEXACO profiles to map these dynamics before they become incidents. When you can see, before a handoff happens, that the handing-off engineer tends to communicate at a level of abstraction that the receiving engineer finds insufficient, or that the receiving engineer's conflict-avoidance makes them unlikely to ask clarifying questions, you can design the handoff process to compensate. You add structured checkpoints. You assign a third party to probe for gaps. You change the geometry of the transition to match the actual people doing it, rather than assuming a generic process will work for any combination of personalities.

The FEA analogy holds here too. A stress concentration isn't just about geometry — it's about the material properties at the boundary. Two different materials joined at an interface have different elastic moduli, and the stress distribution at that joint depends on understanding both. Teams are the same. The handoff failure rate isn't just a function of process quality. It's a function of the specific combination of people at the boundary, their communication styles, their assumptions about what 'good enough' looks like, and their tolerance for ambiguity. Modeling that combination in advance is the difference between designing for the actual load case and designing for an idealized one that doesn't exist.