Loading...

Restructuring to Feature-Based Teams

Stefan Gruber

SVP Engineering & Operations at Bitmovin

Loading...

Problem

I was leading an org where we had a single, separate team delivering components to the rest of the product development teams. All other teams were dependent on this individual team because they were the only ones working on the base layer of the software. As a result of this imbalanced structure, we were consistently having communication issues, priority issues, and delivering issues.

Actions taken

What I realized was that all of these issues were caused by dependency. All of the weight fell onto one team and responsibilities were not evenly dispersed. Therefore, I decided to dissolve the team, dispatch individuals and diffuse their responsibilities to the remaining teams. Instead of having one single team maintaining and developing the base layer, now all product teams were responsible, thus removing the dependency and all issues associated with it.

We ended up having four product teams - four groups, each with 1-3 feature teams, at a size of 5-7 people each.

Everyone was onboard with the change. I effectively communicated the advantages. First, that teams would expand their horizons by being able to look at other parts of the software, giving them a broader perspective. Second, that they would also be a part of the product delivery group thereby not just helping others achieve goals but actually being a part of the whole product. The benefits were clearly understood resulting in no pushback from the teams.

Lessons learned

  • This structural change allowed us to deliver software faster. All the feature teams had a shared backlog where they could, tech-wise, deliver their own features. Before, we always had two separate backlogs - a product backlog and the base-layer team backlog - and teams had to coordinate with each other to deliver. Due to the reorg, though, everybody was able to refer to the same backlog, had the same priorities, and therefore set up to act and deliver much quicker than before.
  • If you see that there is a problem with the team structure, you have to weigh your options and then dare to make the necessary changes. There are always risks that come with change, but so too when no action is taken.

Be notified about next articles from Stefan Gruber

Stefan Gruber

SVP Engineering & Operations at Bitmovin


Leadership DevelopmentCommunicationOrganizational StrategyDecision MakingCulture DevelopmentEngineering ManagementPerformance MetricsFeedback TechniquesTechnical ExpertiseTeam & Project Management

Connect and Learn with the Best Eng Leaders

We will send you a weekly newsletter with new mentors, circles, peer groups, content, webinars,bounties and free events.


Product

HomeCircles1-on-1 MentorshipBountiesBecome a mentor

© 2024 Plato. All rights reserved

LoginSign up