Sustainably scaling engineering teams requires a lot of different elements. Here are eight things your org needs to build teams effectively.
Effectively scaling an engineering team is always challenging. Whether you are scaling your whole startup organization to meet rising demand, or just spinning up a new team to tackle a big project, there are a set of core principles that will help you build healthy teams that stay aligned with the broader business context.
I’ve regularly seen teams that are built through rudimentary size and effort calculations struggle to scale. Imagine it takes roughly six months to develop a new product, hiring three engineers and putting them to work does not help to ship the product in two months. When working in environments that apply less efficient ways of building teams, I noticed that even if these teams managed to scale, they often remained inefficient and unproductive.
Poor planning can also result in teams that are not created to be self-sufficient and autonomous. Through several iterations of building and scaling engineering teams, I have derived some basic principles that can help guide this process.
Aligning team structure with the current product architecture
Broadly speaking, teams working on a monolith product architecture should be organized by product pillars or product features.
Contrastingly, teams working on a microservice architecture should be organized by independent microservices. Not every product is a pure monolith or microservice, but if one weighs more heavily over the other, choose a team structure that reflects the current product architecture.
Avoid falling into the trap of building your team structures based on a futuristic product architecture. Relying on a hypothetical vision like this will negatively impact the efficiency of your product and engineering teams.
Designing highly cohesive, loosely coupled teams
Scalable architectures are built on the principle of high cohesion and low coupling. Each component in a system should have a single well defined responsibility and there should be minimal dependency between other components in the system.
The same principle applies while building scalable engineering teams. Developers within a team should work hand-in-hand, focusing their efforts on reaching a common goal or target, while ensuring they have clear lines of communication with developers in other teams.
Teams that are designed using this framework are largely independent, can make autonomous decisions, and move faster.
Shaping communication paths
There should be a high bandwidth of communication within a team of developers, allowing for greater predictability, speed, and efficiency. However, 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, as that requires a collective and broader outlook toward solving problems.
Measuring the 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 product pillar owned by that team.
A service could be relatively small, but if it falls on the critical path of a product with an aggressive service level objective (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 the cognitive load is not considered while designing team structure, that can cause uneven distribution of work and developer burnout.
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 with the development, QA, and operational skills that are required to build and deploy solutions.
Upon building cross functional team(s), 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.
Avoid constantly changing teams
Often, organizations expect developers to be flexible and to operate at high levels of efficiency, while undergoing constant changes. However, If the structure of a team is constantly changing, expect software delivery to slow down significantly.
Sometimes, reorganization cannot be helped. Whenever a team is reorganized, revisit Tuckman’s model to help nurture it. The forming-storming-norming-performing model is necessary and inevitable for a new team to grow and it takes time for the team to go through these evolution stages.
When a team structure is changed for the right reasons, consider the time it may take for the team to form a new baseline, before setting high expectations and aggressive deadlines. In my experience, it takes three to six sprints for a new team to operate to its full potential. Juggling aggressive timelines while also having to get to grips with a new team structure is difficult. And this breeds delays in delivering outcomes, which impacts the business.
Building a specialist squad
I recommend having around 5% of your engineering workforce be part of a specialist squad that will pair with different product teams to deliver outcomes. The specialist squad brings together top-notch product engineers who are great with tech and have a solid handle on the ins and outs of the platform and its field. The specialist squad sits outside of core product teams to work on complex business requirements.
In scenarios where they’re required, engineers from specialist squads should 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 should join the specialist squad on a rotation from the product teams and should be extremely knowledgeable in the technology, framework, or product pillars at hand. They should have a good background on the business and legacy product features.
Most importantly, these specialist squads should not be treated as a dumping ground for complex, unsolvable problems. Instead, they should be considered as allies who come in to support teams with short deadlines.
Final thoughts
Building engineering teams requires organizational context and deeper insight into the strengths and challenges of the teams and the problem they are trying to solve. Engineering leaders need to be mindful of the opportunities and constraints while building and scaling teams that are productive and efficient. By following the above principles, you should be on the path to building more independent, scalable engineering teams.
