Software Architecture and Feedback Loops in a Scaling Organization

Scaling an organization changes everything.

If you have ever experienced firsthand an organization that scales rapidly in terms of the number of people employed, then I guess you might agree with the claim I am making. Organization at scale simply plays by other rules.

This is actually a fascinating transformation to observe.

In the beginning, when the organization is relatively small, the choices you make are usually based on keeping things simple and fast. For instance, you would decide on having a single codebase with simple pipelines and packaged in one deployable unit. Since the focus is on speed you are quite comfortable adding dependencies across the codebase. Within the small team of developers there is efficient communication, and you are able to ship features quickly. The small organization is serving the customers well, and there is real collaboration between end-users, business and tech.

The eventual product success is usually accompanied by scaling the organization both horizontally, by setting up more product teams, and vertically, by creating more hierarchy. On scale, as Brooks Law advises, adding more people slows everything down. Working on a single codebase and deploying everything together starts to create tricky coordination issues. Dependencies across the codebase challenge the teams and chokes the decision making process. Straightforward decisions, such as upgrade to a new version of an external library, can feature as a heavy topic on the agenda of middle managers’ go/no-go meetings.

The simple choices, once sound and sensible, suddenly appear to be the very root of the technical debt everybody is complaining about.

At this point somebody usually suggests to split the source code in multiple repositories. With multirepo, all of a sudden the developer experience improves and product teams work fast again, feeling autonomy and flow in the daily work. On the other hand, as a shrewd consequence of this seemingly natural choice, the overall product testing becomes more costly. The distributed development environment has in fact extended the testing feedback loop to the integration environment.

The advantage of source code autonomy now turns into an inter-team coordination drawback.

The next thing you know someone suggests moving back to monorepo and the cycle repeats itself.

This story has unfortunately quite often been told in many organizations that happen to deal with the challenge of scaling.

Instead of discussing monorepo and multirepo tradeoffs I suggest observing the organization and the system from multiple perspectives and focus exclusively on the feedback loops.

‍

Feedback Loops in Multi-Team Organizations

Try to answer 2 simple questions after studying the figure above:

• Do you feel incentivized to tick off a product feature as done before it reaches the end-user in the customer environment?
• Is verifying the needs of end-users a tedious process almost always involving dependencies outside your team boundaries?

If your answer is Yes to either or both of the questions then I believe that your organization is, deliberately or inadvertently, choosing to sacrifice realistic end-user feedback. This is usually due to the slowness of the feedback loops within the organization.

At this stage you can trace back this observation to the decision on going with monorepo or multirepo. If there is a connection there, then you have solid arguments on moving in one or the other direction.

However, the real value of observing the feedback loops is relating it to the model that helps us understand scaling as a force that works in multiple dimensions. The model I am referring to is the 4+1 View Model of Software Architecture , which describes each system from 4 different views: logical, development, process and physical perspective while evolving the system through scenarios or use-cases which comprises a “+1”-component.

Following this model, we quickly realize that spreading the source code across multiple repositories is just one dimension that helps us handle scaling. Instead of overfocusing on development view, I advocate establishing the quickest possible feedback loop between the logical view, or logical boundaries, and the end user needs they are meant to serve.

Stressing and questioning your architectural choices by continually exposing your logical boundaries to different scenarios, is what keeps your organization and systems you are building capable of working at scale!

‍

Conclusion

Systematic learning from outside the organization can be time-consuming. Allow me to finish with yet another model that can help you understand the forces we are dealing with when scaling an organization, the CoWork's model of Levels of Alignment applied to the topic of multi-team organizations

Whether or not you are dealing with a small organization or an organization at scale the realistic feedback loop occurs only on the Outside View, where we let end-users, stakeholders and the market guide our decision making. The challenge is much bigger in a scaling organization due to longer time it takes to facilitate learning. This is the real purpose of software architecture, shortening the feedback loops from the Outside View to the inner organization structure.