Before the Next Reduction
Why your organization's actual operating system is about to break, and why you need to map it now.
Three weeks into my time at my last company, they did a 13% reduction in force. I was new enough to the organization and the industry that I was still in the disorientation phase, still learning where the bathrooms were, still trying to place names and faces. I was lost. And I was watching someone who’d been there for over a decade seem just as lost as I was.
The moment I remember is a Sr. Director walking around, seemingly thinking out loud, asking who do I talk to about getting a KB article published?
He needed to get something out, some documentation about a product. The kind of work that should be routine, but the person, or the team, or whatever structure had always handled it was gone. He was walking the floor, basically asking the air, and you could hear the frustration underneath the question. He wasn’t angry, at least not at people. It was frustration at the fact that after over a decade at the company, the answer to a basic operational question wasn’t knowable from the org chart, and he had to rely on whoever he ran into to actually know.
The org chart didn’t help him, and it was never designed to.
Eventually, his problem was solved. Someone knew someone. The network intelligence layer still had a path through, but it required luck and proximity. A Sr. Director’s execution speed should not depend on walking past the right person in the hallway.
That’s the moment I started thinking about how organizations actually work.
Here’s what a RIF does, if you’re paying attention. It makes the invisible operating system suddenly, catastrophically visible through its absence.
Most of the time, the organization runs on two systems at once. The formal one is documented. Org chart –> Reporting structure –> Titles → Responsibilities. Whose name is on what. The informal one is not documented. It’s the trust layer, made up of who translates between functions when they’re supposed to be siloed. It’s who knows where things actually live, the people others go to when they need a real answer. It’s the person who’s been quietly holding five loosely related responsibilities because they’re the translator and no one else can quite do it.
These two systems are always misaligned, and that’s normal. The misalignment doesn’t usually matter because the informal system is absorbing the gap. Information moves because it always has. Decisions happen because someone knows someone, and the work gets done because the operating system, unwritten and unmapped, is quietly carrying execution.
Then a reduction happens. Twenty-three hundred people leave, and just like that, the gaps become sudden and real. A Sr. Director can’t get a KB article published. A critical translator between product and engineering is gone. The person who knew how to move ideas through the organization…the person whose trust opened doors… isn’t coming back. The informal operating system has a hole in it now, and the formal structure can’t fill it.
Organizations experience this as a slowdown. Decisions that should take a week now take three. Adoption of new systems stalls, execution speed drops, and people feel it as friction. Leadership reads it as a culture problem, thinking they need better communication, more engagement, and thinking they need to rebuild morale.
What they’re actually experiencing is an operating system that’s broken.
I’ve been thinking a lot lately about the era we’re entering, and there’s a real pattern forming. Companies invest heavily in AI, hoping it’s going to solve efficiency problems. But what happens when the efficiency doesn’t materialize as expected, when the return on the investment hasn’t hit yet, the capital is burning, and stakeholders want answers. Companies make cuts. Then they double down on AI again. Then they cut again. This cycle is becoming normal. This is happening across not just the technology sector, but at companies like Nike.
What this means is that RIFs are becoming normal, not a singular event, but a recurring pressure and escape valve. Every twelve to eighteen months, companies are going to face another round of reductions, not because they’re failed organizations, but because they’re in a holding pattern, waiting for AI to deliver the value everyone promised. In the meantime, they’re managing burn.
If that’s the reality, then every organization needs to think very carefully about what happens to execution when the informal operating system keeps getting fractured.
Here’s the thing I don’t think is being considered: You can’t solve this by hiring back. You can’t rebuild the operating system by restructuring, and you can’t fix it with a better org chart or better communication software. The informal operating system is built on relationships and trust and proximity and knowledge that lives in people. When those people leave, the system breaks, and it’s not obviously broken on paper. It’s only broken when a Sr. Director can’t find anyone who knows how to publish a KB article.
But in a compressed organization, with fewer people, moving faster, trying to do more with less, that kind of breakdown isn’t an edge case, it’s a constant state. Execution becomes dependent on luck and proximity. The right person is not there, the trusted translator is gone, the person who knew how information actually moved through the system is not coming back. And nobody built a map of where that person was carrying work.
This is not a sustainable way to operate. Especially not in the next phase, where reductions are going to happen faster and more frequently.
Here’s what I mean by building the map. It’s not complicated in concept, it’s impossible in execution, which is why I suspect nobody’s actually done it.
You map the informal operating system. You identify the trust-carriers, understand where work actually flows, see who translates between functions. You know who knows what, you understand the relationships that make execution possible, and you build visibility into the operating system instead of pretending the org chart is telling you anything meaningful.
Once you have that map, everything changes.
First, you can actually protect the operating system during a reduction. You don’t just cut headcount, you understand what work is trapped in people and you either distribute it before the people leave or you protect the people who are carrying it, or you plan for the execution hit. You’re not surprised, and so you’re not walking around asking who to talk to about a KB article.
Second, you understand how to distribute ideas. Every organization complains that adoption is slow, that change doesn’t stick, and that people resist. What they’re usually experiencing is that ideas are moving through a fragmented operating system. They’re moving through the formal channels (which are inefficient) instead of through the trust network (which is fast). If you have a map, you know where the adoption leverage is. You know which trust-carriers can move an idea. You know where to create redundancy so the idea moves even if one person leaves.
Third, you can anticipate where execution will break. When a new system gets implemented, or a process changes, or a strategic shift happens, you can predict where it will stick and where it will move forward. Not from the org chart, from the operating system. You’ll know that the shift will move fast through engineering if the right translator is involved. You’ll know adoption will stall in support because there’s no trust bridge between support and product. You can design around those gaps before the change happens.
Fourth, and maybe most important, you can understand who your high-trust individuals are. The people who hold disproportionate influence. The people who, if they believe in something, everyone around them moves with them. In a compressed organization, you don’t have time for slow adoption. You need those people. You need to know who they are, and you need to make sure they’re not just holding a job title in your org chart. You need to make sure they’re actually carrying the operating system work that makes the organization functional.
This is not soft stuff, it’s operational necessity. This is about whether your organization can move when it needs to move.
I think a lot about that Sr. Director, still frustrated, finally finding whoever it is that publishes KB articles. And I think about the organizations coming into the next wave of reductions without any idea where the actual work is moving. Without visibility into the operating system, because they don’t have the map.
They’re going to be slower. They’re going to lose people, not because they made bad cuts, but because the remaining people can’t get the things done that they need to get done. They’re going to struggle with adoption because they’re trying to move ideas through a fragmented system, and they’re going to keep getting surprised when execution drops after a RIF.
The organizations that figure out how to see and map the operating system first are going to have an advantage that’s not obvious from the outside. They’ll move faster, they’ll adopt change more quickly, and they’ll protect what matters during reductions because they actually know what matters. They’ll bounce back from RIFs instead of limping forward. They’ll understand where the leverage is, they’ll know who the trust-carriers are, and they’ll know where to go when they need something to actually happen.
This is not a vanity metric or insight. This is not a nice-to-have. In the era we’re entering, where reductions are recurring and compression is constant, understanding your operating system is not optional. It’s the difference between an organization that can move and an organization that’s stuck.
The choice is whether you’re going to see it and build the map, or whether you’re going to keep being surprised when a Sr. Director walks around asking who to talk to about getting something published.