As a company scales and product needs for mobile grow across the org, many mobile teams avoid bottlenecks by shifting away from a single, centralized team towards a distributed model with different mobile teams grouped under specific product features or initiatives.
Although the goal of this transition to decentralized mobile is to help teams scale their mobile practice, it also introduces new complications that are often difficult to navigate and force both managers and team members outside of their comfort zone. Issues include lack of visibility across the distributed mobile org, difficulty collaborating with competing timelines and priorities, opaqueness in ownership of core mobile tasks, fragmented development processes, and – with more moving pieces and more distance between them – a higher risk of things breaking.
In this article, we’ll highlight the main pitfalls you need to watch out for both during and after you make the change from a centralized to decentralized mobile org.
The key challenges of moving to a multi-vertical, decentralized mobile org
Lack of visibility across decentralized teams
When a centralized mobile team divides into multiple decentralized teams, the different teams naturally start focusing on their own roadmaps and their own goals. And with that, the teams disperse into separate daily rituals and distinct projects in tooling. Visibility across the mobile org can suffer as a result.
The shift from team-wide sync meetings and standups to vertical-specific meetings is a prime example. Unified meetings in the centralized setup fulfilled an important function: to provide visibility across the team, keeping everyone up-to-date on progress and ensuring a mutual understanding of goals. Without these meetings, decentralized teams don’t always have the necessary context about what others are working on and how it impacts them. As a result of the diminished visibility, there can be confusion, communication overhead, and a risk of silos forming.
But meetings aren’t the only area where fragmentation decreases visibility. Previously shared Jira boards become redundant as teams start using new, separate boards to manage their own team's projects. Communication channels also diverge: the #mobile Slack channel everyone used to use for updates pre-transition gets quieter as decentralized teams create new internal channels.
Working in a not-yet-familiar team structure is a challenge of its own, but without unified meetings and communication channels, things will inevitably become more chaotic across the different teams. Not having the appropriate platforms and processes to help keep everyone on the same page will lead to frustration and inefficient collaboration.
Competing timelines and priorities
Since each individual team tends to prioritize its own timeline and product roadmap, collaboration can get more difficult as competing needs arise. Things get especially difficult around releases, when everyone is hoping to squeeze their work into a single binary that has to get out the door.
Competing timelines and priorities can get especially hairy when the mobile org is sharing resources. For example, if there is one QA team for the entire mobile org, each team's individual needs and deadlines can lead to fighting over testers and, ultimately, animosity between teams. It’s common to see a similar phenomenon with shared design resources.
Because the demands on any given mobile team are often coming from a wider product group within the company, external pressure can be quite high and this exacerbates the situation. Teams often find themselves having to politick and bargain across the mobile org, which isn’t a great situation for anyone.
Ambiguity in ownership and accountability
Transitioning to a decentralized mobile team brings major changes to the ownership of core mobile tasks and foundational work. Before the transition, a unified team would just chip away at this kind of work – keeping libraries updated, maintaining tooling, establishing style conventions – together. Post-transition it’s unclear who’s responsible for it, and because each decentralized team is preoccupied with its own work, there’s often a game of “not it” that results in core mobile tasks ending up at the bottom of everyone’s backlog.
Unclear ownership leads to a lack of accountability, which increases the risk of things not being properly maintained, with bugs slipping through the cracks and tech debt piling up. The bystander effect takes hold: everyone assumes everyone else is responsible, and then no one does anything. Because core mobile tasks are often considered “not fun”, it’s even less likely a particular team will lead the charge and assume ownership, meaning these sorts of tasks either won’t get done on time or will be abandoned entirely.
As the mobile org continues scaling, hiring and onboarding new engineers can also become a bigger challenge. Which team or teams are responsible? Does each team take care of itself? In an environment with ambiguous ownership, it’s hard to know whose responsibility it is to teach new hires about certain processes or areas of the codebase.
Fragmented development processes and code style
After the transition to decentralized, teams across the mobile org will start to diverge in their development processes and code style. This happens organically as each team starts working independently in their own areas of the codebase, and it’s magnified because new leadership forms in each team and they tend to push their own preferred conventions.
The lack of uniformity on standards can lead to redundancies, duplicate code, and inconsistent conventions around APIs. As a result, navigating the codebase across domains and getting different areas of functionality to play nicely together can become a challenge. The product itself can also be impacted: parts of the app can start feeling quite different in terms of UX and quality.
Another risk of processes and norms that aren’t unified is that folks on the different teams won’t feel comfortable stepping outside of their own product domain, increasing their odds of getting stuck working in silos. If and when team members move to different teams, that process will also be slower, with a steeper learning curve.
Higher risk of things breaking
As the mobile team decentralizes, there are more “moving pieces” and the distance between them increases. More team members are working on an increasing number and diversity of product initiatives, with divergent conventions and code style, but they’re all still touching the same codebase and shipping the same end product — all of which leads to a higher chance of things breaking. Without effective communication and visibility across teams, there will be more regressions, inconsistencies, and redundancies in the codebase and finished product.
Tackling this higher risk is made even harder when accountability and ownership are ambiguous (point #3 above). When regressions surface, whose responsibility are they? What if one team’s changes have caused bugs in an area of the code they don’t own? Often responsibility is actually split, which makes dealing with these issues especially hard.
Besides causing decentralized teams to ship more bugs, often without even realizing it, suboptimal visibility and lack of clear ownership also slow down the process of triaging and fixing issues. Before anyone can even start working on an issue, it takes time and effort to figure out which team is responsible for triaging that part of the app and who’s the first-responder within that team.
How to navigate the transition to decentralized mobile teams successfully
There comes a point in your mobile team’s life when transitioning from a centralized team to a decentralized, multi-vertical mobile org is the logical (and necessary!) next step. The decentralized model can ease bottlenecks and unlock scale as a company grows and demands for mobile product grow with it. But, as we’ve seen in this post, decentralizing mobile resources also introduces pitfalls that teams need to address both while undergoing the transition and also following it.
Now that you’re clued into some of the key pitfalls to watch out for, how can your team navigate the transition to a decentralized mobile model successfully? In our next post, we’ll share best practices to help you manage the complexities that arise during the transition to decentralized, and improve your team’s processes post-transition as well.
