Plato Elevate Winter Summit has been announced (Dec 7th-8th)

🔥

Back to resources

Structuring a Large Team: A Two-Phase Approach

Reorganization
Ownership

26 May, 2021

Mike Cruz
Mike Cruz

VP Engineering at CMG

Mike Cruz, VP of Engineering at CMG, speaks of his efforts to structure a large team that by the sheer number of people on the team became inefficient and difficult to work with.

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.

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

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.

Discover Plato

Scale your coaching effort for your engineering and product teams
Develop yourself to become a stronger engineering / product leader


Related stories

Transitioning From Tech to Product Management

23 November

Nicholas Cheever, Divisional Vice President, Global Supply Chain Technology at Trimble Transportation, talks from his experience on how to excel in a PM role when transitioning from tech roles.

Ownership
New PM
Nicholas Cheever

Nicholas Cheever

Divisional Vice President, Global Supply Chain Technology at Trimble Transportation

The Benefits of Stakeholder Communication

17 November

Piyush Dubey, Senior Software Engineer at Microsoft, shares how to understand the stakeholder communication process better and why it is essential.

Meetings
Internal Communication
Collaboration
Ownership
Stakeholders
Piyush Dubey

Piyush Dubey

Senior Software Engineer at Microsoft

Overcome a Poor Working Relationship

11 November

Rajesh Agarwal, VP & Head of Engineering at Syncro, shares how he took the time to develop and understand one of his co-workers to drive impeccable business results.

Conflict Solving
Internal Communication
Collaboration
Ownership
Health / Stress / Burn-Out
Rajesh Agarwal

Rajesh Agarwal

VP and Head of Engineering at Syncro

How to Successfully Complete A Major Reorganization

4 November

Kirk Gray, VP of Engineering at McGraw-Hill, recalls his experiences performing major reorganizations of departments, including successful techniques to ensure a smooth transition.

Alignment
Convincing
Reorganization
Roadmap
Fairness
Kirk Gray

Kirk Gray

VP Engineering at McGraw Hill

An Engineer’s Place in Product Creation

25 October

James Andrew (Andy) Vaughn, Principal Technical Product Manager at AppFolio, speaks on the mutually beneficial partnership between product managers and engineering leadership and its relation to a harmonious product development organization.

Different Skillsets
Meetings
Internal Communication
Reorganization
Roadmap
Toxic Atmospheres
James (Andy) Vaughn

James (Andy) Vaughn

Principal Technical Product Manager at AppFolio

You're a great engineer.
Become a great engineering leader.

Plato (platohq.com) is the world's biggest mentorship platform for engineering managers & product managers. We've curated a community of mentors who are the tech industry's best engineering & product leaders from companies like Facebook, Lyft, Slack, Airbnb, Gusto, and more.