Mobile infrastructure needs to be more than an afterthought for your org

Building and shipping an iOS or Android app can be more complex and involved than other types of software, but mobile teams don’t usually receive the kind of critical support around core platform, distribution and release infrastructure that other platforms do. Maybe it’s because phones are small and it seems like they can’t possibly be all that complicated (how much code can you fit in there anyway?), but mobile infrastructure and tooling is way too often an afterthought, even in organizations where mobile apps drive a significant portion of the business.

While some larger, mature orgs have come to recognize the need for dedicated mobile infrastructure support at the build tooling level, and have even formed mobile platform teams to meet this need, support for distribution and release infrastructure isn’t always in their scope of influence. Too often, improving distribution and release tooling is something that teams can just get to later and instead they end up wasting valuable hours in every release cycle bridging the gaps in whatever unnecessarily complex Rube Goldberg release machine they built.

When it comes to developing, improving, and maintaining tooling to help manage app distribution and releases, mobile teams are more or less left on their own.

Mobile engineers are forced to become their own infrastructure

This is not a good thing. Not because mobile engineers aren’t any good at it; actually, when forced to spend enough time dealing with it many engineers naturally become fairly skilled at it.

But they shouldn’t have to be good at it. Because they’re not infrastructure engineers, they’re mobile engineers (it’s right in their title). It's a waste of time and resources to make mobile engineers fully responsible for their own infrastructure.

Asking a mobile engineer to build out their own deployment infrastructure is sort of like asking infrastructure engineers to build your iOS and Android apps. They could maybe muddle through and learn to build something bad in quintuple the time it would normally take, but no one would consider that acceptable and it’d be ridiculous to even suggest it.  

And yet the reverse is not only suggested, but practically required. Mobile engineers (with some lucky exceptions, like those who use Runway) spend an enormous amount of time down in the weeds, building their own systems, writing fastlane scripts (in Ruby!!) and continually tinkering with process. Work that someone might do as a hobby for a personal project is instead relied upon by large orgs to achieve critical business goals.

It’s not just the technical infrastructure. Mobile engineers end up doing a lot of bookkeeping and checklist writing that non-mobile engineers don’t have to deal with either because of their relatively simpler release processes or because all that work has been mostly automated away by tooling they’ve been given the priority to implement.

But mobile engineers often just accept that they need to do this because:

The mobile perspective is rarely taken into account

Mobile is rarely considered at any time other than after the fact. The organization sets out to do this thing or that thing and the mobile team is left to figure out how to translate that goal to mobile. No one worries about it unless the app starts crashing or work isn’t shipping on time. It’s difficult to change this kind of status quo.

Part of this problem is perhaps that both engineering leadership and broader company leadership often have no direct experience with mobile. For many such leaders, every mobile engineer is a magical mobile whisperer who can build and fix these ‘apps’ on these ‘devices’ that they themselves don’t really understand.  

Having no experience with mobile can cause leadership to have both increased and decreased expectations. Org leadership may have increased expectations insofar as they believe their mobile team can take care of anything mobile related that they ask of them (how hard can it be?) and decreased expectations insofar as they don’t see the need to prioritize investments for a part of the org they don’t have any real experience in (how hard can it be?).  

Within most orgs, the customers’ needs are considered and rightly come first. Other engineering platforms’ needs are considered. The needs of sales and customer success are considered. But mobile engineering is often the ugly stepchild, a resource that is expected to be self-sufficient and turn anything thrown at them into a swipeable, tappable experience that arrives on everyone’s phones in a timely manner.

Yet, as companies mature, pressure will often grow to the point that they’ll have to recognize that mobile needs more help. This most often comes in the form of growing the team with dedicated mobile infrastructure engineers. More hands on deck is obviously good for getting things done and building new features, but:

Devoting more people to in-house tooling helps, but creates other problems

Infrastructure engineers can be brought in to take on all this responsibility and start building out processes and automations that make the mobile engineers’ lives easier. Seems like an easy solution to the problem and we can probably just end the article right here.

But there’s a problem: removing all responsibility for releases from your mobile engineering team  dumps the entire release process (that they heavily rely upon to do their jobs) into a ‘black box’ they have no real view into. This becomes especially problematic as more and more automations are built, creating an intricate web of dependencies understood only by the small number of people who built the web. This won’t seem like a big deal to the infrastructure engineers, as their familiarity and dedicated attention makes digging down and getting in the weeds to diagnose an issue or add functionality relatively easy. But for everyone else who is affected by the release process in their day to day, stuffing everything away into the black box can make life difficult.

Building the infrastructure can also become an inward-looking exercise for the infrastructure engineers. They may build processes that feel familiar and comfortable to them — based on their own past experience — but that have been arrived at randomly or are completely divergent from current industry best practices. What to them is simple and straightforward can appear to outside observers to be a Rube Goldberg machine of a process that’s full of extraneous moving parts whose actual purpose isn’t easily understood.

Even if all the scripts and automations run without a single hitch, and even if the process that’s created runs relatively smoothly and is easy to understand, the more people who are involved in the moving parts of a release the more there needs to be quick and accurate communication between all those people. The mechanisms of a release turn into a game of telephone, or more accurately, a game of constantly pinging Slack channels and scheduled Zoom calls.    

Human organizational problems are often understated and their costs treated as a given. ‘That’s just how things are done’ ends up being a guiding principle.  

How can this be changed?

Replace human infrastructure with real infrastructure

Many mobile engineers have simply accepted their fate. They’re used to doing a lot of manual grunt work supporting releases that other engineers working on other platforms don’t have to do. But they shouldn’t have to accept it, and the org should be thinking far enough ahead that mobile engineers aren’t forced into a subpar situation just because ‘this is how things are done’.

First, you have to give real thought to the human cost of building everything manually. Not just in time spent working on your CI/CD pipeline or managing scripts, but also in time no longer spent on building features and providing more value to customers. How many hours a week are mobile engineers spending on the administrative work of just getting new releases into the App Store and Play Store? How many hours is that in a year and how many other features or updates could have shipped without this commitment?

Organizationally, this means never treating mobile like a magic box that you put people into and then get an app out of. Like any other part of the org, mobile engineering has needs that require some level of prioritization from the company.

Pause and plan before adding complexity. Each automation you build and each point added to the release checklist can create short term gain and long term pain. Set out the ideal state for releases and work towards that state, versus just doing what has to be done to get through the present release and then doing what needs to be done for the upcoming release continually onward over time. Your mobile engineers need time to think about and plan your release process (and just to breathe), and the more this is considered up front will mean less time wasted down the line.  

Give mobile engineers the opportunity to think beyond how they’ve done things in the past. As noted, they’re used to handling all of this themselves and have often accepted this as just the cost of doing their job. Challenge them, challenge your team, and challenge yourself to find a better way of doing things. An engineer working five hours late every other Monday to ensure your release actually goes out on time shouldn’t be seen as just a sign that this engineer is a hard working employee but also as a sign that your release infrastructure is broken.

Don’t let mobile releases to be a silent killer for your team. See why Mobile DevOps matters and how to adopt it for your own team.