Transforming Mobile Engineering: From Organizational Friction to Continuous Delivery
One of the most meaningful outcomes of our mobile engineering transformation at Control4 was reducing the time it took to get bug fixes into customers’ hands.
Previously, we released our applications at most once per quarter. After the transformation, we could get a customer-reported defect fixed and released to everyone within a month, sometimes sooner for customers participating in our beta program.
That improvement didn’t come from simply asking engineers to work faster. Over several years, we changed how the organization was structured, how teams collaborated, who owned quality, and how we developed, released, and supported software.
The changes weren’t always popular, and we didn’t have every piece of the solution in place when we started.
Aligning the Organization with the Architecture
The first challenge was organizational.
When I took responsibility for mobile engineering, we had two Scrum teams operating somewhat independently. Each team included a mix of iOS, Android, and QA engineers, but the team boundaries didn’t align with our shared application architecture. Decisions made by one team frequently affected the other.
Conway’s Law tells us that organizational structure influences software architecture. We could change the architecture to support the existing teams or change the organization to better support the architecture.
I chose the latter. Even if we redesigned the architecture, the applications would still need to deliver consistent experiences across platforms, and engineers would still need to collaborate closely.
Creating one cohesive team
I combined the two Scrum teams into one, bringing approximately sixteen engineers together for planning, standups, retrospectives, and demos. We retained distinct platform expertise and management, but created one shared forum for delivery.
Sixteen people in a standup isn’t ideal. We needed to be disciplined about using everyone’s time. But everyone could now see what their colleagues were working on. Staff and Principal engineers could share technical feedback with the entire team rather than just half of it.
This was particularly important at Control4 because effective application development required both mobile platform expertise and Control4 domain knowledge. An engineer might understand iOS or Android deeply but lack experience with a particular Control4 subsystem. Someone with that domain expertise might previously have been on the other Scrum team.
Bringing everyone together made it easier to find expertise, collaborate on shared components, resolve technical issues, and maintain consistency across platforms. It reduced the chance of independently building redundant components or solving the same problem differently.
The goal wasn’t to create a larger Scrum team. It was to remove an organizational boundary that didn’t make sense for the architecture.
Years later, as meeting demands increased and coordination within iOS, Android, and Qt became more important, we adjusted the rhythm again: horizontal standups on Monday, Wednesday, and Friday, and combined standups on Tuesday and Thursday. That replaced some duplicated team and combined standups while preserving cross-platform visibility.
The communication structure evolved as the organization did.
Making QA an Active Part of Development
Around the time of the Scrum team merger—possibly just before it—we changed who presented features during sprint demos.
We asked QA engineers to present the work. If QA was going to demonstrate functionality, they first needed to validate what was being shown.
That didn’t require the feature to be complete. Many features took more than a two-week sprint; demos showed progress, not necessarily finished functionality. But the change encouraged QA to participate throughout development instead of waiting until the end.
Our QA engineers became exceptionally good at presenting. They developed consistently polished demos across mobile applications, touch panels, on-screen displays, and remotes. High-quality demos became the norm, and we eventually invited executives to attend.
What started as a way to encourage earlier quality involvement became an effective way to communicate engineering progress.
Establishing a DevOps Strategy
In June 2019, we released Control4 OS 3.0, including completely rewritten mobile applications. The rewrite gave us an architecture that made feature development faster, and we had practiced test-driven development from the beginning, giving us good automated test coverage.
But writing software faster didn’t mean we could deliver it faster.
We released applications at most once per quarter. QA had thousands of regression test cases available but could execute only a portion of them in the available release window. Large releases accumulated more changes than we could comfortably validate, and we had experienced quality misses.
I wrote a Navigator DevOps plan, organized around a framework similar to the 5 Ps, to establish a more modern engineering operating model. It covered faster releases, trunk-based development, feature flags, testing automation, on-call engineers, and ownership of software in production.
Define the outcomes; let teams own the implementation
I established measurable goals rather than dictating every technical decision.
One was a faster release cadence. I offered an example of two weeks of development followed by two weeks of testing and a release—not a mandated implementation.
I also set a goal of approximately 25 open bugs per team. We had metrics suggesting a team could review about 25 bugs in an hour. I wanted each backlog small enough that engineers could regularly understand, prioritize, and address outstanding issues. Other goals included incident response and defect resolution times.
Each team took the broader DevOps plan and wrote its own implementation plan.
My job was to establish direction, provide support, and hold teams accountable for progress—not make every technical decision myself.
Changing Quality Ownership
In late August 2019, my manager made a broader organizational change that eliminated dedicated QA teams. I transitioned the QA engineers in my organization into engineering or management roles.
Manual validation responsibilities moved to the development teams. The engineers weren’t particularly enthusiastic about repetitive manual testing.
My response was simple: If you don’t like doing it manually, automate it.
I wasn’t trying to make developers into full-time manual testers. I wanted teams to own the quality of the software they built and invest in making validation easier.
Our OS 3.0 applications already had a good automated test foundation, but broader regression and release validation still needed work. Giving engineers ownership made those gaps visible and created a reason to address them.
Quality starts and ends with the engineer. That doesn’t diminish specialized QA expertise; it means development teams can’t treat validation as someone else’s responsibility.
Moving to a Two-Week Release Cadence
I also had to convince people outside engineering.
Program management and release management were particularly worried that faster releases would reduce quality. Their concerns weren’t unreasonable—we’d already had quality misses.
I saw a different risk. With limited regression testing capacity, accumulating months of changes into each release made validation harder.
Less frequent releases weren’t necessarily reducing risk. They were concentrating it into each release.
Change release ownership
Rather than asking the central release management organization to manage Navigator releases every two weeks, I proposed taking responsibility for application releases within my organization. That allowed central release managers to focus on the base operating system.
They were reluctant, but agreed to a trial. We began the two-week Navigator release cadence in January 2020.
We hadn’t completed every practice in the DevOps plan. Feature flags were just beginning to take hold, and I was advocating for trunk-based development, but it wasn’t established yet.
I could have waited until all the ideal practices were in place. But sometimes engineers need to experience the limitations of the current process before they’re persuaded to change it.
I think of it as ripping off the bandage and exposing the wound before people are willing to undergo the surgery. The problems were already there. The new cadence made their costs harder to ignore.
The teams scrambled a bit for the first month or two. The transition to trunk-based development happened fairly quickly, though, and made an enormous difference. We could produce a release from the main development branch at almost any point.
Unfinished work could stay hidden behind feature flags, so features didn’t have to launch on the same schedule as application releases.
To the best of my recollection, we didn’t miss a scheduled release during that first year.
Make releases routine
We established a patching structure that made it easy to produce additional beta builds when necessary. We also changed our version scheme to combine the Control4 OS version and year into the first number, followed by the week of the year, patch number, and build number. For example, 426.44.0.1234 represents an OS 4 application build from week 44 of 2026, patch 0, build 1234.
We tracked feature flags on a Scrum board and established telemetry alerts to catch features being exposed prematurely. Feature flags deserve their own article, but they were an important way to separate releasing an application from launching a feature.
The trial eventually became the normal operating model. Navigator retained responsibility for its releases, and central release management no longer needed to oversee them or worry that the cadence would compromise quality.
We still coordinated app and feature launches with the broader organization when they depended on OS capabilities. The OS typically released twice a year, and at most quarterly, while Navigator could keep delivering app updates every two weeks.
We removed unnecessary release dependencies without eliminating coordination that actually mattered.
Making Engineers Responsible for Software in Production
The technical foundation for operational visibility came before the DevOps plan.
We integrated New Relic telemetry into the rewritten OS 3 applications. I personally wrote the Android telemetry API, and the iOS team adopted the same API for consistency across platforms.
We also followed an architectural rule: cross-cutting third-party integrations belonged behind our own API wrappers, so switching providers wouldn’t require changing every application component. That’s a broader architecture topic, but it helped make telemetry consistent.
The DevOps plan built on that early work. Collecting telemetry was useful; having engineers act on it was better.
Give on-call engineers time to do the job
We established an on-call rotation in each engineering team. Each sprint, one engineer took the on-call role and wasn’t assigned feature stories that sprint.
Their capacity was reserved for monitoring app health, triaging incoming bugs, investigating issues, and responding to customers. Responsibilities varied somewhat by team, and each team maintained an on-call checklist for the engineer to review.
Engineers also participated in customer outreach through forums, staying connected to how people experienced the software.
The rotation created clear operational ownership without expecting engineers to absorb it on top of a full sprint of feature work.
If operational ownership was important enough to expect from engineers, it was important enough to allocate time for it.
The Results
The improvements reinforced one another, but they weren’t a single overnight transformation.
The teams eventually reached our goal of approximately 25 open bugs per team. The backlog ebbed and flowed. iOS maintained the target more consistently; Android had a broader portfolio, including touch panels and originally the on-screen display applications, alongside mobile. With roughly the same number of engineers, I expected Android’s backlog to run somewhat higher.
The number wasn’t the point. Keeping the backlog manageable meant teams could regularly review, prioritize, and address defects.
The result I value most was getting fixes to customers sooner.
Before the transformation, a customer might have to wait for the next quarterly release. Afterward, we could get a reported bug fixed and released to everyone within a month, with some beta customers receiving fixes sooner.
I remember the VP over QA being particularly happy about that outcome. It’s notable because quality concerns had been a major reason for resisting the faster cadence in the first place.
Faster releases didn’t eliminate defects. They made us much more responsive when defects occurred.
What I Learned
The transformation wasn’t about adopting a particular methodology. It was about changing the environment around engineering work.
When Scrum team boundaries conflicted with our architecture, we aligned the organization with the software.
When delivery couldn’t keep pace with development, we changed release ownership and engineering practices.
When teams became responsible for manual validation, we encouraged them to automate the repetitive work.
When engineers became responsible for production software, we reserved capacity for that responsibility.
And throughout the process, I defined outcomes while leaving implementation decisions with the teams closest to the work.
Some changes were uncomfortable. At times we committed to a new way of working before every supporting practice was established. But that only works if engineers have the authority, time, and support to improve the system.
I didn’t want a process that depended on everyone continually working harder. I wanted the right practices to make sustainable delivery possible.
Engineering leaders shouldn’t simply demand better outcomes. They should build the environment that makes those outcomes possible.
That’s a central idea behind my Engineering Operating System.