How to Structure an Engineering Team for Scale

When I joined Electric, the top priority was to reshape the Engineering organizational structure in order to prepare the team for scale. To deliver on Electric’s growth objectives, I require 60% growth in headcount this year. However, before doing so, improving the existing structure was critical so that we would be expanding on top of a scalable foundation.

The challenge was twofold:

• Structure the teams in a way that best serves existing business and technological missions.
• Devise a high-level structure that allows for easy scaling, optimized for adding new teams into appropriate logical spots as soon as new resources are available.

Researching the state of the union on agile team organization, I rewatched the Spotify Engineering Culture video we’ve all seen, now six years old, and once again I was impressed with how well the video was put together. So much so that the video itself is probably better than the model it presents, if it was intended to be a model at all. Anthony Mersino has written on this subject extensively. I also reread some notable articles from the plethora of sources out there writing about every incarnation of an agile team (product team, feature team, self-manage team, you name it), of which I especially enjoyed Kenneth Lange’s overview of strengths and weaknesses of some of these forms.

I am generally in favor of the tribes and squads model, or any equivalent breakdown of a business into domains (tribes) that provide shared context across several agile teams (squads). A tribe provides a mission-critical area of focus, and may benefit from dedicated leadership at the director level. A squad is a fancy name for what would otherwise be called any of the aforementioned names for an agile team, which in our case, we simply call a pod. Beyond tribes and squads, Spotify offered chapters as horizontal units representing a single-function (Back-End, Front-End, etc.), and guilds, representing cross-functional groups that come together around a shared topic of interest (e.g. Security). Pretty neat.

The main thing that bothered me with the Spotify organization was the reporting structure. Based on the video, engineers reported to their chapter lead, for the benefit of being able to move between teams as resourcing needs surface, without having to change their manager. This may seem like a good idea, promoting dynamic resourcing and structural adjustments without the pain of leadership reassignments. However, to me, if you’re reporting to someone who shares with you merely a technological affiliation (e.g. if you’re a Back-End engineer reporting to the Back-End chapter lead), it means your manager does not share with you a profound understanding of your team’s business mission.

It’s not practical for a chapter lead to be deeply familiar with the subject-matter of every team within their tribe. Given each person they manage belongs to a different squad, there’s only so much domain expertise they can build. I’d much rather folks receive leadership support from a manager who is not just familiar with but accountable to the same product objectives and business goals.

There are certainly cases where being able to move engineers between teams without worrying about HR changes is advantageous. In our case, however, such reassignments were happening so often that we’ve started experiencing fatigue and frustration among our engineers. The overly dynamic resource allocation created a sense of instability and a struggle in building individual team culture and subject-matter expertise among the pods.

Choosing vertical engineering management reporting structure over a horizontal one is more in line with our overall structure of pods and tribes: all three would then be organized around business missions: the tribe represents a business domain or a general product area. The pod carves out a piece of said domain and owns it to the fullest. The vertical reporting structure correlates to the business focus, creating ample opportunities for manager and individual contributor to be in the same room together - in ceremonies, kickoffs, design reviews - through the lifecycle and inner workings of the pod.

Here's a sample of a basic structuring exercise you could follow:

1. Define your business as a set of focus areas, which when put together cover your entire product offering. Those would become your tribes.
2. Think of each of your existing agile teams: which business domain does it belong to? What is its particular mission? Place each team into the relevant tribe.
3. Imagine you have the resources to spin up the next three to five teams. For each, think about what its mission would be, and what tribe it would best fit in. This should give you a general idea of the hottest areas around which to focus your scaling efforts.
4. Create a diagram describing your tribes and pods, including possible future pods. Revise as the organization grows, as missions change, and as new teams are added.

Our vertical organization clarified, we went on to examine our horizontal units. Sneak peak: our guilds, which were in practice much closer to being chapters inasmuch as they were each comprised of a single engineering function, would soon be rebranded as “councils” - a unifying term that stands somewhere between chapters and guilds, but without a reporting structure attached to it, and with a mission-focused operation. We then also solidified our Platform tribe and inaugurated our core platform pods, now prized with permanent resources and team roadmaps. But that is a story for Part 2 - structuring horizontal org units

It may be obvious, but there’s never a global right or wrong engineering organizational structure. What fits our growing team right now may not fit a year from now, so we’ll have to stay agile and iterate on the structure itself. But until then, I am confident we’re well-set for the near future. With our hiring budget also finalized for the year, we’re ready for a heavyweight talent acquisition effort.

I hope that’s helpful for other leaders grappling with similar dilemmas. Best of luck with your structuring!