While supporting small organizations, I noticed how easy it is for everyone to have a fairly precise idea of what others are doing and how they are doing it. In such organizations, all members contribute to the decision-making process based on their competencies and experience.

Keeping everyone up-to-date is not resource-intensive, and information sharing is usually self-regulated through daily interactions.

Decisions are made collectively during recurring or ad-hoc meetings, or asynchronously in chat groups. The outcomes are not only documented but also become part of a “living” shared common knowledge, as everyone knows almost everything.

This is one of the benefits of small organizations that also applies, to a certain extent, to small development teams.

However, in larger organizations, this magic ceases to exist. They face one of the most difficult challenges when it comes to scaling: how to handle the decision-making process across teams while ensuring consistency, velocity, and efficiency?

Scaling software development teams is a difficult and complex task that is often influenced by a variety of business, technical, and strategic factors. As there is no one-size-fits-all solution, each organization must carefully tailor its approach to meet its unique needs. Therefore, there is no simple answer to that question.

However, I will try to define some of the most important points to keep in mind while designing a solution.

Adding a centralized, accountable group

Any organization that has multiple development teams working on the same product must address a common problem:

the delivery of a coherent whole. [1]

Although teams should strive to maintain as much independence as possible, it’s inevitable that they will share some core topics within the organization. This may include coding standards and guidelines, libraries, tools, and generic problems and solutions. However, the biggest role is played by architecture solutions and implementations.

I’ve seen a variety of strategies aimed at achieving as much consistency as possible.

However, as Will Larson writes in his work An Elegant Puzzle: Systems of Engineering Management:

when the problem becomes truly acute, folks eventually reach for the same tool: adding a centralized, accountable group__.

In almost every project I have worked on, at some point someone has started a discussion about creating a new cross-team group.

The purpose of this group is to find consensus on a multitude of overarching topics.

Efficient centralized group

Characteristics for an effective and efficient centralized decision-making group

For a centralized group to be effective and efficient, it must possess the following characteristics:

• Small: not more than 7–8 people. A bigger team would struggle with productivity since has to deal with communication and coordination overhead.
• Enabled: the group must possess enough authority, domain knowledge, scope experience, and technical skills to design and implement a solution.
• Committed: each group member should have enough time and capacity to work on the group’s tasks, take decisions and deliver business value in a short time frame.
• Representative: every team involved must have representation in the overarching group. Otherwise, there may be issues in the future with the acceptance and adoption of the group’s decisions and solutions.
• Goal-oriented: it is essential that everyone in the group understands the group’s goal. If the goal no longer exists or has already been achieved, the group should be dismantled or put on hold. The risk of having groups that meet regularly without a clear or meaningful agenda is always high.
• Measurable: Define metrics to measure the effectiveness of the group. Allow the group to track them and make them visible and accessible to everyone. Positive results will reinforce the group’s authority and have a big impact on the adoption process of all teams. Negative results will indicate that the centralized group may not be necessary, and the issues must be addressed in another way.

Create the right environment

Failure modes of centralized groups

I have spent countless hours discussing how to shape such groups, how to handle communication, and most importantly, how to solve all the frictions and conflicts they cause.

The topics and issues encountered have remained more or less the same over time.

Therefore, it would be extremely useful to know beforehand what common mistakes to avoid at all costs.

I completely agree with the “failure modes” defined by Will Larson:

1. Domineering groups limit individual freedoms and can cause high member turnover. This often happens when decision-makers are disconnected from the consequences of their decisions, such as in architecture groups with minimal coding involvement.
2. Bottlenecked groups try to do more than they can, which leads to burnout or a backlog that slows down decision-making.
3. Status-oriented groups prioritize being a member over the group’s intended purpose. Members seek recognition more than making contributions, which dilutes the group’s original mission.
4. Inactive groups are usually those where members have not yet formed a connection or are too busy. While this is the most harmless of the four failure modes, it also means missing out on a lot of opportunities.

Of course, since this is just a summary, I recommend reading the book if you are interested in the topic.

How are you handling the decision-making process across teams?

Undoubtedly, there are many other ways to handle the decision-making process across teams. How are you currently doing it?

Summary:

Scaling software development teams face the challenge of consistent decision-making processes across teams.

It can lead to communication breakdowns, inconsistencies, and problems with architecture solutions.

A centralized group can help address this problem:

• it finds consensus on topics that affect multiple teams, such as coding standards and architecture solutions.
• It ensures consistency across teams.

A successful centralized group must be small, enabled, committed, representative, goal-oriented, measurable.

It’s very important avoid common failure modes, such being domineering, bottlenecked, status-oriented, inactive.

References

• [1] **"Scaling the Practice of Architecture, Conversationally" by Andrew Harmel-Law
• “An Elegant Puzzle: Systems of Engineering Management” by Will Larson
• “Scaling Decision-Making Across Teams within LinkedIn Engineering” by Haricharan Ramachandra
• “Architecture awakens” by Saul Caganoff, Ken Corless
• “Architecture without Architects” by Erik Dörnenburg