Treat Your Absence Like a Handoff
A teammate is out. Something comes up with a feature they were working on. You check Slack and find one message from two days ago: "Out this week, back Monday."
You dig through tickets. You find a PR with no description and a comment thread that trails off mid-decision. You spend 30 minutes reconstructing context that should have taken 30 seconds to find. Eventually, you make your best guess and move on, hoping you got it right.
The teammate did communicate, but failed to share the most important information.
This is one of the more common sources of friction on software teams, and it tends to get attributed to everything except its actual cause.
The delayed PR review, the question that sat unanswered for two days, the decision that got made twice because no one knew it had already been discussed — these get logged as bad luck or poor timing. They are usually the result of an incomplete handoff.
When someone goes out and leaves enough context, their team keeps moving. When they do not, the people left behind absorb the cost.
How Your Vacation Becomes a Bottleneck
Software teams use a concept called the bus factor to measure this kind of vulnerability. The bus factor is the number of people who would need to become unavailable before a project stalls. A bus factor of 1 means a single person’s absence can stop work.
Teams usually think of the bus factor as a long-term risk — what happens when someone leaves the company, or moves to another team. But a low bus factor shows up in smaller ways constantly. Every time someone goes out for a week and no one else knows where their work stands, the team’s bus factor for that work becomes 1 for the duration of the absence.
The teammate who checks out without leaving context has not technically done anything wrong. They told people they would be gone. What they did not account for is what happens to the people carrying on the work while they are away.
Context switching is more expensive than it looks. When a teammate has to stop what they are doing to reconstruct your work, find the right person to ask, or wait until you are back to get an answer, that interruption compounds. One unclear absence message can trigger several of those interruptions across multiple people over the course of a week.
What to Communicate When Taking Time Off
A useful absence message answers three questions: what is currently in motion, what might need attention while you are gone, and who to reach if something comes up.
That framing is straightforward, but it requires you to think through your work from someone else’s perspective. Most engineers do not do that until they have been on the receiving end of a gap enough times to know what actually helps.
For planned PTO, aim for a message that lets a teammate handle anything time-sensitive without needing to reach out to you. That means covering:
- Active work: What is in progress, where it stands, and whether anything has a deadline during your window
- Pending decisions or blockers: Anything that might need to move before you return
- Escalation path: Who to contact for specific things — one or two names, not a general “ask the team.”
- What can wait: Naming what does not need attention is just as useful as naming what does
You do not need to document everything. You need to document the things that could cause confusion if left undocumented.
|
|
Where can AI save you time?
My friends at Big Creek Growth put together a quick survey to spot the repetitive work you can hand off to automation.
|
|
When You Call Out Same-Day
Emergency absences leave little time to prepare. A thorough handoff is not realistic when you wake up sick or have a family emergency. But a short message before you go offline still makes a real difference.
Something like: "Out sick today. Working on [ticket], currently blocked on [thing]. [Name] has context if it comes up. Will check in tomorrow." is enough information. You do not need to write a novel. It gives whoever needs to pick things up a place to start, which is significantly better than silence.
The standard for a same-day absence is not a perfect record. It is a usable thread.
Communicating Extended Leave
For absences measured in weeks, the stakes are higher and the lead time is longer. This is where written documentation does the most work.
Async, written artifacts create alignment without requiring everyone to be available at the same time. A well-structured written handoff stays useful long after the conversation that produced it — it can be referenced when a question comes up on day three just as easily as day one.
For extended leave, the handoff document should cover the status of active projects, who owns what while you are gone, and the reasoning behind recent decisions that others might need to understand or continue. The “why behind recent decisions” part tends to get left out, and it is the hardest thing to reconstruct from a ticket or a PR.
Extended leave also surfaces ownership gaps that were previously invisible. If you are the only person who fully understands the state of something, your absence makes that visible in a way that no amount of communication can fully compensate for.
The actual fix is earlier: shared documentation, cross-training, and making sure the bus factor for critical work is higher than 1. But it’s often during extended absences that teams realize they haven’t done that work.
The Pattern Teams Notice Over Time
Nobody formally tracks who communicates well before going out. But teams develop a clear sense of it.
The engineer who goes out and leaves things in good shape is remembered as someone who thinks about the work and the people doing it. The engineer whose absence created a week of confusion may not even realize the problem happened — they were on vacation.
This kind of continuity thinking tends to cluster. Engineers who write clear tickets also tend to write clear handoffs. Engineers who document decisions as they make them tend to have more useful absence messages. The underlying habit is the same: accounting for what other people need to keep working, not just what you need to move forward.
Going out is not the moment to develop that habit. But it is a consistent, low-stakes opportunity to practice it.
The question worth asking before you go dark is not whether you told your team you would be unavailable. It is whether they can keep moving while you are.