Our withdrawal from Afghanistan, we’ve been told, has been utter chaos. Utter chaos that has somehow resulted in the successful evacuation of 122,000 Americans and an expected 50,000 Afghans, actively assisted by the Taliban.

While we’re waiting on self-consistent reporting on the subject, or even if you don’t much care about it at all, take time to read this guidance on management theory by the always insightful Fareed Zakaria, cleverly disguised as a commentary on the deficiencies in the U.S. national security apparatus that led, or at least contributed to, the 20-year fiasco in Afghanistan.

And I quote: If you want one statistic to explain the failure of the U.S. withdrawal from Afghanistan it is this: The National Security Council met 36 times since April to discuss it. Even more remarkable, this number was shared with the media to illustrate how well the administration had handled things. The U.S. foreign policymaking apparatus has transformed itself into a dinosaur, with a huge body and little brain, a bureaucracy where process has become policy.

And this: Preparation and memos for meetings become a substitute for effective action.

Another: The larger an organization gets, the more layers it develops, and the more layers, the harder it is to navigate them.

One more: Many insiders had come to realize that the mission was doomed, but the information stayed trapped within the bureaucracy.

Sound familiar? My experience as a management consultant suggests you could choose the name of just about any Fortune 500 enterprise more or less at random, substitute it for “National Security Council” in the snippets I quoted above, and the observations would be equally accurate.

Not that Zakaria’s analysis is perfect. It isn’t – it’s incomplete, exploring only one side of a two (at least) sided issue, namely, how many layers of management an organization should have so as to function effectively.

As Zakaria points out, the more layers you have, the more information “… stays trapped within the bureaucracy.”

Except that this formulation misses one of the primary root causes for this trapping: Every layer is headed by an individual whose career can depend on the heads of higher layers not knowing exactly what they need to know most, namely, what isn’t going as well as planned.

Or, to be more plain-spoken about it, I brag about what’s going well to my boss while doing my best to make sure anything that isn’t going well gets concealed, blame-shifted, or, occasionally, quietly fixed.

The fewer the layers, the less likely it is that this filtering keeps upper-layer management completely in the dark.

Seems like a cut-and-dried case for a leaner organization, doesn’t it?

Not so fast. Simple geometry suggests it’s time to say “yeah, but.” The simple geometry?

For any number of people in an organization, fewer layers, means each manager has more direct reports. More direct reports means less time spent with each direct report. Less time spent with each direct report means less opportunity to provide leadership.

Not only that, but one of the primary benefits of a lean organization … fewer barriers to the flow of important information … is partially negated. Spend less time with each direct report and you have less time, and therefore less opportunity to explore the ramifications of what your direct reports are telling you.

So what’s the right answer? Sorry, there is no right answer, only less-wrong answers for different situations:

  • Focus on Operations: If what you need most is a smooth-running operation, go for fewer layers. Operations is about management, where you need to know What’s Going On Out There to know if something isn’t running as smoothly as it should.
  • Focus on Change: If you’re trying to accomplish significant change of some kind, go for fewer direct reports. Change is about leadership, so you need to expand your leadership reach and impact. That means spending more time with each direct report.
  • Focus on Policy: Smart policy comes from expertise. Ignore the organizational chart altogether. Instead, form cross-functional teams composed of as small a number as possible of smart, knowledgeable, creative, innovative thinkers, who are … and this is vitally important … on the team to provide their expertise, not to represent the area they work in.

Bob’s last word: When you charter a cross-functional team, make sure it has a limited lifespan. If it doesn’t disband after finishing its mission it will inevitably bloat into exactly what you formed it to avoid.

Bob’s sales pitch: I know it’s hard to believe, but there’s yet another piece on CIO.com (on an entirely different subject) by yours truly for you to admire, and maybe even read. This one is titled “The 3 IT processes CIOs need the most.” I think you’ll like it.

Is your organization performing as well as it should? As it could?

Do you know? Can you know?

Random notions on the subject:

Notion #1: If you’re confident your organization is performing as well as it could, you’re right by definition. Neither you nor anyone reporting to you will try to improve it because why would you?

If, on the other hand, you’re confident it could be better and you’re wrong, you might do some damage, because if your organization is already doing as well as possible, the best any change can achieve is neutrality. That’s the best outcome. The rest must leave you worse off than where you started.

Notion #2: Benchmarks were popular because an executive could use them to “prove” a recalcitrant manager wasn’t performing as well as possible. They were flawed because they rarely avoided the sin of apples-to-basket-of-randomly-assembled-fruit comparisons.

“Best practices” have replaced them as the flogging tool of choice for those whose closest level of descent is 50,000 feet (15,240 meters if you’ve adopted altitude-measurement best practices).

Best practices are popular because what they prescribe rarely matches how we do things around here. Which means the manager responsible for following less-than-best practices surely deserves a whuppin’.

True story: I once saw a consultant’s PowerPoint slide that promised to “… institute best practices followed by a program of continuous improvement.”

Ahem. If the practices are best they can’t be improved. If they can be improved, continuously or otherwise, they aren’t best yet.

As the KJR Manifesto pointed out there are no best practices, only practices that fit best. Most so-called best practices are one-size-fits-no-one off-the-rack pants. They’re too small for your waist and too short for your inseam, but your boss insists you wear them anyway.

Notion #3: Fixing the root cause isn’t always the best way to deal with a problem.

Imagine, for example, that you, like me, suffer from cluster headaches. Your research determines the root cause is spontaneous activation of nociceptive pathways.

So what. We can’t do anything about the root cause. I don’t even know what the root cause means.

What we can do is take Sumatriptan as soon as a headache starts and wait 15 minutes or so for it to take effect.

Sometimes, suppressing symptoms is the best alternative. Not a good alternative, mind you, but the best one available.

Notion #4: A common and pernicious barrier to organizational change is the Assumption of the Present. It’s the Assumption of the Present when employees are sure a proposed change will fail because otherwise it would have already happened.

The Assumption of the Present is a close cousin of “We tried that and it didn’t work,” only you can suggest the reason it didn’t work is that, “Maybe we did it wrong.”

The Assumption of the Present, in contrast, is circular. And being circular there’s no entry point you can use to rebut it.

Notion #5: Agile isn’t a methodology. It isn’t a family of methodologies. Well, it is, but more importantly it’s a way of thinking about how to accomplish things.

It’s the practical application of Gall’s Law: A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system.”

What it means to you: If you want to try to improve how your organization functions and don’t want to risk doing more harm than good, figure out ways to improve it one small increment at a time. As you do, consider that each increment should be:

  • Easy to explain: If it’s complicated it isn’t incremental.
  • Easy to integrate: The increment shouldn’t disrupt how the rest of the work gets done, or at least it shouldn’t disrupt it badly.
  • Contained: Its scope should be limited to your organization. Processes have inputs, outputs, and methods. Incremental changes should focus on methods, unless a source of your inputs or consumer of your outputs wants to collaborate.
  • Non-limiting: To the extent you can tell, implementing the increment shouldn’t close off potentially desirable future changes.
  • Reversible: If it doesn’t work out, you should be able to stop doing it without difficulty.

Last Notion: Some managers are good at operations — at keeping the joint running. Others are good at making change happen — at making tomorrow look different from yesterday.

Neither skill is good enough by itself.

Managers who excel at operations but can’t make change happen will lead a long, slow slide into obsolescence. But those who excel at change without being competent at operations have the opposite problem.

They won’t survive until the future gets here.