Reorganizing Your Teams According to Function

Problem

"In my career I went from an individual contributor to a manager role. But rather than simply going into a management position, I became the manager of managers, something of a unique case. I had inherited a team in Canberra, Australia as well as the San Francisco teams. One of my first roles as a new manager was scaling the teams."

Actions taken

"All of the ICS went up through the director of engineering while all of the architecture people went through me. The director of engineering had started putting in place the concept of engineering managers who were essentially managing various individuals across multiple functional areas. Immediately, this was one of the issues that I wanted to fix. Another issue was the disparity between QA and engineering. To begin with, I applied functional areas to each of the individual teams. This allowed the teams to have clear ownership over their series of the product. Next, I made sure that the engineering managers were managing people that they were working closely with so that they were able to give effective feedback. When I came into the role, I was getting lost about who reported to which manager. Afterwards, it was a lot clearer because the manager was able to keep up with each individual performance. The QA team also partook in the reorganization. Prior to, as we were moving towards an automated fashion of testing, code would be written only to be thrown over the fence to QA and then back again to engineering. I really wanted to break down that barrier in order to keep growing the team. So I also moved QA into functional areas, embedding them within the team and having them all report up to the same person. We rolled this out across the entire portfolio, Canberra as well as San Francisco, giving clear functionality that each team could own. As a result, we were able to continue adding people to the teams. We would hire people and once the teams would get to a certain size we were then able to have part of them easily break off, and consequently carry on with our expansion."

Lessons learned

• "Grouping teams by functionality makes a lot of sense. In terms of management, the goal is to make sure the team gels together and that we get the results that we want. So once we restructured, those items fell into place."
• "Having this particular structure allowed us to scale the teams and to continually grow the teams in a repeatable fashion."
• "A challenge that arose was making sure that the teams still felt that they were part of one organization and that they weren't working in isolated silos. Further still, I didn't want to have several different funneling technologies in use making it feel like everything was being built completely separate. I wanted to bridge the foundations between them and ensure that we had a shared platform for how we approached the product."