Restructuring to Feature-Based Teams
11 June, 2020
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.
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.
- 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.
Scale your coaching effort for your engineering and product teams
Develop yourself to become a stronger engineering / product leader
Kirk Gray, VP of Engineering at McGraw-Hill, recalls his experiences performing major reorganizations of departments, including successful techniques to ensure a smooth transition.
VP Engineering at McGraw Hill
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.
James (Andy) Vaughn
Principal Technical Product Manager at AppFolio
Andrew Tsui, Product Leader at Sailthru, recalls his opportunity to navigate a tricky user-and-business problem by leveraging a new platform to simultaneously optimize SEO content and sustain advertising inventory for a media business.
Director of Product at Startup
Mu Qiao, Senior Engineering Manager at Teladoc Health, was able to provide other departments with context from his engineers by dividing their efforts and conquering with a cross-functional model of collaboration.
Sr Engineering Manager at Teladoc Health
Jennifer Agerton, VP of Product at letgo, reflects on her efforts to scale up a product team and set it up for success through a threefold action of introducing a new structure, new roles, and new ways of working.
Chief Product Officer at AirHelp
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.