Nearly every EM spends three or more hours a cycle on status updates.
97% of EMs spend three or more hours per cycle updating others on the release.
EMs by hours spent on status updates each cycle
1 to 2 hours3%
3 to 5 hours92%
6 to 10 hours5%
Small teams, monthly releases
The bush plane
You're here if your mobile team has 10 to 49 engineers and ships about once a month.
In short
- Engineering managers here report release status by hand
- The more people a release needs, the later it ships
- The gap between build done and release shipped is where the incidents come from
- EMs here see the problem and plan to make fixing it an initiative
How small mobile teams on monthly releases compare with all teams
Small monthly teams put fewer people on each release (61% of EMs say 21 or more act, against 77% across all teams) and miss dates less often. But 93% of EMs can't see release status in one place, and 93% of engineers see an incident that delays features or forces a hotfix at least once every three to five releases.
Small teams, monthlyAll teamsRange across the six segments
97% of EMs spend three or more hours per cycle on status updates
All teams: 96%
93% of EMs can't see release status in one place
All teams: 87%
61% of EMs say 21 or more people are required to act on each release
All teams: 77%
27% of EMs say most of their releases miss the planned date
All teams: 34%
33% of engineers lose six or more hours per release to low-value work
All teams: 37%
93% of engineers see an incident that delays features or forces a hotfix at least once every three to five releases
All teams: 87%
What a monthly release costs a small mobile team
Twelve releases a year still carry the full status load, with 97% of EMs spending three or more hours a cycle on updates. Inside each cycle, 41% of engineers lose 40% or more of the release to non-productive work. Incidents come every three to five releases for 89% of engineers, which on a monthly cadence means two to four a year.
Four in ten engineers lose 40% or more of each release to non-productive work.
85% of engineers spend at least 20% of each release on non-productive work, and 41% spend 40% or more.
85%
At least 20% of the release
41%
40% or more
Incidents hit every three to five releases for nine in ten engineers.
89% of engineers say one in every three to five releases causes an incident that delays features or forces a hotfix. 59% believe a centralized process would have prevented most of them.
89%
One in every three to five releases has an incident
59%
A centralized process would have prevented most of them
EMs blame tooling and tech debt, and engineers blame hotfixes and manual steps.
EMs point first at tooling and CI reliability (73%) and codebase technical debt (51%); engineers point first at hotfixes and critical bugs under pressure (52%) and manual steps (38%).
EMs
73%
Tooling and CI reliability
Engineers
52%
Hotfixes and critical bugs under pressure
Why monthly releases still slip on small mobile teams
27% of EMs across the segment say most releases miss the date, and 55% of those with 31 or more people on a release do. The work rests on senior engineers in two thirds of teams, only 3% have a dedicated release team, and no EM is very confident any engineer could run a release end to end. With twelve releases a year, there are few chances for anyone else to learn.
For six in ten EMs, a release needs 21 or more people to act.
61% of EMs say 21 or more people are required to act before a release ships.
61%
21 or more people
19%
31 or more people
Releases with 31 or more people miss their date twice as often.
Among EMs with 31 or more people on a release, 55% say most releases miss the date, double the 27% across the segment.
27%
Across the segment
55%
31 or more people on a release
Larger releases eat more engineer time in busywork.
With 31 or more people on a release, 55% of EMs say busywork takes up half or more of engineer time, against 34% across the segment.
34%
Across the segment
55%
31 or more people on a release
Fewer than one in ten EMs can see release status in one place.
Only 7% of EMs can see release status in one place. 49% check multiple tools to piece it together.
One place7%
Multiple tools49%
Other44%
Six in ten EMs run release status out of the issue tracker.
59% of EMs call the issue tracker their primary source of truth for release status. 8% use a release-specific tool, and 8% have no single source.
Primary source of truth for release status
Issue tracker59%
Docs or checklists24%
Release tool8%
No single source8%
Engineers spread releases across project management, chat and CI.
54% of engineers use a project management tool to run releases, 53% use chat and 51% use CI/CD with tracking.
Tools engineers use to run releases
Over four in ten teams ship five or more apps, each with its own release.
44% of teams own five or more apps, each with its own release.
Of teams own five or more apps, each with its own release.
More than half of teams already gate AI-touched code before it ships.
54% of teams require an approval or validation gate on AI-touched code before it ships.
54%
Of teams require an approval or validation gate on AI-touched code before it ships.
No EM is very confident any engineer could run a release end to end.
22% of EMs say a new engineer needs five or more months to run a release confidently, and none is very confident any engineer could run one end to end.
22%
Five or more months to run a release confidently
0%
Very confident any engineer could run one end to end
Releases rest on senior engineers, and few teams have a release team.
Releases fall to senior engineers in 68% of teams and to the EM in 24%. Only 3% have a dedicated release or platform team.
Who runs releases
Senior engineers68%
Engineering managers24%
Dedicated release team3%
What's at stake for small mobile teams shipping monthly
Quality risk leads what EMs watch on each release (85%), and codebase maintainability and testing maturity lead their risks for the next 12 to 18 months. Leadership notices slipping timelines as often as quality problems, at 34% each.
We asked EMs
“What worries you most about each release?”
85% of EMs name quality risk.
Their answers
185%
Quality risk
244%
Governance gates
341%
App store review and rollout
We asked EMs
“Does your organization see mobile as higher risk than web or backend?”
54% say yes.
Their answers
154%
Higher risk than web or backend
We asked EMs
“When leadership loses confidence in mobile, what reason do you hear?”
34% hear slipping timelines, and as many hear post-release quality.
Their answers
134%
Slipping timelines
234%
Post-release quality
We asked EMs
“What are the biggest risks for the next 12 to 18 months?”
68% name codebase maintainability, and 59% testing maturity.
Their answers
168%
Codebase maintainability
259%
Testing maturity
354%
Knowledge concentration
We asked engineers
“What's the greatest risk to your team's ability to scale?”
35% say budget, and only 16% name the release process.
Their answers
135%
Budget
226%
Limited engineering resources
316%
Release process
What small mobile teams on monthly releases say, and what the numbers show
“We've automated our releases.”
Automation hasn't changed the hours or the incidents here. Engineers with moderate or significant release automation (79%) lose six or more hours per release at the same rate as those with little (32% against 33%), and see incidents at least once every three to five releases at the same rate (94% against 90%).
“We've invested in testing.”
Every EM in this segment rates their investment in automated testing and QA as moderate or high. 58% still call the release process a significant or top frustration, and 59% name testing maturity a top three risk anyway.
“We'd rather fix the process ourselves.”
Of the EMs who answered which option they would try first to improve their release process, 81% would improve their internal release process before buying or building any tooling.
“We keep track in Jira and Slack.”
77% of engineers say their team has no tool that centralizes release coordination. What they use instead is the project management tool (54%), chat (53%) and CI tracking (51%), none of them built for running a release. 40% say their team would benefit from centralizing it.
Where small mobile teams shipping monthly plan to start
Nearly every EM plans to invest in the release process next year.
95% of EMs are likely to invest in improving their release process or tooling in the next year, and 97% expect it to accelerate the roadmap.
EMs say engineering capacity limits delivery, and release busywork is where much of it goes.
EMs name engineering capacity (46%) as what most limits delivery; only 5% name release overhead. That capacity is where release busywork lands: 41% of engineers lose 40% or more of each release to it.
What most limits delivery
Eight in ten EMs would fix their own process before buying or building tooling.
Of the EMs who answered which option they would try first to improve their release process, 81% would try to improve their internal release process (standardize, document, clarify ownership) before buying or building any tooling.
What they would try first
Improve the process81%
Build12%
Evaluate a platform6%
Nearly every EM says monthly is the right cadence.
98% say their release cadence is about right.
WeeklyBiweeklyMonthly
Alignment with this cadence
98%say it's about right2% would change it
Suggestions for small mobile teams on monthly releases
Releases here mostly land on time, and fewer people act on each one than the all-teams figure. However, the release runs through a ticket tracker and a few senior engineers, and with twelve releases a year few others ever learn it. 97% of EMs spend three or more hours a cycle on updates, only 7% can see status in one place, and no EM is very confident any engineer could run a release end to end. Teams have tried to throw automation at this, and it hasn't solved the coordination. AI-written code will add review work on top, and 54% of teams already gate it before it ships. 81% of EMs would start with process changes. To work, those changes would have to give everyone one place to see the release and spread the know-how beyond the few people who run it now. We'd go further. 98% of EMs call monthly the right cadence, but that is the pace a hand-run release can sustain. Once the coordination stops depending on a few people, shipping every two weeks becomes realistic, and users get fixes and features twice as often.
Where to go next
ArticleHow to improve visibility and coordination across your mobile release processFor teams fixing coordination first: ownership, release captains and one place for status.Read »ArticleMobile app release process best practices: visibility, coordination, and scaleFor the 81% who would improve their internal process before buying or building tooling.Read »ArticleHow to build the perfect mobile release trainFor teams on a fixed train and still frustrated by it.Read »WebinarThe ROI of mobile release managementFor EMs making the case to invest, with data from tens of thousands of releases.Watch »WebinarBuild vs. Buy: Mobile release toolingFor the 12% who would build first and the 6% who would buy: practitioners who did both and rebuilt.Watch »
See how Runway handles the coordination.
A 30-minute walkthrough for small teams on monthly releases: status in one place, release pilots and rollouts.
Get the full report.
All six segments in one report, ready to pass along to your team.