Scaling a mobile app team from 1 to 20 people

When you start upscaling your app team, it’s tempting to look at it as a developer shopping spree. But more developer capacity doesn’t always equal more developer productivity. Without the right support roles in place, your most experienced developers will end up spending their time on QA testing and gathering user feedback, not necessarily what you actually hired them to do.

You might get lucky and find a mobile developer who loves making UX decisions as much as writing code. But the chance of finding a whole dev team that can double up on all the extra support skills you need without diluting their own work is impossible. What you really need to build an efficient mobile app team is to be strategic about the expertise you need and when you need to find it.

‍

If you’re starting your scaleup journey, check out our guide to hiring app developers and signs your app team needs support. Or if you’re looking for that support, don’t hesitate to get in touch.

‍

When one developer isn't enough

‍

If you’re starting your app journey with a team of one, that one person is almost always going to be a developer – otherwise you probably won’t make it to the app store. Let’s say you’re that one developer, and you have a prototype in the app store, what kind of expertise do you need to bring on board next?

The goal with a second hire should be to start covering your bases. If you’ve only got a sole developer on the team, they’ll end up spread across a bunch of product-focused tasks outside their wheelhouse – tasks like feature design, testing and product feedback. Going forward you’ll want to bring in a product manager who can dedicate themselves to those jobs.

That product manager will help to “top and tail” the development process. They’ll be gathering user feedback and turning it into a tight design spec for your developer to go and replicate with working code. Once the code is ready, they’ll then pick it up to make sure it adheres to the designs and is bug free.

‍

From two to five: what support do you need?

‍

When you build from two to five, it’s time to start specialising the skills in the team. You’ll probably be looking to add a second product person, so one can stay closer to the customer and user experience, while the other focuses more on the management. 

And it’s often helpful to split the developer function in the same way, hiring another tech hand who can specialise in either the frontend or backend.

As for Hire #5, you’ve got a couple of choices. One option is to bring in someone to cover off the testing end of product development. The other option is to hire a project manager to bring some order to your team’s communication..

With a team of two, communication is simple – either you’re talking to the only other person in the team, or you’re talking to yourself (we’ve been there!). But once the team gets bigger, things start to get messy. 

At five people, the team is still small enough for everyone to be talking to each other, but now there are dozens of possible lines of communication to keep track of. And it’s easy to get those lines tangled and your development process in a twist.

So we’d recommend making sure your team has this covered. If you’re adamant you want to bring in a tester as your fifth team member, one of your product team might be able to handle the comms. But unless your team already has the organisational skills you need on tap, you might be better off hiring a dedicated project manager instead.

‍

Read: What is the Expo Router?

‍

From five to ten: get some sub-teams going

‍

Ten is a tricky number for mobile teams. Until now everyone’s been one unit, but double digits is when that single team starts becoming inefficient. One answer is to divide team members into dedicated sub-teams based on each app development stage.

By now you’ve probably got two or three people forming the product team at the front of the chain. They’re responsible for kicking the product development off, gathering user feedback and turning it into feature designs and product decisions.

Then there will be a dedicated development team, including a technical architect whose job is to think long-term about how to structure code for new features. 

Finally, a QA group takes over the code at the end to check it against the original design.

Once you start breaking things down into sub-teams, you need to make sure the contracts between them are well defined.  Is it clear what “done” means when a ticket passes from one team to the next? The individual members of each sub team might not be constantly talking to each other anymore, but they still need to know what’s expected at each stage of the process.

This is also one of the best points in your scaling to slot in someone like an agency to augment your in-house team. Meshing mobile app developers from different sides of the fence is easier than it sounds, and means you can bring in specialists in areas like React Native without going through a lengthy hiring and onboarding process.

‍

Read: Avoid 3 key mistakes for a successful marketplace app.

‍

Building to 20: align your teams to specific goals

‍

At this stage, you’ve (hopefully) gathered a wide range of tech expertise across frontend and backend development. You’ve got expert product people shaping new features and testers putting code through its paces. And most importantly, you’ve managed that transition from one team to several sub teams.

But as you near that magic 20, you’re not just looking to divide your team based on their expertise – you want to segment them across different areas of the app’s development.

There are a couple schools of thought on how to do this. 

‍

School no. 1: Give teams responsibility for handling specific features. 

Imagine you’re in charge of Spotify. You might have one team – including product managers, development and testing – in charge of user authentication, another in charge of playlists, and so on.

But this is a bit old fashioned. It’s not usually the best solution for mobile app developers, for the simple reason that people are likely to get bored, and nobody wants their app team walking out the door. 

‍

School no. 2: Divide your teams according to your north star metrics. 

Here, instead of giving a subteam responsibility for an app function like authentication, you’re giving them charge of a more specific goal. For instance, one team might aim to make the app as sticky as possible to reduce churn – and they can work across a number of different features to achieve that.

It’s so much easier to motivate everyone when they’re aligned around one clear metric and not tweaking the login button over and over. And if they’re not restricted to one aspect of the app, they’re less likely to get tunnel vision – your product team, developers and testers can work their magic across the board, and keep a bigger picture view of the app as a whole.

‍

If you’re starting your scaleup journey, check out our guide to hiring app developers and signs your app team needs support. Or if you’re looking for that support, don’t hesitate to get in touch.

‍