You're here if your mobile team has 50 or more engineers and ships about once a month.
Engineers here lose less time than the all-teams figure (25% lose six or more hours per release, against 37%), while no EM can see release status in one place and 70% say most releases miss the date, double the rate across all teams.
100% of EMs spend three or more hours per cycle on status updates
100% of EMs can't see release status in one place
50% of EMs say 31 or more people are required to act on each release
70% of EMs say most of their releases miss the planned date
25% of engineers lose six or more hours per release to low-value work
71% of engineers see an incident that delays features or forces a hotfix at least once every three to five releases
Engineering manager figures here come from a small group of respondents, so read them as directional rather than precise. How the figures are counted.
Twelve releases a year keep the yearly status work lower than on faster cadences, but each release is heavy. Most EMs spend six or more hours on updates per release and say busywork takes half or more of engineer time while it runs. EMs experience that as coordination overhead, and engineers as manual steps.
Every EM spends three or more hours per cycle updating others on the release, and 60% spend six or more. Twelve releases a year keeps that to one or two working weeks per EM.
60% of EMs say busywork takes up half or more of engineer time during releases.
62% of engineers say one in every three to five releases causes an incident that delays features or forces a hotfix.
EMs point first at release coordination overhead (70%) and tooling and CI reliability (60%); engineers point first at manual steps (54%) and lack of automation for repetitive tasks (48%).
Every EM says 21 or more people have to act on each release, and half say 31 or more. With no single view of status, EMs piece it together from tools and conversations. Releases come round once a month and usually fall to the same few people, so few others get the practice. Only 10% of EMs are very confident any engineer could run a release end to end, and 80% say a new engineer needs five or more months to learn.
Every EM says 21 or more people are required to act before a release ships, and half say 31 or more.
None of the EMs can see release status in one place. 60% piece it together from tools and conversations with the team.
70% of EMs call the issue tracker their primary source of truth for release status. 10% use a release-specific tool.
66% of engineers use a project management tool to run releases, 59% use a custom internal tool and 54% use CI/CD with tracking.
60% of teams own five or more apps, each with its own release.
80% of teams require an approval or validation gate on AI-touched code before it ships.
80% of EMs say a new engineer needs five or more months to run a release confidently, and only 10% are very confident any engineer could run one end to end.
Releases fall to a dedicated release or platform team in 50% of teams and to the EM in 30%. 20% leave them to senior engineers.
80% of EMs say their organization sees mobile as higher risk than web or backend, and slipping timelines are what they hear about when leadership loses confidence (60%). EMs rank release process reliability as a top risk ahead, level with codebase maintainability at 70%. Engineers rank it below testing and budget.
“We've automated our releases.”
96% of engineers describe their release automation as moderate or significant, and 55% have custom-built release tooling. But 70% of them see an incident at least once every three to five releases, and 26% still spend six or more hours per release on non-productive work.
“We've invested in testing.”
Every EM rates their testing investment as moderate or high, and 80% call the release process a significant or top frustration anyway.
“We'll build it ourselves.”
Of the EMs who answered which option they would try first to improve their release process, two thirds would build an internal tool. Among engineers on teams this size and cadence, 59% already run one, and 70% of those see an incident at least once every three to five releases and 27% still lose six or more hours per release to non-productive work, the same as teams without one. The new tool would sit on an issue tracker that 70% of EMs use as the source of truth.
“We keep track in Jira and Slack.”
88% of engineers say their team has no tool that centralizes release coordination. What they use instead is the project management tool (66%), custom internal tools (59%) and CI tracking (54%), none of them built for running a release. 55% say their team would benefit from centralizing it.
80% of EMs are likely to invest in improving their release process or tooling in the next year. All expect it to accelerate the roadmap, 70% significantly.
EMs name waiting on other teams (40%) and scope changes (40%) as what most limits delivery. None names release overhead.
Of the EMs who answered which option they would try first to improve their release process, two thirds would build an internal tool and one third would try to improve their internal release process (standardize, document, clarify ownership). None chose a third-party platform.
80% say their release cadence is about right.
Engineers here describe release automation in good shape, with 96% calling theirs moderate or significant. However, EMs describe a different release, with 70% saying most releases miss the date and none able to see status in one place. Every EM spends three or more hours a cycle on updates, half say 31 or more people act on each release, and 80% say their org sees mobile as higher risk than web or backend. Teams have tried to throw automation and custom tools at this, and it hasn't solved the coordination. AI-written code adds to the review queue, and 80% of teams already gate it before it ships. Two thirds of EMs would build an internal tool first, which fits orgs this size, where security reviews, compliance and approval gates often push teams to build in-house. To work, that tool would have to cover the coordination their automation doesn't reach.
A 30-minute walkthrough for large teams on monthly releases: status in one place, release pilots and rollouts.
All six segments in one report, ready to pass along to your team.
