When does your organization actually feel the loss of someone important? Not on the day they leave. And usually not in the first month either. Often not until three to six months later, when a critical decision stalls or a system breaks in a way nobody quite understands.

That gap, between when something happens and when the system actually registers it, is one of the most underestimated forces in organizational life.

Many leaders think in straight lines. Problem appears, action taken, problem solved. But the systems we work inside: teams, organizations, markets - don't behave that way. They move in loops. And loops, especially ones with delays built into them, produce outcomes that feel unpredictable. But some of them are more predictable than you realize once you know what to look for.

This post is taking a look at some real world challenges in many organizations and connecting them with concepts from Donella Meadows' book "Thinking in Systems". These are concepts I personally think every engineering and organizational leader should understand. They aren't complicated in theory. But they explain almost everything that goes wrong in how organizations hire, restructure, and respond to losing key people. The concepts are: feedback loops, delays, and oscillation.

Feedback Loops: The Engine Under Everything

A feedback loop exists when the output of a process circles back to influence its own input. Every system that exhibits ongoing, dynamic behavior has at least one. Meadows describes two kinds of feedback loops.

The first is a reinforcing loop. This is an amplifying engine. Change in one direction causes more change in the same direction. More of A leads to more of B, which leads to more of A. These loops are exponential by nature, and don't level off on their own. When they run in your favor, they look like momentum: a strong engineering team ships quality work, which attracts better talent, which makes the team stronger. When they flip however, they can look like a death spiral: a high-profile departure signals instability, which prompts others to leave, which makes the org less stable, which prompts more departures.

The second is a balancing loop. This is a goal-seeking mechanism. It detects a gap between where things are and where they should be, and it drives corrective action to close that gap. Thermostats run on balancing loops. So do hiring plans. The team is understaffed, a gap opens versus the headcount target, recruiting ramps up, hires come in, the gap shrinks, recruiting slows down. Balancing loops stabilize systems. They are not dramatic. They are just always running in the background, comparing current state to desired state and nudging the system back toward its goal.

Most organizational problems involve both types running simultaneously. The interesting question is never "which loop is at work" but rather "which loop is currently dominating, and what's happening to the other one?"

Feedback Loops

Delays: Where the Theory Meets Reality

Even systems that look very simple can quickly become quite treacherous. Feedback loops rarely operate instantly. There is almost always a delay between an action and the effect of that action becoming visible. And between that visible effect and the next corrective response.

Delays are what many organizations forget. But they are real, and they fundamentally change how a system behaves. A balancing loop without a delay is smooth and self-correcting. A balancing loop with a significant delay oscillates. And the longer the delay relative to the speed of decision-making, the more violent the oscillation.

The classic illustration is a shower with a slow hot water pipe. You step in. It's cold. You turn the hot tap up. Still cold. You turn it up further. Then thirty seconds later, scalding. You quickly turn it back to cold. Then it's freezing. But what's happening? The water heater is working, and the balancing loop is functioning exactly as designed. The problem is the delay between your action and its effect, combined with the fact that you kept acting during the delay window, compounding the correction before the previous one even landed.

This pattern here is: overshoot in one direction, correction, overshoot in the other direction, correction, and thats what's called oscillation. And it appears in every system with delayed feedback, from inventory management to traffic jams to engineering headcount.

Oscillation

What This Looks Like in an Organization

Let's look at a real world scenario. Your engineering team is stretched. Velocity is slipping, PMs are frustrated, and the signal is clear: you're understaffed or overworked. The balancing loop kicks in. You open up new positions.

But there is a delay. Finding and hiring a good senior engineer easily takes a few months. Add notice periods, onboarding, and the ramp to genuine productivity, and you're looking at six to nine months from the need arises before those hires are actually contributing at the level you needed them. By then, the conditions that drove the original decision have changed. The roadmap shifted, or growth softened. The specific gaps the hires were meant to fill have moved.

But the hires are in the pipeline. Offers have gone out. The loop did its job. The headcount arrived, just into a future that no longer matches the past that requested it.

This is the overshoot. The correction was right. The timing was wrong. And because the system looks fine on paper (headcount target met, requirements closed), nobody adjusts. Then the business hits a rough quarter, and leadership looks at the payroll and initiates a restructuring.

Layoffs. The loop corrects in the other direction. Now you're understaffed again. Eighteen months later, the cycle begins once more.

No individual decision in this sequence was irrational. The mistake was not accounting for the delay, and continuing to push harder during the window when nothing seemed to be working, compounding the correction before it had landed.

The Bus Factor Makes the Delay Problem Worse

Another version of the delay problem, one organizations almost never model, and one of the most damaging, involves what engineers call the bus factor: meaning how many people on a team could disappear before critical knowledge or capability is lost?

