Building a Self-Sufficient Engineering Team: The Control4 Halo Turnaround
In January 2023, Control4 released the original Halo remote. Six months later, in July 2023, Halo Touch shipped.
Those launches followed a challenging period for the Remote Control GUI team. By fall 2022, the project needed additional technical and organizational support, and I became more directly involved.
Our immediate objective was to stabilize development and deliver the first product. The longer-term goal was more important: build a team capable of developing and maintaining Halo without depending on engineers temporarily assigned from another organization.
Starting with a Technical Foundation
My organization had developed a Qt-based on-screen display application, which we called OSD. When the Remote Control GUI project began, there was an opportunity to reuse much of its architecture and shared functionality.
Our OSD team was heavily engaged in launching the CORE controller line and didn’t have capacity to own another major GUI project. I asked one of my Principal engineers to extend the OSD application to support different themes and views, conceptually similar to Android product flavors.
That gave the new Remote Control team a starting point while leaving it responsible for implementation and delivery. For the first several months, that was largely the extent of my involvement.
Bringing Experience into the Team
By fall 2022, the Remote Control project was having difficulty making progress. At the same time, our CORE controller work had largely wrapped up, giving my team capacity to help.
My manager brought me up to speed and asked how I thought we should address the situation. The team included a first-time engineering manager and several early-career engineers, with limited experience in the C++ and Qt technologies central to the project. It had also diverged considerably from the reusable OSD architecture, expanding the implementation work it needed to own.
I reassigned two experienced engineers from OSD into the existing Remote Control Scrum team. A Staff engineer became the Scrum master, helping establish a more effective development rhythm. A Principal engineer brought hands-on Qt and OSD expertise, helped resolve technical issues, and mentored the engineers.
The existing manager retained responsibility for the team. We weren’t building a separate group to take over the project.
The objective was to transfer experience into the team, not establish a permanent dependency on the people helping it.
Establishing UI-Platform
We also had an organizational opportunity I’d discussed with my manager well before the Halo project needed help: a dedicated UI-Platform team.
Qt, iOS, and Android applications relied on shared capabilities in a common Core library. Those capabilities needed clearer ownership.
When we reviewed the challenges in Belgrade, my manager and I recognized that creating UI-Platform could address both a longstanding architectural need and concerns some Remote Control engineers had raised about their existing team arrangement.
We moved two engineers to the new UI-Platform team to focus on shared capabilities rather than the remote-specific GUI.
My manager and I evaluated experienced engineering managers in our Belgrade office and chose the one whose background best matched the new team’s responsibilities. He brought substantial C++ experience and was already successfully leading another team. UI-Platform expanded his scope while giving shared functionality experienced leadership.
This was another practical lesson from Conway’s Law: organizational ownership and software architecture need to support one another.
Addressing Management Challenges
I met weekly with the Remote Control engineering manager to discuss the challenges and agree on improvements. Unfortunately, those changes weren’t consistently reflected in how the team operated. The Principal engineer embedded with the team independently observed similar difficulties.
Technical mentoring and improved Scrum practices were helping, but they weren’t sufficient on their own. We also needed to revisit the management arrangement.
The manager wasn’t my direct report; he reported through another manager to my boss. My responsibility was to provide observations and recommendations, while the final decision belonged to my boss.
Eventually, the experienced manager leading UI-Platform also assumed leadership of Remote Control. This helped create a more consistent environment for collaboration and technical decision-making.
The lesson wasn’t that more senior engineers could solve every problem. Effective technical support and effective engineering management needed to work together.
Stabilizing Delivery and Shipping Halo
By the time I became directly involved, the original Halo launch had already been reduced significantly in scope.
Our first priority was to stabilize development, finish the remaining functionality, and ship the remote—not attempt an architectural redesign during a difficult release.
The Remote Control application had diverged substantially from OSD. I believed moving toward the shared architecture was the right long-term direction, but doing that immediately would have added complexity and risk.
The original Halo shipped in January 2023, a few months after our more direct involvement began. The initial feature set was limited, and substantial work remained. The team continued delivering and Halo Touch shipped in July 2023.
These milestones showed that the team could move beyond the initial recovery and continue delivering product functionality. They didn’t mean every architectural issue had been resolved—or that the team had already become fully independent.
Evolving Toward a Shared Architecture
After the initial launch, we could begin addressing the longer-term architectural work.
The OSD architecture simplified GUI development substantially, but it represented a different way of thinking for the Remote Control engineers. Adoption required learning, not just copying code.
Because much of the original OSD code had been replaced or left behind, the migration was larger than originally anticipated. We approached it one feature at a time: new features used the shared OSD architecture, while existing features remained on the Remote Control implementation until there was a reason and opportunity to migrate them.
The Principal engineer helped guide that transition. The work continued over an extended period and, to the best of my knowledge, beyond my direct involvement.
A shared architecture is useful only if the team can understand and evolve it. We needed to build that capability along with the code.
Building a More Effective Team
The combined changes gradually improved how the team operated.
We saw less conflict, more productive collaboration, and greater receptiveness to technical guidance. Recommendations were incorporated more consistently, changes happened faster, and the team’s development velocity improved. There were fewer escalations over technical disagreements.
Those improvements weren’t attributable to one intervention. Experienced engineers strengthened delivery and mentoring; UI-Platform clarified shared ownership; and the management transition improved the team’s leadership environment.
Most importantly, we could gradually reduce the temporary engineering support.
The Staff engineer returned to other responsibilities. The Principal engineer transitioned from substantial hands-on implementation into a largely advisory role. She continued meeting with the team weekly, but the team increasingly made its own technical decisions and completed the development work.
That mattered more to me than keeping an expert permanently embedded.
What I Learned
Stabilize before optimizing. When a project is struggling, not every important issue is equally urgent. We prioritized delivery first and introduced architectural improvements incrementally.
Address technical and organizational problems together. Technical mentoring helped, but the team also needed clear ownership and effective management. Creating UI-Platform served an architectural need while improving organizational alignment.
Respect decision-making boundaries. I supported and coached the manager, brought observations to my boss, and worked within the management structure instead of treating the personnel decision as mine alone.
Build capability, not dependency. Borrowed senior engineers can accelerate delivery, but the lasting outcome is a team that no longer needs them to do its work.
The original Halo launched in January 2023, followed by Halo Touch in July. Both were important milestones. But the more meaningful accomplishment was helping the Remote Control organization grow more capable and less dependent on outside support.
A successful turnaround isn’t just getting a project back on track. It’s building a team that can stay on track without you.
That’s a central part of my Engineering Operating System.