the handover problem

there’s a version of this that happens visibly — a designer leaves the team, someone else picks up the project, and within a few months the design has drifted in ways nobody can fully explain.

but there’s a quieter version that happens in every team, constantly. the handover isn’t to a new person. it’s to the next phase. the work moves from research to design, from design to development, from design to stakeholder review. and at each transfer, something gets lost.

not the work. the reasoning.

the file gets passed on. the brief gets shared. the figma link goes into the project folder. but the conversation that happened while the decisions were being made — why that direction and not the others, what was tried and ruled out, what constraint was quietly shaping everything — that stays in someone’s head.

and because it’s never written down, it doesn’t travel.

so the person receiving the work has to reverse-engineer the intent from the output. they look at what was made and construct a theory of why. sometimes they get it right. often they don’t, and they don’t know they don’t, because there’s nothing to check against.

i’ve been on both sides of this. i’ve received work where the constraints were obvious in hindsight — once someone explained them — but invisible in the handover. i’ve made design decisions that seemed self-evident to me and arrived at the other end of the process looking like choices nobody understood.

the problem isn’t that the designer failed to communicate. it’s that handover formats are almost always about the deliverable, not the reasoning. here’s the file, here’s the brief, here’s the spec. the thinking that produced those things is treated as scaffolding — useful during construction, removed after.

except it’s not scaffolding. it’s load-bearing. the next person needs it to make any good decision about what comes after.

the fix is smaller than it sounds. before any significant handover, write a paragraph — not a document, a paragraph — about what problem the work is solving and what you traded off to get there. what you optimised for. what you deliberately left open.

it doesn’t have to be comprehensive. it has to be enough that the next person isn’t starting from zero when something unexpected comes up. because something always comes up.

the handover that includes the reasoning produces a different kind of collaboration than the one that doesn’t. questions get asked about intent, not just execution. decisions downstream actually connect to the thinking upstream. and when the work needs to change — which it will — people know what they’re allowed to change and what they’re protecting.

if your team is losing coherence across phases — if the work keeps arriving at implementation not quite matching what was intended — i can help trace where the reasoning is dropping out. that’s what synthesis is for. $300.