You're here if your mobile team has 10 to 49 engineers and ships every two weeks.
Small biweekly teams track the all-teams figures closely, within a few points on most measures. The exception is engineer time, with 45% of engineers losing six or more hours per release to low-value work, against 37% across all teams. EMs carry their share as well, with 98% spending three or more hours a cycle on status updates.
98% of EMs spend three or more hours per cycle on status updates
90% of EMs can't see release status in one place
77% of EMs say 21 or more people are required to act on each release
31% of EMs say most of their releases miss the planned date
45% of engineers lose six or more hours per release to low-value work
84% of engineers see an incident that delays features or forces a hotfix at least once every three to five releases
Every two weeks, EMs spend three to five hours on updates, which adds up to two to four working weeks a year, and most expect an engineer on release duty to finish less than half their sprint. EMs blame tooling and CI reliability, engineers blame manual steps, and about half of each group names coordination with other teams.
98% of EMs spend three or more hours per cycle updating others on the release, and 20% spend six or more. Over a year of biweekly releases, that is two to four working weeks per EM.
When an engineer acts as release manager, most EMs (53%) expect them to get through less than half of their planned sprint work.
73% of engineers say one in every three to five releases causes an incident that delays features or forces a hotfix, and 11% say every other release does. 77% believe a centralized process would have prevented most of them.
EMs point first at tooling and CI reliability (68%); engineers point first at manual steps (54%). The one both name is coordination with other teams, at 54% and 49%.
Across the segment, 31% of EMs say most releases miss the date. Where 31 or more people have to act on a release, 62% do, and 71% of those EMs say busywork takes up half or more of engineer time. Most releases fall to senior engineers (54%) or the EM (21%), and only 3% of EMs are very confident any engineer could run a release end to end.
77% of EMs say 21 or more people are required to act before a release ships, and 18% say 31 or more.
Among EMs with 31 or more people on a release, 62% say most releases miss the date, double the 31% across the segment.
With 31 or more people on a release, 71% of EMs say busywork takes up half or more of engineer time, much higher than across the segment as a whole.
Only 10% of EMs can see release status in one place. 58% piece it together from tools and conversations with the team.
56% of EMs call the issue tracker their primary source of truth for release status. 19% use a release-specific tool.
68% of engineers use a project management tool to run releases and 61% use chat. 12% have a custom internal tool.
55% of teams own five or more apps, each with its own release.
74% of teams require an approval or validation gate on AI-touched code before it ships.
33% of these teams run a fixed release train, and 82% of those EMs call releases a significant or top frustration.
39% of EMs say a new engineer needs five or more months to run a release confidently, and only 3% are very confident any engineer could run one end to end.
Releases fall to senior engineers in 54% of teams and to the EM in 21%. 19% have a dedicated release or platform team to take it on.
On each release, EMs worry about quality and app store rollout, and leadership notices quality and slipping timelines. Engineers here rarely call the release process a scaling risk (18%). On the same cadence with 50 or more engineers, it becomes the risk they name first, at 47%, so it is a problem these teams grow into.
“We've automated our releases.”
58% of engineers describe their release automation as moderate or significant. But 47% of those engineers still spend six or more hours per release on non-productive work, and 88% see an incident at least once every three to five releases.
“We've invested in testing.”
92% of EMs rate their testing investment as moderate or higher, and it has not changed the coordination figures. Those EMs report the same load as everyone else: 10% can see release status in one place, and 61% call the release process a significant or top frustration.
“Our senior engineers have it covered.”
Releases fall to senior engineers in 54% of teams. But 39% of EMs say a new engineer needs five or more months to run a release confidently, only 3% are very confident any engineer could run one end to end, and 45% name knowledge concentration as a top risk for the next 12 to 18 months.
“We keep track in Jira and Slack.”
78% of engineers say their team has no tool that centralizes release coordination. What they use instead is the project management tool (68%), chat (61%) and CI tracking (42%), none of them built for running a release. 69% say their team would benefit from centralizing it.
90% of EMs are likely to invest in improving their release process or tooling in the next year. 90% expect it to accelerate the roadmap, 19% significantly.
EMs name testing and QA capacity (30%) and engineering capacity (28%) as what most limits delivery. Only 11% 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, 54% would try to improve their internal release process (standardize, document, clarify ownership) before buying or building any tooling, and 29% would evaluate a third-party platform.
96% of the EMs who would evaluate a platform first call releases a significant or top frustration. Among those who would improve the process first, 40% do.
90% say their release cadence is about right.
Most releases here land on time, and nine in ten EMs plan to invest in the release process next year. However, release status still lives in the EM's head, and every two weeks they spend hours relaying it. 98% of EMs spend three or more hours a cycle on updates, only 10% can see status in one place, and once 31 or more people are involved, 62% say most releases miss the date. Teams have tried automation and testing, and neither has solved the coordination. AI will add to it: 74% of teams already gate AI-touched code before it ships, and more AI-written code means more to review and coordinate on every release. Most EMs would start with process changes, while the most frustrated are already looking at a platform. To work, either move would have to cut the hours EMs spend on status and keep large releases on schedule.
A 30-minute walkthrough for small 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.
