Dividing a Product Engineering Sprint Team
10 May, 2019
In my organization we work on two general types of projects. They can be thought of as revenue-enhancing projects and cost-reduction projects, or customer-facing experiences and internal-facing experiences. What I found was that it was hard for us to track the amount of resources we were spending on one versus the other. We were all working as one big scrum team, and it was hard to gauge when we were overinvesting in one are at the expense of another. We wanted to make sure that we could manage the amount of investments we were making on the two sides of the business. In addition, a large team working on a variety of projects led to unnecessary overhead related to prioritization, sprint planning, and project management.
Working closely with the head of engineering, we decided to split the group into two separate, dedicated sprint teams. In order to do this, we needed to determine who would be on what team and what the teams would work on. On the Product side I decided that we needed each team to have a fully dedicated Product Manager on each team so that they could manage the overall customer experience and prioritization. On the design side, we considered having dedicated designers, but given the variation in projects, I decided that it would create too much of a bottleneck when a particularly large design project prevented other work on that team. Designers would be assigned to projects rather than teams. On the engineering side, there were two more experienced engineers who took the lead on making a recommendation on assigning engineers to each team, taking into account skills & preferences, but with the goal of creating balanced full-stack teams. After discussions with the engineers, they recommended a team structure that we approved. To address concerns of future growth for individual engineers, and shared expertise for the entire code base, we agreed that engineers would have the opportunity to move between teams over time.
Now we had our teams, and we needed to distribute the work. Each team was dedicated to specific areas, but I knew that we'd need to have some flexibility for the movement of initiatives and projects between teams. While in general we had one team working on consumer-facing experiences and the other on internal-facing, there were many projects that touched both sides. For these, I decided that they should be assigned to the lesser booked team. This provided additional flexibility to balance overburdened teams and provided opportunity for engineers to work on other areas of the code base.
- The overhead of managing one large team wasn't obvious until it was eliminated. The entire team was spending time to understand all the work, even though less than half of it was relevant to them. Now, teams focused only on their projects. They spent the same amount of time, but used it better. They went deeper into strategy and planning, were more engaged, and improved their productivity.
- The split made it immediately clear where we were under-allocated: we were two weeks behind in one group while a little bit ahead in the other. So once the teams were broke in two, we could shift some projects and rebalance.
- We did have had to make some difficult trade-offs. With increased visibility on our resources, smaller projects were harder to "slip in" because it was immediately obvious that they were taking the team away from other higher priority items.
- Prior to this change, it was hard to predict how long a project would take, or what the opportunity cost would be. Now, it's clear what other projects will be delayed and it's easier to plan.
Jeffrey Wescott, Director of Engineering at Splunk, describes how he introduced clarity on ownership between four disparate teams by drafting a charter that precisely demarcated who owned what.
Director of Engineering at Splunk
Pete Murray, Principal Software Engineer at Electronic Arts, explains how he successfully solved a long-troubling problem by applying a root cause analysis.
Principal Software Engineer at Electronic Arts
Adam Bauman, Engineering Manager at Quizlet, shares how he had to find his way through when the company he was working at transitioned from one stage to another leaving many people redundant.
Engineering Manager at Quizlet
Michael Mac-Vicar, CTO at Wildlife Studios, dissects how to set guardrails that would contain the exponential increase in cloud costs.
CTO at Wildlife Studios
Marian Kamenistak, VP of Engineering at Mews, explains why EMs shouldn’t be measuring the output of a team or individual engineers, but the outcome of the whole team.
VP of Engineering at Mews
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.