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


Back to resources

How to Restructure Organization and Break Down Silos


24 August, 2020

Brian Hough
Brian Hough

CTO at Beam Dental

Brian Hough, CTO at Beam Dental, shares how his company transitioned from a shared services model and work in silos to a group lead model that is vertically integrated.


We were initially structured like most traditional small startups -- we created an engineering team, a design team and everyone was able to freely collaborate with each other. We were able to move resources from one project to another and that made things easier especially since we were unsure what was the next thing we will be working on and where we will be spending our time. We could spend a lot of time in one part of our app and throw the entire company at it or we could split it between multiple parts. Shuffling teams around really worked well for a long time.

As the company began to scale, we started to run into many communication issues with the shared services model. For example, if a project had designers and developers, managers and product owners, it would be often challenging to understand what was going on with the project because each one of those people would have their own manager. It was also unclear who to go to when there was a challenge with the product or a particular project. The new model allowed us to pick three leaders across the organization who would have an entire full-stack team underneath them and have dedicated design, development and product management resources.

Actions taken

As we scaled we started to need subject matter experts in particular areas of our product. In the early days, we were optimizing for giving people the ability to work throughout the tech stack and throughout the product because everyone at the company was new and 85 percent of our product organization had been with the company for less than six months. Therefore, it was important that they would be able to understand everything that was going on.

However, as we scaled that became a problem because we needed people who knew one part of the system exceptionally well and we didn’t have many of those people. We ended up shifting to a group lead model where we created four individual group leads that owned a portion of the business and had all the resources they needed to be dedicated specifically to that. We scaled currently to four groups.

The concept of the group lead is essentially like a general manager of a portion of the business. A group lead is a person who leads an entire full-stack organization that is tied to a specific part of the project. In our case, we might have somebody who's over our mobile application and iOS, somebody who's over our dental insurance, or over ancillary lines insurance. They would have their share of profit and loss and their responsibilities would go beyond just managing people and ensuring that projects get done.

The group lead job completely changed their role and responsibilities. We took people who were previously on top of a particular function -- design, product or engineering -- and as group leads, we have had to augment them with people below who had stronger skills in the areas where they were weak. For example, our director of design as a group lead was supported by one of our most experienced engineering leaders because he knew design really well and product decently well, but didn't have any engineering experience. We also supported our VP of Engineering as a group lead with strong designers and product managers because they may not be as strong in those particular areas.

Lessons learned

  • The biggest areas that struggled under the shared services model were our designers because they often felt they were having to do a grab beg of work and it was challenging for them to own experience long-term. They would come in and they'd be asked to work on a project, do exactly what was asked of them and then move on. Now they're tied to the same PM and the same projects longer term and they can own, measure and develop UX over time. They can measure what is happening with users and have the ability through that same development team to go back and refine those experiences.
  • Our group lead would have their own engineering team, their own set of designers, and their own product managers who would work as a subset of the organization. They are subject matter experts in a particular area, everybody knows who's responsible for the project and we're no longer having to go to five or six people to figure out what is going on with the project
  • We can still deliver that distributed experience for developers and designers through PMs because we have multiple PMs on a team and those PMs can be subject matter experts and developers can be subject matter experts below. They may not know the entire stack but they still get some variability and deal with two, three, or four different portions depending on how many PMs are on a team.
  • However, there were some downsides. Career paths proved to be tricky for us. We've had to spend a lot of time on the structure because, in the previous structure, it was very clear what you do as an engineer -- you got to be a senior engineer, then you can manage engineers, and afterward manage managers of engineers. It's a very linear career path. When you have everything nestled within a group, there's less of that verticality to the hierarchy and it's not always clear how a person becomes a group lead or gets to manage PMs. We've had to do extra work to be able to give people that breadth of knowledge and experience so that they don't feel limited at the top of their particular functional area.

Discover Plato

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

Related stories

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.

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
Internal Communication
Toxic Atmospheres
James (Andy) Vaughn

James (Andy) Vaughn

Principal Technical Product Manager at AppFolio

Delivering Outcomes on a new platform in the first 180 days

11 October

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.

Cross-Functional Collaboration
Andrew Tsui

Andrew Tsui

Director of Product at Startup

Structuring Cross-Functional Teams

13 July

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.

Dev Processes
Internal Communication
Mu Qiao

Mu Qiao

Sr Engineering Manager at Teladoc Health

Setting Up a Product Team for Success

2 July

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.

Product Team
Jennifer Agerton

Jennifer Agerton

Chief Product Officer at AirHelp

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

Plato ( 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.