3 minutes read
I recently had the chance to sit with a number of middle managers and discuss a core client interface process involving a number of different roles, functions, and innovation projects across the organization. The overall setting was a highly hierarchical organization as represented by a neat org chart, a pronounced organizational upper class, and a strong sense of, and respect for, chain of command.
A strongly hierarchical organization and organizational fragmentation go hand in hand
One would think that such an organization is highly integrated – it is not, to the contrary. It is highly fragmented. This fragmentation shows, for example, in a high number of staff functions like “chief of staff”, “secretaries”, or “operating officers” across the organization – meaning that there are a high number of roles with an underspecified remit. Another symptom of fragmentation are hundreds of alignment meetings with unclear agenda ownership, little to no decision-making power, and far too many participants. And finally: consultants and contractors everywhere, ‘shadowing’ virtually every significant project within the organization, often with a number of different vendors working on the same topic in different corners of the business. You would guess that the PowerPoints reaching the board of management would tell a coherent story of what was going on (the respective chiefs of staff of the board members and the operating officers of board members’ direct reports would somehow see for that, mostly through, have a guess, endless alignment meetings).
The consequences of fragmented hierarchy
How can an organization so formalized and hierarchical be that fragmented at the same time? Wouldn’t the board members collectively tend to unified approaches across the divisions? The answer is no, and upon reflection, that seems almost logical. Each unit on every level of the organization would feel the need to replicate topics within their own little pyramid. Central guidance was both to be feared and useless. On the one hand, it was feared for its hierarchy-related implications. Accordingly, everything was carried up the ladder, just for people to cover their back. So, on the other hand, what was handed back down in terms of decisions and direction was way too underspecified to be of much practical use in the respective unit. Accordingly, people would start giving their own answers. The motto at the top was probably something like: “decide and execute”. Down in the organization it was rather “duplicate and align”.
This organization would end up in the worst spot: it would appear to be slow and underperforming in virtually every topic requiring cross-unit collaboration.
Agile organizing is about getting the balance of centralization and decentralization right
The point I want to make here is the following: the managers of this organization would be the first to doubt that self-organizing (or agile organizing speaking more generally) could ever work. They would express their fear such experiments would necessarily end in chaos. It seems chain of command gives a powerful illusion of being in control.
While I can relate to such doubts, it is based on a misunderstanding of what productive self-management in large organizations should mean. We believe that agile organizing is above all about getting the balance of centralization and decentralization right – and that implies getting the centralized pieces right, however you call them: the framework, the backbone, the joint platform, the overarching cross-divisional strategy. This then is a precondition to empower autonomous teams to decide, execute and create value within their remit, without fear of disobeying fuzzy guidance and the urge to align and cover your back at every meaningful juncture. Being clear on what the firm as a whole is about and what decentral teams can, and should decide on their own is a precondition to organizational agility.