Restructuring Teams Around Products

Problem

"In our engineering organization the teams are typically defined by function. For example, we have a mobile team, a few back-end teams, and a web team. As our company was growing I noticed that our teams (as defined by function) were not scaling well due to the fact that every single project involved different teams. For me, it became difficult to manage across these different teams."

Actions taken

"Leadership decided that we should organize our teams more around the products that we were trying to deliver rather than function. My team was the first to integrate this new structure and so we had back-end, mobile, and web engineers all on the same team.

At first, this was tough for the engineers because these individuals, who came from different teams, never had to collaborate with each other. What I did to ease this pain was I introduced a team share-out meeting. The meeting involved learning about what other engineers on your team were working on. Individuals would walk through something that they had worked on recently, giving everybody else on the team an idea of how their development process worked. This helped each engineer on the team develop a sense of each other's technical space and gain empathy for the challenges that others had. Further still, these new insights led to better understanding of how each one interacted with each other.

In addition to our share-out meetings, we started structuring our work to make things more collaborative. We did so by working together on shorter-term projects rather than working on longer-term projects separately, for example a long-term back-end project and a long-term mobile project. This allowed all of the functions- back-end, mobile, and web- to be run on the same sprint. Consequently, we had faster iteration, a clearer understanding of what each component was working on, and more actual collaboration within a sprint."

Lessons learned

"When we began bringing mobile engineers onto the team I didn't initially think it would be a big change. But once we got started and after talking to individual engineers, I realized that it was. None of the engineers knew what the other was working on and they didn't view themselves as a team. Reflecting upon this, I wish I had more consciously thought of this before we started the new structure and got ahead of getting that sense of a team a little earlier."