When someone with a high bus factor leaves, whether through a layoff or a voluntary departure, the delay between their exit and the visible damage is not weeks. It is months.

When a senior engineer, a key product manager, or an experienced team lead leaves an organization, they take three things with them that rarely appear on any org chart.

The first is explicit knowledge: the systems they built, the architectural decisions they made, the code they own. This is the stuff organizations usually try to capture in handover documents and exit interviews. It's important, but it's also the easiest part to see and address.

The second is tacit knowledge: the intuitions, heuristics, and judgment calls that come from years of context. Why did we build it this way? What did we try before that didn't work? What does this customer actually need versus what they're asking for? This knowledge doesn't transfer in a two-week handover. It transfers through months of shared work, observation, and conversation. When the person is gone, this knowledge is simply gone with them.

The third is relational infrastructure: the informal relationships that make things move. The person who could get a fast answer from legal. The one who knew which stakeholder to call when something needed unblocking. The individual who bridged two teams that didn't otherwise communicate well. This is almost never documented anywhere, and it almost never shows up in a job description.

The delay exists because the loss of tacit knowledge and relational infrastructure is invisible until someone reaches for it and finds it isn't there anymore. That moment usually doesn't come until weeks or months after the person has left. The system is operating on inertia, coasting on the decisions that were already made, the relationships that are still warm, the documentation that was written when things were working.

The clock starts the day they leave. The alarm goes off much later.

The Reinforcing Loop That Feeds the Balancing One

Delays in balancing loops cause oscillation. But there is a second, compounding problem: departures, especially high-profile ones, activate reinforcing loops simultaneously.

When a respected engineer is let go or quietly resigns, the people around them update their own models of the organization. Some of them, particularly the ones with the most options, begin exploring alternatives. Attrition picks up. The team that remains is smaller and carries more load, which strains morale further, which drives more attrition. A vicious reinforcing loop is now running alongside the already delayed balancing loop trying to close the capability gap.

Reinforcing loops do not stabilize on their own. They amplify until something external interrupts them. And because the amplification is exponential, the window for intervention is narrow. The early signal, the first few people showing signs of disengagement or quietly updating their CVs, is the moment to act. Once the loop has momentum, the cost of interrupting it is an order of magnitude higher.

This is why the most damaging organizational outcome of a layoff or a key departure is often not the direct capability loss. It is the secondary attrition it triggers in the people who remain. The people most likely to leave next are frequently the highest bus-factor individuals on the team. The people with the strongest external options and the most accurate sense of what has actually been lost.

Applying the Theory: What Changes When You Think in Loops

Understanding these dynamics does not require abandoning urgency or avoiding hard decisions. It requires adjusting how and when you act, and what you watch for.

Respect the delay before amplifying the correction The instinct when a hiring intervention isn't producing results is to do more of it: open more positions or push recruiting harder. In a system with a three to nine month delay, this is the shower problem. The effect of your previous correction is on its way. Adding more corrections before the first lands almost always makes the oscillation worse, not better.

Make smaller, more frequent adjustments Large corrections produce large overshoots. Hiring in smaller batches at regular intervals, evaluating the effect, and adjusting at each step gives you real feedback before the next decision is made. It converts one large oscillation into a series of small, controlled corrections.

Treat departures as the start of the delay, not the end of the event Exit interviews and handover documents address only the explicit knowledge. The tacit knowledge and relational infrastructure gaps won't surface for months. Flag them, set checkpoints at three and six months, and stay watchful long after the person is gone.

Watch the reinforcing loops, not just the balancing ones Morale and attrition are not lagging indicators, they are leading ones. A balancing loop running slowly against a delay is expected. A reinforcing loop accelerating in the wrong direction is a different problem entirely, and it requires a different intervention: not more hiring, but addressing the narrative and the conditions that are driving the secondary departures.

Map bus factor before making structural decisions Restructuring happens at the level of org charts. Bus factor lives at the level of systems, relationships, and judgment. Before finalizing any significant cut, someone should be asking: which of these people is a single point of failure for something critical? What happens to the feedback loops in six months if they're gone?

The Takeaway

Feedback loops, delays, and oscillation are not a hiring phenomenon. They are the fundamental architecture of how every complex system behaves over time. Inventory management, supply chains, software release cycles, monetary policy, they all exhibit the same underlying dynamics. The organizations and systems that perform best over time are the ones whose leaders have internalized this mental model deeply enough that it shapes how they act under pressure.

The hardest part is that the delay is precisely what makes this unintuitive. You act, nothing seems to happen, you act more, and then the effects of both actions land at once. Patience in those windows, waiting for the signal before turning the knob again, is not being passive. It is the correct response to a system with a delay built into it.

And when a key person leaves, the loop has already started. The question is only whether you recognize it early enough to shape what happens next.

The Clock Is Already Running