How dissolving a high performance mobile team would help boosting mobile development
Disclaimer, this postmortem is based on a unique combination of organization setup and team performance. It may not be applicable with companies having dynamic setup like Spotify or ones with luxury resources. It is mostly true to small/medium startups where resources are limited with existing specialized skill sets. Restructuring teams most of the time is a hard and sensitive practice; it needs to be as sound as possible, as minimal disruption as possible while keeping the teams happy to move forward.
Why we wanted to make the move
Because our core product experience is centered around running SMEs, say, expense reports, receipt capturing, bookkeeping, invoicing, salary, we feel it's more natural for customers to have full experience on desktop-size web pages. Our mobile app was originally designed to be an add-on to the product where customers could quickly capture and categorize receipts on the go; further actions can be completed on web app later. We had a dedicated mobile team to take care of the mobile app development. The mobile team was kept quite small compared to other feature teams and our tech organization structure was like this.
Over time more features have been added to our product, leading to more teams. We deliberately chose to ship some flows to mobile app due to customer requests. The mobile team did a great job delivering new features with very nice user feedbacks. That model worked well in the beginning, then friction started appearing even though individual teams were still able to maintain high performance. Basically there are quite some impediments to go through before shiping a feature to mobile users. Rather than feature teams control the development of both web and mobile, we relied on mobile team to do product planning and independent development while we weren't really betting big on mobile-first product either. This bited us in term of ownership, maintainability, and stretching resources. The team structure became like this, which looked obviously bad.
The mobile team which didn't even reach their critical mass had to "stretch" themselves to other feature teams to discuss the porting of existing features to mobile. Also when they tried to accomplish certain functionalities, the other teams perceived that as something pushy, aka extra unplanned workload for other teams. It's worth noting that customers are happy with the works of mobile team, we reached averaged 4.4 star rating on AppStore, increasing retention by 75% within a quarter 📈 🚀. Still the more we did, the more we realized that model wouldn't scale but creating more unnecessary frictions in development process as a whole. Especially the effort to synchronize cross-team and develop separated user interfaces for both mobile and web is considerably high. Our VP of engineering and team leads sat down, finding a way to improve the efficiency.
How we made the bold move
Eventually we got two options on the table. Either keeping the way it is and staffing more mobile developers, or shifting the actual feature development to feature team. The second sounds much more sensible. However we also had to deal with the fact that we hadn't invested on mobile development very much. Changing the model would assume feature teams have some capacities of mobile development along the side of frontend and backend development. Alexey Krivitsky wrote a very nice article about transforming mobile team, which inspired us about mobile platform team versus feature teams. In the end we went with the ... third option, we boldly dissolved the mobile team, moving everything to feature teams where it is supposed to be. That said each team needs to decide how much they want to invest on mobile, how they keep mobile app in sync with the web counterpart ,etc. We introduce solution architect role to help transferring mobile development knowledge to all teams, to coordinate mobile releases, to plan for mobile milestones, and so on. We hope this model would eliminate frictions while boosting our mobile development process as there are now more members care about mobile. Existing mobile features are distributed to new relevant team owners. There are new challenges to synchronize cross-team but it is now at product level, which puts us in a much better position to move forward.
Was it worth it?
Honestly we don't know. It may give a shining outcome, or we may switch to the previous model with some modifications if we have to. As long as the teams are happy to embrace changes. This is one of Agile practices I want to share so you can get some inspiration. Keep adapting, and keep opening to changes.