How to Restructure Organization and Break Down Silos

Problem

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.