Restructuring a Team Methodically

Problem

At my current company, I was an early employee; I had joined just as we were entering series A, the first person on the engineering team. We were growing rapidly and hiring quickly and had gone through several iterations or organizational changes. Seeing each different stage has been a challenge, but it has given me insight into what has been important during different times in the company.

During that time, I had established some amount of product-market fit. We had raised a series B round. Now, the company was focused on building the product and beginning to gain a wider reach. As part of that, we had to attack two very important projects headfirst. One was continuing to define and to improve the product. The second was growing the organization.

We started hiring at a really impressive speed, but pretty early into the process, we realized that while we were hiring great engineers, we were not really moving the needle as quickly as we wanted to be. We started thinking more about how we were structuring the organization as we brought more people in. How could we empower them and set them up for success?

Actions taken

As a broader leadership group, we sat down to identify some of the principles around which we wanted to set up the organization. This included simple things, like optimizing for speed, but also other wishes, such as the desire to not be duplicating work. Purity in engineering and design will help keep everything in place to some extent, but may also create bottlenecks in different parts of the system. We were intentional and cautious when making these trade-offs.

The other metric was autonomy vs. control and direction. When we were smaller, it was much easier to make key decisions and to communicate these decisions effectively to everybody on our team. As our product started growing, however, the way that we were doing this previously was not scalable. We couldn’t oversee every single part.

The challenge became finding a way to give autonomy and empowerment to every part of our new team without worrying whether or not they would end up going in the right direction. We wanted to provide some context to the framework, some guardrails indicating what the specifics looked like. This would allow them to exercise autonomy within those guardrails constraining the problem.

Stability vs. agility was another topic of contention. Conventionally, when people join a team, there is a strong sense of belonging. There is chemistry and people form relationships and identities within the group. In reality, for us, as a start-up during that time, we could not afford to have these long-lasting, permanent teams. We wanted our teams to be agile in terms of what happened to be most important for the business. This often meant setting up and tearing down teams. This created some confusion for people, however. They felt that they did not have any clarity when it came to what was coming up next for them. They didn’t feel stable, because things were constantly changing around them.

This was another difficult one. Their need for stability was valid, the nature of a start-up is dynamic and requires each player to be able to keep up with the pace and to adapt to different business challenges. We decided to level with the team, explaining to them how and why we were setting up and tearing down different teams as we worked. We put things in terms of temporary initiatives, and, when these initiatives met certain criterias for success or we found that our focus would be better-directed elsewhere, we would “graduate” the team. We gave these “graduates” a chance to share what they’d learned with us, explaining what they felt did and did not work well in terms of the decisions being made. Then, we were able to apply those lessons to the next initiative.

After finding agreement on these principles, we aligned our teams according to customer experiences. Onboarding is one example of these areas. When people are first introduced to our product, how could we delight them? How could we get more people to convert into the product and to find the value that we were seeking to create? Retention was another area. We started to break that down a little bit further. In each of these critical moments in the customer journey, we centered the efforts of one of our teams.

Every part of our team had to be able to access many different parts of the engineering system. It was difficult to have somebody come in and write code, and, just like that, have expertise over all of our different systems. Each one was enormously complex in and of itself. The teams struggled to maintain speed without the context and knowledge behind how the system was designed. This led to our effort to compose our teams as effectively as possible.

From there, we started forming a core group of people; we started with a handful of vertical teams focused on these customer needs without being tethered to any one individual engineering domain. They would go across the stack, looking at every part of the system to see how the experience comes together. A horizontal division of teams were tasked with providing that expertise and context informing these complex, underlying systems. The vertical teams no longer needed to worry about knowing the internal details of these systems. This allowed them to work more quickly.

Through this approach, we were able to clearly carve out what was important for each team. Simplicity, reliability, and the robustness of the system were allowed to come to the forefront of our process.

Lessons learned

• One key lesson: initially, we failed to articulate our core principles clearly to each team. Even though we had some conviction in terms of what we felt that these principles should be, we did not do a great job of bringing everybody up to speed and achieving that alignment over these principles with everybody involved. We needed to give them more insight into why we felt that they were important for the business. Clarity over the parameters that should be optimized needs to come first. We visualized what we felt may not be ideal down the line and tried to come up with ways that we would be able to manage these challenges when they did come up.
• The feelings of fear and instability that came as a result of the initial dysfunction proved to be detrimental to our efforts. The team members felt that some of our decisions were being made arbitrarily, without their needs in mind. Thinking intentionally about these decisions and being honest with the team as we walked them through our thought processes reassured them that these structures would be revisited periodically.
• Before we implemented this solution, each of our teams was focused only on their small area. They ended up losing the forest for the trees. Every person would solve their own individual problem without connecting the dots that would show how their work made a difference to the customer.