Eight Effective Principles On Building And Scaling Engineering Teams
Improve efficiency and reduce communication overload
I have had many opportunities to build and scale engineering teams in my leadership career. These opportunities often arise from the addition of a new business function or product pillar. When a new team needs to be created, or an existing one needs to be scaled up, my immediate starting point is to assess the scope of the work, and identify the number of developers needed to accomplish the job.
In the past, I’ve worked in a less efficient, and a frankly more archaic way of building teams.
The teams built through rudimentary size and effort calculations struggled to scale, and even if they did scale, they were not efficient and productive.
Layered on top of that was the complex dependency structures built across teams, as they were not originally designed to be autonomous and independent. Through several iterations of building and scaling engineering teams, I have derived some basic principles to apply to the process.
1. Team topology that reflects product architecture
Teams working on a monolith product architecture are organized by product pillars or product features, and teams working on a microservice architecture are organized by independent services. Not every product is a pure monolith or microservice, but if one weighs heavily over the other, choose a team topology which reflects the current product architecture. Over-engineering team topology based on a futuristic vision of the product architecture will have a negative impact on the efficiency of product and engineering teams.
2. Bounded context of the team
Bounded context is an architectural pattern used for designing complex solutions. The purpose of bounded context is to design a loosely coupled, highly cohesive product architecture which offers high reliability and scalability. This should be leveraged when designing engineering teams. Developers should collaborate closely in building a highly cohesive service, and should have well defined communication paths with teams that build other services. Teams that are designed using this framework are largely independent, can make autonomous decisions, and move faster. They also exhibit a high level of dependency within the team, and a limited dependency on other teams.
3. Shaping communication paths
There should be a high bandwidth of communication in a team of developers, as it results in predictability, speed, and efficiency. On the contrary, communication across teams should have low bandwidth, because it increases dependency and blurs lines of accountability. Cross-team collaboration should be limited to when the teams are working on new ideas or building proof of concepts. When teams are focussed on execution, cross-team communication will increase cycle time, decrease speed, and delay time to market. Creating limited communication paths across teams is therefore ideal.
4. Inverse Conway Law
The Inverse Conway Law states that team structure should be designed based on the product architecture. Having a target architecture in mind, we can explicitly evolve structure and communication paths between teams that will help achieve the planned design. Following the Inverse Conway Law is an opportunity to consciously design product and engineering teams while building new products, or rewriting legacy products. Building team structures and team topology is not a purely managerial decision. To build a team topology that closely reflects the product design, architects and designers of the system should be involved in the process.
5. Measuring cognitive load of a team
A team’s cognitive load is not measured by lines of code, or the number of classes/modules they create and maintain. It is measured by the complexity of a service, module, or a product pillar owned by that team. Even if a service is relatively small, and it falls on the critical path of a product with an aggressive SLO, the team that builds and maintains the service will carry a higher cognitive load, compared to a team that manages a larger service that is not hugely critical for the product function. If cognitive load is not considered while designing team structure, it causes uneven distribution of work and developer burnout.
6. Adopting a team-first approach
High performing engineering organizations are built based on “services for teams and not teams for services”. In order to embrace a team-first approach, start by building cross-functional teams that have a high bandwidth on technology and skills to make impactful decisions. Now, layer the services or product pillars on top of these high performing, autonomous teams. This model will result in higher efficiency, extreme ownership, and accountability. Every service or component should be owned by exactly one team. In the event that a library, code, or component is shared between multiple teams, one of the teams should claim ownership of the shared artifact while developers from other teams continue to the shared codebase.
7. Constantly changing teams
A constantly changing team design slows software delivery. Organizations expect developers to be flexible, continuing to operate at high levels of efficiency, while undergoing constant changes to the team. This is an anti-pattern to build and sustain high performing teams. Every time a team is reorganized, revisit Tuckman’s model to help nurture it. There is anecdotal evidence that it takes three to six sprints for a new team to operate to their full potential, and those teams will often have less than six sprints to produce a new product feature. As a result, there are delays in delivering outcomes, which impacts the business.
8. Specialist Squad
Around 5% of an engineering workforce should be part of a specialist squad that will pair with different product teams to deliver outcomes. Engineers from specialist squads will be brought into product teams to solve complex problems, build small subsystems for the product feature, or debug hard to solve performance and stability issues. Developers in the squad should be a specialist or subject matter expert in a technology, framework, or a product pillar. They should have a good background on the business and legacy product features. Specialist squads should not be treated as a dumping ground for complex, unsolvable problems, but should rather be considered as allies who come in to support teams within short deadlines. Developers should join the specialist squad on a rotation from the product teams.
Building engineering teams requires context. Considering the state of the organization and its short and medium-term needs is key. But while doing so, it is important to keep in mind the long-term sustainability and productivity of the engineering organization.
If you are interested in learning more about Engineering Team Topologies, I highly recommend reading “Team Topologies” by Matthew Skelton and Manuel Pais.
