Every engineering manager has a favorite move.
For some it's the meeting. Something breaks, and by lunch there's a calendar invite with eleven people on it. For others it's the ticket. A teammate is struggling, a customer is furious, a release slipped... and every one of those becomes a Jira issue with a priority label. Some managers reorganize. Some write a process document. Some roll up their sleeves and fix it themselves at 11pm.
None of these moves is wrong. The trouble starts when it's the only one you've got.
Gillian Jones-Williams, who I talked with on Corey-osity earlier this year, put a name to this for me. She calls it the law of requisite variety, and the version she teaches goes like this: whoever has the most responses controls the system.
I love the idea. I also think the popular version gets it half right, and the half it misses matters most for anyone running a technical team.
What Ashby Wrote in 1956
The law comes from W. Ross Ashby, a British psychiatrist and one of the founders of cybernetics. He laid it out in chapter 11 of An Introduction to Cybernetics, and he framed it as a game.
There are two players. D throws disturbances at the system. R, the regulator, picks a response to each one. R wins by keeping the outcome on target, no matter what D does.
Ashby showed the outcome's variety has a floor. If D has more possible moves than R, some of D's moves will get through. The only way to push the floor down is to give R more moves. He boiled it down to a slogan people still quote seventy years later: only variety destroys variety.
A few pages later he gives the plainest example I've seen. A press photographer facing twenty different subjects, each needing its own exposure and distance, needs a camera with at least twenty distinct settings. Fewer settings means some photos come out wrong. No amount of effort fixes this. It's arithmetic.
Now swap the camera for a manager. Your team throws disturbances at you every day. A senior engineer wants to leave. A junior one is drowning and won't say so. Production is down. Product changed its mind again. Two people have stopped speaking to each other.
If your response to all five is "let's set up a meeting," you have one setting on your camera. Four of those photos are going to come out wrong.
The Coaching Version, and Where It Breaks
The leadership world picked up Ashby's law through NLP. It sits on the standard list of NLP presuppositions, usually phrased as "the system/person with the most flexibility of behavior will control the system."
There's good evidence behind the core of this. Robert Kaiser and his colleagues studied how to measure manager flexibility, and their 2007 paper found the usual approach, asking coworkers whether a manager "adapts to the situation," tells you almost nothing useful. What worked was measuring whether a manager had mastered pairs of opposing behaviors. Forceful and enabling. Strategic and operational. Leaders who had both sides of each pair, and used them, looked far more effective. Their models predicted as much as 42% of the variance in overall effectiveness ratings. A 2010 follow-up by Kaiser and Overfield built a full assessment around this "mastery of opposites."
So range matters. Gillian is right about this, and I'd push it further. Most of the bad bosses I've worked for weren't cruel. They had one move and used it on everything.
Here's where the coaching version breaks, though. "The most flexible person controls the system" turns Ashby's law into a contest you win by being the most adaptable person in the room. Ashby said something narrower. More variety is necessary for control, not sufficient. And he was talking about the whole regulator, not one heroic person inside it.
Run the numbers on a real engineering org. Thirty engineers, a production system, three product managers, a few hundred customers, a sales team and a board. The variety coming at you is enormous. You, alone, will never match it. Not with all the coaching courses in the world.
Managers who try become the bottleneck. Every decision routes through them because they're the only one with enough moves. I wrote about the result in Your Best Engineer Is a Single Point of Failure, and it's worse when the single point of failure is you.
Three Ways to Win Ashby's Game
Read Ashby closely and you'll find three ways to stop losing. Only the first one involves you getting more flexible.
1. Add settings to your own camera
Start with an honest count. Look back over the last ten problems your team brought you. Write down what you did with each one. If the same response shows up seven times, you've found your one wrench.
Then use Kaiser's pairs as a checklist. If you always push, practice pulling. Ask a question and wait. If you always enable, practice being direct and saying "No, we're not shipping this." If you live in the code, spend an hour a week on the roadmap. If you live in the roadmap, sit with an engineer during an incident.
You won't enjoy the side you've neglected. You'll be bad at it at first. Do it anyway. Every new response is another setting on the camera.
This is the self-awareness work behind StepUp2BAT. You won't grow your range until you see where it ends.
2. Lend out your variety
This is the move the coaching version leaves out. In Ashby's game, R doesn't have to be one person. It's the whole regulating system. Your team counts.
Every engineer who handles an incident without you is another setting. Every tech lead who resolves a disagreement without escalating is another setting. Every person trusted to say "No" to a product request is another setting.
Micromanagement does the opposite. It strips variety out of the team and funnels everything through the narrowest channel in the building... one manager's calendar. I've called micromanagement a coaching crime before. Ashby gives a second reason. It's bad math.
So delegate decisions, not tasks. Give people the context to choose a response you wouldn't have thought of. Hire people who think differently from you, since a team of clones has one setting no matter how big it gets.
3. Shrink the storm
The third move gets the least attention. If you're short on responses, cut down the disturbances reaching you.
Ashby saw this too. When a regulator's capacity is fixed, he wrote, "the discovery of a constraint is the would-be regulator's only hope." The Principia Cybernetica entry on the law adds buffering to the equation and gives a lovely example. A bacterium has two moves, speed up its random wandering or slow it down, and it survives a world full of food and poison anyway. Its environment does most of the filtering.
Engineering teams have plenty of buffers on offer. Coding standards mean fewer arguments about style in review. A paved road for deployments means fewer bespoke pipelines to debug at 2am. Work-in-progress limits mean fewer half-finished things competing for attention. A clear "what we don't do" list stops a whole category of requests before anyone writes a ticket.
Each constraint removes disturbances you would otherwise need a response for. Good constraints aren't bureaucracy. They're how a small regulator survives a big system.
The Point Gillian Got Right
Her phrasing overreaches, but the instinct underneath it is sound. If you keep losing the same fights, the fix is rarely to fight harder with the same move. You need more moves, more people with moves, or fewer fights.
I spent years believing the answer to a struggling team was a better process. Sometimes it was. Often the team needed me to listen instead of plan, or step back instead of step in, or say "No" to a stakeholder instead of saying "Yes, we'll find a way." I had one setting, and I kept wondering why the photos came out wrong.
So try this before Friday. Write down the last ten problems your team handed you, and next to each one write what you did. Count the distinct responses.
If the number is smaller than you hoped, you know which camera needs more settings. And you know which ones belong to your team.
Gillian's own work on coaching and neurodiversity comes up again in Stop Fixing People. Fix the Climate.