Merging a Web and Mobile Team: A Tale of Two Cultures

Problem

When I took over engineering at Zynga Poker it had a mobile and web team that had been located in different departments. As I was tasked with merging the two, I had to solve the very large challenge of resolving both the technical and cultural divides. They were interacting before, but being part of different departments they had different goals and thus reluctant to help if that would conflict with their own priorities. I had to figure out how to merge them into one cohesive, fully functional team.

Actions taken

The first thing I did was to co-locate them. I took the mobile team, which was smaller, and put their tables smack in the middle of the web team. Then I took their line manager, brought him into our leadership staff and made sure that his voice was heard on every departmental issue. I continuously broadcast the message that he and his team were valued by me and I expected him to be treated as an equal.

Next, I encouraged heavy social interaction between the teams through happy hours and other intermingling events. I approached one of my web developers, who was very social and well-liked and asked him to put a large effort into making friends with the mobile developers and make them feel comfortable.

In team meetings, I would keep a lot of focus on the team and emphasize the importance of their collaboration - going so far as to overdo it a bit in order to get the message through.

But I saw that this would not be sufficient and wanted to further mix them up. I was able to take a few back-end people from the web team, who were interested in mobile and had the experience the mobile team needed, and put them on that team. They were very interested and passionate about the domain and the mobile team was appreciative not only of their knowledge but their enthusiasm as well. That had a huge impact on the morale and productivity to a team that had always been neglected.

Pushing the mobile team from the product perspective made the web team realize how their work was critical for our studio. Within two or three months things were going very well. There were still process issues that we had to iron out, which was slow going, but we gradually got them on the same page.

The only big challenge that was an ongoing challenge was technology-based. The mobile team had reverse-engineered the web team’s APIs and the web people didn’t understand how mobile was different, especially in terms of connectivity and reliability of the connection. There was a significant disconnect about how to build APIs that mobile could easily consume, and it took longer for people to learn how to be more productive and build a more resilient platform.

Lessons learned

• Immediately making the mobile team first-class citizens was crucial. Showcasing how their work is critical was a must for establishing collaboration and respect among the teams.
• Co-location and mixing them around, both spatially and functionally, was very important from a cultural as well as from a technology perspective. Culture is institutionalized in people, so there is no substitute for this.
• We did not do enough to aggressively address architectural differences in the platform, which came back to bite us later. It is always hard for people working in one domain to fully understand the risks inherent in another domain. What we needed to do was to very quickly have a massive architecture and code review on the networking related codebase.