Reorganizing the engineering department for more agility

Problem

At Square, teams used to be structured around engineering disciplines. I was the manager of a highly performing team of ten engineers in charge of the merchant dashboard. The advantage of this organization was that my team was focused and maintained a high-quality bar, with the trade-off of centralized development, requiring other teams to submit their projects to us for prioritization. In order to scale our teams, a group of managers - including myself - decided to change the organization from teams based on engineering disciplines to teams based on products. This meant that my team would be split and my engineers would be moved into different teams.

Actions taken

As a manager, I prepared my team for this reorganization by being very transparent about the details and rationale. I took advantage of our one-on-ones to inquire about where they wanted to transfer, and allowed them to provide us with up to three preferences that we would try to reconcile later between managers.

"I prepared my team for this reorganization by being very transparent about the details and rationale."

On the other side, this transition required me and other managers to precisely define the scope of the new organization: What is the right headcount per team? How should the engineering budget be allocated between each product teams? How do we measure the success of this transition? It took substantially more time and effort to accomplish a reorganization of this magnitude with consideration for our engineers' preferences and well-being, but we nailed the execution and by doing so enabled more agility in our product development.

Lessons learned

A reorganization is not always easy. As a manager, you have to think about what's best for the company and understand the tradeoffs. One of the main lessons learned is to consider both the immediate and long-term effects of a reorganization. In this example, the most efficient solution in the short-term would have been to move engineers to other teams without asking them what they wanted to do. However, it would have frustrated them and probably lead to additional management challenges.