Greenbox has 9,000 subscribers, three cities, twenty-eight people, and a technical backbone that has held together through every expansion, every migration, every 2am incident. That backbone is a person. His name is Tom, and he’s starting to crack.
The deploy goes out on a Friday afternoon at 4:47pm.
A year ago, Tom would never have deployed on a Friday afternoon. He’s the person who helped Charlotte write the no-deploys-on-Friday policy. He’s the person who added the automated rollback to the CI/CD pipeline. He knows the rule. He wrote the rule.
But the subscription billing fix has been waiting since Wednesday. The bug is small, a rounding error in the GST calculation for Brisbane subscribers that’s overcalculating by two cents per box. Two cents. It affects 1,200 people. Nobody has complained yet, but Sam noticed it in the monthly reconciliation and flagged it as urgent.
Tom looks at the fix. Four lines. He’s tested it locally. The staging environment is green. The canary deployment will catch any regression. It’s fine. It’s four lines.
He deploys.
At 6:12pm, while Tom is driving home, the billing service starts throwing 500 errors. Not from Tom’s four-line fix, from a database migration that was queued behind it in the deployment pipeline. The migration locks the billing table. Subscriptions that try to renew during the lock window fail silently. No charges go through. No error is surfaced to customers. The system just… stops billing people.
Sam’s phone buzzes at 6:30pm. Then again. Then again. She calls Tom.
Tom is at a red light on Stirling Highway. Leo is asking about dinner from the back seat. Ava is complaining about homework. Sarah is driving. Tom looks at his phone, sees five missed alerts and Sam’s call, and feels something he hasn’t felt before: nothing. Not panic. Not urgency. Not the familiar spike of adrenaline that makes him sharp. Just a flat, grey nothing.
He answers. “I’ll look at it when I get home.”
A year ago, Tom would have pulled over, opened his laptop on the bonnet, and fixed it in the car park. Tonight, he tells Sam he’ll handle it after dinner.
He doesn’t handle it after dinner. He falls asleep on the couch at 8:30pm. Priya rolls back the deploy at 9:15pm, having figured out the migration issue from the error logs. She messages Tom: “Rolled back. No customer impact, billing retry caught everything. We’re fine.”
Tom doesn’t see the message until Saturday morning. He reads it, puts his phone down, and stares at the ceiling for a long time.
The signs nobody names
Priya notices first. She’s noticed things before, she’s the person who spotted the Event Storm photos fading, the person who caught the bounded context violation in the Perth API change, the person who fills notebooks with things other people miss. She notices Tom.
It’s not one thing. It’s a dozen small things that add up to a pattern she can’t ignore.
Tom’s code reviews used to be thorough, detailed comments, architectural suggestions, questions that made you think. Now they’re one-line approvals. “LGTM.” “Looks good.” “Fine.” Priya submitted a PR last week with a deliberate edge case bug to see if Tom would catch it. He didn’t.
Tom used to arrive at the office with energy, not performative enthusiasm, but the quiet hum of someone who likes what they do. Now he arrives at the office. That’s the whole sentence.
Tom used to argue in architecture discussions. He’d push back on Charlotte’s suggestions, challenge Ravi’s approaches, debate with Priya about testing strategies. The arguments were productive, they sharpened decisions and built shared understanding. Now Tom agrees with everything. “Sure. Sounds good. Whatever you think.” Not because he’s become more collaborative. Because he’s stopped caring enough to disagree.
Tom used to leave the office at six. Then it was seven. Then eight. Now he’s sometimes still there at nine, but he’s not shipping more. He’s staring at his screen, rereading the same function, unable to hold the logic in his head. The hours go up. The output goes down. He stays late because he can’t finish things at the pace he used to, and he can’t finish things at the pace he used to because he’s exhausted from staying late.
Priya pulls Tom aside after a Wednesday standup. They’re in the kitchen. Priya is making tea. Tom is holding an empty mug and staring at the kettle.
“When did you last take a day off?” Priya asks.
Tom thinks about it. “I took a half day when Leo had his school concert.”
“When was that?”
“August. Maybe July.”
It’s December. Tom hasn’t taken a full day off in at least four months. He’s been the first to respond to every production alert, the last to leave after every incident, the person who reviews every PR from every squad, the person who joins every architecture discussion even when it’s not his area. He’s been the technical backbone of Greenbox since day one, and nobody has ever asked whether that backbone needs a rest.
“Tom,” Priya says. “It’s December.”
“I know what month it is.”
“Do you? Because you deployed on a Friday afternoon yesterday. You. The person who wrote the Friday deploy policy.”
Tom puts his mug down. He doesn’t say anything for a long time. Priya waits.
“I just wanted it done,” he says. “I couldn’t carry it into next week. I can’t carry anything into next week. Everything is already in next week.”
Priya hears the sentence and understands that this isn’t about a deploy. This is about a person who has been carrying too much for too long, and the weight has stopped being something he notices and started being the shape of his life.
The health check
Charlotte runs a team health check the following week. She’s been doing them quarterly since the ensemble programming sessions. Same format, eight dimensions, anonymous, 1 to 5.
The results come back. Most scores are healthy. Speed: 4/5. Quality: 4/5. Mission: 4/5. Teamwork: 4/5. The team has recovered well since the Jordan episode and the coordination structures are working.
Two scores are not healthy.
Support: 2/5. Fun: 1/5.
Charlotte has seen this pattern before. High speed, high quality, low support, low fun. It means the team is productive but unhappy. It means people are delivering because they feel they have to, not because they want to. It means the pace is unsustainable and people are starting to withdraw.
She asks a follow-up question she doesn’t normally ask: “On a scale of 1 to 5, how sustainable is your current pace?”
Anonymous. Every answer is the same number: 1.
Charlotte shows the results to Maya on a Friday morning. Maya reads them in the small meeting room, the Event Storm photos behind her, the laminated sticky notes still bright after two years.
“One,” Maya says. “Every single person said one.”
“Every single person.”
Maya puts the printout down. “I’ve been asking Tom to ‘just handle it’ for two and a half years.”
“Yes.”
“I did the same thing with the domain knowledge. Kept it all in my head and expected everyone to route through me. Now I’ve done it with the workload. Kept it all on Tom and expected him to carry everything.”
Charlotte doesn’t correct her. Maya is being harder on herself than the situation warrants, the team’s pace is a system problem, not a personal failure. But the recognition is real, and Charlotte knows not to soften a moment of clarity.
What burnout actually looks like
Burnout doesn’t look like a dramatic collapse. It doesn’t look like someone slamming their laptop and walking out. It doesn’t look like a breakdown in a meeting room.
It looks like Tom.
Tom is still functional. He’s still at his desk every morning. He’s still responding to Slack messages, still attending standups, still reviewing PRs. He hasn’t missed a deadline. He hasn’t made a catastrophic error. From the outside, Tom looks like Tom, a little quieter, a little slower, but still there.
That’s what makes burnout dangerous. The visible symptoms, the Friday deploy, the one-line reviews, the staring at the kettle, are easy to explain away individually. He’s tired. He’s having an off week. He’ll bounce back after the holidays.
He won’t bounce back after the holidays. A weekend doesn’t fix burnout. A week’s holiday doesn’t fix burnout. Burnout is what happens when the recovery time is consistently shorter than the depletion time, for months, until the deficit becomes structural.
The research on burnout identifies three dimensions: exhaustion, cynicism, and reduced professional efficacy. Tom has all three. He’s exhausted, the kind of tiredness that sleep doesn’t fix. He’s cynical, the architecture discussions he used to love now feel like noise. And his professional efficacy is declining, the code he writes takes longer and has more bugs than it used to.
Tom hasn’t changed. The system around him has. Three years ago, one senior developer could hold the technical direction of a five-person team. Now one senior developer is expected to hold the technical direction of a twenty-eight-person company across three cities, and nobody adjusted the expectation when the denominator changed.
Tom takes two weeks off
Lee is the one who makes it happen. He calls Maya on a Saturday morning, unusual for Lee, who respects boundaries. He’s heard about the Friday deploy from Sam. He’s heard about the health check scores from Charlotte. He’s heard about the kettle conversation from Priya, who mentioned it in passing.
“Tom needs to stop,” Lee says. “Not slow down. Stop. Two weeks minimum. No laptop, no Slack, no phone calls about work.”
“We can’t afford to lose Tom for two weeks,” Maya says.
“You can’t afford not to. What you’re doing right now is borrowing against his future capacity. Eventually the loan comes due, and the interest rate is someone walking out the door.”
Maya books a call with Tom for Monday morning. She tells him he’s taking two weeks off, starting Wednesday. Not optional. Not “when it’s convenient.” Wednesday.
Tom’s first reaction is to list the things that will break.
“The Adelaide onboarding is next week. The Perth billing migration is halfway through. Ravi’s subscription refactor needs architectural review. The Melbourne squad’s API versioning –”
“Tom,” Maya says. “Stop.”
“I can’t just –”
“Who else can do the Adelaide onboarding?”
Tom opens his mouth. Closes it. The Adelaide onboarding is a technical setup he’s done three times before, for Perth, Melbourne, and Brisbane. He’s never written it down. He’s never taught anyone else. The procedure lives in his head.
“Nobody,” he says. “Nobody else knows how.”
“What about the billing migration?”
“I’m the only one who understands the legacy schema.”
“And the subscription refactor?”
“I’ve been the architectural reviewer for every major change since –” Tom stops. He sees what Maya is showing him. Not a list of things that will break. A list of things that depend on one person. A bus factor of one, replicated across every critical system in the company.
“This is the problem,” Maya says gently. “Not the two weeks. The fact that we can’t survive two weeks without you.”
What breaks
Tom leaves on Wednesday. He takes Sarah and the kids to Margaret River for a fortnight. Sarah has been wanting to go since September. Leo wants to see the caves. Ava wants to read on the beach. Tom wants to sleep.
Back at Greenbox, the gaps appear immediately.
The Adelaide onboarding stalls. Priya picks it up, but Tom never documented the infrastructure provisioning steps. She spends two days reverse-engineering the process from the Brisbane deploy logs and the Perth configuration files. She documents everything as she goes, writing the runbook that should have existed from day one.
The billing migration slows. Ravi takes over the architectural review, but the legacy schema has undocumented quirks, fields that look like they should be nullable but aren’t, foreign key relationships that exist in practice but not in the schema definition. Ravi messages Tom on Slack out of habit, then deletes the message. He figures it out. It takes him three times as long as it would have taken Tom.
The Melbourne squad’s API versioning ships without architectural review. Anika makes the call. It’s fine. It was always going to be fine, the versioning strategy was well-established in the ADRs. The review was a formality that existed because Tom was always available to provide it.
Three things break. All three are fixable. All three reveal the same underlying problem: knowledge and authority concentrated in one person.
The structural changes
Tom comes back on a Monday. He looks different, not transformed, but rested. The grey flatness behind his eyes is lighter. He sat on a beach for two weeks while his children built sandcastles and his wife read novels, and he slept nine hours a night for the first time in three years.
At the Wednesday team meeting, Maya and Charlotte present the changes. They’ve spent Tom’s absence building a plan.
On-call rotation. Production alerts no longer go to Tom by default. A formal rotation of four people. Tom, Priya, Ravi, and Anika, covers the week in shifts. Each person does one week in four. They’re compensated for it. The rotation starts immediately.
Pair programming for critical systems. Any change to the billing system, the subscription engine, or the farm reconciliation pipeline requires two developers. Not optional. Not “when convenient.” Two people, always. This builds redundancy and spreads knowledge.
No deploys on Fridays. The rule that already existed but that Tom broke. Now it’s enforced in the pipeline. The deploy button is literally disabled after 2pm on Fridays. Tom looks slightly embarrassed. Priya catches his eye and smiles.
Mandatory leave. Every team member takes a minimum of one week off per quarter. Not rollover. Not buyback. One week, away from work, not checking Slack. Maya puts herself on the list first.
Architecture review rotation. Tom is no longer the sole architectural reviewer. Priya and Ravi join the rotation. They’ll shadow Tom for a month, then take reviews independently. The ADRs provide the context they need.
Runbooks for every critical process. Priya’s Adelaide onboarding documentation becomes the template. Every process that lives in one person’s head gets written down. Not as a side project. As a priority, scheduled into sprint planning.
Tom reads the list. “This is a lot of meetings,” he says. Old habit.
“This is a lot of people sharing what used to be your burden,” Charlotte says. “The meetings are the mechanism. The goal is that no single person is indispensable.”
Tom knows the word for this. He’s heard Charlotte use it. Bus factor. The number of people who can be hit by a bus before the project is in trouble. For three years, Greenbox’s bus factor for critical technical knowledge has been one.
Sustainable pace
The changes aren’t just about Tom. They’re about a principle that the team has violated since day one.
Extreme Programming calls it “sustainable pace”, the principle that teams should work at a pace they can maintain indefinitely. Not a sprint pace that requires recovery. Not a crisis pace that requires heroism. A steady pace that produces good work, week after week, without anyone burning out.
Greenbox has never had a sustainable pace. They’ve had a startup pace, fast, intense, fuelled by passion and the implicit promise that things will ease up “once we get past this next milestone.” The next milestone was the Melbourne launch. Then the Brisbane launch. Then the B2B pilot. Then the Adelaide expansion plan. The promise kept moving. The pace never eased.
Charlotte draws it on the whiteboard.
“Heroic pace is borrowing from the future,” Charlotte says. “You’re spending tomorrow’s energy today. It works for a while. It always stops working.”
Tom looks at the whiteboard. He’s been the hero for three years. Not because anyone asked him to be, though Maya did, implicitly, in every “can you just handle this” message. Because he wanted to be. Because being the person who holds everything together felt like being important. Because the alternative, slowing down, sharing the load, admitting he couldn’t carry it all, felt like failure.
“I thought if I stopped, everything would fall apart,” Tom says.
“It didn’t,” Priya says. “We had two bad days. Then we figured it out.”
The connection to everything else
Burnout and bus factor are the same problem.
When one person carries critical knowledge, their absence is a crisis. When one person carries the workload, their burnout is inevitable. The solution to both is the same: distribute. Distribute the knowledge through ADRs and runbooks. Distribute the work through on-call rotations and pair programming. Distribute the authority through management structures that don’t depend on one person signing off on everything.
The common thread is that systems shouldn’t require heroes. Heroes are single points of failure in human form. They’re the bus factor of one, the deploy key in one person’s pocket, the domain knowledge in one person’s head. When the hero is healthy and present and motivated, everything works. When the hero deploys on a Friday afternoon because they’re too tired to think straight, everything breaks.
Tom messages Priya that evening from his desk at home. Leo is asleep. Ava is reading. Sarah is watching something with the volume low.
I think I’ve been scared to let go for three years.
Priya replies at eleven, because Priya always replies at eleven: You don’t have to carry everything. That’s what teams are for.
Tom puts his phone down. He doesn’t open his laptop. He goes to bed at a reasonable hour, for the first time in months, and sleeps without dreaming about error logs.
It’s not fixed. Burnout doesn’t resolve in a fortnight. But the structure is different now. The system doesn’t need a hero any more. It needs a team, working at a pace they can maintain, sharing the load by design rather than by desperation.
That’s the sustainable pace. Not fast. Not slow. Maintainable. The kind of pace you can keep up for years without anyone breaking.