Scaling the Architecture Function through Organizational Growth

In a company’s early days, managing architecture is simple. When you have a single team building a product, they all have the principles in their head and peer accountability takes care of poor choices.

As a company scales, the number of teams begins to grow. Past a few, they can’t keep track of the day to day decisions being made by other teams and you need a central point who understands the pieces. This is often the engineering manager.

At some level of scale, the manager realizes that they either have to focus on the people and process or on the technology. Past some number of reports, it becomes impossible to track the work, the architecture, and the people and service all of them well. The simplest solution is to have a dedicated architect. They work with the tech leads (or line managers) for the teams and help them line what they’re doing up with a bigger coherent vision.

Past a certain number of teams, there are enough different products and technologies that a single architect can no longer manage all the complexity. They either become the bottleneck by trying to stay engaged in the practical for all the teams or they climb into their ivory tower and hope that the vision they create gets absorbed somehow by all the teams. The end result is the same — disconnect between architecture and implementation and a LOT of teams doing what they want how they want.

With strictly senior teams, this can sometimes be okay (delta the inefficiencies introduced by teams duplicating work when they encounter similar problems). Scaling quickly, however, requires hiring a lot of people earlier in their career and the pace of feature development in a growth company limits the sharing of best practices. Without the benefit of architectural oversight, some of these teams will create fires in production, even in the face of their best intentions. If there are enough teams, at least a few of them have something on fire at any moment. Customers lose trust.

This problem can be solved by layering the architectural responsibilities across three tiers — the Strategic Vision, the Tactical Day-to-Day Trade-offs, and the Bridge Between them. The Strategic Vision is the realm of the Chief Architect. This person sets the lighthouse on the horizon (2-3 years out) so that we know where we are steering the company from a technology perspective. In order to be a lighthouse, the vision should be relatively unchanging from month to month and so, by necessity, remains fairly pure and high level.

The Tactical Day-to-Day Trade-offs are best made by the tech lead within a given scrum team — the very person who is under pressure to ship a specific feature by a specific date. They are the closest to the actual implementation and can understand time vs. value. Their focus should be on making decisions that maximize customer value over time. This (often) means that they will choose between different technical solutions based on how quickly or easily they can be implemented. Typically, these decisions do not account for the long term vision or show understanding of what is being developed across the organization. We can try to educate this layer and hope for the best but the reality is that it is too much to expect all of the folks at this level to always adhere to best practices in the face of the pressure to ship. What is needed is a more senior architect who understands their struggles and their goals and can help them align to the overarching vision.

The Bridge Between the chief architect and the technical leads is built by these very senior (typically director+ level) architects who have intimate knowledge of the lighthouse vision and work daily with some set of the scrum team tech leads. Their job is to own the mapping between the strategic vision and the day to day work of their smaller set of teams. They help the tech leads make very practical decisions to ensure that while we do not strive for architectural perfection, the trade offs we must make are at least directionally correct.

This organizational structure is not a theoretical one. It served me well in three different companies spanning over a decade of time. As with anything, it is subject to the second law of thermodynamics — everything falls apart without work. In future posts, I’ll cover the mechanics by which I’ve seen it work as well as the type of architect who does best in this system.

What it looks like in a picture