Below Water Level

Consider for a moment some of our day to day struggles:

• A Software Developer chasing people to request PR reviews,
• Product Managers running from team to team to sort out development bottlenecks,
• Executives trying to push through change that constantly runs into management aches.
• Constant investment in headcount just to stay where we are in terms of product velocity.
• Degrading product quality as more code and more people are added into teams.

There is no hiding from these struggles even in a modern, fast-paced iterative product team. For leadership already struggling to meet business and investor expectations, Founder Mode seems like an easy fix but this is a profoundly mistaken view. What we need is to rethink how we organize our teams.

I argue that keeping the size of a work-group absolutely minimal is the answer. Here’s why.

There is no hiding or avoiding accountability in small teams.

Smaller teams need to be self-sufficient or full-stack enough due to limits on their headcount. A full stack developer may not require support or may not have dependencies on other backend developers. UI and Interaction design will not need two separate persons. Such separation is a result of industrial-era mindset where specialization is encouraged in large teams. That may have been true with machines, but does not hold for humans. Separation also requires immense coordination and planning that increases costs and time-to-value.

Smaller teams usually will have lower communication overhead.

Because there is an acceptance of self-sufficiency of teams, there is an encouragement to learn and a fix-it-yourself attitude pervades rather than a “not my problem” mindset.

Smaller team sizes inherently enforce smaller scope projects. Smaller scope results in sharper definition of value and faster delivery time frames.

Smaller teams enable deeper relationships and trust, especially when combined with regular rotation among team members across the different teams.

Change management is easier as the team with fewer people can change direction, composition, tooling faster than large teams.

When there are fewer people to manage in a team, usually there is no need for a dedicated “Manager”. Coordination, planning and external communication responsibilities can be taken on by one of the team members. Better still is when this coordination and communication role is rotated among the members. It helps develop those critical skills.

With fewer managers, there are less entrenched interests, turf protection and empire-building that comes with the territory. Although most such behaviours are with a good intent to further the team’s own cause, there is a tendency to optimize for the team rather than the system.

For many projects, having a small team reduces risk as investment is lower. Because a small team will be multi-skilled, communication and coordination overhead is low, leadership can run many experiments without betting the farm.

Size of a small team can also be a forcing function for how much work can be handled by the team. Smaller teams enforce lesser work-in-progress which speeds up time-to-value, reduces wasted and half complete work kept around as unfinished inventory. This is also the genesis of the Amazon “single threaded leadership” principle that enforces accountability of one goal, one outcome. Single threaded leadership ensures that performance evaluations allow for considering the size and complexity of that one goal, rather than having multiple goals and projects assigned to a person or team, creating even more ambiguity in gauging how well a person or a team did.

Technical and product architecture decisions will also be influenced by the small size of a team. In a small team there is an assumption of self-sufficiency. There is also an expectation that a small team’s time is highly valuable. There are so few people in it in the first place, we cannot waste their time navigating the organization, which usually happens when teams are organized by ownership of systems or parts of a product. Naturally, small teams become a forcing function for devising architecture for fast ramp and quick time-to-value.

To be self-sufficient, small teams will need adequate cross functional mix within the team. This helps develop incredible cross-functional empathy, knowledge and increasingly the ability to take on the work of a different discipline.