Efficient Adaptive Team Structure

The traditional “team chart” has fallen out of favor. Self-organizations the idea de jour. At the same time, predictability remains a top priority — especially in safety-relevant, large systems projects. The project’s key stakeholders demand transparency and a well-defined team structure. That sounds like a contradiction in terms, but the concept of an adaptive-agile team structure answers this dilemma.

Small expert teams often don’t need an explicitly defined team organization. A team of 10 developers can typically self-organize efficiently and deliver results to the customer on time. The difficulties begin when the teams become larger. The planning often becomes a nightmare, as the project team usually struggles with delivering required features and meeting the agreed delivery deadlines.

The challenge of team scalability can be explained using the complexity theory (more common in mathematics and computer science) paired with the graph theory. Although such matters may appear somewhat abstract, a general understanding of complexity theory offers a significant advantage when it comes to designing efficient project team structures.

Let us look at a hypothetical team of eight developers and then compare it to the situation in a team of 20 and see how the team complexity behaves. Both teams don’t have a deterministic structure (i.e., there is no hierarchy in each of those teams). To self-organize, everyone would theoretically communicate with each other to coordinate the development effort. The number of possible social connections can be calculated using the following formula:

N = n(n – 1) / 2

In our first example, there is a maximum of 28 potential team interactions.

Developers	Interactions
1	0
2	1
3	3
4	6
5	10
6	15
7	21
8	28

Computer scientists use the “O” notation to indicate the effort class, the “order of magnitude,” if you will, of algorithmic computations. The formula “n(n – 1) / 2” implies the complexity class O(n²) of a pair-wise team interactions. Such polynomial complexity can be viewed as suboptimal but deemed acceptable in small teams.

The total number of 28 interactions, however, is not the whole truth about the team complexity. The team will naturally spontaneously form transitive interaction chains, in which a developer A will talk to developer C, and, acting on A’s input, talk to developer E.

Two transitions (A -> C -> E)  are the result of the three developers working on adding value, such as implementing a complex feature.

Independently, developer A could contact developer H, then hand the task over to developer E. In turn, E would delegate a chunk of work to B to finalize the feature. In this case, three different transitions were needed to complete the complex feature: A -> H -> E -> B.

The maximum number of all possible “sub-trees” (the “complete graph,” see here) of such interactions (= graph vertices) can be calculated using the following formula:

n^2*(n-1)/2

The total length of such transitive interactions “chains” grows very fast.

Developers	Interactions	Possible Transitions
1	0	1
2	1	2
3	3	8
4	6	64
5	10	1024
6	15	32768
7	21	2097152
8	28	268435456

Using the O-notation nomenclature, the formula n^2*(n-1)/2 can be simplified as O(nⁿ), which means an exponential complexity of this algorithm. The massive number of all possible “sub-trees” of team interactions is, of course, a theoretical figure. In reality, an interaction chain length of 3 is likely, while longer transitive interaction chains are not. It does not, however, invalidate the complexity assessment. Instead, let us assume that a team of eight developers is indeed efficient and compare it to a larger team’s efficiency.

In the following example, a 20 developers team works in the same manner as the previously discussed, smaller minor team.

Developers	Interactions	Possible Transitions
1	0	1
2	1	2
3	3	8
4	6	64
5	10	1024
6	15	32768
7	21	2097152
8	28	268435456
9	36	68719476736
10	45	3,51844E+13
11	55	3,60288E+16
12	66	7,3787E+19
13	78	3,02231E+23
14	91	2,47588E+27
15	105	4,05648E+31
16	120	1,32923E+36
17	136	8,71123E+40
18	153	1,1418E+46
19	171	2,99316E+51
20	190	1,56928E+57

While the number of peer interactions in the team of 20 grows moderately (190), the number of potential interaction chains (distinct social graphs) now grows to truly astronomical orders of magnitude!

Those theoretical numbers may appear too abstract to have practical implications, but those implications should be taken seriously. There is no way to underestimate the results of this simple thought experiment. Managers have always known that all is not well in the realm of systems projects world working in weakly structured teams, but now we have at least a ballpark number that gives a rational explanation of the disproportionally distressed projects in such team settings. In summary, the complexity theory explains why smaller, unstructured teams often work fine while larger projects struggle to deliver expected results. The root cause is now plain: those teams tend to be of exponential complexity.

