In mobile, there’s no “one size fits all”. Our users are on different operating systems, devices, wireless providers, and more. The list is endless. And the same goes for mobile teams and their composition. As companies learn and grow, the needs of the company and what they focus on begin to change. Maybe there’s less of an immediate focus on revenue and more on network performance and startup times compared to competitors.

Team composition is one expression of these needs, and thus must be hyper-focused and built with mobile and the company’s current KPIs in mind.

We’ve worked with many successful mobile teams and have seen teams grow from just starting out to enterprise-level. In this article, we’ll go over four common team structures we’ve seen find success in the mobile space.

One team with a single focus

A small but scrappy team all focused on one thing at a time.

If you’re at this stage, you’re likely just beginning your mobile operations. Though you may or may not have a well-developed team for web, your current team for mobile is just a couple of people working on your application. Because of your team’s size, there’s not much flexibility in terms of individuals working on separate features as their own projects. Rather, your team’s main focus is building out your app by shipping new features as quickly as possible.

Because your team is smaller and more cohesive though, it has incredible agility and is quick to refocus if you’ve made a misstep or need to make changes. The problem becomes how to maintain your roadmap when jumping back into existing features means delaying work on future ones.

Focused attention with specialized platform expertise

A couple of teams built to maintain the same app on different platforms.

After the first stage, your team has hit a stride. Your app has seen some success, but you’re noticing that your users are differentiating into groups. Across all applications, this is true: iOS users often spend more, each platform surfaces their own separate types of issues based on different rules (terminations by the OS or ANRs for Android), and more.

This new need for a better product fit to cater to your users, possibly even in terms of design — as each platform’s applications have different visual looks and feels — requires platform experts on each team. Now, though you may be working on the same features and even if you’re working with a cross-platform framework, you may need to adjust your vision to better fit your users instead of focusing on releasing something to gain a source of revenue.

While this type of team still maintains agility, the two teams (e.g. Android vs. iOS) might begin to separate, work with different tooling, and cater toward their users’ needs by building different features.

Many teams each with their own features

An enterprise team that needs to release quickly while also managing stability and app health.

Now, as you’ve grown, you have enough engineers to build multiple pods that compose a team. Pods are small teams of engineers (2-4) who all work on the same project and report to a leader who manages each pod’s work, who might be the Head of Mobile, CTO, or VP of Engineering.

Each pod could work on separate applications or, more likely, there are multiple teams composed of these pods working on separate applications. As your application has grown, you may have seen a need to create internal tooling that an entire team is dedicated to or the need for a team to be more focused on your backend.

Having separate teams for applications, each with sub teams that function similarly to the team structures from the previous two categories, balances stability and agility. Different pods can focus on separate tasks—building features, debugging issues, and maintaining internal tooling—all at the same time.

Product lines as P&L

An enterprise team with a focus on release velocity with each team taking responsibility for their piece.

Another structure we’ve seen enterprise teams field is having separate teams that build and maintain a specific piece or product on the application (e.g. a specific page on the application or feature) and focus mainly on their own product’s P&L. This structure allows for incredible product specialization and expertise. Though it might seem less stable having work from one team that might conflict with another’s, it actually allows for extreme ownership for stability: Each team is responsible for its own product and ensuring their product doesn’t cause conflicts.

For example, an e-commerce company might have separate teams working on the front page, check out, main store offerings, etc. Or, they might bucket teams as working on featured items and merchandising, payments, checkout flow, etc.

What team structure should you choose?

Again, there are many considerations to how you should build your teams. You’ll likely face just as many growing pains or challenges when making bets on KPIs as you will when structuring your teams, even if that style has demonstrated success at another similar company. So, you also have to remember: these aren’t the only structures that exist.

Maybe you mix and match among these styles, taking pieces from #4 and #2. At the end of the day, it’s essential that you work with what you have and your unique situation. It’s important that you don’t just automatically shift to what’s seen success historically, though you should use it as a model.

So, keep your team hyper-focused on those actionable metrics, no matter what team structure you choose. This process changes constantly, and you can always adjust as you go. Just as you are working to build a product that works for your users, build the team that works best for you.

How Embrace helps mobile teams

Embrace is a data driven toolset to help mobile engineers build better experiences.

Want to see how Embrace can help your team grow your app with best-in-class tooling and world-class support? Request a demo and see how we help teams set and exceed the KPIs that matter for their business!