There is a saying that has been incredibly formative for me in how I think about teamwork:
“If you want to go fast, go alone. If you want to go far, go together.”
Whether I was coding, selling, or launching something, I could do things fast by myself. However, it was only when I had a team that meaningful outcomes were achieved.
A perfect example was a community I launched several years ago. It started small in NYC as a monthly meetup. Then people in different places reached out asking if there was a chapter in their city to join. So I went on the road to Boston to start that group. Then I journeyed to Philadelphia and Washington DC to open those chapters.
Then the floodgates opened. There were chapters in Atlanta, Denver, San Francisco, Seattle, and elsewhere. I racked up 30 roundtrip flights in three months, including one trip that took me from New York, to London (via Zurich), to Boston, to Denver, and then back to NYC. Clearly it was impossible for me to continue at this pace.
I started reaching out to the most active members in the different chapters to see if they wanted to join the team. I had no idea what this team would be, but I figured that sharing the workload between several of us would be significantly better than one person doing all the organizing, promotion, and managing.
There were bumps along the way in building the team. Some were not committed. Others were flaky and disorganized. Then there were some that were so domineering, they repelled people in the community. This led to miscommunication, conflicts, and delays in rolling out new procedures and programs.
Though the team building was slow, the outcomes were well beyond what I had imagined. This team of leaders enabled the community to expand to 24 cities across three continents while maintaining a monthly cadence of high quality meetups. The community grew to over 30,000 members with many in the community sharing how their careers changed for the better.
When I chat with startup CTO's, one of their favorite moments in the journey are the early days. Besides the fact that the CTO gets to be hands on with the code, the team is small and tight knit. You can swivel in your chair and ask a teammate a question or have a quick Slack chat with a colleague. The team works in lockstep and ships faster without a lot of process or approvals. This is the ultimate in team flow.
As the startup scales, the single team becomes a few teams. Then there are sub-teams and team of teams. Things take longer to complete, teams disagree, things fall through the cracks, expectations get misaligned, and communications breakdown.
When I was with Stack Overflow, I would often talk with engineering leaders about developer experience. The number one problem they would cite is the velocity in shipping features. When we peeled this back to identify a root cause, it always boiled down to communication and collaboration roadblocks.
As teams grow in size, so do the number of people each member of the team interacts with. When there are four people, that is six unique pathways to communicate. When you double the team size, there are 28 pathways, while a team of ten results in 45 pathways. This is known as communications overhead, and this overhead creates internal friction, especially as team size grows to hundreds and thousands of people.
From the first militaries to the rise of the modern corporation, many of the same issues of bureaucracy and communications plague organizations as they scale. This was the insight Kelly Johnson, the founder and head of Skunkworks, understood when he was tasked with assembling a team to develop a jet fighter ahead of the Germans during World War II. He kept the teams small and nimble so they could focus on the work rather than wasting time in communications and process.
Amazon figured this out early on as the retail site got bigger and more complex. The website was architected as a massive monolith, becoming harder to maintain and riddled with dependencies. Jeff Bezos then put out the mandate that Amazon.com would be entirely rearchitected using a services-oriented architecture. The result was not only a more manageable and flexible site, but teams were also decoupled and more focused on serving just their service.
One of the cornerstones of Amazon team structure is the two pizza team. Look anywhere across Amazon and you will see this in play. From the standpoint of project execution, it has worked perfectly, evidenced by the massive growth of Amazon since that fateful decision to go completely services based.
There is one area however where the two pizza teams still struggle to move fast. When setting vision and plotting strategy, the more people involved, the slower it becomes to produce results. I have seen this happen on numerous occasions in startups and in large enterprises. Why is that and what is going on here?
The problem is one of threading. When a team is in execution mode, every person on the team has ownership and responsibility over some aspect of delivery. Their work has a stake in the results. At the same time, the work is multithreaded, meaning there are multiple tasks critical to executing on the whole of the project or effort. Thus the work and the team are aligned.
Ideation, visioning, and strategy however are often not multithreaded. There is one thread at the conclusion of these exercises; the idea, the vision, or the strategy. As you add more people to the task, you get more divergent views, tangential concerns, and conflicts. This is not wholly negative since more diverse views often can add value in shaping the best direction and reducing bias. Too many opinions and feedback however often leads to the dreaded analysis paralysis.
The nature of most organizations is to reduce friction and conflict. The larger the group, the more driven we are subconsciously to seek consensus. In order to drive to consensus, we want facts, data, and evidence to support a group decision. This inevitably reduces risk tolerance and supresses the willingness to pursue bigger ideas which often lack supporting data. This is a dangerous state, because it stifles the freedom to explore and willingness to experiment.
In order to break through the paralysis, there are two options. The first is to have a core value or mechanism that explicitly resolves deadlocks and paralysis. At Amazon, that is the leadership principle known as Disagree and Commit, which simply means even if some of may disagree with a decision, as a team we will commit to supporting a decision. The second option is to reduce team size. This optimal size is what I call the one pizza team.
A one pizza team is more than simply reducing a two pizza team in half from 6-10 people to 3-5 people. This size is optimal for creating the focus and clarity required to think longitudinally and strategically because it eliminates communication overhead and reduces the tendency towards consensus thinking.
Consider early startup teams. Even without the lack of people power, they can get an enormous amount of accomplished because decision making is insanely fast. There is less worrying about risk. The bigger risk is in moving too slowly. We even see this in enterprises. In the book The Unicorn Project, Gene Kim introduces the protagonist, Maxime, to the team of corporate rebels (a one pizza team), they manage to turn around the dreaded Phoenix project. Though this is a fictional example, similar stories have been shared with me by engineering leaders about the incredible feats of small teams being the catalyst for transformational change.
Not every situation will benefit from a one pizza team. One of the dangers of small teams is the participants may not have the diversity of thought and experience needed to tackle big questions or paint an expansive vision. Then there are times when a large team can be beneficial when broad scale buy-in is important to the decision making process. The lead up to that broader decision point however can be smaller iterations and decisions made through one pizza teams.
How are you making team-based decisions today in your organization? Have you found friction in your current approach that could be solved by smaller teams?
Mark Birch, Editor & Founder of DEVBIZOPS
It has been busy the past few weeks. I jsut got back from meetings in San Francisco and then will be jumping on a plane to head to Portugal. I am giving a talk at BIN @ Porto and then the following week to speak at Web Summit. While I am thrilled to be out on the road, I definitely do not have my travel legs under me yet 😂
One of the topics of discussion this week was building community and what that means for AWS. Part of that conversation involved the AWS Startups Show I have been hosting on Clubhouse which continues to go strong. In fact, we are close to our 150th show since launching in March!
Over the next several years we are diving deep into AI/ML. We are featuring startup founders innovating in the AI/ML space and building on AWS. We had awesome of conversations with Nathan Kundtz, CEO of Rendered.AI, and Sean Byrnes, CEO at Outlier AI the week before. Tonight we talk about AI and Retail at 6 PM ET / 3 PM PT with the co-founders of Lily AI, Purva Gupta (CEO) and Sowmiya Chocka Narayanan (CTO). Come join the AWS Startups club on Clubhouse and hope you can make it for our future shows!
Want to learn more about DEVBIZOPS and read more hot takes about IT, technology, and working smarter. Receive our weekly newsletter by signing up to our Substack!