You're here if your mobile team has 50 or more engineers and ships weekly.
Large weekly teams have better visibility than the all-teams figure, with a third of EMs able to see release status in one place against 13% overall. They also put more people on each release, with 97% saying 21 or more have to act. Dates and incidents land close to the all-teams figures.
90% of EMs spend three or more hours per cycle on status updates
67% of EMs can't see release status in one place
97% of EMs say 21 or more people are required to act on each release
33% of EMs say most of their releases miss the planned date
30% of engineers lose six or more hours per release to low-value work
90% 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.
60% of EMs spend six or more hours a cycle updating others on the release, which adds up to more than seven working weeks a year at a weekly cadence. Asked for their biggest release frustrations, EMs name coordination overhead (60%) and waiting on other teams (57%), and engineers name manual steps (80%). Coordination with other teams is on both lists.
60% of EMs spend six or more hours per cycle updating others on the release, and 90% spend three or more. At roughly 50 releases a year, six hours a cycle adds up to more than seven working weeks per EM.
47% of EMs say busywork takes up half or more of engineer time during releases.
80% of engineers say one in every three to five releases causes an incident that delays features or forces a hotfix, and 10% say every other release does. 70% believe a centralized process would have prevented most of them.
Asked for their biggest release frustrations, EMs name release coordination overhead (60%) and waiting on other teams (57%), and engineers name manual steps (80%). Coordination with other teams is on both lists, at 60% and 50%.
97% of EMs say 21 or more people have to act on each release, and 53% say 31 or more. Half of EMs can find release status without asking anyone, yet 90% still spend three or more hours a cycle sending updates to everyone else on the release. A release tool or a release team helps the EM find the status. Keeping 30 or more people informed every week is still manual work.
97% of EMs say 21 or more people are required to act before a release ships, and 53% say 31 or more.
33% of EMs can see release status in one place, and 50% can usually find it without asking anyone. 90% still spend three or more hours a cycle reporting it.
33% of EMs call a release-specific tool their primary source of truth for release status. 47% use the issue tracker.
73% of teams own five or more apps, each with its own release.
87% of teams require an approval or validation gate on AI-touched code before it ships.
77% of these teams run a fixed release train.
63% of EMs say a new engineer needs five or more months to run a release confidently, and 27% say nine or more. 20% are very confident any engineer could run one end to end.
Releases fall to a dedicated release or platform team in 67% of teams and to senior engineers in 17%. 13% rotate them among engineers.
Quality is what EMs worry about most on each release (77%), followed by whether they can roll back a bad release (70%) and the approval gates it has to pass (67%). Over the next 12 to 18 months, the risk they name first is pressure to ship more often (53%). These teams already release every week, and each release costs most EMs six or more hours of updates, so shipping more often would add to that load unless the coordination changes. Engineers name limited engineering resources as their biggest risk to scaling (50%).
“We've automated our releases.”
80% of engineers describe their release automation as moderate or significant. But 90% see an incident at least once every three to five releases, and 70% still run part of the release out of spreadsheets or docs, which is where the automation stops.
“We've invested in testing.”
73% of EMs rate their investment in automated testing and QA as moderate or high. 77% of those EMs call the release process a significant frustration, against 62% of EMs who rate it low.
“We've got a release tool.”
33% of EMs point to a release-specific tool as their source of truth for release status, about double the rate across all teams, and 33% can see status in one place. But 90% still spend three or more hours a cycle on updates, and 60% spend six or more.
67% of EMs are likely to invest in improving their release process or tooling in the next year. 63% expect it to accelerate the roadmap.
EMs name waiting on other teams (37%) and engineering capacity (20%) as what most limits delivery.
Of the EMs who answered which option they would try first to improve their release process, 75% would evaluate a third-party platform, against 24% across all teams. A third already run release status from a release-specific tool.
80% say their release cadence is about right.
Two thirds of these teams have a dedicated release team, and a third run release status from a release-specific tool. However, more than half of EMs say 31 or more people act on each release, and at a weekly pace keeping all of them informed still falls to the EM. 60% of EMs spend six or more hours a cycle on updates, and 73% call the release process a significant frustration. A release team and a release tool have not taken that work off the EM. AI-written code will add to it, since 87% of teams already gate AI-touched code before it ships. EMs also expect pressure to ship even more often. Any change here has to take the status updates off the EM, or a faster cadence will only multiply the hours.
A 30-minute walkthrough for large teams on weekly releases: status in one place, release pilots and rollouts.
All six segments in one report, ready to pass along to your team.
