Menu

Subscribe

Mobile Platform Teams

This post is an excerpt from my book Building Mobile Apps at Scale.

As the number of mobile engineers working on an app - or in the company - grows, the trend of “reinventing the wheel” tends to emerge as one of the many challenges of building mobile apps at scale.

TeamA will need a piece of functionality - like logging, analytics, data storage and others. They’ll make their own choices and choose their own implementation. Then TeamB faces the same challenge. Assuming they talk with TeamA, they’ll probably decide it would make sense to reuse what TeamA did: not just for them, but for other teams.

The reusability dilemma: scratch our own itch or build a component that is reusable?

Reusable Mobile Libraries

Internal mobile libraries are usually created sooner rather than later during the development of apps. In many cases, the internal library might just be a lightweight wrapper around a vendor solution: written with the goal of easy migration to another solution, should the need arise.

There’s no limit on what can be an internal library, but common internal libraries often include:

  • Logging
  • Analytics
  • Data persistence
  • Feature flags, A/B testing & experimentation
  • Networking & authentication
  • Testing: UI testing, unit testing, mock generation
  • Brand UI elements, colors, themes
  • UI elements, frameworks & layouts.
  • Message display
  • Animations
  • Image management
  • Navigation frameworks
  • Architecture frameworks
  • Performance monitoring/profiling tools
  • Push notifications
  • Shared functionality specific to app domains: calling, PDFs, scanning, location, maps, and others

Mobile Platform Teams

Creating mobile platform teams when the number of mobile engineers is large enough is a common solution to the ownership and maintenance problem. There is no “golden rule” on at what size this should be done - but most companies make this step when they have - or expect to have - around 20-30 mobile engineers.

Mobile platform team ownership can vary heavily, based on what is considered “common” in the company. Areas commonly owned by a dedicated mobile platform are these ones:

  • Mobile build infrastructure - especially when deciding to keep the builds in-house. Even when using a third party vendor, a mobile infra team might own the vendor relationship and the setup of the builds.
  • App Store release management. At companies with mature release processes, this area often includes owning the manual testing process after the build cut, dogfooding/beta processes, and the process for last-minute hotfixes.
  • Developer tooling & experience. At scale - with 15+ engineers working on apps with hundreds of thousands of lines - the limitations of the “default” tooling start to become more painful. Building the app or running tests becomes slower - both locally and on the CI. Speeding up these steps is no longer just a “quick change”, but one that could need more complex tooling changes, code structure changes, or both.
  • Architecture & architecture maintenance. The first non-infra platform team tends to take ownership of the app’s architecture, ensuring it is built in a maintainable way. This team often becomes both a guide to help less experienced engineers make sustainable design decisions, as well as a “policing team” that ensures the architecture stays clean and in-line with the broader vision. Dependency management, code quality governance, testability - and testing - will often fall under this umbrella.
  • SDKs used within - or outside - the company. SDKs are usually specific to the business - and to the needs of the teams.
  • Mobile app reliability & performance: from crash rates, networking reliability, logging and performance monitoring.
  • Building capabilities to enable developers to be more efficient. With mobile frameworks - and even languages - evolving quickly, much of the ecosystem has gaps. The larger the team, the more visible these gaps are. Several mobile platform teams decide it’s worth them building a solution when the tooling they could buy is not good enough. Examples of this can include building a custom UI testing framework, putting a device lab in place, or implementing a build train that integrates with bespoke tools across the company.
  • Shared internal library ownership. Once mobile platform teams are in place, they tend to take over - or build - some of the internal mobile libraries.

A few guidelines on running a healthy mobile platform team are these:

  • Clear mission. Ensure the platform team has a well-defined mission that is more specific than “own all the shared stuff”. Examples of missions could be “Enable mobile engineers to work more efficiently, month after month” or “Ship the most reliable app in our industry.”
  • Clear goals. The platform team should have measurable goals on the areas they want to include. Possible goals include range reliability targets, percentage of teams using shared components, lines of code to integrate certain features, number of projects open sourced, and others. A platform team without goals will struggle to decide where to focus on. They will become less efficient than a team that knows where it is going and how they will get there.
  • Think of it like a product. Many people think of platform teams as "pure engineering" teams. However, good platform teams have customers, roadmaps and goals. Pete Hogdson goes into more detail on why you should think of your platform like a product and how you can harvest ideas from the platform's customers.
  • Sufficient staffing. The team should be big enough so that they have the bandwidth to do “product” work on the platform, on top of providing support for the rest of the org.
  • Clear contracts between platform and non-platform teams. The platform team should be clear on what they do and what they don’t own - and this should be a shared - and agreed - understanding with the product teams.
  • Clear support channels. Engineers should know where and how they can get support from the platform team. This could be shared chat groups, office hours, dedicated people to ping - and, most likely, a combination for all of these.
  • Clear process for engagement. The platform team should make it clear how product teams can work with them for feature requests: how to make the request, who and how will prioritize this work, and how they can track the status.

