How dissolving a high performance mobile team would help boosting mobile development
Disclaimer: this postmortem is based on a unique combination of organizational setup and team performance. It may not be applicable to companies with a dynamic setup like Spotify, or to those with the luxury of abundant resources. It is most relevant to small and medium-sized startups where resources are limited and skill sets are specialized. Restructuring teams is almost always a difficult and sensitive undertaking; it needs to be as well-reasoned as possible, with minimal disruption, while keeping teams motivated to move forward.
Why we wanted to make the move
Our core product experience is centered around running SME operations — expense reports, receipt capturing, bookkeeping, invoicing, payroll — and we felt it was more natural for customers to have the full experience on desktop-sized web pages. Our mobile app was originally designed as a companion to the product, allowing customers to quickly capture and categorize receipts on the go, with further actions completed in the web app. We had a dedicated mobile team responsible for mobile app development, kept quite small relative to our other feature teams. Our tech organization structure looked like this.
Over time, more features were added to our product, leading to the formation of more teams. We deliberately chose to ship some flows to the mobile app based on customer requests. The mobile team did a great job delivering new features, with very positive user feedback. That model worked well in the beginning — then friction started to appear, even though individual teams were still able to maintain high performance. There were quite a few impediments to navigate before shipping a feature to mobile users. Rather than having feature teams own the development of both web and mobile, we relied on the mobile team to handle product planning and independent development, all while we were not fully committed to a mobile-first product strategy. This bit us in terms of ownership, maintainability, and resource allocation. The team structure evolved into something that looked obviously problematic.
The mobile team, which had not yet reached critical mass, had to stretch itself across feature teams to discuss porting existing features to mobile. When they tried to accomplish certain functionalities, other teams perceived the requests as pushy — extra, unplanned workload. It is worth noting that customers were genuinely happy with the mobile team's work; we maintained an average 4.4-star rating on the App Store, increasing retention by 75% within a quarter 📈 🚀. Still, the more we built, the more we realized this model would not scale — it was generating unnecessary friction throughout the development process. Synchronizing cross-team efforts and building separate user interfaces for both mobile and web carried considerable overhead. Our VP of Engineering and team leads convened to find a way to improve overall efficiency.
How we made the bold move
We ultimately had two options on the table: keep the existing structure and hire more mobile developers, or shift actual feature development ownership to the feature teams. The second option was clearly more sensible. However, we also had to confront the reality that we had not invested heavily in mobile development. Shifting the model would require feature teams to build some mobile development capacity alongside their existing frontend and backend work. Alexey Krivitsky wrote a great article about transforming a mobile team, which informed our thinking around mobile platform teams versus feature teams. In the end, we went with a third option: we boldly dissolved the mobile team entirely, distributing ownership to the relevant feature teams where it belonged. Each team would now decide how much to invest in mobile, how to keep the mobile app in sync with the web counterpart, and so on. We introduced a solution architect role to transfer mobile development knowledge across all teams, coordinate mobile releases, and plan mobile milestones. The goal was to eliminate friction while accelerating mobile development — with more team members now invested in mobile outcomes. Existing mobile features were redistributed to their new, relevant team owners. New cross-team coordination challenges emerged, but they now lived at the product level, placing us in a much stronger position to move forward.
This approach aligns with what Skelton and Pais describe in Team Topologies as the shift from a siloed component team to stream-aligned teams: ownership and context live with the people closest to the product, reducing cognitive load and hand-off overhead across the organization.
Was it worth it?
Honestly, we do not know yet. It may produce a great outcome, or we may return to a modified version of the previous model if necessary. What matters is that teams are willing to embrace change. This is one Agile practice I wanted to share in hopes it might offer some inspiration. Keep adapting, and remain open to change.