Team Design and More

Over time, engineering managers have opportunities to reshape their engineering teams, reconsidering how they are organized and oriented to their work. This reshaping might be gradual, as managers work to guide engineers and influence their team climate and emergent states, or it may be sudden in response to organizational change.

Engineering team design refers to how you structure your engineering team, its roles, and how those roles operate. Team design optimizes productivity and other success metrics, such as efficiency, effectiveness, and innovation. You might have an opportunity to design your team from scratch during an organizational change event, but more often, team design involves incremental changes to solve team problems that crop up in day-to-day work.

In this chapter, you will learn the foundational concepts in designing engineering teams. You will learn about team structures and characteristics and revisit Conway’s Law. You will receive...

Introducing engineering team design

New engineering managers rarely have the opportunity to directly choose a team design, but regardless of where you are in your manager journey, having awareness of team design concepts can help to orient you and reveal solutions to problems. Depending on your work context and goals, team design can make a big difference in your team’s productivity and performance. To that end, let’s start by learning some of the most common software development team designs and how they operate.

Common team structures

Software development organizations structure their teams in different ways to meet organizational needs. In terms of reporting hierarchies, these are the most common approaches for team structure:

• Functionally aligned teams are grouped by a particular skill, which may be a technology or type of work, such as an iOS development team or an infrastructure engineering team
• Product aligned teams have members who are dedicated...

Lingering questions

In this handbook, there is a broad range of information to help engineering managers do their best work, but there are a few topics not covered in previous chapters. Along with team design questions, you may have a few more lingering questions, which will be addressed here.

What are squads, chapters, guilds, and tribes?

If you have heard these terms used in the context of team design, you might have heard them in reference to the Spotify model. In the early 2010s, Spotify wrote extensively about its team design approach and popularized a structure consisting of a product aligned organization with formalized communities of practice, as shown in Figure 16.5:

Figure 16.5: The original Spotify model of team design

In the Spotify model, a squad is a cross-functional team working together on a specific product area. A chapter is a small community of practice with a narrow area of focus. A guild is a large community of practice that...

Summary

In this chapter, you learned the foundations of engineering team design and how to adjust your team to suit your needs:

• Engineering team design refers to how you structure your engineering team, its roles, and how those roles operate
• The three primary engineering team structures are functionally aligned, product aligned, and matrixed:
  • Functionally aligned teams are built around a particular skill area with an engineering manager who is knowledgeable in that skill
  • Product aligned teams are organized according to product areas rather than functional skills
  • Matrixed teams incorporate both functional and product structures
• Communities of practice help to maintain skill-based conventions and communication in product aligned organizations
• Team characteristics to consider in team design include organizational tenure and personality traits:
  • Teams with a mix of different tenures help each other to learn about the organization and new approaches
  • Belbin’s personality...

Further reading

• “Understanding team design characteristics” from Organizational Behavior, 2010 (https://open.lib.umn.edu/organizationalbehavior/)
• Belbin’s team roles (https://www.belbin.com/about/belbin-team-roles)
• How to Build Your Own “Spotify Model” (https://medium.com/the-ready/how-to-build-your-own-spotify-model-dce98025d32f)
• Davison, Barbara. “Management span of control: how wide is too wide?.” Journal of Business Strategy 24.4 (2003): 22–29 (https://doi.org/10.1108/02756660310494854)
• Reckoning with the force of Conway’s Law (https://www.thoughtworks.com/en-us/insights/podcasts/technology-podcasts/reckoning-with-the-force-conways-law)
• Measures of engineering impact (https://lethain.com/measures-of-engineering-impact/)
• Disagree and commit: the importance of disagreement in decision making (https://hackernoon.com/disagree-and-commit-the-importance-of-disagreement-in-decision-making-b31d1b5f1bdc...