How to slowly destroy your organisation
Here is a tip if you want to destroy your organisation: keep adding roles!
I’ve seen it in many companies, and it is a typical slippery slope! Let’s discuss why and what the alternatives are.
Back to the “beginning”: the agile team
Think of a small company. Just a handful of people working together on the same product. They all understand it. They can all take part in the system of work. Simple, easy, adaptive (i.e. agile). Wonderful!
But then the organisation grows, and more people are hired. Finally, the point is reached where the organisation believes they need to have “roles”.
There are good reasons for creating roles in a company, the two most common being:
- We need specialisation
- There is too much to know for a single person. We need to divide the mental workload among several people
My observation is that, while this is probably unavoidable as the product under development grows, the decision to create roles in most companies inevitably happens way too early when the two points above are not really a necessity yet.
So we start having…
Roles
Gregory Bateson said that a “role” is only one end of a relationship, a “half-a**** relationship” (as per a video snippet that is part of the beautiful documentary on Gregory produced by his daughter Nora: http://anecologyofmind.com – an overall highly recommended view!). So when we define a role, we’re actually defining a set of relationships among roles, i.e., the need for proper interfaces.
This means that saying something like “you now have the role of X” doesn’t make sense unless we consider that person part of a complex system of interactions. Therefore, how a person will perform in a role will depend also on their counterparts in the organisation.
The consequence is that if my role is X, your role is something else than X. I have some form of authority on X, but you don’t. I can gain more knowledge about X, but you don’t (and I will lose or never gain any knowledge on everything else, of course).
George Spencer-Brown would say that by defining a role, we’re drawing a distinction that was not there before (see here for more). Why does it have to be this way? Because… it’s arbitrary.
Of course, there is a “tradition” of having some specific roles just because this is what many companies do, so we copy that without thinking…
- How, for example, is a requirement engineer different from a tester? One thinks in terms of “the system shall do [something]”, while the other thinks in terms of “let’s see if the system does [something]”.
- And why do we conceive coding separate from testing and testing from coding? It does not make any sense!
Yet, this is what most companies do. Unfortunately, there are some dire…
Consequences
1. Separation of knowledge and creation of silos
Every distinction we’re drawing in an organisation creates a separation of knowledge and the respective silos. But our products need to be able to work as an integrated system, so the more roles we have, the less capable we are of creating consistent products. In the worst case, we are victims of Conway’s Law, but even before reaching that extreme, collaboration, integration and teamwork are progressively more difficult.
(for an introduction to the syntax used in the following causal loop diagrams, please refer to this post)
The obvious way to compensate for this effect is by investing more in coordination meetings. This has a cost in terms of money spent, time-to-market delays, and lower motivation because people spend time in meetings instead of doing creative work.
And the more coordination, the more need for coordinators, who also happen to be knowledge silos increasing the number of specialised roles.
Over time, this causes…
2. Organisational complexity
This is when a company grows in hierarchy and in the number of people needed to get the job done — no need to spend more words describing why this is detrimental. Over time, this might become the kiss of death for your organisation (and I’ve seen it happening quite commonly).
The reason why you cannot simplify the company pyramid is, at the core, too many roles!
3. Increase in defensiveness
When the system does not work, and somebody even mildly suggests the problem might be in my area, I might feel attacked, and my ego might ask me to fight back – of course, I am the expert on X, so how can “they” insinuate the problem might be in X?
I’ve noticed that this conflation of expertise and identity in the role is often at the base of many conflicts among people. The silo I am in becomes also an identity to defend.
Of course, we’re all different, and some people are very open to working to get the job done – regardless of where the problem might be; the hell with my ego! But the more roles and silos in a company, the more often these situations arise.
4. Roles are challenging to remove
For many people, a role is recognition. Often, role assignment is considered a career move and has salary implications – my role is important, i.e. I am important.
At the same time, once knowledge gets siloed in a role, it will become much harder for that person to step out of their comfort zone and try something different. Companies usually reward a “job well done” rather than learning!
This is the primary drive behind the first Larman’s Law of Organizational Behavior, and removing such a role will be very difficult.
Conclusion
Please, please, please: think twice before adding a role. There will be situations where that is the right choice, but in most cases, I’d instead suggest expanding the skills and competencies of the people doing the work and having them act as a team to get the job done. While this is harder in the short term, it might keep your company sane while growing. And remember: it’s much easier to add a role than to remove it!