Looking for the more effortless mobile CI/CD solution? Bitrise is the solution I'd recommend. They're a mobile-first CI/CD solution to help automate the workflow from pull request to app store submission, with hundreds of open source integrations. Try Bitrise for free and build better apps, faster.

Mobile Platform Teams in the Real World

As inspiration, I've collected are examples of how companies approached mobile platform teams. Note that some of the examples are anecdotal, and others might have changed how they operate since. Don't forget that each company solves their own problems, taking their people and other constraints into account. Don't blindly copy what other companies are doing: follow the setup that will result in the right level of leverage you need.

  • Uber had a platform team owning mobile developer experience - including development tooling and build systems. Another team - called Mobile Platform - owned the architecture and shared services (RIBs and internal additions like experimentation framework). Mobile Platform later split to App Platform (owning app metric/reliability/performance, architecture and Core modules governance) and Mobile Foundations (owning reusable components and frameworks).
  • UberEats was a "startup" within Uber, operating almost fully independently from the rest of Uber in the early years. UberEats was started in 2015, and the first "official" mobile platform team was created 4 years later, in 2019. Even before this first platform team, UberEats teams all "pitched in" to build components that other teams would use in a reusable fashion.
  • Twitter used to have an iOS and Android foundation team with a few workstreams each. As the size increased, these teams split into smaller teams within each foundation, like UI, performance, architecture, builds, and developer experience.
  • Amazon had a platform team owning app architecture, logging, metrics, and shared, "infrastructure-like" features. Major features are often spun off in experience teams to own. These experience teams have contracts with the platform to bring clarity on code ownership and how design and code reviews are done.
  • Just Eat had an iOS and an Android platform team. These teams own all of the "typical" platform work, as well as the release process for iOS or Android.
  • Skyscanner had a Mobile Infra team (owning CI/CD, build and release management) and a Mobile Core team (owning reusable libraries and helping with issues impacting multiple teams).
  • VMware had a small team building mobile UI components and another team owning SDKs used internally, and by third parties.
  • Zenly (a Snap company) has a mobile platform team consisting of both mobile and backend engineers. They found that the nature of much of the mobile platform work spans from the app level to the backend. Examples of this include changing the networking layer for a different transport mechanism than TCP, metrics across the app and backend, custom crash reporting, remote debugging, and other advanced functionality.
  • N26 N26 had a "Core" iOS and a "Core" Android one, these teams owning all shared capabilities. They later explored splitting this team into smaller cross-functional teams, starting with a Design System team.

When to spin off the first mobile platform team is always a challenge. Large mobile teams clearly need one - or more - of these teams. But what about teams that are still small - say, at 15 engineers?

Starting a platform team too late can mean lots of redundancy in the code, poor abstractions, and little reusability between identical functionality. Were a platform team in place earlier, this team would have been the natural owner of several - shared - features and would have also taken ownership of the app-wide architecture.

Starting a platform team too early has the drawback of making it hard to make a business case for it - why hire an engineer who will not ship product work? Additionally, the first platform team usually draws the most experienced engineers into joining this team. These engineers are often also the most productive product engineers. Even if the company hires new engineers, these original engineers often leave a gap for a few months on the product teams.

Creating Mobile Platform Teams

Once you build - and ship - an app, and the app becomes successful, mobile engineering becomes more complicated than most people would expect. There are more than 30 engineering challenges that can all cause headaches: many of which do not have one size fits all solutions. Most of the problems come from smartphone development being a relatively young field - coming up around 10 years - and one that still keeps changing.

Sooner or later, you'll probably find yourself noticing engineers or teams "reinventing the wheel". As a manager, you might have more exposure to spot pain points that could be better solved with a uniform solution. By building a shared framework, improving tooling, or unifying processes.

The idea of setting up a "mobile platform team" will probably come around to you if your area has around 20 or more mobile engineers working on one or more apps. You'd probably be able to identify areas that could make more sense to be owned by a single team. But how do you go about this? Should you champion this cause?

