You're here if your mobile team has 50 or more engineers and ships every two weeks.
Compared with all teams, EMs here report more slips and bigger releases. 46% say most releases miss the date, against 34% across all teams, and 90% say 21 or more people have to act on each release, against 77%.
98% of EMs spend three or more hours per cycle on status updates
85% of EMs can't see release status in one place
90% of EMs say 21 or more people are required to act on each release
46% of EMs say most of their releases miss the planned date
76% of engineers lose six or more hours per release to low-value work
100% of engineers see an incident that delays features or forces a hotfix at least once every three to five releases
Engineer figures here come from a small group of respondents, so read them as directional rather than precise. They aren't shown against the range across segments. How the figures are counted.
EMs and engineers both lose time to each release here, and both name coordination as their top frustration. More than half of EMs spend six or more hours a cycle on updates, and three in four engineers lose six or more hours per release to non-productive work. Incidents add to it, with 29% of engineers seeing one every other release, triple the rate across all teams. Half of EMs say 31 or more people act on each release, and keeping that many people in step every two weeks is the work both groups are describing.
98% of EMs spend three or more hours per cycle updating others on the release, and 56% spend six or more. Over a year of biweekly releases, that is three to four working weeks per EM.
When an engineer acts as release manager, most EMs (63%) expect them to get through less than half of their planned sprint work.
76% of engineers spend six or more hours per release on non-productive work.
29% of engineers see a release incident every other release, triple the 9% across all teams. 82% believe a centralized process would have prevented most of them.
Release coordination overhead for EMs (63%), coordination with other teams for engineers (53%). EMs then point at tooling and CI reliability (59%); engineers at manual steps (53%).
With 31 or more people on a release, 60% of EMs say most releases miss the date, against 46% across the segment, and 80% say busywork takes half or more of engineer time. Only 15% of EMs can see release status in one place, so the EM keeps each of those people up to date by hand.
90% of EMs say 21 or more people are required to act before a release ships, and 49% say 31 or more.
Among EMs with 31 or more people on a release, 60% say most releases miss the date, against 46% across the segment.
With 31 or more people on a release, 80% of EMs say busywork takes up half or more of engineer time, against 66% across the segment.
Only 15% of EMs can see release status in one place. 59% piece it together from tools and conversations with the team.
76% of EMs call the issue tracker their primary source of truth for release status. 10% use a release-specific tool.
66% of teams own five or more apps, each with its own release.
88% of teams require an approval or validation gate on AI-touched code before it ships.
37% of these teams run a fixed release train, and 93% of those EMs call releases a significant or top frustration.
78% of EMs say a new engineer needs five or more months to run a release confidently, and only 12% are very confident any engineer could run one end to end.
Releases fall to a dedicated release or platform team in 44% of teams and to senior engineers in 32%. 15% rotate them among engineers and 10% have the EM run them.
Slipping timelines are the reason EMs hear most when leadership loses confidence (46%). Engineers name the release process itself as their biggest risk to scaling (47%), and EMs list pressure to ship more often as their top risk ahead, on a process that already slips at two-week intervals.
“We've automated our releases.”
76% of engineers describe their release automation as moderate or significant, and 65% have custom-built release tooling. But 69% of them still spend six or more hours per release on non-productive work, and 38% see a release incident every other release.
“We've invested in testing.”
90% of EMs rate their investment in automated testing and QA as moderate or higher. 86% of those EMs still call the release process a significant or top frustration, and 44% name testing maturity a top three risk anyway.
“We run a fixed release train.”
37% of teams do. 93% of those EMs call releases a significant or top frustration, against 88% across the segment.
“We keep track in Jira and Slack.”
82% of engineers say their team has no tool that centralizes release coordination. What they use instead is the project management tool (82%) and custom internal tools (59%), neither built for running a release. 53% say their team would benefit from centralizing it. 76% of EMs run status out of the issue tracker.
80% of EMs are likely to invest in improving their release process or tooling in the next year. 76% expect it to accelerate the roadmap.
EMs name engineering capacity (29%) and production issues and unplanned work (20%) as what most limits delivery. 17% name release overhead, even though most of them expect an engineer running the release to lose half a sprint to it.
Of the EMs who answered which option they would try first to improve their release process, 38% would try to improve their internal release process (standardize, document, clarify ownership) before buying or building any tooling; all of them call releases a significant or top frustration. Hiring more people for the role is the next option (33%), then evaluating a third-party platform (17%) and building (12%).
93% say their release cadence is about right.
These teams have dedicated release teams, approval gates on AI-touched code and widespread automation. However, 46% of EMs say most releases miss the date, and leadership notices, since slipping timelines are the reason EMs hear most when confidence drops. 98% of EMs spend three or more hours a cycle on updates, only 15% can see status in one place, and engineers name the release process as their biggest risk to scaling (47%). Teams have tried to throw automation and custom tooling at this, and it hasn't solved the coordination. With 88% already gating AI-touched code, more AI-written code means more reviews to coordinate on a release that already slips. EMs would start with process changes or more headcount. To work, either would have to give everyone one place to see the release, or a new hire inherits the status load as it stands.
A 30-minute walkthrough for large teams on biweekly releases: status in one place, release pilots and rollouts.
All six segments in one report, ready to pass along to your team.
