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

🔥

Back to resources

Restructuring a Team Methodically

Dev Processes
Reorganization

21 June, 2021

Vinodh Sundararajan
Vinodh Sundararajan

Sr. Engineering Director at Earnin

Vinodh Sundararajan, Senior Engineering Director at Earnin, shares his experience restructuring a cross-functional team from the ground up, providing context and streamlining the work at hand simultaneously.

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.

Discover Plato

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


Related stories

The Right Way to Ship Features in a Startup

11 November

Matt Anger, Senior Staff Engineer at DoorDash, shares how he took the risk and shipped features in a startup.

Alignment
Product
Dev Processes
Matt Anger

Matt Anger

Senior Staff Engineer at DoorDash

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.

Alignment
Convincing
Reorganization
Roadmap
Fairness
Kirk Gray

Kirk Gray

VP Engineering at McGraw Hill

The Problem-Solving Process: A Modern, Data-Driven Approach for Engineering leaders

28 October

Sudheer Bandaru, CEO at Insightly Analytics, recalls how he formed a company for carrying out data-driven solutions to daily engineering problems.

Dev Processes
Team Processes
Sudheer Bandaru

Sudheer Bandaru

CEO at Insightly Analytics

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

James (Andy) Vaughn

Principal Technical Product Manager at AppFolio

Taking The Lead As A Manager In Crisis

14 October

James Tobias, Senior Product Manager at Mapware, unveils a riveting journey to build a product from ground zero successfully.

Product Team
Product
Dev Processes
James Tobias

James Tobias

Senior Product Manager at Mapware

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.