Maximizing Efficiency: How Small Engineering Teams Can Achieve Big Results with APIs

In the?previous article, I discussed organizing products, domains, and platforms. In this article, I will discuss guiding principles for organizing engineering teams to work on products, domains, and platforms.

Each engineering team should be small, dedicated, autonomous, long-lasting, self-contained, self-organizing, and own one product, domain/subdomain, or platform service. Out of all those topics, I will focus on why team size needs to be small and the interaction model between engineering teams. I will cover other aspects in subsequent articles.

The most anecdotal theory on team size is from Jeff Bezos with his two-pizza rule. The team size should equal the number of people fed by two pizzas. Does any research back up that intuition? Yes, quite a bit of research backs that up. A recent article published in?Nature?provides evidence from multiple disciplines that the smaller the team, the more creative, innovative, and impactful the output. In addition, psychology-based analyses such as the "Ringelmann Effect" and "Diffusion of Responsibility" indicate that smaller teams are more effective than larger teams. The Ringelmann effect is the tendency for individual members of a group to become increasingly less productive as the size of their group increases. The Diffusion of Responsibility refers to the decreased responsibility of action each group member feels when they are part of a group.?

There are two communication costs: intra-team (within) and inter-team (between two teams). The intra-team cost of communications increases exponentially for every additional team member added. For example, if there are five members in a team, the number of possible connections is 10. If the number of team members is 10, then the number of links is 45. The formula is n(n-1)/2. As team sizes increase, the cognitive overload to keep every team member in sync becomes impossible.?

The cost of communication due to inter-team dependencies can also be expressed similarly. The more dependencies a team has on other groups, the more cognitive overload in communications. One way to reduce inter-team cognitive overload is to eliminate team communication. Jeff Bezos eloquently articulated the guiding principles for reducing the burden of inter-team communications.?Italics?is what?Jeff Bezos wrote, and regular font is my addition.

• "All teams will henceforth expose their data and functionality through service interfaces"??- Every team should abstract and expose the functionality - data, control, and management plane through an API.?
• "Teams must communicate with each other through these interfaces" - Every team should have published spec. Other teams should be able to consume API by following the instructions.?
• "There will be no other form of interprocess communication allowed no direct linking, no direct reads of another team's data store, no shared-memory model, no back-doors whatsoever. The only communication is via service interface calls over the network."?
• "It doesn't matter what [API protocol] technology you use"
• ?"Service interfaces, without exception, must be designed from the ground up to be externalizable. That is to say, the team must plan and design to be able to expose the interface to developers in the outside world. No exceptions."
• API should be designed for plasticity. The API should not change for various combinations (product, country, etc.)

In summary, the productivity of engineers can be greatly enhanced by keeping the team size small and minimizing the need for human coordination between teams.

#platformengineering #platform #microservices #leadership #organization #domain #innovation #team #api #product #productivity