Interestingly, the exponential complexity itself is often a notoriously underrated problem. We, as human beings, have always struggled with grasping the concept of exponentiality. The famous “Wheat and Chessboard Problem” helps to understand the phenomenon of exponential growth. In other words, exponentiality is inherently unnatural, if you will. The good news is that, once the problem is understood, a solution is relatively plain and straightforward to implement.

Team Partitioning

A resolution to the project scalability challenge lies in the establishment of an efficient structure of the project team based on responsibilities and roles. For example, a specific team member could take responsibility for the functional safety concept. Naturally, the proper training and experience are required for such a role, but, especially in the case of functional safety documentation, such “concentration of responsibility” benefits the entire team. Similarly, in large teams, “sub-teams” take the responsibility of a set of customer features, usually based on the systems architecture. Thus, the role of a “team lead” (or “sub-product owner”) can be established.

While the team structure should be as flat as possible, the natural outcome of such responsibility partitioning is a “tree of responsibilities.” The complexity of data trees, as opposed to unstructured graphs, tends to be logarithmic— O(log n) (using the O-notation).

Let us construct a hypothetical team of 20 developers, partitioned as follows, to see how the team complexity behaves. Let us assume that the team consists of the following team roles: 1x Lead Product Owner, 1x Product Owner 01, leading nine developers, and 1x Product Owner 02, who leads eight developers.

Assuming that, in our hypothetical example, the Lead Product Owner is responsible for defining the scope of work for each team, and the team is “coherent” (in the sense that there are no significant interactions between Team 01 and Team 02), the team complexity could be calculated as follows:

Team 01
Developers	Interactions	Possible Transitions
1	0	1
2	1	2
3	3	8
4	6	64
5	10	1024
6	15	32768
7	21	2097152
8	28	268435456
9	36	68719476736
10	45	3,51844E+13

Team 02
Developers	Interactions	Possible Transitions
1	0	1
2	1	2
3	3	8
4	6	64
5	10	1024
6	15	32768
7	21	2097152
8	28	268435456
9	36	68719476736

The Lead Product Owner is available for each team, thus adding 1 to each teams’ total number of developers.

Let us further assume that the total number of work transitions (that is, multiple work steps performed by different persons) can be calculated as a simple sum of the teams’ complexities. Comparing this “partitioned” team to the previous example of weakly organized teams of 20 developers reveals the complexity differences between those two.

# developers	# direct interactions	# transitive interactions
20	190	1,56928E+57
20	81	3,52531E+13
Relative difference	43%	0,000000000000000000000000000000000000000002%

As a result of partitioning the team into two cohesive groups, the relative difference between the maximum number of pair-wise interactions reveals that only 43% are required for the partitioned team. At the same time, the proportion of the transitive actions decreases thanks to the hierarchy team structure reciprocal-exponentially! The result might appear exceedingly odd, but such is the power of the exponential complexity growth. In other words, partitioning a large team into smaller teams can decrease the team complexity disproportionally.

What Does That Mean for an Efficient Team Organisation

Even though the assumptions in the above example are of a very general, oversimplified nature, and the theoretical number of potential, transitive partial graphs are significantly overstated, the fundamental relative difference between peer-to-peer and partitioned teams is so dramatic that it cannot be ignored.

The strategic implications of the above considerations are substantial for organizations that are planning to conduct an agile transformation. The reasoning for such transformation is that team efficiency will be increased, thus offering a strategic edge against the competition. However, especially in MtO project settings, it only works when the teams’ structure is well-organized by partitioning the teams around their responsibilities in a tree-wise manner that benefits from the logarithmic team complexity.

A “Fractal” Team Blueprint

A flexible team hierarchy is instrumental to achieving logarithmic team efficiency. The concept of a “hierarchy” has become a red rag to organizations aspiring to facilitate the agile transformation, but such opinions, especially when asserted as a categorical rule, are biased and scientifically inconsistent. Leading psychologist Jordan Peterson explains in his book “12 Rules for Life” the evolutionary reasoning for the existence of social hierarchies. The concept of a social hierarchy, he states, is a disruptive evolutionary achievement that has proven successful over hundreds of millions of years for nearly all social life forms on Earth, including us humans. We might want to be careful when attempting to re-invent such an evolutionary approach. As Jordan Peterson further explains, social hierarchy is an essential vehicle for social values, particularly corporate values. The “agile mindset” can therefore only effectively be achieved in the context of efficiently established hierarchies.

