By Benjamin Augustin, Technical Leader

When you’ve launched a successful mobile product and need to scale quickly, your engineering team will likely grow quickly too.

While it’s not difficult to be aligned and work well together when you have a handful of people in a team, as you hire more people and start separating into different teams and departments with various responsibilities and KPIs, getting all those parts to work cohesively and efficiently becomes more difficult. That’s when a robust mobile team enablement framework is vital.

Why mobile team enablement matters

Mobile team enablement encompasses absolutely everything your business does to improve the efficiency, comfort and experience of your development teams.

Creating an environment that enables your mobile team to operate to the best of their abilities and maximises their skills takes time, continuous attention and sustained effort. While most organisations have good intentions and care about creating a better working environment for their teams to function, often mobile team enablement tasks will be de-prioritised as they feel less tangible and harder to measure than day-to-day performance metrics such as releases, fixes and user feedback.

That’s why, when it comes to measuring the success of your mobile team enablement efforts, instead of looking at the outcomes, you need to look at how efficiently these outcomes are being produced, such as how long it takes to ship a product once it's built or how often you’re able to release.

So, how does a fast-growing organisation create the most effective and efficient working environment for its mobile development team? Here are some of the most common ways we support our clients.

Enabling automation

When it comes to mobile operations, it’s possible to automate everything including building, validating, pushing to app stores, incrementing and releasing.

If your processes involve a lot of steps to reach a goal – for example, if a release process usually spans multiple days with several actions – then it’s time to put in an automated process. 

While this might mean more effort up front, if it means the same result can be achieved with drastically less time and without interrupting your team, this is going to have a much greater long-term benefit in terms of saving time and resources.

Implementing shared tooling and frameworks

If you have different teams taking the same actions in parallel multiple times, this equals a lot of wasted energy that could be directed to other things. Developing shared tooling and frameworks for multiple teams to access and use is an excellent way to create efficiencies.

To be able to implement shared solutions, you’ll need to review and identify where this is happening across multiple departments – a difficult thing to spot if you’re only measuring output and not efficiency.

Focusing on communication

When you have multiple product teams, all doing independent work, communication across those teams might not be necessary for product tasks – but it is vital for the overall efficiency of your business.

If you have separate verticals within your business, you need horizontal communication.  Without communication between teams about the solutions they’re working on, multiple teams might identify the same need and end up working on very similar things. Whereas if needs and solutions are regularly discussed between teams, one team can be assigned to develop a tool or framework and share it with everyone else.

Streamlining the release process

It’s not uncommon for the release process on mobile to be suboptimal, because there are so many more additional steps when it comes to shipping on mobile compared to the web. This means there’s more that can go wrong, and more places efficiency can be lost. And when you scale, these inefficiencies can add up to create big costs for your business.

There aren’t a lot of existing tools out there to support mobile releases, which means increasing efficiency here usually requires a bit more effort than on web or backend where existing tooling is established. This might mean custom work such as creating release management, custom scripts to automate deployment, etc.

Reducing build time

The bigger your organisation grows, the more impact delays to build time will have on your operations. For example, if there’s a 30-minute build time within a process and you’re building 300 times a month, that’s 150 wasted hours. When we worked with Glovo, we reduced the time taken for full validation from an hour to 15 minutes. Multiplied by hundreds of times, this was a huge cost-saving for them.

It can be difficult to identify where there’s potential to reduce time within your processes because they become so habitual. Your team might not even be aware of the things that slow them down. Recently, I spoke to a team who had a CI environment where the build on CI was failing 50% of the time when running PRs. When it failed, they just ran it again. It had become so habitual for them, they didn’t even think to raise it as an issue. But when we realised what was happening, we could see that the knock-on effect of all that unnecessarily repeated work was enormous – and we could find a solution.

Avoiding context switching

Developers are part creatives and part problem solvers. Usually, they’ll spend a lot of time absorbing a problem and creating mental models before moving forward. This is why avoiding context-switching – jumping from one task to another – is especially important for your mobile teams.

Research has shown that if you’re forced to task-switch, it takes an average of 23 minutes to regain your focus. Therefore, if you’re being forced to do this multiple times a day, it’s easy to see how this can add up and impact productivity.

For example, if you have a mostly manual release process and you want to release weekly, team members will probably have release-related tasks to worry about every day. Not only does this take their focus away from more skilled work, wasting time on tasks that can be automated, but they’re also wasting additional time due to context switching. 

While we all have to multitask sometimes, adding forced multitasking daily will drain your team. They’ll feel more stressed and less productive because they don’t have the environment they need to do their best work.

Ensuring ownership and accountability

Within developer teams, people will often build a piece of code because they need it to accomplish something. After a while, it isn’t needed anymore, nobody pays attention to it, and it falls into disrepair. And when it inevitably needs an update or breaks, it creates problems because it doesn’t have an owner, and nobody knows whose responsibility it is to fix it.

When you build anything, identify who is going to own it and be responsible for maintaining it moving forward. Create a rule that says if you can’t identify that person, it doesn’t get built.

Having a dedicated mobile team enablement function

Undoubtedly the most efficient organisations are those that have a team dedicated to mobile team enablement, ensuring it’s always a priority alongside day-to-day delivery work.

Having a dedicated team allows you to look at mobile enablement from a product mindset, running surveys across your developer base to identify pain points, identifying where it’s necessary to create longer-term efficiencies and coming up with solutions that benefit the organisation as a whole.

Additionally, having an individual responsible for enablement within every team creates a coordinated effort across verticals, ensuring the dedicated mobile enablement team is continually in touch with the developer experience within each team.

This structure of representatives from each team is also a good option when a dedicated team is not yet achievable, as it allows for coordination and focus on enablement across the business. For this approach to work, the representatives from each team need to meet regularly and be empowered to drive enablement efforts within their team.

Setting enablement KPIs

It’s easy to overlook operational elements that are less visible, therefore you need to measure your mobile team enablement efforts in a way that makes them tangible.

Some operational elements are easier than others to surface and measure, for example, CI metrics and delivery are a widely discussed topic and a few solid examples have emerged including DORA metrics or Circle CI’s take on 4 metrics for CI/CD.

For the most part, what you measure will depend on the structure of your organisation, therefore it’s best to start by looking at your team’s processes and feedback from beginning to end and identifying what can be observed and measured. For example, if you notice feature tickets are often ping-ponged between teams, look at how often this happens and ask how you can reduce it.

Involving your team in the process

Your mobile enablement efforts are for your team, so they need to be involved in the process. Top-down management won’t work, you need to talk to your teams and be guided by their needs and insight.

Regularly ask your mobile developers what their average day is like, how they go about specific tasks, and what frustrates them. You’ll likely notice trends in what people struggle with and where people are manually performing habitual tasks which could easily be automated.

While dedicated mobile team enablement might not feel critical when you have eight people, it will certainly feel critical when you have thirty.

No matter the size of your organisation, mobile team enablement must be a key focus if you have any intention of scaling efficiently and profitably. The sooner it becomes embedded into your processes, and you start evaluating and improving your efforts, the easier it will be to maintain efficiency as you grow.

‍