The magic answer to organisational design…

Simple rules that solve organisational design?

For a long time I wasn't really exposed to people who believed that building teams on complex projects was essentially like ordering a prefabricated house and fitting it together.

“How many outside walls?”

“That's easy. Four.”

So, simple rules that solve highly complex nuanced projects. Let’s look at some topics.

Span of control:

The correct span depends on the capability of the people involved, the complexity of the work, the degree of standardisation, and how much decision-making authority sits below the leader.

Layers and hierarchy:

Each layer creates a potential point of coordination, interpretation, delay and political influence. Hierarchies can be needed to provide mechanisms for escalation, accountability and decision-making. They are bad when they exist just because somebody needs a title, a larger empire, or protection from direct accountability. They can also become islands of equal worth where instead of people looking at removing them altogether because they are not needed they are gradually shaved off (leaving them even less effective and promoting negative behaviours as they try to grip on for survival).

Layers and hierarchy can be adversely affected if Span of Control becomes in and of itself a more important topic that doing the work.

Being aware of this theory is positive as quite often organisational design in teams within large organisations is delegated to people who may be good managers but have not had any training or awareness of this topic.

Asking a question to gauge understanding of someone within an interview on these topics would be very useful to have a candidate elaborate on their experience to gauge whether they would have potential awareness and experience to optimize existing team structures.

However, expecting someone to come up with a magic number as a maximum is trivilising the topic. For the interviewer asking this question their belief that there is a maximum really just shows that they themselves are looking at these topics as being far simpler than in reality they are.

The cascade scenario of these sorts of fixed rules in people’s heads is that management behaviour becomes highly erratic. So, for instance, let’s look at the following flow.

• Maximum number of people reporting to someone has to be 8. This is a fixed rule and cannot be exceeded. This is enforced by a senior manager who believes this rule.
• The manager with 8 people reporting to them finds that their team are unable to cover the full extent of the work required. Due to the rule, noone else can be added.
• Performance of the manager is seen as low. The manager cannot have more people reporting to them (remember this rule is fixed). Bringing this to life imagine there are 8 people, 6 of whom are delivering different functional aspects of a project. There is 1 person who runs the administration of the project e.g. reporting, requests for hiring, etc. and there is another person who advises the manager on compliance aspects of the overall programme.
• The 8 people within the team start hiring additional people to fill the gaps in the overall team ability. Communication that would be direct from the 9th person has to go through 1 of the 8. So for instance, a cyber security expert to advise on overall security constraints and standards.
• Communication is slow and frustrating and performance is even worse than before with just the 8 people.
• The Manager has failed and is removed, their performance was low and “they” had management issues.

The rule of "8 maximum" is retained.

For a simpler program of work 8 maximum could have worked, but it’s just an arbitrary number.

For a program where the work is constantly being constrained, 8 people could be the maximum required.

For a program where the actual functional complexity / domain coverage is low, 8 people could also work as a maximum, although you would assume there would be fewer than eight people.

Now I just chose 8 because it’s at the upper end of most agile team recommendations however it could really be any number. The point is that this is "an answer to the meaning of life, question i.e. highly complex question, too simple answer".

Now if you are supplying people to a program this sort of rule is actually extremely profitable. If your client hears the maximum number of people rule enough, there won't be any push back when they want more resources. "Ok, so we have the request for those three extra analysts. Great we’ll get those 3 new people and, of course the new manager for you, as soon as possible ($$$)".

As well as the profitable side of things I think one reason for this sort of thing is that some people don’t like working with unknowns. Instead of working through something piece by piece and getting a result they have to try to simplify things in their own minds so that they feel they are in control. There is also the more negative aspect where you can promote an answer which you can then weaponise e.g. going back to our interview question. In interviews when people do ask these questions expecting a stock answer, it is surprising how one sided these sorts of things are. I have interviewed hundreds of people and also attended other people’s interviews. It is surprising how many people will ask questions like this and not explain the answer that they were looking for. A possible motivation for not explaining the required answer is it opens themselves up to potential questions and debate on why people think that a complex question can be solved with a simple answer.

From my experience if you are working on highly complex programme or project, reducing the layers is a key to success.

Accountability is far more obvious and there is a real incentive to trust each other and provide support when it's needed.

This actually is the process working in reverse from what I have described previously. By focussing on reducing the layers we actually see the span of control grow for people in the layers that remain.