That said, I am not proposing a rigid, top-down, inflexible command-and-control project hierarchy. I am far from it. In fact, we have learned over thousands of years of written history that static, inflexibly structurally fixed societies are fundamentally flawed. Instead, the team semantics, that is, the underlying rules governing such teams, are pivotal. As previously mentioned, team partitioning is achieved by defining smart team roles with well-defined responsibilities. The roles structure remains “tree-like,” while the rules governing the teams should be consistent with the individual tasks, their abilities, and preferences (see also the article “The Right Genes for Your Projects“).

We must allow such team structure to change in an agile way as needed, thus being responsive to team growth and project phase in the overall project lifecycle, in accordance with the role semantics. In other words, and in particular, in MtO projects, an “agile hierarchy“ is needed. It can be achieved using two team role types:

1. Group roles (roles that are similar in each team)
2. Singleton roles (roles that contribute to all teams)

Group Roles in a Team Fractal

Let us now focus on the basic team responsibilities and their structure. The smallest, atomic team, should consist of the following roles: the Team Lead (it could also be called Product Owner^*), the Tech Lead (short for “technical lead”—it could also be called Architect or similar), the Developer, and a role taking care of the product quality assurance: the Validator. The idea is to follow the conventional V-model principle and replicate it throughout the entire project. The developers are located on the left side of “V,” while the product quality (responsible for testing) is located on the right side of the “V.”

In principle, the most minimalistic, small team could consist of just two persons. One role would include the Team Lead, the Developer, and the Tech Lead as one person. The remaining role of the Validator must be a distinct team member for the reasons mentioned above. For simplicity’s sake, however, let’s assume that the four roles are assigned to four persons.

The team scalability is achieved by replicating the team horizontally and vertically. For example:

The above scheme is a “fractal” in that the team roles are built recursively, fractal-like structure.

Expanding this role model could include other team roles, replicated for each team, such as Requirements Team Lead, Systems Team Lead, Build and Merge Lead, and so forth.

Team Singletons

Some roles cannot be easily organized in a fractal-like way. For instance, the Functional Safety Lead is such a highly specialized role that it cannot be “replicated” across all teams. This role is a “singleton” role.

The overall Team Lead is another example of individual responsibility, and it should be a distinctive role, as such a person has “end-to-end” responsibility for the entire project. This role could be called “Project Team Lead,” “Leading Product Owner,” or something along those lines.

Further examples of “singleton” roles could be:

• Functional Safety Engineer
• Project Requirements Engineer
• Build & Integration Lead
• Change Request Lead
• Project Tools Engineer
• Systems Build Integration Lead
• Project Coach

The Project Coach is responsible for structuring both the team fractals as well as the singleton roles in a most efficient, flat “role tree,” while the Leading Product Owner (with the help from Project Coach and other roles) leads the product development as agreed in the MtO development contract. 

Team Structure Semantics

Specific rules (the “team semantics”) are crucial for an efficient, adaptive agile project that implements an agile hierarchy. Example rules include:

