Restructuring a Team: How to Enhance 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.