Team-first
Amazon’s two-pizza team concept is often brought up in discussions about modern software development teams. But while it’s become common to measure the size of a team based on their appetite for pizza, people often forget that these teams are intentionally kept small because the business domains they are part of are also broken down to a granular level to give each team a singular purpose, focus, and identity. Such teams are known under different names: product development teams, engineer‐ ing teams, development squads, product squads, feature squads, service teams, etc. In their book Team Topologies: Organizing Business and Technology Teams for Fast Flow (IT Revolution Press), Mathew Skelton and Manual Pais call them stream-aligned teams. According to Skelton and Pais, a stream-aligned team is a team aligned to asingle, valuable stream (flow) of work that is aligned to a business domain, as shown on the right in Figure 2-4.
Figure 2-4. Team ownership of multiple bounded contexts versus a single bounded context
Enabling Teams
Team Topologies introduces new thinking around effective team structures for enter‐ prise software delivery. It discusses four team types: stream-aligned, enabling, plat‐ form, and complicated subsystem teams.
A key observation is that not all engineering teams in an enterprise are responsible for building products and services that express domain logic. Enabling teams act as enablers for those stream-aligned teams so they can perform efficiently. Their focus might be on the platform, DevOps practices, tooling, developer experience, security measures, auditing, and observability principles, among other things. These teams may have different names in different organizations, but their general responsibilities remain the same.
A common misconception in the industry is that serverless technology does not require some of the roles and responsibilities an enabling team fulfills. This is not entirely true, even though serverless eliminates most platform and infrastructure heavy lifting. Your organization requires engineers with the expertise to set up guardrails and processes, such as security principles, well-architected service audit processes, etc. Unlike the siloed team structure, the key difference here is that ena‐ bling teams don’t carry out the work on behalf of the stream-aligned teams; instead, they empower others to perform better with a reduced cognitive load and work efficiently to increase velocity and flow.
In addition to establishing different types of teams with distinct responsibilities, many organizations adopting cloud and serverless form a working group commonly known as the cloud center of excellence (CCoE), described in more detail in Chapter 11.
