Back to resources

Restructuring a Team: How to Enhance Accountability and Ownership

Reorganization
Ownership

29 January, 2021

Naveen Veeravalli

Naveen Veeravalli

Engineering Manager at Uber

Naveen Veeravalli, Engineering Manager at Uber, shares how he successfully planned and executed a team restructure that enhanced his team’s accountability and ownership.

Problem

When I joined my current company, I joined a team that consisted of two large blobs totaling 40 people with no clear boundaries and ownership. Team structure was entirely project-based, and people would be shuffled around different projects. As such, the team was not set up to execute and scale well. Because of its size and project-based nature, the execution was chaotic, and its short-term focus made scaling difficult.

The lack of clear boundaries and unified planning process also resulted in no clear ownership and poor accountability. The most important issues would be always completed first, leaving tech debt and on-call problems unaddressed. Consequently, the team was not engaged, and the complaints I would hear in one-on-ones and through pulse surveys were troubling for me as a manager.

Actions taken

My high-level goal was to come up with the right structure and have competent leads that would enable the team to execute and scale. As I was relatively new to the team and was unaware of all the details, I partnered with another EM and senior engineers to come up with the best solution for a restructure. We had several brainstorming sessions discussing different options, only to settle for the one we felt was the right one. We decided to break the team down to service-level ownership and have subteams own services end-to-end. Also, each team would work with their set of partner teams as opposed to everyone working with everyone else.

We pitched our proposal to leadership, got valuable feedback, and reiterated on that feedback. As a result, we divided our two large groupings into six smaller subteams, each consisting of 6 to 8 people. Through restructuring, we bootstrapped new areas that were non-existent before. Also, some things were dropped on the table that no team wanted to take, and we had to build a new team responsible for that area, small in size but with the potential to scale. We also noticed that some areas were underinvested, and in our previous chaotic structure, this problem went unnoticed. Now, we could clearly see that, for example, an important area was covered by only two people and we could allocate more people to it.

Each team had vertical ownership; that is, each team had full ownership of one end-to-end service and an agency to solve a particular problem. Before, two or more teams would have to come together to solve almost any problem. Each subteam was assigned a tech lead responsible for driving a charter and making them more accountable for a long-term vision of their particular area.

In addition, our on-call rotation improved. Instead of having 30 to 40 interchangeably on rotation, now we have six on-calls, and each team is responsible for its own. Being accountable for their own on-call quality, each team works hard to improve it, and as a consequence, the overall reliability of the system is more streamlined.

Lessons learned

  • Large teams should be particularly well structured to enable strong execution and scale in the long-term.
  • Keep your team engaged. The team needs to have a clear growth path, clear ownership, and a clear long-term vision. There is a strong correlation between clarity and team happiness.
  • Leadership had more visibility into areas that needed more investment or lacked sufficient funding. Smaller improvements on the team level also brought clarity and affected the state of improvements company-wide.
  • What didn’t work: we formed a research team too early that heavily relied on the underlying platform that was not mature enough at that time. The research team had to work with a number of teams and didn’t have the agency to build their own things. Three or four months later we realized that it was not the most suitable team breakdown; we merged them with another team and reprioritized their goals.

Discover Plato

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


Related stories

DevSecOps: Why, Benefits and Culture Shift

29 November

Why DevSecOps matter and what's really in it for you, the team and the organisation?

Innovation / Experiment
Building A Team
Leadership
Ownership
Stakeholders
Cross-Functional Collaboration
Vikash Chhaganlal

Vikash Chhaganlal

Head of Engineering at Xero

The Growth Mindset in Modern Product Engineering

28 November

The impact you can have with a Growth Mindset' and the factors involved in driving orchestrated change.

Building A Team
Leadership
Collaboration
Feedback
Ownership
Stakeholders
Vikash Chhaganlal

Vikash Chhaganlal

Head of Engineering at Xero

Strategies for Hiring

12 October

Recruiting right people is the single most important decision for the company. Building a great platform, product and company is hard. Getting the right people into the company is twice hard.

Building A Team
Company Culture
Ownership
Hiring
Praveen Cheruvu

Praveen Cheruvu

Senior Software Engineering Manager at Anaplan

(Re)Organizing Your Teams Using Domain-Driven Design

12 July

A proposal for how to create an org structure that will deliver software systems that you want, not ones you get stuck with.

Alignment
Architecture
Scaling Team
Building A Team
Internal Communication
Reorganization
Ram Singh

Ram Singh

Principal / Founder at id8 inc

Leading A (Distributed) Team? Foster "Above the Line" Behaviors.

12 July

No online tool will address your team's ability to connect, collaborate, and deliver results if the individuals don't bring the right mindset to work.

Changing A Company
Building A Team
Company Culture
Leadership
Ownership
Ram Singh

Ram Singh

Principal / Founder at id8 inc