Dennis Howlett commented on a recent post of mine, On Control, where I was musing over Big’s relationship to Control Failure, and arguing that we needed a Better But Not That Big approach. One of the things Dennis said was
“Big often means complex. So how do you propose to solve the complexity issues?”
That stayed in my mind; I have tremendous respect for what Dennis has to say, it’s not often that I am able to connect with a tech-savvy open-minded articulate accountant :-).
Almost coincidentally, I was reading The Origin Of Wealth by Eric Beinhocker, as recommended to me by a couple of readers of this blog. [Thank you Dave Bridgeland and Tommi Vilkamo]. [And yes it’s true, I read every comment, try and reply to as many as I can, and try and learn from the comment. Otherwise why bother?].
I’m still reading it. [I read maybe a dozen books in parallel, usually in multiple passes as well. First pass skim-read, take a few notes along the way. Determine where to focus serious reading time the next time around. Second pass do the serious reading. Take notes on what I didn’t understand, what I need to dig deeper into, not necessarily in the book either. Third pass follow up and clean up, get the ideas clear in my head.]
And it was while I was reading the Beinhocker book first-pass that I was given the opportunity to revisit some of the stuff that Scott Page had written. I’d come across Scott before, I think it was Erik Brynjolfsson who first pointed me at him; I’d read Scott’s Computational Models from A to Z some time ago, and some of his stuff on Path Dependence more recently; I couldn’t link to that, you can find it on his homepage as a pdf.
I quote from Beinhocker:
Page proposed that there are two dimensions to the difficulty of an economic coordination problem. One dimension is how hard it is to decompose the problem into chunks that can be solved in parallel. [……] The second dimension is the number of steps that need to be done sequentially. […….] Page posited that organisations evolve to match the nature and difficulty of the probelms they are trying to solve. In rough terms, if the problem can easily be chunked into parallel tasks and doesn’t require much sequencing, then the organisation will reflect this simplicity and tend to be broad and flat. If the problem cannot be easily divided up and has numerous sequential steps, then the organisational hierarchy will tend to be narrow and deep.
And I think that’s where one of the major problems of Big and Complex lie.
There is considerable organisational inertia to task redefinition, de-sequencing and re-sequencing, as people desperately try and hold on to fiefdoms and power bases built around particular task definitions and sequences. As a result, things are done sequentially where they don’t need to be done sequentially. This false sequencing yields an unsolvable complexity and an immense amount of wasted energy, repeat work, even completely unnecessary work. Which in turn demotivates the workers and reduces task completion quality and increases task completion time. Workers aren’t stupid, soon you have apathy.
And I guess apathy is the hierarchical organisation’s equivalent of anarchy.
Big is necessary for Complex. But only when Complex itself is necessary. What I worry about is how often Complex is a construct of past hierarchies rather than a genuine need to solve a problem. I’ve heard phrases like “Don’t Allocate, Isolate”, “Don’t Automate, Obliterate” for a few decades now. I’ve even read HBR and related articles with similar titles that long ago. So why doesn’t it happen? Because of Unnecessary Complex.
As Einstein said, we need to keep things as simple as possible. But no simpler. So where there is a need for Big, Big can and should stay.
When you take into account the fruit of Moore’s Law and Metcalfe’s Law and Gilder’s Law, when you take into account the sheer power of the web and virtualisation and consolidation and service orientation, when you overlay all that with distributed computing and the grid and P2P, then maybe some of these hub-and-spoke approaches are ripe for obliteration. Just maybe.
Thanks again to Dennis for forcing me to think harder about this. And I look forward to more challenging comments, that’s how I learn.