Recently I’ve been doing a number of assignments that involve a significant amount of organisational design. I think that the conventional thinking in this space is completely broken and only a view that breaks the existing convention will help.The work I’m doing seems to start from this problem statement: “I’m a CIO and I believe that Agile is a better way to work. I’m ready to re-shape more than just my software delivery teams to improve productivity. What do I do?”.
Here’s where I become a heretic. I’ve read most of the material on ‘Enterprise Agility’ and I think it’s fundamentally wrong. The reason I think it’s wrong is that it takes the existing paradigm and tries to tweak it to make it ‘Agile’, however the paradigm is inherently un-Agile. I think we have to be increasingly radical in our approach to solving this problem.
Here’s a graphical representation of what I’m trying to get at…
In the diagram the X-axis represents the choices of organisational architecture available to us (structure & process). The Y-axis represents the performance resulting from the selected organisational architecture. Of course in the real world this is a multi-dimensional problem; I’m not including people capabilities and culture in the model.
If we start at point X then we can use continuos improvement (Kaizen) to get to point A in the model, which is the local optimisation for the selected architecture. However, if there is another, higher performing optimisation out there (B) - and I believe there is - we won’t find it from point X using continuous improvement. If we move to the right we will detect that process performance is worsening and move back to the left, towards point A. To get to point B requires a more radical shift in thinking and strategy (Kaikaku). If we shift the underlying paradigm to point Y then we can start to use continuous improvement to move to the new local optimisation at point B, a marked improvement over point A. To do this we need to radically re-think the way the work works.
This is my issue with thinking of enterprise agility as a continuous improvement problem. If we take a top-down, command & control model and continuously improve it, we’ll only ever end up at a local optimisation built on command & control. The systems management community have known this for years. This is why Messers Toyoda and Matsushita were never concerned with their Western competition. “The problem is not in your businesses. The problem is in your heads.”.
The fundamental issue is that the organisational model applied by most corporate IT divisions was developed to maximise the efficiency of 12 year-old boys working in sweatshops in the North of England in the 1860’s and reached it’s pinnacle as a model for managing thousands of uneducated, low-skilled men in the production of cars in the early 1900’s. It’s a model designed to solve a problem that bears no resemblance to the challenge of modern business; it’s over 100 years out of date. Systems management theory is largely a response to this issue.
In a command & control world we take a top-down (inside-out) view of the organisation. We start with the top manager, in our case often the CIO, and we build a structure that maximises the ease of managing the people. In a systems management world we take a sideways (outside-in) view of the organisation and build a structure that maximises our ability to deliver customer value. This means that where command & control is about managing economies of scale, systems management is about managing economies of flow.
In a command & control system, managers create the system and set the targets for the workers. The initial focus of failure is on the people. Managers manage the people.
In a systems management model, managers and the people in the process create the system and define the system performance measures. The initial focus of failure is the system. Managers manage the process.
This leads to a new way of thinking about the way we architect the way IT divisions deliver value. The guiding principles I’m currently focussed on are…
- Outside-in over Inside-out.
- Process efficiency over man-management.
- Process measures over performance targets.
Of course thinking this way leads us to new challenges. We’ve just broken our cost accounting models as they rely on being able to hold divisional heads accountable to budgets, not value realisation. Our policy deployment tools (balanced scorecard) won’t work any more as we don’t have a top-down organisation. I’m also parking the challenge of recruiting great people. We shouldn’t worry though, someone smart will solve these problems by applying models like throughput accounting and hoshin kanri; systems management versions of the command & control tools.
I’m currently working on a presentation for JAOO in Denmark called ‘The IT Division Refactored’, where I’ll talk about these ideas and where they are in the maturity life-cycle. I’ll post a version on here when I’m done.

September 10th, 2009 at 12:53 am
I think the key thing in your diagram/assumptions is that a small change in behaviour makes a small change in the performance. Its certainly possible that in complex problems, a simple and obvious next step could cross the chasm in your diagram resulting in finging the other maxima. Just like in mathematics, there are many tools to solve systems, perhaps we could clasify traditional management as linear least squares (as a best case :-), Kaizen then becomes something akin to non-linear regrassion like Levenberg-Marquardt or perhaps Nelder-Mead simplex method, in that it is able to solve a wider range of problems. Simulated Annealing could perhaps be considered Kaikaku.
September 10th, 2009 at 3:35 am
Hi Richard, this is an interesting point and perspective. I think I’ve run into a similar situation between implementing Knowledge Management and how it connects with the organization as a whole, and seeing that using Lean practices to tie it all together makes a lot of sense. I just made a post about this earlier today: Lean, Agile, and Knowledge Management
Regarding the value realization vs. cost accounting, it seems like that could be tied together so that budgeting is proportional to how much value is created by something. It seems like the disruptive part of this is it would need to be much more iterative in order to not just be based on a perceived value generated, but to be able to adjust to the actual value over time.
May 6th, 2010 at 5:39 am
You are absolutely correct in what you are saying about - especially - around the intuition expressed in your diagram and in the quote -
“The problem is not in your businesses. The problem is in your heads.”.
Now consider that the journey to B is exactly throughthe valley between X and Y and that indeed this is the natural order.