I have set up a mobile platform team at Uber, creating the Payments organization's first mobile platform team. Here's the advice I have on how to go about with an effort like this:

  • Verbalize the problems a team like this could solve. Talk about issues the company is facing today and what the impact of a platform team could be. Talk with numbers. In my case, our pain point was how it took months to ship a new payment integration at Uber, and the cost was about an engineering year per integration. And we had a long backlog of these.
  • Empower engineers to think about problems, solutions, and data. Mobile platform teams are run by engineers. Lean on them to learn about the problems they see. Empower them to come up with platform solution suggestions and try to estimate the impact of these. Consider telling them, "Imagine I had a magic wand to create a platform team that can focus on solving the biggest pain points we have today. What are these pain points, and what would the impact of solving them be?"
  • Get informal buy-in from your manager chain and product management. You won't get the support or funding to create a platform team if your manager(s) and product manager(s) don't agree. Once you have the data, socialize the idea. Aim to do this at the decision-maker level: the people who will decide to allocate funding. In my case, this meant my manager, my skip-level manager, and the head of product for Payments.
  • Write a draft narrative - and share it with key people. Once you have verbal buy-in, put together a narrative of the team. Summarize the context to why this team should be created, the problems it will solve, ownership, success metrics, staffing, roadmap, and other relevant topics. Make it as specific as possible, using numbers and dates.
  • Get the funding. At this point, you should have support from your management chain and a strong business case. If you get the go-ahead: congratulations, you can "formally" start the team!
  • Don't sweat if you're not funded. Even with support from your management chain, you might not get funding for a variety of reasons. This doesn't make the business case any less valid. See if you can "do more with less", kicking off a few "platform efforts" with your current team. If you can show impact and further convince your management chain in the ROI, you will probably be able to revisit funding later. Everything you have put together should only help with this.

I share a business case for funding a mobile platform team with paying subscribers of my newsletter: access it here. The document outlines the context, the vision and mission, ownership and success metrics for the team.

Mobile Engineering is Challenging at Scale

Building mobile applications at scale are just as challenging as architecting and operating distributed systems. Platform components and teams are just one of the many challenges you'll probably across.

Check out my book, Building Mobile Apps at Scale: 39 Engineering Challenges. Covering an additional 38 mobile challenges on top of mobile platfrom teams.

Featured Pragmatic Engineer Jobs

  1. Engineering Leader - Card Platform at X1 Card. $250K+. Remote (US).
  2. Engineering Leader - Card Product at X1 Card. $250K+. Remote (US).
  3. Senior Android Engineer at Polarsteps. Amsterdam.
  4. Frontend Software Engineer at Enveritas. $130-150K. Remote (Global).
  5. Senior Software Engineer, Distributed Systems at Mixpanel. $200-270K + equity. New York, San Franciso, Seattle or Remote (US).
  6. Senior Software Engineer, Fullstack at Mixpanel. $200-270K + equity. New York, San Franciso, Seattle or Remote (US).
  7. Software Development Manager - eCommerce at Card Kingdom. $175-195K. Seattle, WA or Remote (US).
  8. Senior Frontend Engineer at Pento. £80-92K. Remote (Global).
  9. Senior Fullstack Engineer at Synthesia. £70-110K . Remote (Europe or US Eastern time) or onsite (London, Amsterdam, New York).
  10. Senior Backend Engineer at Synthesia. £70-110K . Remote (Europe or US Eastern time) or onsite (London, Amsterdam, New York).
  11. Senior Frontend Engineer at (catch) Health. $90-120K + equity. Remote (North America).
  12. Staff Backend Engineer at Pento. £95-115K. Remote (Global).
  13. Senior Full Stack Engineer (Laravel / Vue) at RXMG. Remote (Global).
  14. Sr. Cloud Infrastructure Support Engineer at RXMG. Remote (Global).
  15. Founding Engineer, Front End and API at Causal. $175-225K - equity. Boston.
  16. Senior Full Stack/Frontend Engineer at Vitally.io. $180-270K. New York or Remote (US).
  17. Senior Software Engineer - Core Platform at CAST.AI. €72-€96K. Remote (EU).
  18. Senior Software Engineer - Cost Optimization at CAST.AI. €72-€96K. Remote (EU).
  19. Solution Architect at CAST.AI. Remote (EU).
  20. Senior Software Engineer - Security at CAST.AI. Remote (EU).
  21. Solutions Engineer at Pigment. $70-120K. New York or Toronto.

The above jobs score at least 10/12 on The Pragmatic Engineer Test. Browse more senior engineer and engineering leadership roles with great engineering cultures, or add your own on The Pragmatic Engineer Job board and apply to join The Pragmatic Engineer Talent Collective.

Want to get interesting opportunities from vetted tech companies? Sign up to The Pragmatic Engineer Talent Collective and get sent great opportunities - similar to the ones below without any obligation. You can be public or anonymous, and I’ll be curating the list of companies and people.

Are you hiring senior+ engineers or engineering managers? Apply to join The Pragmatic Engineer Talent Collective to contact world-class senior and above engineers and engineering managers/directors. Get vetted drops twice a month, from software engineers - full-stack, backend, mobile, frontend, data, ML - and managers currently working at Big Tech, high-growth startups, and places with strong engineering cultures. Apply here.