Greenbox has 9,500 subscribers, three cities, and a subscription system that Ravi has owned for eighteen months. He knows every edge case, every workaround, every reason behind every quirk. He’s about to take all of it with him.
Ravi sends the message to Maya on a Tuesday morning at 9:14am. It’s a direct message on Slack, not a meeting request. Three sentences.
“Hi Maya. I’ve accepted an offer at Canopy. My last day would be in two weeks, happy to discuss handover.”
Maya reads it at her desk with her coffee going cold. She reads it again. She puts her phone down, picks it up, reads it a third time.
Canopy is a well-funded Melbourne startup building supply chain software. The kind of company that recruits aggressively from mid-stage startups and offers salaries that Greenbox can’t match. Ravi has a new baby. His wife Meera went back to work last month. A 40% pay rise and a role with “senior” in the title is not something a rational person turns down.
Maya’s first instinct is to counter-offer. Match the salary. Offer equity. Promote him. Whatever it takes to keep the person who understands the subscription system better than anyone, including Tom.
She picks up her phone to call Lee. Then she puts it down. She calls Charlotte instead.
“Ravi’s leaving,” Maya says.
Charlotte is quiet for a moment. “When?”
“Two weeks.”
“How are you feeling?”
“I want to counter-offer.”
“Don’t.”
The advice Maya doesn’t want to hear
Charlotte and Lee both tell Maya the same thing, independently, within the hour.
Lee, over the phone from Margaret River: “If you have to beg someone to stay, they’ve already left. A counter-offer buys you six months of someone who knows they can leave whenever they want, and you’ve just taught them that the way to get a raise is to threaten resignation.”
Charlotte, in the small meeting room, more gently: “Ravi isn’t unhappy. He’s not making a statement. He got a better offer and he’s taking it. That’s normal. The problem isn’t that Ravi is leaving. The problem is that his departure is a crisis.”
Maya knows Charlotte is right. She knows it the way she knew the domain knowledge was stuck in her head during the Event Storm. She knows it, and she still wants to make the call.
She doesn’t make the call. She sits with the Slack message open on her screen for twenty minutes, then closes it and opens the calendar to look at the next two weeks. Every meeting with Ravi’s name on it now looks different. Every sprint planning session, every code review slot, every architecture discussion. Two weeks to transfer eighteen months of accumulated knowledge.
Two weeks is nothing. Two weeks is an insult to the complexity of what Ravi carries. But it’s standard, and Ravi has been professional about it, and the law says two weeks, so two weeks it is.
The announcement
Ravi tells the team at the Wednesday standup. He does it simply, at the end of his update, the way he does everything, calm, professional, slightly understated.
“I’ve accepted an offer at another company. My last day is in two weeks. I’m grateful for everything here. I want to make sure the handover is solid.”
Stunned silence.
Tom looks at Priya. Priya looks at her hands. Jas stares at the table. Sam’s jaw tightens almost imperceptibly.
Ravi is not dramatic. He’s never been dramatic. He joined Greenbox eighteen months ago with eight years of experience and a wife who was six months pregnant, and he quietly became the most knowledgeable person on the subscription system, the heart of Greenbox’s business. He wrote the pause feature. He built the retry logic. He implemented the seasonal pricing model. He asked the question about billing on delivery day that led to the first ADR. He sat in ensemble sessions and navigated with precision. He caught the bounded context violation in Priya’s farm reconciliation refactor.
He did all of this without fanfare, without ego, and without anyone noticing how much weight he was carrying until the moment he said he was putting it down.
Tom breaks the silence. “Is there anything we can do to change your mind?”
Ravi shakes his head. “It’s not about dissatisfaction. Canopy’s a good opportunity. The timing is right.”
The meeting ends. People drift back to their desks. The usual post-standup conversations don’t happen. Instead there’s a quiet spreading awareness, like water finding cracks in a floor: Ravi is leaving, and nobody knows what he knows.
Sam catches Maya in the corridor. “Did you know?”
“Since yesterday.”
“Are we going to be okay?”
Maya doesn’t answer immediately. She’s thinking about the subscription billing run that happens every Thursday, 9,500 charges, each one calculated based on box contents, regional pricing, and seasonal adjustments. Ravi built that pipeline. Ravi monitors it. Ravi is the person who gets paged when it fails and the person who knows which of the seventeen configuration parameters to check first.
“We’ll figure it out,” Maya says. She sounds more confident than she feels.
The scramble
Tom and Priya meet in the afternoon. The question is simple: who knows what Ravi knows?
They make a list.
The subscription system has eleven major components. Ravi built or substantially modified eight of them. The pause and resume logic. The billing integration. The seasonal pricing engine. The subscription migration tool for new cities. The retry mechanism for failed payments. The webhook handler for Stripe events. The subscriber lifecycle tracking. The reporting pipeline that feeds the board pack.
For each component, Tom asks: “If Ravi is gone and something breaks at 2am, who fixes it?”
The answer, for seven of the eight components, is the same: nobody, confidently.
Tom draws the matrix on the whiteboard. Eight components down the left side. Team members across the top. Green for “can debug and deploy independently.” Yellow for “can read the code but would need support.” Red for “doesn’t know it exists.”
The subscription system column is green for Ravi and yellow or red for everyone else. One green cell, about to walk out the door.
“Bus factor of one,” Priya says quietly. She’s heard Charlotte use the term. She’s heard it in the burnout conversations about Tom’s knowledge concentration. And yet here they are again, with a different person and the same problem.
Priya can read the code. She’s reviewed most of Ravi’s PRs. But reading code and understanding its intent are different things. The seasonal pricing engine has a function called apply_regional_adjustment that modifies prices based on a combination of growing region, season, and supply constraints. The function is well-tested but the tests describe what it does, not why. The business logic behind the regional adjustments lives in Ravi’s head, the conversations with Maya about why Perth prices differ from Melbourne’s, the decision to cap adjustments at 15% to avoid customer shock, the edge case where two regions share a growing season and the adjustment should apply to neither.
The ADRs help. The billing-on-delivery-day ADR that Charlotte introduced, the one that started because of Ravi’s question, captures the reasoning for the payment timing. But ADRs cover architectural decisions, not domain logic. The regional pricing rules aren’t architecture. They’re business knowledge encoded in code.
Tom opens the subscription codebase and searches for comments. He finds one in the retry mechanism:
// Ravi knows why this is here
He stares at it for a long time.
The handover
Ravi is generous with his time. He schedules handover sessions every afternoon for two weeks, ninety minutes each, with Priya and Tom alternating, and sometimes both together. He prepares notes. He draws diagrams. He walks through the code methodically, explaining not just what it does but why it does it that way.
The sessions are productive and slightly heartbreaking. Every session surfaces knowledge that should have been documented months ago.
“Why does the retry wait seven minutes before the second attempt instead of five?”
“Because Stripe’s rate limiter has a soft reset at six minutes. If you retry at five you’ll hit the limit again. I found this when the Brisbane launch caused a spike in failed payments.”
“Is that documented anywhere?”
“It’s in a Slack thread from… April? Maybe. And a comment in the test file.”
Priya writes it down. ADR-047: Stripe retry timing.
“Why does the regional adjustment cap at 15%?”
“Maya and I agreed on that during the Brisbane pricing discussion. Higher than 15% and customers feel like they’re being price-gouged. Lower than 10% and we can’t cover supply variance. 15% was the compromise.”
Tom writes it down. Nobody ever recorded that decision. It was a conversation between two people in a meeting room nine months ago.
“Why does the subscription migration tool run on Sundays?”
“Because it’s the only day the billing system isn’t processing renewals. The migration locks certain tables. If a renewal hits during the lock, the transaction fails silently. I know because it happened during the Melbourne migration and I spent a weekend fixing it.”
Priya writes that down too. A production incident that nobody wrote a post-mortem for, fixed by one person over a weekend, never documented.
By the end of the first week, Priya has filled two notebooks. Tom has written fourteen ADRs. Ravi keeps discovering things in his own head that he’d forgotten he knew, small decisions, edge cases, workarounds, configurations. The tacit knowledge is enormous. Two weeks is not enough to transfer it. Two months wouldn’t be enough.
On Thursday afternoon, during the fifth handover session, Ravi stops mid-sentence. He’s been explaining the webhook handler’s retry queue and he’s just described a workaround for a Stripe API quirk that he implemented eleven months ago.
“I never told anyone about this,” he says. “Not because I was hoarding it. Because it never came up. It just… lived in my head. I knew it, and because I knew it, nobody else needed to.”
Priya looks up from her notebook. “How many more of these are there?”
Ravi thinks about it honestly. “Dozens. Maybe more. Things I’d do automatically if something broke at 2am. Patterns I’d recognise. Error messages I’d know the fix for. It’s not in any document because it’s not the kind of thing you document. It’s the kind of thing you learn by being the person who gets woken up.”
This is the distinction between documented knowledge and tacit knowledge. Documented knowledge is the ADR, the runbook, the test suite. Tacit knowledge is the instinct that says “check the webhook queue first” or “that error usually means the config cache is stale.” You can’t transfer tacit knowledge in a handover session. You can only transfer it by working alongside someone for months, in the same codebase, handling the same incidents.
The exit interview
Charlotte runs the exit interview on Ravi’s second-to-last day. She does it in the kitchen, not a meeting room, because Ravi has always been more comfortable in informal settings.
“What would have made you stay?” Charlotte asks.
Ravi thinks about it. “Money, honestly. Not because I’m mercenary. Because Meera and I have a baby and a mortgage and the market rate for what I do is higher than what Greenbox pays. I love the team. I love the work. I couldn’t afford to love it.”
“Was there anything else?”
“Career path. I’ve been ‘developer’ for eighteen months. The subscription system is the most critical thing Greenbox has, and my title is the same as someone who joined last month. Canopy offered me ‘Senior Engineer’ and a path to staff. Greenbox doesn’t have engineering levels.”
Charlotte notes this. Greenbox’s flat structure, the thing Maya values, the thing that made it feel like a startup rather than a corporation, has a cost. When everyone is “developer,” the person who owns the most critical system has the same title and similar pay to someone maintaining the farm portal’s CSS. There’s no formal recognition of the depth Ravi has built.
“What should Greenbox do differently?”
Ravi pauses. “Don’t let one person own anything this important. I know that sounds self-serving coming from the person who owned it. But the subscription system should never have been mine. It should have been the team’s. Pair on it. Rotate who reviews it. Make sure at least three people can debug it at 2am.”
“Why didn’t you raise that while you were here?”
Ravi looks at his hands. “I liked being the expert. It felt good to be the person everyone came to. I didn’t want to give that up.” He pauses. “That’s probably the most honest thing I’ve said in an exit interview.”
What the team learns
Ravi’s last day is a Friday. The team buys a cake. Sam organised it, chocolate, from the bakery on the corner, with “Thanks Ravi” in green icing that matches the Greenbox brand. It’s a small gesture and it matters.
Ravi shakes hands with everyone. He hugs Priya, which surprises her. He gives Tom a USB drive with his personal notes on the subscription system, the things that didn’t make it into the handover sessions. Tom holds the USB drive like it’s made of glass.
“It’s just text files,” Ravi says. “But they’re annotated. The stuff I couldn’t explain in ninety minutes.”
Maya gives a short speech. She’s not sentimental by nature, but she means every word. “Ravi joined us eighteen months ago and quietly became the person who held the most important part of our system together. He did it with grace, with patience, and without ever making it about himself. We’re losing a great engineer and a better colleague.”
Ravi looks at his shoes. He’s never been good with public attention. Meera would tell you he proposed in the car, not in a restaurant, because he couldn’t stand the idea of people watching.
“I learned more here than anywhere I’ve worked,” Ravi says. “The ensemble sessions, the ADRs, the way you lot actually talk to each other about what you’re building. I didn’t know work could be like that.”
Meera picks him up at five. The baby is in the car seat, asleep. Ravi waves from the passenger window. The team watches from the office kitchen, cake plates in hand. Then he’s gone.
The following Monday is strange. The standup has a gap where Ravi’s update used to be. Tom catches himself about to Slack Ravi a question about the retry mechanism, then stops. Priya opens the subscription codebase and reads the comment – // Ravi knows why this is here, and makes a decision.
She spends the next two hours tracing the code. She finds the reason: a race condition between the webhook handler and the billing renewal that only manifests when a customer pauses and resumes within the same billing cycle. The function prevents a double charge. Ravi added it after a customer support ticket from Mrs Patterson, subscribed since week three, loyal through everything.
Priya deletes the comment and replaces it with a proper explanation. Six lines describing the race condition, the customer impact, and the fix. She commits it with the message: “Document retry guard, previously tribal knowledge.”
Then she writes ADR-051.
The no-single-owner rule
At the retro the following Friday, Charlotte facilitates a discussion about what the team wants to change.
The answers are unanimous.
No single owner for any critical system. Every component of the subscription system, the billing pipeline, the farm reconciliation, and the delivery scheduling must have at least two people who can debug, modify, and deploy it. Not just read the code. Understand the intent.
Rotation through critical systems. Every quarter, a developer who hasn’t worked on a critical system pairs with someone who has. Not a full handover, a week of pairing, enough to build familiarity and catch undocumented knowledge.
Exit documentation as a continuous practice. Not something you do in someone’s last two weeks. An ongoing process: every month, each developer spends an hour documenting the thing they know that nobody else does. Charlotte calls it “writing your own handover notes while you’re still here.”
Engineering levels. Tom and Maya agree to build a career ladder. Developer, Senior Developer, Staff Engineer. Not just titles, clear expectations, compensation bands, and a path that doesn’t require leaving to get a raise. This one takes months, and it’s still rough around the edges when the next hire starts. But it exists.
Tom looks at the list. “We learned all of this because someone left.”
“You learn it because someone left, or you learn it because someone gets hit by a bus,” Charlotte says. “One of those scenarios has a handover period.”
Sam, who has been quiet through the retro, adds something practical. “We should do Ravi’s exit interview format for everyone. Not when they leave. Every six months. Sit down with people and ask: what would make you leave? What’s missing? What would you change?”
“Stay interviews,” Charlotte says. “They’re a real practice. Most companies only ask those questions when it’s too late.”
Maya writes it down. A stay interview every six months. Not to prevent departures, you can’t prevent all departures, and you shouldn’t try. To understand what people need before they start looking elsewhere. To fix the things that are fixable while there’s still time.
What Ravi’s departure reveals
Every organisation has knowledge that lives in people’s heads. The question is how much, and what happens when those heads walk out the door.
Ravi’s departure revealed that Greenbox’s most critical system was held together by one person’s understanding. Not one person’s code, the code was well-written, well-tested, and maintainable. One person’s context. The reasons behind the decisions. The edge cases discovered in production. The conversations with Maya about pricing. The Slack threads about Stripe rate limits. The weekend incident that nobody wrote up.
The ADRs captured some of it. The ensemble sessions spread some of it. But the gap between “documented” and “understood” was wider than anyone realised until the person who bridged that gap handed in their notice on a Tuesday morning.
The lesson isn’t “don’t let people leave.” People leave. That’s normal. The lesson is: build systems that survive normal events.
A departure isn’t a crisis. It’s a Tuesday. The system should be able to handle a Tuesday.
Six months later
Priya is the subscription system’s primary maintainer now. She’s not alone, she pairs with a Brisbane developer every fortnight, and Tom reviews the architectural decisions. Three people can debug the retry mechanism at 2am. The regional pricing logic is documented in four ADRs and a decision table that Maya helped write.
Ravi messages the Greenbox Slack occasionally. He sends a photo of the baby’s first birthday. He asks how the seasonal pricing refactor went. He recommends a conference talk about event sourcing.
He’s happy at Canopy. The team is glad he’s happy. There’s no bitterness. There shouldn’t be. Ravi was a good colleague who made a rational decision for his family. The system that made his departure painful wasn’t his fault, it was a structural problem that existed long before he arrived and would have existed whether or not he left.
Maya learns something from Ravi’s exit interview that changes how she thinks about retention. It’s not always about culture, or purpose, or the quality of the work. Sometimes it’s about money and career progression. And if you don’t offer competitive compensation and a visible career path, the people you most need to keep are the people most likely to leave, because they’re the ones with options.
The // Ravi knows why this is here comment is gone from the codebase, replaced by Priya’s six-line explanation. But Tom keeps a screenshot of it on his desktop. Not as nostalgia. As a reminder.
Every comment that says “ask [person]” is technical debt of the most dangerous kind. Not code debt, knowledge debt. And unlike code debt, you don’t get to choose when it comes due. It comes due when someone sends a three-sentence Slack message on a Tuesday morning, and there’s nothing you can do but wish you’d written it down sooner.
Ravi was the best kind of colleague, thoughtful, skilled, generous with his time when he knew he was leaving. The system shouldn’t have needed him to be irreplaceable. That it did is nobody’s fault and everybody’s responsibility. The fix isn’t to stop people from leaving. The fix is to build a team where leaving is normal and survivable. Where the knowledge lives in the system, not the person. Where a quiet departure on a Tuesday morning is exactly what it should be: a Tuesday.