The PM role I left had 650 documents prepared for whoever came next. None of them said what the team would actually need.
I want to write about transitions — what happens when someone leaves a role and someone else steps into it. Not about handoff process, exactly. About what the new person carries that nobody handed them, and that the documents couldn’t catch.
I’ll use a PM transition I lived through directly, but the pattern is broader. Vendor changes do this. Leadership changes do this. A new designer joining a senior team does this. The mechanic is the same: a role isn’t just a set of responsibilities, it’s a set of relationships that took months to negotiate, and those relationships don’t migrate when the person does.
The handoff fiction
The standard handoff story is technical. The outgoing person writes documentation. The incoming person reads documentation. Information transfers. Continuity is preserved. This is what documentation is for.
In my case, this part actually went well. Over seven months I wrote more than 650 documents — architecture decisions, requirements specs, meeting notes, vendor evaluations, decision logs. By the time I left, the new PM could trace any major decision to its rationale, any feature to its requirements, any vendor relationship to its negotiation history. The documentation, by industry standards, was excessive.
It wasn’t enough.
What documentation captures is what was decided and why we decided it. What it doesn’t capture, because it can’t, is how the team felt about the decision. Whose buy-in was real and whose was performative. Which engineer the previous PM trusted to push back on bad specs. Which stakeholder needed to be told twice before they’d remember. The undocumented map of who actually drove what — that map lived in my head, and when I left, it left with me.
What the new person actually inherits
The new PM walked into the same job description I had. They inherited the same documentation. They also inherited five other things, none of which were on the handoff list.
Trust topology. Every team has a quiet map of who’s trusted for what. Talk to this engineer when the issue is the database; talk to that engineer when it’s anything front-end. This designer’s reviews are gospel; that designer’s reviews are advisory. This stakeholder will say yes in a meeting and email you a no on Monday. I’d negotiated all of that over months. The new PM had it as a blank slate. Their first month was a series of trust-bets they didn’t know they were making.
Communication channels. Some decisions on this team happened in Slack DMs. Some happened in scheduled syncs. Some happened in a Telegram channel I’d been added to in week three of my tenure and forgotten existed by week thirty. Documentation listed the official channels. Reality was a layered map of unofficial ones, each with its own conventions about response time and tone. Channels are the substrate of decisions; you can’t make decisions on a substrate you don’t know exists.
Blame patterns. The last time we shipped on a Friday, this happened. The last time we promised this stakeholder a date, they held us to it for six months past the slip. Teams remember. Documentation usually doesn’t write down blame patterns because they’re embarrassing. But blame patterns are a high-resolution forecast of what the team will resist next, and a new PM walking in fresh will accidentally trip every one of them in the first quarter.
Decision context the docs don’t capture. The architecture decision record says we chose hybrid filtering. It does not say we chose hybrid filtering because the lead engineer had a strong opinion that the alternative would create a maintenance burden, and overriding their opinion in week three would have cost more than it bought. The political weight of every decision — who pushed for it, who agreed reluctantly, what the alternative would have cost in human terms — those don’t make it into ADRs because ADRs are written for outsiders. The political subtext is what runs the team.
Team posture. Some teams default to pessimism; some to optimism. Some are recovering from a recent failure and still flinching; some are riding a recent win and over-committing. The team I left had a particular posture I’d helped shape over months — cautious about scope, eager about quality, allergic to surprises. The new PM inherited that posture, didn’t know they’d inherited it, and read several of their first weeks’ interactions through a lens that wasn’t theirs.
Why this is a design problem, not just a process one
Most writing about transitions treats them as a process problem. Better handoff documents. Longer overlap periods. More structured shadow weeks. These are real and they help.
But the deeper problem is that the system a team operates inside has both an explicit shape (org chart, documentation, processes, codebase) and an implicit shape (trust topology, communication channels, blame patterns, decision context, posture). The explicit shape transfers via documentation. The implicit shape transfers via time spent inside it — and a new arrival hasn’t spent time yet.
The interface between explicit and implicit is exactly where design lives. The product I designed for that team had a particular shape because the team had a particular posture. The decisions I’d made about feature scope, about UX trade-offs, about which edge cases to push and which to defer — those decisions were legible to me because I’d absorbed the team’s posture over months. They were less legible to anyone else. When I left, the docs explained what I’d designed but not why those particular trade-offs felt right at the time.
This is why design that gets handed off without context tends to drift. Not because the new designer makes worse choices — often they make better ones — but because the previous design’s coherence depended on a context that no longer exists in the room.
What the new arrival should actually do
The most useful thing I’ve seen new arrivals do, in my own transitions and in others I’ve watched, is resist the urge to do things in the first weeks. Reading inherited shape is real work. It looks like nothing. It produces no artifacts. But it’s the only way to acquire the implicit map that lets the explicit one make sense.
Concretely:
- Listen for which decisions get re-litigated and which don’t. Re-litigated decisions have weak political consensus; the docs may say they’re settled but the team hasn’t accepted them.
- Ask the team — separately — who decides X and who decides Y. The answers will diverge. The divergences are the trust topology.
- Watch for what doesn’t get said in the official channels. The most important decisions on most teams happen in side conversations; the channels you’re in are not the only ones that matter.
- Notice the team’s emotional weather before introducing change. A team in week eight of a delayed launch will receive a process change differently than a team in week one of a successful one.
None of this is in the handoff documents because none of it can be. It’s the substrate the documents float on top of. Reading it takes weeks. Doing things before reading it is the source of most “the new person changed everything and now nothing works” stories.
The principle
A role isn’t a set of responsibilities. It’s a set of relationships that took months to negotiate, layered over a substrate of conventions, trust patterns, and undocumented context that the previous occupant absorbed by living inside them.
When the role transfers, the responsibilities transfer cleanly. The relationships don’t. The substrate doesn’t. The new person inherits a job that looks like the old one and feels like a different one — because, in the parts that matter, it is.
The most generous thing the outgoing person can do is name the parts that don’t transfer. The most generous thing the incoming person can do is take the time to read them. Documentation helps. Documentation isn’t enough.