Autonomy across the enterprise

Moving from the comfort of the age-old bureaucratic structures (DP1) towards a flatter and more democratic organisational structure founded on participation (DP2) can seem like a treacherous journey into the unknown. So much so that many may still prefer the devil they know and try to dress that up so it looks nicer and less scary instead. The thing though is that the path is lit by the numerous researchers and theory builders that has come before and the journey has been taken my many to learn from. Not only can they provide gear needed, they can also show what the destination may look like. Not only in principle, like the DP2, but even its potential and tangible manifestation. I will try to give you my understanding of how the structure of an enterprise can become when only consisting of self-governing teams, often referred to as a “hierarchy of functions,” and it will feel surprisingly familiar.

Disclaimer: I promised in my last post, “Enabling a Learning Organisation,” to finally get into some of the praxises in open systems theory (OST), but after I had a long and difficult discussion on Twitter, I see the need to explore one way DP2 could look like in a non-trivial organisations: hierarchy of functions. Consider this my current interpretation.

When collectively designing a new organisation based on the second genotypical design principle it is important that there is some consensus that this is what people wants. There will be some that feel challenged by the idea of a participative democracy based on their current position in the existing organization and any career they path they may be on. There will therefore be inertia to this move and it can be hard to get the design right and even harder to keep it running afterwards if not dealt with early on if not handled properly. When everybody hopefully is onboard – which all should be; no downsizing needed – there will probably be some bewilderment next if there are no clear and shared understanding on how to get there and what good looks like in the end. It is therefore important that everybody in the whole organisation is fully briefed on concepts and process and all questions are explored before the process begin. The process itself, which will be the topic of later posts, has to be run as a set of temporary DP2 structures for both doing the strategic planning that takes you towards a shared desirable future and for designing the new organisation that supports it.

“In a DP2 structure, nobody has the right to tell others what to do and how to do it. All communications are conducted as negotiations between equals." —M. Emery

The basic building blocks of DP2 is the self-managing groups that has no first line managers/supervisors. This alone is creating a lot of confusion for people indoctrinated in the bureaucratic model where everybody in essence are irresponsible and are told what to do – except the few at the top. Even more so if you are part of a large enterprise with a deep reporting hierarchy. How on earth can such a huge structure be replaced by a a set of teams? This is where “hierarchy of functions” comes in. It acknowledges that different types of work need to be done at different levels of the organisation, especially large ones like enterprises.

Before moving on, let us define "hierarchy" as used here as that seems to create different associations in people depending on where they come from. Hierarchies are abundant in nature and is a very common way to organise things where something consists of other things, like a system and its parts. The definition used here is aligned with Herbert A. Simon's: “By a hierarchic system, or hierarchy, I mean a system that is composed of interrelated subsystems, each of the latter being, in turn, hierarchic in structure until we reach some lowest level of elementary subsystem.” It is placid and neutral, i.e. power in play here – that we know as the autocratic/bureaucratic hierarchies.

When a sizeable group of people design their organisation and want to self-organise in teams at all places in the company, the functional way of splitting will be a natural choice. Some, probably most, will be concerned with the production of goods, be it manufacturing or software development, while others will be running the business, such as HR, finance, branding, customer service, sales, production, BI, etc. These functions are all needed in order to run the company and they obviously need to work together as peers to do this. This can be viewed as a flat organisation, where the teams/groups are fully owning their own function, but for any non-trivial context a hierarchy will form.

This structure will look like a business capability model and for good reasons as people are self-organising around business functions. In the same way business capabilities are nested in levels, will then the supporting organisation mirror this. The teams will actually be the driver for the fragmentation of the business into smaller and smaller business capabilities as the teams grow and splits into smaller groups, taking charge of smaller and more specific business functions, which means that some will be have to work across and consider the bigger picture and different time spans, such as support functions, middle level planning, strategic work. There will be fewer levels in a DP2 type organisation and the number of people in the higher levels as management moved down and replaced by productive work, directly relating to and helping fulfilling company goals. Important to note then that the hierarchy of functions stands in direct contrast to the hierarchy of dominance, where all levels need to cooperate as peers and changes can occur anywhere and can potentially impact everyone as the teams are in charge of their own goals and are actively adapting to their environment.

From Merrelyn Emery's paper "Self managing management of the self managing organization: an update" (2018)

What about IT then, how will it look like in organisations where software and digital products is core business? How will the production parts look like there? Firstly, IT will probably not be a separate function, like an IT department. It will be spread around in the company, each business function that need IT capabilities will have that themselves, be it sales, finance, branding, etc. Secondly, in companies that offers digital products you will have teams supporting and owning each one and when the products grows and need more people supporting it, it will too fragment into subgroups and you end up with many teams supporting the same product. Check out Eduardo da Silva’s post “Prodtech Teams” on how this can play out.

There is another interesting dimension that is added to the functional hierarchy by Team Topologies (TT) and Domain-Driven Design (DDD), which obviously do not come from OST and shows how DP2 can take many different forms. In TT there are other team types in addition to these productions teams (known there as “stream aligned”) like platform and enabling teams. These teams are all also collaborators, working on and owning different parts of the whole, i.e. the hierarchy, and their relationship is concisely described in DDD by the context map patterns where they have a upstream/downstream relationship to ecah other. The stream aligned teams are dependent on services delivered by the platform teams and the services provided by the enablement team; they are upstream, steam aligned downstream. Again, no power over, but negotiations among peers, which also indecently shows why the platforms must be product-ified; hard to be good peers in a customer-supplier relationship.

Hierarchies is the most natural thing and you will have them in both DP1 and DP2. The difference is how it is managed, either by autocratic command & control in DP1 or by collaborating self-governing teams in DP2. What OST shows us is that there is no inherent need for the legal hierarchy, the bureaucracy, to design or run a well-functioning company – even a large one.

"'Management by objectives' or goals is no longer a dream; it has become an essential component of self management at every level of the functional hierarchy, a reality that governs the behaviour of the organization as a system in its environments." —M. Emery