Teams shrink. It happens in startups, in big companies, and especially during the lean stretches that follow rapid growth. When a group of five becomes a group of two, or a department of twelve shrinks to four, the first thing everyone worries about is the workload. But the slower, more dangerous problem is the loss of operational knowledge—the hard-won, often unwritten understanding that keeps systems running and prevents small hiccups from becoming full-blown outages.

At Gray Haven Lab, we think about resilience as a property of systems, not just hardware. A resilient operation can lose key people and still function because knowledge is spread around, easy to find, and regularly tested. When a team contracts, the people who remain suddenly own a much bigger surface area. Without the right habits, that surface area becomes brittle. Here’s how to keep it flexible.

Recognize the Difference Between Documentation and Knowledge

Most teams treat documentation as a substitute for knowledge. It isn’t. A wiki page describing a deployment process is not the same as knowing why that process exists, what happens when it breaks, or which monitoring alerts are just noise. Operational knowledge is the stuff that lives in people’s heads—the context, the scars, the intuition built from late-night pages.

When a teammate walks out the door, they take that context with them. What’s left is a set of instructions that might be accurate, or might be a snapshot from six months ago before someone added a workaround that everyone forgot to write down. The gap between the runbook and reality is where incidents breed. So stop treating documentation as the source of truth. Treat it as a signal—a best guess at what someone believed at a point in time. The real truth is in the minds of the people running the system. When the team shrinks, you lose those minds faster than you can update the wiki. The trick is to shrink the gap between what’s written and what’s real before people leave.

Map the Hidden Infrastructure

Every ops team carries a mental model of the systems they own. That model includes the official architecture diagram, sure. But it also includes the unofficial dependencies: the ancient server that still handles one critical batch job, the load balancer rule someone added during an incident and never cleaned up, the monitoring check that fires constantly but nobody silences because it occasionally catches something real.

When the team shrinks, the remaining folks inherit these hidden dependencies without the backstory that made them manageable. A practical exercise is to build a dependency map that captures not just what talks to what, but who knows about it and how much it matters. This map should include:

• Known-unknowns: Systems or processes that only one person understands. These are your single points of failure.
• Unknown-unknowns: Areas where the team lacks confidence. If nobody can explain how a particular service gets deployed, that’s a risk.
• Drift: Places where documentation and reality have diverged. This is common in fast-moving environments where runbooks get updated after the fact, if at all.

Once you’ve mapped it, prioritize the items that would cause the most damage if they failed. The goal isn’t to document everything—that’s a fool’s errand. It’s to close the most dangerous gaps.

Run Deliberate Knowledge Transfer Sessions

When someone gives notice, the standard playbook is a flurry of handover meetings. These are usually rushed, poorly structured, and focused on the wrong things. A better approach is to run knowledge transfer sessions continuously, not just during departures.

One format that works well is the silent runbook review. Hand an operator a runbook for a process they’ve never touched and ask them to execute it in a staging environment without asking questions. Watch where they get stuck. Those friction points are where critical knowledge is missing. Update the runbook, then repeat with a different operator.

Another format is the failure rehearsal. Pick a realistic failure scenario—a database failover, a certificate expiry, a region outage—and walk through the response without actually triggering the failure. The point isn’t to test the system. It’s to test the team’s understanding of the system. Who knows what to do? Who knows why that’s the right thing to do? These sessions reveal gaps in knowledge that documentation alone can’t fill.

Build a Culture of Shared On-Call

In a shrinking team, on-call rotations get thin. The same people carry the pager more often, which increases fatigue and the risk of burnout. But there’s a subtler problem: when only one or two people respond to every alert, they become the sole holders of operational knowledge. Others on the team lose touch with how the system behaves under stress.

Even if the team is too small for a full rotation, rotate responsibilities anyway. Have the person who isn’t on call shadow the responder. Review incidents together after they’re resolved, not just to write a postmortem but to transfer the sensory knowledge of what the system felt like when it was failing. That sensory knowledge—the pattern of alerts, the shape of the graphs, the specific error messages—is what lets experienced operators diagnose problems quickly. It can’t be captured in a document, but it can be shared through practice.

Write the Recovery Checklist Before You Need It

We’ve written before about the value of having recovery procedures ready before an incident strikes. That advice becomes even more important when the team is small. A recovery checklist reduces the cognitive load during an outage, which is precisely when a lean team is most vulnerable. If you haven’t created one yet, now is the time. Our earlier piece on writing the recovery checklist before you need it walks through the process in detail.

A good recovery checklist does more than list steps. It encodes the team’s shared understanding of what matters most during an incident. When a team shrinks, that shared understanding can erode quickly. The checklist becomes a forcing function to maintain it.

Treat Onboarding as a Continuous Process

When a team is stable, onboarding happens once per new hire. When a team is shrinking, onboarding must happen continuously for the people who remain. Every time a responsibility shifts from one person to another, that person is effectively new to the role. They need the same structured introduction to the systems, the same guided tours through the runbooks, and the same safe environment to ask questions without judgment.

Create an onboarding path for each operational domain—deployments, monitoring, incident response, database administration—and have every team member walk through it periodically, even if they think they already know the material. The goal isn’t to teach them something new. It’s to surface what has changed since they last looked. Systems drift. Runbooks become stale. Periodic onboarding catches the drift.

