Strangler Patterns for the Human Org

Why big-bang reorgs fail

I've watched three major reorganizations up close. All three followed the same script: consultants arrive, boxes move on org charts, new reporting lines announced, and then... chaos. People spend six months figuring out who does what. The old informal networks persist because they're the only way to get anything done. Eventually the org settles into something that looks suspiciously like what it was before, just with different titles.

Big-bang reorgs fail for the same reason big-bang rewrites fail:

• You can't design the new system without understanding the old one, and you don't understand the old one as well as you think.
• The transition period is too long and too painful.
• People route around the change to preserve what was working.
• You lose institutional knowledge that was never documented.

The strangler pattern for orgs

Instead of redrawing the entire org chart, you identify one dysfunction and build around it. The old structure continues to exist while the new structure proves itself. Traffic - in this case, decisions and work - gradually routes to whichever structure serves it better.

Choosing the first vine

Not every dysfunction is worth strangling. The first vine needs to be:

1. Visible: People already complain about it. You won't have to convince anyone there's a problem.
2. Bounded: You can define where it starts and ends. "Communication is broken" isn't bounded. "Incident response takes too long" might be.
3. Measurable: You'll know if the new structure is better. Not vibes - numbers.
4. Survivable: If the experiment fails, the org can recover.

I usually look for processes that cross too many teams, decisions that require too many approvals, or work that sits in queues waiting for someone who's always overloaded.

Running the experiment

The key is parallel operation. The old structure keeps running. You create a small team or working group with explicit permission to try a different approach for a specific scope.

Example: Instead of reorganizing all of engineering around product areas, you create one cross-functional pod for one product. They get dedicated people, a clear charter, and metrics to hit. If it works, you create another pod. If it doesn't, you've learned something without disrupting everyone.

The experiment needs:

• A sponsor who can protect it from organizational antibodies
• Clear boundaries on what's in scope and what's not
• A timeline for evaluation (usually 2-3 months)
• Permission to fail without career consequences

Routing decisions

The strangler pattern only works if you actually redirect traffic. In orgs, traffic is decisions and work. You need explicit rules about what goes to the new structure:

• "All incidents for Product X go to the new pod."
• "Feature requests under $50K don't need architecture review."
• "The new working group owns the decision on vendor selection for this category."

Without explicit routing, people default to the old paths. The new structure starves. Document the routing rules and enforce them.

When to decommission

The old structure is ready to dissolve when:

• The new structure handles all the relevant traffic
• People naturally route to the new structure without being told
• The metrics show sustained improvement
• The people in the old structure have moved on or been absorbed

Don't rush this. A premature decommissioning is as bad as a big-bang reorg. Let the old structure wither; don't kill it.

What this looks like in practice

One org I worked with had a classic dysfunction: every technical decision required approval from a central architecture board that met biweekly. The queue grew, teams waited, and by the time decisions were made, requirements had changed.

Instead of abolishing the board, we created a "fast path" for decisions under a certain complexity threshold. Two architects from the board rotated into an on-call role, empowered to approve or reject within 48 hours. The full board kept meeting for the big stuff.

Within three months, 70% of decisions went through the fast path. The board's queue shrank. A year later, the board only met monthly, and the fast path had expanded to cover almost everything. The old structure wasn't killed - it evolved.

The meta-lesson

Organizations resist change because change is risky. The strangler pattern reduces risk by making change incremental and reversible. You're not asking anyone to bet on a new structure. You're asking them to let you run an experiment.

The best organizational changes I've seen didn't feel like changes. They felt like natural evolution - new growth slowly replacing old, until one day you look up and realize the org is different. That's the strangler pattern working.