Structuring a Large Team: A Two-Phase Approach

Problem

"When I joined my previous company as a VP of Engineering, I inherited a team of 18 engineers. The team initially had only three engineers, but it quickly grew to have five, ten, and finally 18 people on the team. The problem was that the processes remained the same, making the team inefficient and difficult to work with."

"The problem was that the processes remained the same, making the team inefficient and difficult to work with."

Every morning 18 people would attend a standup which was rather unpractical for such a large crowd. Also, it was not clear who was doing what. But, large as it was, everything was handled over by that one team. Everyone could come in and out, had a little hand in it, depending on their availability. Needless to say, it was a recipe for disaster, to put it mildly.

Actions taken

Deciding on the right structure

"My two-phase approach consisted of:

• Deciding on the right structure and how to organize the transition. I would consider alternatives to ensure that we picked the right solution that corresponded with the maturity of our product.
• Conducting a domain analysis to establish what each team owns and then separating the services. Also, I would set the goals for each team and give them a sense of autonomy and alignment to the bigger, company-wide goals."

"Deciding on the right structure"

Structuring the team and the work accordingly was the most critical part of this undertaking. It took a month and a half to put into practice what I thought was the right structure. I had an opinion of how that should be done -- how to structure skill sets and mix people together -- because I had a clear vision of a fully complemented team. We had enough resources to form five smaller squads that were self-sustainable in terms of their skill sets and competencies.

We considered different alternatives, though. Status quo was one of the options, but we could tell from the start that it was not going to work. There was another alternative we didn’t pursue too. Having competency-based teams that would be created by splitting the existing team into a front-end and back-end team or multiple front-end and back-end teams was not an option as well. The roadmap was not flashed out well enough to allow for that distinction. In my opinion, a roadmap needs to be laid out at least six to twelve months to be able to split between the front-end and back-end team. It would take too much coordination if API needed UI and if that had to be done quickly. But also, without a mature product, the success metrics of each team would be dependent on one another. In the early stages of a product, they are too tightly coupled both from the point of what they need to do and how that could be measured.

Domain areas

"The next step was to break down technical work into domain areas. While conducting a domain analysis provided me sufficient understanding of where the logical boundaries of the product were, delineating who owns what was not an easy task. I inherited an amorphous backlog with ambiguity about who owned what and what their responsibilities were."

To set the metrics for each team and create their own roadmaps, we ran a domain-driven design (DDD) exercise. The DDD process helped us break the product down into its bounded context, i.e., components parts. We found out that four large pieces of the product corresponded with four main user experiences or domains. Then, we mapped out services to have them fit into those domains.

This problem was tightly connected with the size of the team. Since there were four main features, we could have one big team that would own all four workstreams. However, when there are more than two streams, a standup becomes less efficient. The fewer things a team would be working on, the more they would be able to focus on what mattered the most. When there are too many workstreams, a team becomes work-shy on prioritization. There are too many options and too many decisions and a lot of wiggle room. Having one team work on one workstream forced them to make hard decisions and empowered them to be more autonomous.

The value of having one large team was also that they could be assigned work every week and could pivot quickly. With small committed teams, ad hoc projects are out of the question. However, one large team with the potential to do everything is like spinning the wheels, and frequent context-switching makes the engine less efficient.

Lessons learned

• If most people are bored in a standup, it means that standups are inefficient. If you ask people on the team what their goals are and they don’t have a clear answer or have too many goals, the team is too big.
• If success metrics of different teams are mutually dependent, either those teams -- or at least one of them -- are too small or the metrics are broad and ill-defined.
• Every team should have its own Why, which converges ownership. The best approach is to have Whys that address user problems. Technically dividing up the services is critical for ownership. If you have a renter rather than an owner mentality, people will commit but won’t feel responsible for it. But, when a team owns something, they do more than required.
• From a leadership perspective, having five teams makes visibility harder to achieve. For example, the company founders attended one of the meetings, and they had a hard time understanding what each team was doing. You need to let go of having to know everything every day and instead create check-ins, so there is a way to keep people up to date.
• Consistency across the teams should be nurtured. While I would encourage a significant degree of autonomy within the team, how teams report on progress should be standardized. You can either create consistency in tools or add an additional layer of program management. In that particular company, we used the same tool and the same planning process, but in some other places I worked at, we used different tools but would report to the same structure.