In the first article of the series, I show you the key concepts of setting up a team for an early-stage startup. Early-stage startups should treat the team as the means of delivery and software development as a process.
Growth stage startups generate a steady stream of income and regularly acquire new users. At this stage, you should be looking forward to expanding your software development team. The goal of the hiring is to speed up the delivery cadence.
Adding manpower to a late software project makes it later — Brook's Law
The statement above is the simplified version of what Fred Brooks tried to point out in his 1975 book The Mythical Man-Month. He suggested:
- It takes some time for the new member to become productive in the complex software project.
- Communication overhead increases as the number of people increases.
Besides, people have different perspectives and interests. Aligned autonomy is getting difficult as the number of different perspective and interests increase.
Therefore, you should reduce the complexity by defining the team structure and the team interaction mode.
The following ideas are inspired by the Team Topologies by Matthew Skelton and Manuel Pais. In the book, Team Topologies, the authors suggest four fundamental team topologies and three team interaction modes. In this article, I show you how to utilize them.
The Team Structure
A new web team is formed when the current web team has a bigger backlog than they can deliver on time. A data team is formed when the current product/delivery team doesn't have the capacity or lacking the knowledge to meet the data needs (e.g. building dashboard).
In most cases, the teams expand vertically with a flat hierarchy. If the team or software boundaries are not properly defined, it is difficult to understand which team is responsible for which part of the software. And, the teams constantly having conflict in priority.
Four Fundamental Team Topologies
Stream-aligned team is a team that delivers software end-to-end independently. Examples like product team, feature team, agile team, cross-functional team, etc.
Enabling team is a team that assists other teams in adopting new technology or practice. It is preferable to be a short-lived team, as a task force. It also can be a long-lived team-like community of practice.
Complicated-subsystem team is a team that requires specific domain knowledge or skillset. Examples like data team, machine learning team, payment team, etc.
Platform team is a team that provides tools and services that empower the stream-aligned team to deliver software faster independently. Examples like DevOps team, infrastructure team, SRE team, developer experience team, etc.
In sports, the first team is the first-choice lineup of players who start the game. Behind the first team, there is a team of backroom staff consists of managers, coaches, nutritionists, and etc. The backroom staff help make life easier for the first team to compete on the field on a regular basis. I find it very relevant to how software development team structure should be.
First Team and Backroom Staff
The first team, in most cases, is the user-facing team. The team that delivers software directly to the end-users. It is also known as the stream-aligned team.
The team structure starts with the first teams. The teams receive feedback from the users and stakeholders and manage the software roadmaps.
Today, the software is very complex. Any application screen or page that users are using, requires the combined knowledge of design, development, and delivery to produce. It exceeds any first team's cognitive load to deliver in a timely manner. First-teams need a supporting system.
The backroom staff plays the support role in delivering the complex software.
Platform teams provide infrastructure, CI/CD pipelines, and other necessary tools. So that, the first teams can build and run the software while outsourcing the knowledge to the platform teams.
Complicated-subsystem teams provide specialist services to reduce the need for the first-teams to acquire knowledge from other domains, like payment, compliances, and machine learning.
Enabling team, usually, a short-lived team is also known as a task force in a different context. Occasionally, organizations form a temporary team to solve a specific problem, such as bringing in a new authentication service and helping other teams to adopt it.
Let's go back to the previous example of the web and data teams. If we were to apply the first-team and backroom staff structure, it will look like the image below. Web teams are the first-teams and the data team plays as the backroom staff supporting them.
Team Interaction Modes
Organizing teams into patterns is halfway to the fast flow development. Team interaction is always an oversight from the organizations, or they assume the same interaction mode between teams. Without a clear definition, communication overhead is usually the common result.
Three Team Interaction Modes
Collaboration mode is one team working closely together with another team. Both teams are expected to interact with each other on a daily or weekly basis. This mode is good for the discovery of new things or boundaries.
X-as-a-service mode is one team consuming or providing something with minimal collaboration with another team. Both teams are expected to collaborate with each other less frequently than the collaboration mode.
Facilitating mode is one team helping (or being helped by) another team to clear impediments.
In some organizations, collaboration mode is the default strategy. Every team is required to work closely with each other. Therefore, most of their weeks are filled with meetings.
Some organizations think X-as-a-service is the best strategy. Every team provides libraries and APIs for other teams to consume. Due to the limited collaboration, cross-team projects or features is difficult to achieve fast flow because there is a conflict of priority among the teams.
The scenarios above are based on the concept of the team interaction mode is fixed. However, strategically apply team interaction mode is the key to fast flow development.
Strategy
Software changes when the business changes, and so does team interaction mode. How teams spend their time and who they spend their time with should be adaptable to the business needs.
Let's say if the business wants to build a new dashboard with richer information, Data Team will work with Web Team A in collaboration mode while maintaining the X-as-a-service mode with Web Team B. Then, when the business wants to expand the usage of the dashboard to the rest of the product, Data Team swaps their interaction mode between Web Team A and Web Team B.
Summary
To maintain or speed up delivery cadence when the team is growing, growth-stage startups should reduce the complexity with the first-team and backroom staff team structure, and strategize the team interaction mode.
