DILBERT © Scott Adams. Used By permission of ANDREWS MCMEEL SYNDICATION. All rights reserved.
Early in my career, I learned that effective teams are small teams. Communication is hard, and the time spent discussing context alone exponentially increases the more people that are included.
I recently learned that effective teams are also teams without external dependencies. Autonomous delivery helps to deliver features in an agile way. So what do you do when you have a big, critical project? Do you work in a few small teams so collaboration and communication is strong? Or do you build a big team with little or no dependencies? In order to do this, how can you build or scale the team?
One of the fundamental principles of successful communication at Amazon (where I worked from 2005-2014), is the concept of the two-pizza team. Any team should be small enough to be fed by two pizzas (roughly five to seven people). It’s based on Brooks’s law (see the diagram below), which states that the lines of communication increase exponentially, not linearly, as you add more people.
I joined Contentful just over two years ago and started learning more about product development. We use a delivery team model. This is based on the “Spotify model,” where delivery teams focus on developing features by forming cross-functional teams. Each delivery team can contain front-end and backend engineers (or experts in a particular language, such as Ruby), a designer, a QA and a product owner. The engineers in these teams also belong to chapters that focus on overall technical strategy.
In 2017, we investigated ways to improve Contentful as a product by adding a new concept called environments. These would establish another dimension to Contentful by enabling teams to set up a master environment (production) and multiple test environments (pre-production, CI/CD). This was a huge undertaking as it was changing how Contentful worked at a core level.
The initial MVP was built by a team that I supported: development velocity. This team comprised backend (node.js) and infrastructure engineers along with a product manager. Five people, so it fit into the two-pizza team model (Yay! Everything makes sense). Still, we found that we needed support from engineers working on our authentication service because we lacked knowledge about that service. .
So we did what you do in delivery teams: bring your dependency into the team rather than asking another team to deliver something for you and hope that the stars align for delivery. We were up to seven people in the team. It was fine, since we still fit into the model.
The MVP took a number of sprints to build and showed that we were onto something. We decided that environments was a strategic project for the company when we looked at the results. We needed to plan what a full-featured version of it would look like. It became clear — we needed more engineers. The two-pizza team model was not going to work.
Figuring out what changes were needed, and in which system, was one of our largest challenges as we grew our team.
We initially added a designer to assess how user flow would work, since we had only worked on the backend implementation. Then, we added two front-end engineers for the work on our web app, and a QA engineer to help the team. We added a second Ruby engineer later in the project, when we remembered that people are human and they get sick or take vacations. The second Ruby engineer minimized the bottlenecks we experienced on such a long project.
We ended up with twelve people on the team towards the end of the project.
Half way through the process, Contentful hired an agile coach. He became a great support.
Contentful was no different to other companies. Before he joined, it was normal for people (often managers) to declare themselves the resident agile expert after completing a single training, reading a book, or attending a conference. But, really, they weren’t. They were like me: opinionated with some experience. When we hit a deadlock on deciding what path to take and how to change direction, it was difficult to get a clear answer. We often ended up with a solution that had too many compromises. These compromises can kill teams and companies. At the very least, they can make them unpleasant places to work. Teams go from experimenting to focusing on things that are the least upsetting for the majority.
Our agile coach helped us set up a few workshops for the teams to navigate these challenges, as well as providing coaching to me — two of these workshops were really useful.
The first workshop was a values workshop. I suspected that the values and workflows of the original team were different from those of the people who had just joined the group. This became especially clear in the first expanded-team retrospective.
The goal of the workshop was to review what we felt were the most important values for this new team. The two values we settled on were: “Open, Honest, Respectful” and “Don’t assume, show it.”
The second workshop was a skills matrix, where everyone on the team listed their strengths and what they were willing to work on. This resulted in a grid with names of engineers in a column and each row labeled with a skill (node, Ruby, facilitation etc.).
This grid had two key benefits. First, it gave a clear overview of what skills we had in the team. When we needed support on something, there was a reference for who was strong in that area (or who wanted to learn more). Second, it allowed the team to recognise and appreciate their peers for their diverse skill sets.
When we decided that the project was critical for Contentful, one of my roles was to work with other engineering managers to see who we could get to join our team and when. It provided an opportunity for some engineers to work on something new and collaborate with others. Not everyone joined at once — it staggered over a period of weeks — but there weren’t too many big challenges in terms of moving people into the project. There were no ownership battles, and everyone got on board smoothly.
The team lead did a really strong job of guiding the technical direction for the project and ensuring there was purpose within the wider group.
As other senior engineers joined, they focused on what they could contribute without trying to take control. It was great to see this collaboration across senior engineers and there were no large egos in the team.
Our QA engineer brought a great initiative to the team: for every task there was a person leading the task and a “testing buddy” who would pair with them to give feedback, test it out or just pair on the implementation. The first engineer was responsible for getting the thing done, and the second was there to ensure quality and remove blockers. This worked really well.
It was a struggle at times to keep everyone on track with eleven or twelve people in some meetings. Some early retrospectives were tough, because we had to go back to the team forming and storming phases every time people joined the team. This is where lots of conflicts and challenges happened. It was ultimately healthy, but also a difficult process.
As the team changed and grew, space was a challenge. At the time, all of the engineering teams were on the same floor of our building, and each team had a designated “team room.” We found they supported a good balance of communication while limiting distraction. The issue was that the team rooms were “two-pizza,” size so we ended up moving to a different part of the building for a few months. At one stage, both the product manager and I sat in an adjacent room, as we had run out of space. There was a suggestion at the start that different pods in the team should sit elsewhere, but in the end it was best to keep everyone together.
I was the designated engineering manager for the team of twelve, although only five of those people reported to me. This is not a big issue typically when it’s a short term project, but for longer projects it can be tough. One of the roles of an engineering manager is to give feedback on how the person is performing and if your manager is not spending much time with you, then there can be an absence of valuable feedback. I found having bi-weekly one-on-one meetings with the people joining the group to be helpful here.
There was a lot of context for everyone to be aware of, and we had to ensure that this didn’t become overwhelming. Having people work in pairs helped, but it was a challenge to work on a project and try to isolate yourself from what everyone else is doing. A few times we sketched out “dependency maps” in order to figure out which streams of work depended on others.This worked really well as it helped people understand where they might get stuck, or whether we were overloading a single person and needed more support.
Rules and guidelines are there to help, but as a leader you should look at what is right for a particular team and for a particular project. (I guess this was is that “agility thing” that I have been reading about all this time.)
This was the right team structure for this project, but it wouldn’t have been sustainable for much longer.
I believe it was the right decision to expand the team and have everyone in one room. It was also important that, as new people joined the group, they had a voice and were full members of the team.
Facilitation was a large part of my role, but we would have experienced fewer bottlenecks if I would have helped other members develop in this area.
Celebration is important, and we should have celebrated before our team dispersed into other teams.
Ultimately, the redesign of our team structure enabled us to successfully deliver the environments feature. Through the process, I saw that building successful products requires the right systems and services; but success also depends on organizing great people into strategically-designed teams. Celebrate team accomplishments and have fun along the way—the right constellation of people can achieve great things.