Speaking of thinking about thinking, it’s time to talk about systems thinking – a topic spotlighted in Peter Senge’s groundbreaking The Fifth Discipline (1990).

Systems thinking is about breaking any whole into not only its component parts, sub-parts, and sub-sub-parts ad infinitum, but also their sub-parts’ interrelationships. It’s a big subject – so big there’s no point trying to provide links to useful sources.

Most likely, you’re already familiar with many of systems-thinking’s tools and techniques. They’re essential for just about any IT-related endeavor.

But there’s a difference between, to take one example among many, using a swim-lane diagram to design a business process and using one to think through who should be responsible for what, to decide if that’s really such a good idea.

What follows are a few tools, techniques, and principles I’ve found useful over the years to help me think things through.

Law of 7 ± 2: This really should be the law of 7, + 2 if absolutely necessary. What it means is that whatever technique or tool you’re using to figure out a system, no representation should ever have more than seven elements in it – nine if you just have to. If you need more, make one or more of the elements more inclusive – a category of elements. Think through its complexity in a separate, cross-referenced diagram that also follows the law of 7, + 2 if absolutely necessary.

Why seven? Humans can easily grasp a collection of seven or fewer items. More than that and we have to inspect. We can verify the correctness of a diagram that obeys the law. With more elements we’re left hoping we didn’t miss anything.

Black box: If you’re trying to understand a business function – a process or practice – black-box thinking is essential. Black box descriptions describe what something does, not how it does it. They cover five subjects (thereby obeying the Law of 7, + 2 if absolutely necessary):

  • Outputs – what the function is for. They’re its products and byproducts.
  • Inputs – the raw materials the function converts to outputs. Any input not needed by at least one output isn’t an input at all. It’s a distraction, unless it suggests a missing output.
  • Resources – the tools the function uses to turn inputs into outputs.
  • Constraints – restrictions on what the process does or how it does it.
  • Controls – mechanisms for adjusting process operation, such as turning a process on or off, changing its speed, or setting a configurable output characteristic.

Relationships: Six ways each system element can influence other system elements:

  • Component – an element could be part of another element.
  • Container – conversely, other elements could be part of the element.
  • Output / Input – one element’s outputs could serve as another element’s inputs, and vice versa.
  • Resource – one element could produce resources used by other elements.
  • Constraint – one element could place constraints on other elements.
  • Controls – one element could affect the operation or characteristics of other elements.

Feedback: A special type of relationship that describes how a process’s output encourages (positive feedback) or discourages (negative feedback) its own operation or characteristics. Diagrammatically, black-box diagrams represent feedback as arrows connecting process outputs to their controls.

As a matter of nomenclature, “positive” and “negative” are unfortunate word choices. They suggest feedback is either complimentary or critical.

From a systems perspective, positive feedback drives a process to produce more of whatever it is that it does; negative feedback causes it to produce less. Positive feedback accelerates a process, negative feedback keeps a process in control.

Output / Input Loops: Not all loops are feedback loops. Some make one or more of a function’s outputs one of its own inputs. The well-known OODA loop (for Observe / Orient / Decide / Act) is an example. Some outputs of its Act sub-function are inputs to its Observe sub-function, and in fact each sub-function’s outputs include inputs to the next sub-function.

Decoupling: Eliminating or reducing the strength of system interrelationships is, as a general rule, a good idea. It makes the system more resilient by reducing the ripple effects of any changes being considered.

Bob’s last word: We’ve barely scratched the surface of systems thinking. It’s a highly consequential subject because without it, it’s all too easy to fall into the trap of focusing on a particular element, optimizing it without taking the change’s ripple effects into account.

Bob’s sales pitch: The next “CIO Survival Guide” is ready on CIO.com for your viewing pleasure. It’s titled “The Hard Truth of IT Metrics,” and I think you’ll find it useful. And as always, if you have any feedback for me (see above), please share your thoughts about it.

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.