Restructuring After the Acquisition of New Teams

Problem

Our organization acquired another company that was about the same in size to ours. I was the leader of engineering and originally had five team leads directly reporting to me but after the acquisition, that number doubled to ten. It was a lot of added responsibility. I became the pressure point for most of the interactions so I was spending a lot of time working yet the teams weren't getting the right level of attention from me. Furthermore, the dynamics and maturity level of the teams varied greatly due to various architectures, codes, and product quality. The overall health of the engineering team was diminishing, the organization was super flat, the team wasn't making tangible progress, and I was beginning to feel burnt out.

Actions taken

I began by clearly articulating the charter for a high-performing team, the way I envisioned the team to be. I defined guiding principles for how the team should operate, best practices, and KPIs. Then I started to implement a structure surrounding it. I broke the team down into two main clusters based on the similarity of domain, location, and tech stack (so that skill sets could be shared). Then I hired two directors to lead each of the clusters. One director came to us through the acquisition while the other was hired externally. These two clusters made it manageable for each director to handle the teams at a given point in time while also giving me some breathing room to be more strategic rather than more tactical. Yet, because I had created this separation, I didn't want the two teams to side-off against each other and become less efficient. So I created cross-functional entities called guilds (a resemblance of the Spotify model). There were four guilds: architecture, QA automation, SRE best practices, and productivity engineering. Each guild had an assigned leader and I made sure that there was one representation in that guild from each team. This served to ensure that any knowledge, skills, or capabilities we were developing would level out to all team members.

Lessons learned

The reorganization was supposed to allow the teams to be fairly autonomous in power so they could work independently and we could scale by creating more such teams. Unfortunately, with the new structure in place the teams weren't as self-sufficient as I'd expected. Below are three second-order effects that occurred due to the restructure and how I addressed them.

• The leadership team was weak and not fully developed. Thus, I started making an investment in developing our leaders. I brought them all on-site (team leads, guild leaders, and directors) and had a leadership summit where I set expectations, leadership principles, and what 'good' looks like. Each group took that information, digested it, and returned with a state of the union based on their perspective. In addition, we did management training so that we could upskill some of them. Further still, I thought it important that the leaders build relationships and trust between themselves. As a result, we did team-building exercises so that they could become a support system within themselves rather than being hierarchical in nature.
• I observed a bottleneck with the team leads who were relying too much on the director to come in and work the people management side. More so, the guild leaders wanted to take ownership of the process and this started creating a divide. To resolve this issue I defined roles and responsibilities so that it was clear who was in charge of what. The team leads were to be the main person accountable for anything related to the product or anything that the team was responsible for. The team lead would be in the driver's seat, addressing goals and deliverables, while the role of the director was more or less like that of a coach or facilitator. The director would be responsible for quarterly goal planning across the different teams while also helping to balance out the resources needed across those teams. On the other hand, the role of a guild leader would be more focused on sharing information such as best practices.
• The last side effect was that when I gave the teams autonomy I did not hold them accountable. I made them autonomous but the results were still not happening. Therefore, I learned that it is imperative to trust but verify. Otherwise, though the team is running independently, they could be doing what they want and not working towards the results that you are looking for.