For scaling companies, there comes a point where moving from a single, centralized mobile team towards a distributed model — with different feature or function-based teams — will inevitably become a necessary next step. The aim of the shift is to enable organizations to scale and accelerate their mobile development practice by allowing multiple teams to work on different parts of the product at the same time, independently of each other, as opposed to a single team trying to tackle everything all at once.
In our previous article, we highlighted a number of common pitfalls to watch out for as a mobile team making this transition. In this post, we’ll share best practices and practical tips to help your team navigate this challenging period, as well as improve collaboration and efficiency post-transition.
Tips to help your mobile team avoid common pitfalls during the transition to a decentralized mobile org
Establish a single source of truth for the wider mobile org
As teams start shifting to a decentralized setup, it’s common to see a rapid decline in the level of visibility into team-level goals, product roadmaps, project statuses, metrics, and more. As standups are split up, new communication channels are created, and each team establishes their own processes for creating and maintaining internal documentation, it’s easy to quickly devolve into a situation where each team operates in a silo, which has detrimental effects on collaboration, alignment, and organizational cohesion.
One way to get ahead of this issue is to create a shared space that serves as a single source of truth for the entire mobile org. This shared space can serve to bring to light key information about each team’s roadmap and priorities that might otherwise be difficult to find. It can also be a place to plan, track, and document shared initiatives that are jointly owned across one or more teams in the org (more on that later). Whether it be a simple shared document or part of your org’s favorite knowledge-sharing tool, each team should be responsible for keeping it up to date, so it can be a reliable source of information for the wider mobile org at all times. Having access to a shared source of truth enables team members across different teams and functions to maintain a holistic understanding of the entire mobile product – including project statuses, progress, deadlines, blockers, and more — helping to keep everyone aligned, focused, and on the same page about the priorities of the mobile org.
Remove release bottlenecks
When working in a decentralized team structure, feature-based teams also commonly work within parallel product timelines. But most often, features are being developed for a single main app, so the work of multiple teams must be packaged and distributed as a single binary — which means that in a decentralized team world, releases can naturally become a huge bottleneck. Different teams trying to squeeze in as much work as possible into each release can easily lead to rushed, insufficiently tested features. And as each team focuses on their own product goals and timelines, there’s also a higher chance of important (but often rote) tasks getting overlooked.
For smooth and successful product delivery, teams need a well-organized, streamlined, and predictable release strategy. There’s a reason why moving away from ad-hoc releases towards an agreed-upon release schedule — usually referred to as a release train — is a popular practice among high-performing distributed mobile teams.
Compared to feature-driven releases — which can be unpredictable, as they depend on the team completing the new feature on time — a release train pushes the mobile org to ship updates frequently and encourages developers to focus on smaller, more manageable units of work. The regular cadence takes some of the pressure off of getting everything into a specific release (since there’s always another release not too far away), and helps reduce the bargaining over shared resources — such as QA or testing — because in theory there should be less to test each release.
This dependency can be broken up even further by leveraging feature flags to enable teams to release untested work safely. Features can then be remotely enabled by the team when deemed ready, without requiring another release.
Facilitate ownership and accountability
The transition period to a decentralized mobile org is often accompanied by a lack of continuity — and clarity — around ownership and accountability for different parts of the mobile product. Before new processes can crystallize, answers to questions like who, or which team, is responsible for a certain process or system are often unclear. Many mobile developers know from personal experience that tasks without explicit ownership tend to not get done on time or sometimes get abandoned entirely. During this period, it’s easy for tech debt to pile up as teams play the game of “not it” when faced with critical infrastructure or maintenance work which doesn’t fall neatly within their product domain or team’s goals.
To prevent these issues from snowballing and causing serious problems, teams need to address the question of ownership early on. Assigning, delineating, and documenting the ownership of core tasks, components, processes, and tools needs to be a priority when moving away from a centralized team setup. While parts of your product may have more obvious and clear owners (like the login and signup flow being owned by the User Acquisition team), other parts may not be so straightforward, and will require ownership to be shared across teams. Often, maintaining core components like networking libraries and key workflows like the release process, fall into this nebulous ownership area.
Shared ownership can be one the more challenging aspects of running a decentralized mobile org, as it can be difficult to implement and continuously execute well on. One thing that can help keep shared owners aligned is to create a centralized roadmap that clearly defines common goals for the core components of the mobile product for upcoming quarters. It will still be up to individual teams to determine how to execute their share of the work, but centralized, high-level goals can help foster alignment across the various owners of the components in the organization.
Another approach to help address the problem of ownership when it comes to core infrastructure or maintenance work — and one that’s often seen in much larger mobile orgs at scale — is creating a dedicated platform team to own these tasks explicitly. This approach helps ensure that these tasks won’t get lost at the bottom of the backlog, enabling feature-based teams to truly focus on the product — while having the necessary infrastructure to do so. Still, while platform teams are nice to have, having one is not a must. For many under-resourced teams, forming a platform team isn't always an option; and feature teams can reliably share the work of maintaining the core infrastructure of the app, as long as clear ownership is established early on.
Build bridges between mobile contributors
As the team shifts into a decentralized structure and the distance between different teams grows, issues resulting from inefficient communication and reduced collaboration between distributed teams can start to surface.
Having open forums to share updates, workshop new ideas, and work through problems is a great way to keep different teams on the same page and create space for collaboration and support. Establishing these open spaces where mobile contributors from different domains can all collaborate also helps foster a sense of cohesion across the team — a reminder that despite the fact that the mobile org is made up of several smaller teams, they’re all still working towards a shared vision. Ideally, this forum isn’t just another Slack channel or Jira board — it needs to be designed specifically for the purpose of fostering collaboration, camaraderie, and knowledge sharing across teams. Regular org-wide meetings or check-ins can be a good option for this.
Another way to bring teams closer together is by encouraging mutual learning. Inclusive, cross-org activities like lunch & learns or exchange programs, where team members spend time learning about how other teams work, encourage both learning and knowledge sharing. The ultimate goal here is to promote a sense of community by showing how different teams contribute to the overall success of the mobile product.
Create guardrails to minimize risks
Mistakes on mobile are particularly difficult to correct — because there’s no undo button or straightforward rollback after a buggy release. Decentralized mobile teams are often under pressure to coordinate critical mobile processes across different departments — a task that’s fraught with ever-increasing risk as the number of teams in the mobile org grows. For this reason, it’s critical to establish guardrails wherever possible to prevent mistakes from happening, and increase confidence in the mobile org’s ability to safely ship product as it scales.
Automated tests, rigorous QA processes, regression testing, and phased/staged releases are table stakes for most teams when it comes to ensuring the quality of a mobile product. And once again, feature flags can also play an important role in de-risking new feature work, as they give you more control over releases out in the wild. If you end up shipping a faulty feature, you can just toggle it off remotely.
When it comes to your team’s release process, status-based gates, configurable custom sign-offs, and checklist items can help make your process repeatable and consistent. Keeping tabs on release health post-release is also critical: crash rates, key metrics, and reviews should be monitored (ideally in an automated way) giving your team confidence in their ability to quickly detect and respond to issues in production should they arise.
Standardize conventions and styles
As the mobile org splits, individual feature-based teams also run the risk of gradually diverging more and more in their coding styles and conventions, which can lead to redundancies and inconsistencies in the codebase and even within the app itself. Therefore — more so than centralized teams — distributed mobile organizations need frameworks and guidelines that standardize the development process. It’s important that these frameworks are established even before the transition begins so that coding standards, styles, and conventions are already in place as new teams spin up.
It’s one thing to establish conventions but quite another to maintain them — especially once new teams have formed and cross-team communication becomes more challenging. Organizing a forum for mobile folks to regularly come together post-transition to evaluate and discuss conventions can help ensure that standards are kept up to date and top of mind. The form this takes can vary: some orgs choose to create concrete “chapters” or “guilds” that meet on a regular basis, while looser meetups may suit others better.
Establish mobile DevOps processes early on
While setting coding standards and conventions early on can help avoid common issues associated with inconsistent codebases, distributed teams must also figure out — and agree on — critical mobile DevOps processes. Choosing a branching strategy, setting up continuous integration and continuous delivery, and establishing an on-call rotation are all important parts of an effective mobile DevOps process and therefore critical to establish and document early on.
Although you’ll likely need to tweak and adjust various DevOps processes as part of the transition to a decentralized mobile org, keep in mind that the more fleshed out your mobile DevOps process is, the easier the transition will be.
Towards efficient collaboration in decentralized mobile orgs
Making the shift from a single, centralized mobile team to a distributed mobile team structure is always a challenge, even for the most buttoned-up mobile orgs. The transition period is never entirely seamless, but thinking ahead to potential pitfalls — and putting in the work towards avoiding them — can help smooth the transition and set your mobile org up for success long-term. And, even if your mobile organization is already mid-transition, or experiencing some post-transition issues and communication overhead, it’s never too late — there’s never a bad time to reassess, understand what’s working (and what isn’t), and to make improvements to your distributed mobile org.
