You're here if your mobile team has 10 to 49 engineers and ships weekly.
On paper, small weekly teams look much like everyone else, at or a few points below the all-teams figure on most of these measures. The frequency of their releases is what impacts a small team the most. Unproductive hours and release risks come round every week, so the same percentages cost these teams more over a year than they would on a slower cadence.
93% of EMs spend three or more hours per cycle on status updates
82% of EMs can't see release status in one place
71% 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
33% of engineers lose six or more hours per release to low-value work
92% of engineers see an incident that delays features or forces a hotfix at least once every three to five releases
Three hours of status updates a cycle, fifty times a year, comes to close to a month of each engineering manager's time. Most of it goes to relaying what already sits in Jira and Slack, since only 9% have a release-specific tool. Most EMs also expect whoever is on release duty to finish less than half of their sprint work.
93% of EMs spend three or more hours per cycle updating others on the release, and 24% spend six or more. At roughly 50 releases a year, three hours a cycle is close to four working weeks per EM.
When an engineer acts as release manager, most EMs (52%) expect them to get through less than half of their planned sprint work.
79% of engineers say one in every three to five releases causes an incident that delays features or forces a hotfix, and 12% say every other release does. Every one of them believes a centralized process would have prevented most of those incidents.
EMs point to execution busywork and coordination overhead (47% each); engineers point to the manual steps (54%) and missing automation (58%) that create it.
Each release needs 21 or more people to act, and fewer than one in five EMs can see its status without piecing it together. EMs name execution busywork and coordination overhead as their top two frustrations (47% each). Only 9% of EMs are very confident any engineer could run a release end to end, so the same few people absorb the work every week.
71% of EMs say 21 or more people are required to act before a release ships.
Only 18% of EMs can see release status in one place. 40% piece it together from tools and conversations with the team.
60% of EMs call the issue tracker their primary source of truth for release status. 9% use a release-specific tool.
90% of engineers use chat to run releases and 88% use a project management tool. 19% have a custom internal tool.
47% of teams own five or more apps, each with its own release.
82% of teams require an approval or validation gate on AI-touched code before it ships.
53% of these teams run a fixed release train, and frustration runs higher on them: 75% of those EMs call releases a significant frustration.
36% of EMs say a new engineer needs five or more months to run a release confidently, and only 9% 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 33%. Rotations are less common.
Team sustainability leads the risks EMs name for the next 12 to 18 months (60%), and the risk climbs with release pace. Among small teams, 32% of EMs on monthly releases name it, 53% on biweekly and 60% on weekly. When leadership loses confidence, EMs hear about missed roadmap commitments and the lack of visibility into release status, which leaves them in the middle, brokering status between the team and leadership. Scrutiny from the rest of the org is lower here, with 36% of EMs saying mobile is seen as higher risk than web or backend, against 51% across all teams.
“We've automated our releases.”
of engineers with moderate or significant automation still lose six or more hours per release.
Automation has cut the hours but not the incidents. Among engineers with moderate or significant release automation (67% here), 22% still lose six or more hours per release to non-productive work, against 56% of engineers with little automation.
“We've invested in testing.”
of EMs who invested in testing still call the release process a significant frustration.
82% of EMs rate their testing investment as moderate or high, and it has not changed the frustration. 59% of those EMs call the release process a significant frustration, and 36% name testing maturity a top three risk anyway.
“We run a fixed release train.”
of EMs on a fixed release train call releases a significant frustration.
53% of teams do, and frustration doubles on a train: 75% of those EMs call releases a significant frustration, against 38% of the rest. Coordination overhead is what they name first (50%).
“We keep track in Jira and Slack.”
of engineers say their team has a tool that centralizes release coordination.
No engineer in this segment says their team has a tool that centralizes release coordination. What they use instead is chat (90%), the project management tool (88%) and spreadsheets or docs (58%), none of them built for running a release. 77% say their team would benefit from centralizing it.
71% of EMs are likely to invest in improving their release process or tooling in the next year. 62% expect it to accelerate the roadmap.
EMs name engineering capacity (27%) and waiting on other teams (24%) as what most limits delivery. Only 13% name release overhead, yet more than half expect an engineer on release duty to finish less than half of their sprint work, which is engineering capacity lost every week.
Of the EMs who answered which option they would try first to improve their release process, 55% would try to improve their internal release process (standardize, document, clarify ownership) before buying or building any tooling, 21% would evaluate a third-party platform and 17% would hire more people or a dedicated team.
91% say their release cadence is about right.
Releases here mostly land on time and the build and test automation is in reasonable shape. However, the weekly status loop is still run by hand, and at a weekly pace it wears on the team. Nearly every EM spends three or more hours a cycle on updates, fewer than one in five can see status in one place, and burnout sits at the top of the risk list. Teams have tried to throw automation at this, and it hasn't solved the coordination. More AI-written code will add to the load, with 82% of teams already gating AI-touched code before it ships. Nobody has a single place to see the release. EMs would start with process changes. To work, those changes would have to cut the hours EMs spend on status and give everyone one place to see the release.
A 30-minute walkthrough for small 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.
