All software teams are not staffed equally. Teams follow the same principles, but their composition will vary significantly depending on the type of software under development. In our research, we found that software can be grouped into four archetypal categories on the basis of the complexity of customer interactions and who (the company or the customer) controls software deployments.
A common benchmark of software development teams is the ratio of traditional developers—whom we call “feature engineers”—to other members of the team. As Exhibit 3 illustrates, these ratios can differ greatly depending on the
When a software team internally controls an application or a service, such as consumer cloud software, developers can directly write, launch, track, and adjust code without engaging with the customer. This reduces the need for end-to-end quality engineers, as illustrated in the boxes on the right side of the exhibit.
At the other extreme, when the customer controls and deploys the application or service, as illustrated in the boxes on the left, feature engineers have less ability to modify the software after launch and must address a more fragmented user base. Accordingly, end-to-end quality engineers are necessary to serve as a proxy for customer needs and to monitor deployments.
This model applies to the individual microservices that compose a product, not to the product itself. A single product will frequently have services that fit within all four categories. For example, the team launching an app on the iPhone will have a very different composition from the team responsible for launching the app’s underlying server infrastructure.