• Trust and fairness: All hierarchies are unfortunately prone to negative team dynamics. When team members are nominated to lead other developers, their attitude sometimes changes. Thus, the Lead Product Owner, with the active support from the Project Coach, as well as the entire team, must constantly manage this risk and resolve any signs of negative behavior. It is a critical project risk that must be immediately mitigated.
• The team structure is sacrosanct: the Lead Product Owner musthave theauthority to protect and manage the team’s autonomy. That particularly applies to project team composition and team role responsibilities. Any skewed, sidewise interdependencies between the team members and other authorities, such as line management other than the project sponsor or other, sometimes informal (but influential) customer personalities, must be prevented. For example, if a team expert within the current project team is suddenly removed from the project and ordered to work on some other project without the project team leadership approval, the project team morale may critically suffer, and the entire team structure may become sustainably incohesive.
• Resolving team conflicts: The Leading Product Owner, supported by the Project Coach, must have the authority to resolve the team structure issues immediately. In extreme cases, the project leader must be able to replace the project team member following the corporate guidelines.
• Hiring new team members: The project leadership must be actively involved in selecting or rejecting potential team members. The Lead Product Owner should, at the very least, have a veto when a new hire is proposed by the HR manager or by other critical project stakeholders. I admit that such an approach is quite controversial. However, if new hires are not compatible with the rest of the team, the entire team may become demotivated by being forced to accept such team members and, in the worst case, simply stop taking responsibility for critical, technical decisions. The “It’s not my job” mentality is the worst possible outcome of that. The resulting “The surgery was successful. The patient is dead” organizational anti-pattern must be prevented. 
• Preventing “customer/supplier sandwich”: The hierarchical consistency between project sponsor, customer, and suppliers is key to making the adaptive-agile project work. If your supplier directly colludes with the customer, the organizational anti-pattern “the tail wags the dog” syndrome may develop. When this risk becomes apparent, project leadership must immediately escalate the situation to the project sponsor.
• Controlling the budget: The MtO project leadership should be fully aligned with the project sponsor. As Martin Luther once said: “Whose bread I eat, his song I sing.” If the team is completely “agnostic” regarding the project budget, the project leadership may make bad decisions without even realizing critical risks until it is too late.
• Vertical team-ability: The project leadership (the Lead Product Owner and the Project Coach) must ensure that everyone understands how to be both a leader and a follower in the project roles tree. The ability to lead and the ability to follow are two sides of the same coin. For example, a team Product Owner follows the guidance from the Lead Product Owner while the team’s Product Owner leads the assigned developers.
• Minimize the team’s depth: While a team hierarchy is crucial to achieving the logarithmic team efficiency, minimizing the hierarchy depth is paramount to the success of adaptive-agile projects. If the hierarchy becomes too steep (e.g., new subteams and sup-sup-teams are formed), the team can become inefficient.
• No task left behind: Everyone is talking about taking responsibility, but, occasionally, no one wants to act on it. In an adaptive-agile team, every activity, feature, validation activity, and work product (e.g., code or detailed design)  must have an explicit owner. Whenever a team member notices an unresolved project concern or risk, this person automatically becomes responsible until the task is resolved or the proper task owner is found and explicitly assigned in the project issue system.

The price for achieving a logarithmic project complexity in an adaptive-agile project is the necessity of constantly looking for potential team dysfunctions. For instance, it is crucial to prevent the formation of “silos” and other organizational anti-patterns. The Project Coach carries a special responsibility for closely watching the team behavior and removing any organizational obstacles in the teams’ way.

Further ground rules also follow directly from the role of a Project Coach as described in the article Project Coach.

The Bottom Line

The complexity theory offers an explanation for why weakly structured and incohesive projects tend to deliver suboptimal results. Unstructured “peer-to-peer” teams often work great in smaller settings, but with the growing team size and complexity, especially in MtO projects, the inefficiency threshold is quickly reached. Larger teams tend to become exponentially inefficient, with all ramifications that come with it. Well-structured project teams, on the other hand, can avoid organizational waste and frictions, otherwise resulting from unstructured work. Such teams tend to enjoy working with each other. Few developers remain unmoved by being given the opportunity to work with an efficient team.

An improved organizational efficiency, when combined with non-authoritarian team empowerment actively supported by Project Coaches,  also implies a higher team effectivity. In other words, working hard is good, but working smart is better. In that sense, implementing an agile-hierarchical team of a logarithmic complexity is a “smart” approach.

The term “hierarchy” has a nasty reputation that is well-deserved. Dysfunctional hierarchies often lead to organizational silos and frustrated employees. However, weakly organized teams often have the same effect. The proper project leadership structure can offer the best of both worlds. To achieve the desired efficiency improvement, the project leadership, starting with a Leading Product Owner with the unwavering support from the Project Coach and the rest of the team’s “singletons” and the “team fractal,” must guard and cherish the team’s motivation in a fair, most respectful manner.

Avoiding the fallacy of a potentially exponential, peer-to-peer project organization is a beautiful gift from the science of complexity theory. Let us use it to our best abilities.

_{*) In our example, the role name of a “Product Owner” is flexibly defined, as opposed to the generic SCRUM role definition, which is unambiguously described in the Scrum Guide.}

---

Let’s start a conversation on LinkedIn or X.com (formerly Twitter).