Reduce the Surface Area

When a team shrinks, the instinct is to work harder to cover the same surface area. That’s unsustainable. A more resilient approach is to reduce the surface area itself. This means retiring systems, consolidating tools, and eliminating processes that don’t provide clear value.

Ask: what would break if we turned this off? If the answer is unclear, turn it off in a controlled way and observe. Many operational burdens exist because nobody has taken the time to remove them. A smaller team has less capacity to carry unnecessary weight, so be aggressive about shedding it.

This principle applies to monitoring as well. Every alert that fires and doesn’t require action trains the team to ignore alerts. In a small team, that training happens faster because the same people see every page. Audit your alerting rules and disable or tune anything that doesn’t indicate a real problem. The goal is a signal so clean that every alert demands attention.

Document Decisions, Not Just Procedures

Most operational documentation describes what to do. It rarely describes why a particular approach was chosen or what alternatives were considered. When the person who made those decisions leaves, the team is left with a set of instructions they don’t fully understand. That makes it harder to adapt when circumstances change.

For every critical system or process, maintain a decision record. It doesn’t need to be long. A paragraph explaining the context, the options considered, the trade-offs made, and the date of the decision is enough. These records become invaluable when the original decision-makers are gone and the team needs to know whether a workaround is still necessary or a configuration can be safely changed.

Practice Incident Response with a Smaller Team

Incident response processes are often designed for larger teams, with roles like incident commander, communications lead, and subject matter experts. When the team shrinks, one person may need to fill multiple roles. This isn’t inherently a problem, but it requires practice. Run incident simulations with the smaller team to identify bottlenecks. Does the same person who is diagnosing the issue also need to communicate with stakeholders? If so, build that into the process. Create runbooks that assume a single responder, with clear escalation paths if the incident grows beyond their capacity.

Also, practice handoffs. In a small team, an incident that spans multiple time zones or workdays may require handing off between just two people. A clean handoff requires a shared understanding of the current state, the actions taken so far, and the hypotheses still being explored. Develop a lightweight handoff template and practice using it under simulated pressure.

Maintain a Single Source of Truth for Contacts and Escalation

When a team is large, it’s easy to assume that someone else knows how to reach the database administrator or the security team. When the team shrinks, those assumptions become dangerous. Maintain a single, well-known, and regularly verified list of contacts and escalation paths. This list should include not just names and phone numbers but also the specific systems or areas each person covers. When someone leaves, update the list immediately. When someone new takes over a responsibility, verify that they can actually perform the associated tasks before an incident occurs.

Protect the Team’s Cognitive Capacity

Operational knowledge isn’t just about facts and procedures. It’s about the ability to reason about a system under stress. That ability degrades with fatigue, context switching, and cognitive overload. A smaller team is more susceptible to all three.

Protect the team’s cognitive capacity by reducing interruptions. Batch non-urgent requests. Create quiet periods for deep work. Rotate the person who handles incoming questions and ad-hoc requests so that others can focus. These practices are often seen as luxuries, but for a lean team they’re necessities. A team that is constantly interrupted cannot build or maintain the deep understanding required to operate complex systems safely.

Frequently Asked Questions

What is the biggest risk when a team loses members?

The biggest risk is the loss of tacit knowledge—the unwritten, experience-based understanding that allows operators to recognize and respond to anomalies quickly. This knowledge is rarely documented and often not even recognized as knowledge by the people who hold it. When those people leave, the team’s ability to detect and respond to subtle failures degrades, sometimes without anyone realizing it until an incident occurs.

How can we identify knowledge gaps before someone leaves?

Run regular knowledge transfer exercises, such as silent runbook reviews or failure rehearsals. In a silent runbook review, an operator who is unfamiliar with a process attempts to follow the documented procedure in a safe environment. Every point where they get stuck or need to ask a question is a knowledge gap. Failure rehearsals walk the team through a realistic incident scenario and reveal who knows what to do and where the understanding is thin.

Is it better to document everything or focus on critical systems?

Focus on critical systems and the decisions behind them. Attempting to document everything leads to stale, unmaintained documentation that nobody trusts. Instead, identify the systems and processes that would cause the most damage if they failed or if the only person who understood them left. Document those thoroughly, including the reasoning behind key decisions. For less critical areas, lightweight runbooks and dependency maps are sufficient.

How do we keep documentation from becoming outdated?

Treat documentation as a living artifact that must be verified through practice. Schedule regular reviews where team members execute documented procedures and flag discrepancies. Tie documentation updates to operational events: after every incident, update the relevant runbooks. After every deployment process change, update the deployment guide. Make documentation part of the definition of done for operational work, not an afterthought.

What if the team is too small to rotate on-call responsibilities?

Even with a team of two, rotate responsibilities. The person not on call can shadow the responder, review alerts, and participate in post-incident analysis. This ensures that knowledge is distributed and that both people maintain familiarity with the system’s behavior under stress. If the team is a single person, consider establishing a reciprocal arrangement with another team or hiring an external on-call service for coverage during off-hours, with a strong emphasis on knowledge transfer during handoffs.