We've just launched plato for individuals

🔥

login


Google Sign inLinkedIn Sign in

Don't have an account? 

Dividing a Product Engineering Sprint Team

Product Team
Productivity
Reorganization

10 May, 2019

Meghan Cochran demonstrates how restructuring her team improved engagement, productivity, and planning.

Problem

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.

Actions taken

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.

Lessons learned

  • 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.

Related stories

Driving Clarity of Charter in a Large Organization
27 September

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.

Ownership
Reorganization
Team reaction
New Manager of Manager
Managing Up
Jeffrey Wescott

Jeffrey Wescott

Director of Engineering at Splunk

Getting From What to Why
27 September

Pete Murray, Principal Software Engineer at Electronic Arts, explains how he successfully solved a long-troubling problem by applying a root cause analysis.

Dev Processes
Productivity
Impact
Pete Murray

Pete Murray

Principal Software Engineer at Electronic Arts

Changing of a Guard
24 September

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.

Managing Up
Managing Expectations
Legitimacy
Leadership
Reorganization
Adam Bauman

Adam Bauman

Engineering Manager at Quizlet

Setting Guardrails and Containing an Increase in Cloud Costs
21 September

Michael Mac-Vicar, CTO at Wildlife Studios, dissects how to set guardrails that would contain the exponential increase in cloud costs.

Dev Processes
Productivity
Michael Mac-Vicar

Michael Mac-Vicar

CTO at Wildlife Studios

Outcomes Before Outputs: Measuring Engineering Performance
14 September

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.

Impact
Productivity
Marian Kamenistak

Marian Kamenistak

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.