App releases can quickly become a bottleneck in scaling mobile organizations. A mobile team has to keep up with the increased pace of new features, additional app complexity, and growing headcount, all while still getting regular updates out to users. The release process, already a high-risk part of the mobile development lifecycle, comes under ever-increasing pressure as more projects and people are involved.
To help mitigate the building pressure around releases, many mobile teams adopt a release rotation model with alternating release managers or captains. This approach allows teams to share the burden of release responsibility, reducing pressure and cognitive load on a single release manager while also alleviating concerns around having a single point of failure.
Without a sound strategy in place, however, the rotation model can actually lead to new issues of its own making. Morale and overall productivity can be negatively impacted, especially as a team scales, and all too often the release captain role becomes a dreaded experience for team members anticipating their next turn.
Here at Runway, we’ve been working closely with many high-performing mobile teams who manage their app releases by using the rotation model efficiently and effectively. In this blog post, we’ll share learnings based on in-depth discussions with these teams, including common pain points to watch out for and suggestions for how to empower anyone on your team to confidently lead a release.
The mobile release rotation model: common pitfalls
Before exploring ways to improve your existing release rotation, it can be helpful to take a step back and consider the ways it might be letting your team down. To that end, the following are aspects of the mobile release rotation model that can lead to inefficiencies and bottlenecks, especially as a team scales.
1. Knowledge transfer takes time and focus away from productive work – and disproportionately affects senior team members
Knowledge transfer is vital for teams that use the rotation model – new folks need to learn how to run releases, and any process adjustments and updates also tend to pass from one release captain to the next. Although it’s an important part of the process, it’s also not work that directly adds business value or improves the product; it’s a negative “cost of doing business”.
What’s more, the responsibility for facilitating and actually participating in this knowledge transfer very often falls on senior members of the team who are most familiar with the process. Those are the folks who are already stretched to their limit on most teams, and the additional workload and pressure lead to wide-ranging negative consequences. Perhaps most insidiously, devoting bandwidth to what are often quite mundane and repetitive activities around knowledge transfer can be detrimental to morale.
2. The preparation needed to run a release can be intimidating – and lack of preparation adds risk
It takes a lot for a release manager to not only learn how to run a release but also to prepare for the responsibility it entails. They need to be intimately familiar with the ins and outs of the process, knowing what to keep in mind during rollouts, where to find important release documents, and how to keep the rest of the team in sync.
Even for more experienced team members, it’s not safe to assume you can lean on previous experience running releases. As the team grows, each individual takes on the release manager role less frequently. There’s a good chance that before they next lead a release, there will have been changes to the process, and perhaps even in the tooling. With less-than-prepared release managers, releases can become delayed and the risk of shipping unhealthy work is much higher.
3. Without continuity in ownership, it’s difficult to maintain and improve the release process
One of the big pros of the rotation model, the distribution of release responsibilities across the team, is also one of its cons. A release process needs constant maintenance and up-to-date documentation as things change and a team scales, but with release managers rotating through the role, there’s often no one who really owns that macro-level oversight and upkeep. Release captains may surface issues and suggest improvements while they’re on duty, but it’s hard for the team to actually act when they’re in the middle of a release crunch. Then, the release captain changes over and all is forgotten. With ownership and accountability for releases always moving around the team, it can be hard to maintain and improve the overall release practice.
4. Context-switching is especially taxing on rotating release managers
Context-switching is a “silent killer” across the entire team, wasting hours of valuable time in a steady drip, but it’s especially costly for rotating release managers. Because they’re often splitting their time between release tasks and normal work, a release captain will have to change gears dramatically, and often, while they’re on duty. And, because rotating release managers are less instinctively familiar with the process (compared to a dedicated release manager, who might be able to run releases on mental autopilot), they lose much more time jumping back and forth between different tools, digging into docs, and pinging others for help.
How to make the mobile release rotation model work for the entire team
The potential pitfalls that come with the release rotation model aren’t a foregone conclusion! You can mitigate or entirely avoid them by sticking to certain best practices which improve collaboration, decrease risk, and help you make the most of your release rotation.
1. Give rotating release managers ample time and resources to prepare
To combat the stress and risk that come with the lack of preparation, teams need to build it into the very architecture of their release process and rotation. That starts with giving upcoming release managers advanced notice, well before they’re on duty: rather than appointing team members in an ad-hoc or just-in-time way, there needs to be a formal schedule in place. This “rotation calendar” should be filled out months in advance and shared transparently across the team; swapping shifts should be made easy but very well tracked, to avoid any surprises.
Even with a solid rotation calendar in place, which gives the team a clear and predictable sense of timing manager-to-manager, resources and time need to be carved out for each release manager to actually prepare as their turn rolls around. Consideration should be given as “normal” work is assigned during sprint planning and the outgoing release manager should make themselves available to the incoming manager to sync on any callouts or tips that will help them prepare.
2. Automate release coordination and management
Most teams have figured out how to automate bits and pieces of releases on a tooling level, but the broader release process itself – and much of the coordination and people management involved – can also be automated. For example, while automation in CI/CD is an important piece of the puzzle, zooming out reveals a complex release lifecycle that calls for more holistic automation. Managing sign-offs and approvals, communicating status updates to the wider team, and shepherding interdependent and queued tasks, are all duties that are handled by release managers but don’t have to be.
By automating away more of the coordination and “macro work” on a release manager’s plate, you save them from frustrating cat-herding and free up mental bandwidth. As a result, there’s less human error and the rotating release manager role isn’t such a dreaded experience.
3. Establish a single source of truth to minimize context-switching – and make knowledge transfer easier
To combat the impact of context-switching, especially for rotating release managers, create a single source of truth by bringing the team’s entire toolchain together into a centralized dashboard. With all critical information and context in one place instead of many, release managers won’t have to bounce all over the place to do their job.
Ideally, this single source of truth should also be designed to act as a knowledge base. By codifying the team’s practices in a formal and centralized way, you’ll help new team members onboard, make preparing for the next release much easier, and facilitate knowledge transfer from release to release. These benefits extend beyond release managers to the entire interdisciplinary team and the wider org.
4. Craft a release checklist that is comprehensive, accessible, and up to date
Release checklists, or runbooks, should be considered, comprehensive, and easy to use. No task or step is too obvious to include, and no detail too mundane to spell out. By covering every base, and doing so clearly, you both lower the risk of mistakes and reduce overhead for release managers running the process. There’s a reason why checklists are so widely used in fields like aviation and medicine!
In addition to containing clear descriptions of responsibilities, timing info and deadlines, dependencies, and other critical info, each checklist item needs some ownership assigned. Maybe the owner is the release manager on duty, maybe it’s another stakeholder who gets looped in. Whatever the case, if no owner is explicitly assigned to a task, the bystander effect can take hold: every team member assumes someone else will take care of the task, and then no one takes care of it.
It’s easy for checklists to become relics – out-of-date and hidden away. The whole team needs to go the extra mile to keep checklists updated, incorporating feedback from one release to the next. And checklists should live somewhere readily accessible to the entire team. Ideally, that means it’s integrated into the centralized dashboard the team is already using as its single source of truth (see above)!
5. Foster empathy for the release manager role
When the release manager role is well understood and appreciated by the wider team, everything gets easier. It’s not always obvious to everyone – and it’s easy to forget – that running a release can be a very demanding job, and lack of empathy from teammates can compound the stress on-call release captains are already feeling. With a team that’s tuned in to the release manager function, not only does each release run better, but there’s more collective commitment to maintaining and improving the release process itself.
There are some subtle but effective ways to foster this empathy. For example, find ways to remind the team who’s currently in the hot seat, throughout each release, and celebrate that person with kudos or other little rituals. It also helps to make the extra workload the release captain is under very tangible and visible. You could do this by adding a placeholder ticket in your project management tool, assigned to the release captain and with story points or some other scope attached.
Make the most of the mobile release rotation model
If you’re not careful, the mobile release rotation model – which promises de-risked and de-stressed releases – can actually lead to increased workload and risk. Demands around knowledge transfer and preparation, a lack of continuity in ownership of the release process, and constant context-switching for release managers rotating through the role all jeopardize a team’s ability to ship their app consistently and confidently.
In order to avoid the potential pitfalls and make the most of your release rotation, there are some best practices to follow. First and foremost, take measures to reduce the pressure on release managers when they’re rotating through the role: set aside ample time and resources for them to prepare, think beyond CI/CD to automate away as much of the coordination and cat-herding as possible, and build empathy for the release manager role across the team.
Another effective way to improve your release rotations is to improve the way the process itself is captured and maintained. Effective use of release checklists goes a long way here: not only do checklists reduce risk within each release by ensuring they’re run correctly, but they also become artifacts the team can collaborate on release to release. By updating checklists based on learnings from each turn of the rotation, the team can iterate on the overall process. More broadly, creating a single source of truth around releases can have a huge impact. A shared dashboard connecting all the tools and stakeholders involved reduces context-switching and cognitive load on release managers, and it helps make the entire process more transparent to the wider team.
