Releases aren’t perfect. They could be better, they should be better, but that’s true of every single aspect of software development. You can’t focus on achieving perfection on all sides at all times — there have to be priorities. There’s code to write, features to build, and bugs to fix. The status quo for releases is good enough as it is.
Sure, some engineers may dread their turn managing a release (if they even have to manage releases), but that doesn’t mean that mobile releases are broken. Anyone who would say that, even on our own blog, is engaging in hyperbole. If the release process was broken, would the App Store and Play Store both be as overstuffed as they are with apps? Of course not. If it was that bad, only the richest companies would even bother.
Releases are fine. The process can be convoluted and slow — and maybe it takes too much time and is an annoyance for the engineers who have to focus their attention on it — but that’s just work. Work isn’t always supposed to be fun. Just because a process isn’t perfect doesn’t mean it’s broken.
That’s good enough, right?
Of course it is, you have a dedicated release manager
Your engineers don’t have to dread their turn managing a release because you have a dedicated release manager who takes care of it. Most of the team can focus on building features, and your dedicated release manager focuses on getting your app into the App Store and Play Store. It’s part of their actual job description and they have plenty of time assigned to them to do the task. No one seems unhappy.
Is that good enough? It very well could be.
Isn’t it ok for engineering work to be segmented and siloed?
A mobile engineer sends a Jira ticket to QA when a release candidate is ready for regression testing. QA sends a ticket to the mobile engineer when they’re done. The mobile engineer sends a ticket to the release manager asking them to kick off the release. The release manager sends a ticket requesting screenshots to marketing. Marketing puts the screenshots in the ticket. The release manager copies the screenshots from the ticket to App Store Connect or the Play Console. The release manager… you get the idea. In my experience, people love sending and receiving Jira tickets and quickly take action on them when they see them. I’m sure that experience is universal.
Isn’t it fine for releases to exist in a black box?
Having a dedicated release manager means no one else is thinking about releases. This release manager (or maybe even release team) creates a bespoke process for managing releases which plays to their own preferences, skills, and idiosyncrasies. A good release manager will probably write detailed documentation laying out everything they’ve built and the specifics of what they’re doing, but unless your engineers have a hobby of being bored they’re very unlikely to read it (unless something unexpected happens, but what are the chances of that?).
Are there inefficiencies in how release managers do things? Do they actually need as much time to manage releases as you’re paying them for? Does their work fit into the larger context of how your engineering team does things? Maybe. Nobody really knows except them, and that’s probably fine.
What about when the release manager gets another job or just goes on vacation?
Maybe they did write very detailed docs and wrote them in a clear, engaging manner that any engineer can follow. This will make it easy when someone else is (or many someones are) going to have to pick up the slack and their own work is going to be slowed down as they try to figure out how the release manager does this.
Is it possible they didn’t actually write detailed enough documentation to be followed by other engineers who haven’t thought about your releases in months or years? Probably not.
Of course it is, you have a release manager rotation
Maybe you don’t have a dedicated release manager, but instead your software engineers share the load. Everyone contributes, the work is done in the open, and no one has to focus all or even much of their time on releases. You have documentation and checklists written up in Confluence (or maybe Notion) that every mobile engineer follows when their turn comes up and scripts they can run to handle some of the more manual tasks.
Is that good enough? Could be.
Isn’t the load equally shared?
To be run well, mobile releases require detailed documentation that lays out the steps that need to be taken, the people and teams who need to be kept looped in, which scripts that need to be run and when they need to be run, who should be contacted if they break, who to contact if that person isn’t available, what to do in the case of App Store rejection, how to monitor application health during the rollout, what to do if there’s a problem… you get the idea. Probably every engineer in your org knows to keep this documentation fully up-to-date and writes new stuff as needed on their own.
Everyone could be doing this, or… maybe it's best to have a couple of people with a real knack for this stuff being pulled into almost every release to help out? Regardless, you know what they say: too many cooks make an excellent broth.
Aren’t engineers being given plenty of time to manage the release and their usual work?
Story points need to be assigned to the release process (if you even use them), something that can either go very smoothly and be done in a few hours or very regularly be full of problems and take ten hours. You’re likely assigning enough points, and even if you’re not, engineers know if they take on more work this week that they’ll get an equal opportunity to do less work the next week. Or something like that, I’m sure.
Undoubtedly each release manager is equally good at ensuring the other engineers are submitting their work on time, documenting issues and updates for post-release retros, and planning how to better run the release next time. It probably doesn’t end up being tackled by a couple of people who care the most about it and have a knack for it, who end up putting in time that doesn’t really get counted.
How do engineers prepare for their turn in the rotation?
If your engineering team has 10 people, their turn probably only comes up 2 or 3 times a year, which means they don’t have to put too much of their time into releases. That seems good! You likely assign them enough story points to take care of that work and to also take the time to prepare to tackle something they’ve likely forgotten how to do in the four months since the last time they’ve done it. Besides, your documentation is so thorough and easy to read that any engineer can go through it without issue.
They never make mistakes that slow down the process or waste valuable engineering time. And everyone is equally as committed to running releases, so every release is smooth sailing — no matter who is running it. I feel like this could be the truest thing I’ve ever written.
Of course it is, you’ve automated a lot of it away
You’ve created fastlane scripts and tons of other automations for both the App Store and the Play Store that handle a lot of the manual work engineers previously had to manually do. Mundane tasks are mostly gone and engineers only focus on the big tasks. You’ve created a whole connected machine that gets your new releases out with a barely noticeable bump or two.
Isn’t that good enough? Sure, I reckon it is.
Who builds the automations? We have a guy for that
Just like the documentation, someone had to build and implement your initial automations. This isn’t just a one-off thing, though, and based on the fact that you’ve tackled this work there’s likely someone on your team who builds new automations as the originals become old and incompatible. They optimize this process as new scripts and automations are added in to ensure things don’t fall apart when an inexperienced release manager is running through their well written, properly maintained checklist.
Scripts have been known to fail, sure. Automations have been known to not just work automatically, absolutely. But the above person loves tackling this stuff.
Set it and forget it (until you need to reset it)?
Automation isn’t a magical solution to every problem. Doing something one way may work for six months, but software moves fast, and someone needs to continually question whether how you do things right now is the right approach later. No doubt, this is built into your process.
Overly automating your work is its own variation of the release manager black box, which means the automations are doing stuff that the people running them may or may not understand. That’s fine because they pretty much always work and, when they don’t, the person who built them is definitely on hand to fix them and is incredibly happy to do so. This would never not be the case.
Isn’t good enough, good enough?
Your app is shipping. Customers use it. Everything’s fine.
Interest rates are at zero. VC money is flowing. There’s no need to be efficient since you can power the engine of business by burning time and money. Just throw more engineering time at a problem until it’s no longer a problem.
Well, wait a second — something sounds off about that second paragraph. It’s as if it’s not as of right now the year 2019 (which I certainly don’t believe, I just started watching the first season of the Mandalorian) and efficiently focusing your engineering resources on features that will drive usage of your product is key to success in a tighter market.
The status quo is the status quo for a reason. It works fine. Having a dedicated release manager or a well run rotation or automated processes you’ve built internally are fine. Lots of perfectly fine teams manage things by:
- Spending time and engineering resources long term on process instead of features
- Relying on what could be a fragile Rube Goldberg machine to always get new releases out the door
- Putting extra stress on your engineers to manage ever-changing bespoke systems
- Maximizing context switching for some or all members of your engineering team
Mobile apps only drive an [insert here] percentage of your revenue, so this is probably good enough.
