At the end of the summer, I presented my findings to the institute’s president and other leaders. They asked good questions about the results and the tradeoffs I’d made.

I doubt anyone ever ran that software again. But if someone had opened the code months or years later, would they have understood why I’d made those choices? The reasoning existed in a conversation, not in a durable record alongside the code.

Years later, I encountered a larger version of the same problem at Control4.

When we were designing the OS 3.0 mobile applications, our senior engineers met regularly to evaluate UI architectures, including MVC, MVP, VIPER, and MVVM. We discussed the tradeoffs and the maturity of the available implementations. We also took meeting notes. Some of the reasoning was probably captured there, but those notes were eventually lost during a wiki migration.

The code survived. The context behind some of our decisions did not.

The problem isn’t just missing documentation

Engineers make decisions every day. Most are local to a function, class, or component and don’t need a formal process.

But some decisions affect other engineers, teams, or products. Those decisions need broader input and a way to preserve the reasoning. Without that, we risk revisiting the same arguments, repeating mistakes, or criticizing choices without understanding the constraints under which they were made.

The answer isn’t to have every technical decision made by a committee. Committees can introduce compromises that satisfy everyone on paper while producing a worse technical solution.

I wanted decisions to stay with the engineers closest to the work, while making sure the people affected by those decisions had a voice.

Let the team define the process

I’ve followed Martin Fowler’s writing for much of my career and put many of the patterns he discusses into practice. Andrew Harmel-Law’s Thoughtworks article, Scaling the Practice of Architecture, Conversationally, gave me a useful framework for scaling technical decisions through conversation rather than centralized approval. Architecture Decision Records (ADRs) were one of the tools it described.

ADRs weren’t new, but we hadn’t established them in my organization.

I had a practical reason for wanting to try them. Engineers would sometimes come to my office frustrated by decisions another engineer had made. Often, the disagreement wasn’t only about the outcome. They felt that their concerns hadn’t been heard or that their perspective hadn’t been considered.

We needed a better way to involve stakeholders without turning architecture into design by committee.

I also knew that engineers generally don’t appreciate having a new process imposed on them, especially one they’re expected to follow without helping shape it.

Around that time, I’d formed a small UI-Platform team in our Belgrade office: two engineers and a manager. The team was just getting started, had several architectural decisions ahead of it, and had the capacity to try something new.

I introduced the concept of ADRs, and we read through several articles together. Then I asked the team to create its first ADR:

An ADR defining how we would write and use ADRs.

It was a small decision with an important consequence. The engineers weren’t just adopting a process I’d designed. They were helping define it, testing it on real work, and improving it as they learned.

How we put ADRs into practice

We started with a standard template. It evolved over time, but the essentials stayed consistent:

• Context: What problem are we trying to solve, and why does it matter?
• Alternatives: What credible approaches have we considered, and what are their tradeoffs?
• Evidence: What did we learn from research, prototypes, or proofs of concept?
• Feedback: Who will be affected, what did they recommend, and how did we respond?
• Decision: What did we choose, why, and what consequences do we expect?

The ADR also included metadata such as its author, creation date, status, and stakeholders.

I encouraged engineers to consider multiple alternatives—often three where they were genuinely plausible—rather than start with a favorite solution and work backward to justify it. A proof of concept could be valuable when the tradeoffs weren’t clear.

But the document wasn’t the main point. The conversations it prompted were.

Seek advice, not unanimous approval

For the UI-Platform team’s initial ADRs, I identified Staff and Principal engineers and managers across my organization who should be consulted.

The author’s responsibility was to seek out feedback, understand the concerns, and take them seriously. Sometimes that meant revising the proposal or finding a compromise. Sometimes stakeholders disagreed with each other, and there wasn’t a solution that satisfied everyone.

We weren’t trying to design by committee. After making a reasonable effort to resolve concerns, the author was expected to make the decision within their authority and explain the reasoning, including why some advice wasn’t followed. Genuine blockers or decisions outside that authority still needed to be escalated.

That distinction matters: owning a decision doesn’t mean ignoring advice, and seeking advice doesn’t mean giving up ownership.

Keep the process visible—and the record close to the code

Our workflow used several states.

An ADR began as a Draft, while the author clarified the problem, explored alternatives, gathered feedback, and ran proofs of concept. Once the proposal was ready, it moved to Proposed and was shared with the affected teams. If no blocking concerns remained, it became Ratified.

We also tracked ADRs that were Rejected or Abandoned, recording why they didn’t move forward. Later decisions could Supersede earlier ones, with a reference to the replacement. The history mattered, including the paths we chose not to take.

During drafting and review, we used Confluence. Not every stakeholder had access to every team’s Git repository, and sometimes product managers needed to participate. The wiki made collaboration easier.

Once an ADR was ratified, we converted it to Markdown and committed it to an ADR directory in the repository closest to the code. We also preserved rejected and abandoned decisions. The important thing was that future engineers could find the reasoning where they encountered the implementation.

We established a review committee made up of the managers in my organization. But the committee didn’t review or approve the technical decisions. We reviewed the progress of ADRs, looking for proposals that had become stuck and needed help moving forward.

That was a deliberate separation of responsibilities. Engineering managers helped keep the process healthy; engineers retained ownership of the technical decisions.

Where judgment still matters

Not every decision deserves an ADR. Sometimes a conversation between two engineers is enough. The process should be reserved for decisions with meaningful impact beyond the immediate work.

It also helps to distinguish between one-way doors and two-way doors. Some choices are expensive to reverse once implemented. Others are easy to revisit. The amount of investigation and review should reflect the consequences of getting the decision wrong.

The process wasn’t perfect.

A small number of engineers became too attached to their proposals. They treated authorship as permission to dismiss feedback and move ahead with their preferred solution.

When I saw that happening, I worked with their managers to coach them through the process. Giving an engineer ownership of a decision doesn’t remove the need for judgment, collaboration, or accountability.

I also saw authors criticize previous architectural choices without fully understanding why those choices had been made.

One principle I’ve held for a long time is that we stand on the shoulders of giants. We often don’t know the constraints the engineers before us faced. A past decision may look wrong with today’s information but have been reasonable at the time.

An ADR won’t prevent every disagreement, but it can preserve enough context to let the next engineer evaluate a decision fairly—and improve on it when circumstances change.

What I learned

Over time, engineers appreciated having a consistent way to make and communicate decisions. It encouraged more discussion across the organization, made disagreements easier to surface, and preserved the reasoning that might otherwise have disappeared.

Having the UI-Platform team help define and trial the process made adoption easier. The managers’ review committee helped keep proposals from sitting indefinitely without taking decision-making authority away from the authors.

After two or three years of using ADRs in my organization, I introduced the approach to the broader organization through my VP’s Principal Engineering Committee. Rather than simply adopting our exact process, that group developed and tried its own. The result was similar, but the ownership was theirs.

That’s probably the most important part of the story.

The goal was never to produce more documents. It was to help engineers make better decisions, involve the people affected by those decisions, and preserve the reasoning for whoever inherited the code.

My responsibility as an engineering leader wasn’t to make every technical decision. It was to create the environment in which engineers could make good decisions themselves.

That’s a central part of my Engineering Operating System.

A note on perspective (October 2026): These are my thoughts and opinions as of October 2026, based on my experience and understanding of AI today. The technology is evolving rapidly, and I expect my perspective to evolve along with it.

Another Layer of Abstraction

Software engineering has always evolved through abstraction.

Compilers eliminated the need to manage individual machine instructions. Frameworks and libraries abstracted away common functionality. AI is introducing another layer.

I recently encountered an observation that resonated with me: we may eventually care about AI-generated source code about as much as we care about the assembly a compiler produces.

There is an important difference, though. Compilers translate well-defined languages. AI agents interpret specifications that may be incomplete, ambiguous, or contradictory.

Historically, engineers filled in those gaps using experience, product knowledge, and architectural understanding. Agents make assumptions too, but those assumptions may conflict with existing decisions.

As implementation becomes less expensive, specifications, architectural constraints, and acceptance criteria become more important.

I expect agents to eventually become capable of making most architectural decisions as well. Whether that’s six months or five years away, I don’t know.

Architecture is a harder problem to train and evaluate. Source code is abundant, and functional correctness can often be tested. Architectural decisions involve competing constraints, undocumented reasoning, and consequences that may not become apparent for years.

In the meantime, agents need access to the architectural knowledge that engineers have traditionally carried in their heads.

Communication Doesn’t Disappear. It Moves.

Conway’s Law describes how software architecture reflects the communication structures of the organizations building it.

AI doesn’t eliminate that relationship. It changes how communication happens.

Multiple agents working independently can produce individually reasonable solutions that conflict with each other. One might introduce a new service where existing infrastructure would suffice. Another might implement functionality already provided by a shared component.

Without coordination, those decisions accumulate into architectural complexity.

I’ve invested considerable effort in documenting repositories so agents can understand the systems they’re modifying. But documentation alone isn’t sufficient. Relevant information needs to reach an agent when it’s making a decision.

This is one reason I’ve been studying transformer models and how LLMs, harnesses, and agents work. I think engineers should understand the technologies they’re using to build products.

Those boundaries are evolving as models and agent platforms incorporate capabilities previously handled externally.

The harness is particularly interesting from an engineering leadership perspective. It can retrieve relevant documentation, identify architectural constraints, supply historical decisions, and initiate validation.

We don’t need to provide every document in every prompt. We need to make the right information available at the right time.

But providing context doesn’t guarantee an agent will follow it. We also need checks and balances.

Making Architecture Enforceable

Our mobile and AirPlay 2 development efforts demonstrated how good engineering practices allow developers to operate independently while maintaining quality.

We invested in automated testing, including isolated functional tests with abstracted backend dependencies and end-to-end functional tests. A relatively small number of manual tests supplemented that coverage.

We also used linters, static analysis, and security analysis tools such as SonarQube.

Everything had to build and pass the required checks before merging into trunk.

These practices provided consistent expectations and immediate feedback. AI agents can benefit from the same approach.

Where I think we need to invest more is architectural validation.

Dependency analysis, interface contracts, layering rules, and architecture fitness functions can enforce many structural constraints.

But not every architectural concern can be expressed as a deterministic rule.

At a minimum, I’d want an architecture review agent examining proposed changes before they merge.

It should have access to architectural documentation, relevant decisions, and the context behind the proposed change.

The reviewer should identify potential architectural problems, request revisions from the submitting agent or engineer, and escalate significant concerns for human review.

This provides another layer of architectural coordination without requiring every change to go through a human architect.

Preserve the Reasoning

Around 2022–2023, I began introducing Architecture Decision Records (ADRs) within my organization.

The engineer closest to the problem authored the decision, gathered feedback, and evaluated alternatives, often through proofs of concept.

I’ve found agents effective at this exploratory work. They can implement PoCs quickly and identify weaknesses in proposed designs.

I haven’t yet had agents commit new ADRs, but I see value in having them propose decisions, evaluate alternatives, and document tradeoffs.

I’d also expect better commit messages from agents. They should capture non-obvious decisions, assumptions, and tradeoffs rather than simply describe which files changed.

Both ADRs and useful commit history preserve context for future engineers and agents.

Rethinking Review and Approval

I’m still working through how much human oversight should remain necessary for AI-generated code.

I’m uncomfortable with large, complex production systems being changed without meaningful review. But agents can produce changes faster than engineers can inspect them, making traditional code review increasingly difficult to scale.

I think we need several complementary controls.

Executable requirements. I’ve been exploring behavior-driven development, where requirements are expressed as testable scenarios. These provide acceptance criteria that can be defined independently of the implementation and enforced automatically.

Architectural review. Deterministic checks should enforce known architectural constraints. A separate architecture review agent can identify potential design problems that aren’t easily expressed as static rules.

Automated quality gates. Builds, functional tests, static analysis, and security checks should remain mandatory. Independent validation matters because tests written by the implementing agent may reinforce its own incorrect assumptions.

Risk-based human approval. Changes affecting security boundaries, critical interfaces, or significant architectural decisions should receive additional scrutiny.

Random human inspection. I like the approach of sampling changes that otherwise passed automated approval. It’s similar to manufacturing quality control: periodically inspecting products from the line to find weaknesses in the process. Those findings should feed back into better tests, architectural rules, and agent instructions.

Supply-chain protection. Agents can introduce dependencies without anyone explicitly requesting them. Dependency scanning, package allowlists, provenance checks, and approval requirements for new libraries should help prevent malicious or unsuitable dependencies from entering the system.

Finally, agents need appropriate permissions. They shouldn’t be able to bypass required checks or deploy high-risk changes simply because they can implement them.

These mechanisms don’t eliminate risk. They create multiple opportunities to detect problems and limit their consequences.

The Engineering Operating System

I’ve already seen the practical value of AI agents in engineering workflows.

Recently, I used agents to triage and resolve five issues in our AV team’s escalation backlog. The agents identified problems and fixed the code. We validated the fixes on our own systems before deploying them to the affected customers’ systems.

That reduced the escalation backlog from five issues to zero.

The experience reinforced a principle I’ve followed throughout my leadership career: engineering effectiveness depends on more than individual capability. It depends on the system surrounding the work.

I describe that system as an Engineering Operating System.

Engineering leadership establishes the organizational structure, development practices, decision-making processes, tooling, and feedback mechanisms that enable engineers to deliver.

AI extends those responsibilities to agents.

We need to provide the appropriate context, architectural guidance, permissions, and validation. We also need engineers who understand these tools well enough to recognize their limitations and use them effectively.

As agents become more capable, I expect them to take on increasing responsibility for both implementation and architecture.

The engineering practices surrounding them will need to evolve accordingly.

Producing software is becoming easier. Coordinating architectural decisions, communicating intent, and establishing confidence in the resulting systems may become the more significant challenges.

Communication doesn’t disappear. It moves. Our engineering practices need to move with it.

Melvin Conway described this in his 1968 paper, How Do Committees Invent?:

“organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations.”

That’s the heart of Conway’s Law. Organization design isn’t just a management concern. It’s also an architectural decision.

Team boundaries become software boundaries

Teams naturally optimize for the work they own and the people they talk to most often. Engineers working closely together can make quick decisions, share context, and build tightly integrated software. Across teams, communication requires more deliberate coordination.

Neither tight nor loose coupling is inherently good. A mobile application team may benefit from owning a cohesive app experience. But if mobile and cloud engineers are organized around an individual product feature, shared cloud capabilities—like authentication—can become harder for other products to use.

The question isn’t simply whether teams should be organized by platform or product. It’s where we want strong ownership, where we need shared capabilities, and which communication paths the architecture will require.

What I saw at Control4

Control4 experimented with different organizational structures as our products and teams evolved. One of those experiments was the pillar model: teams organized around major domains of the Control4 system, each responsible for work across the software stack.

I was a Staff Software Engineer in the Listen and Watch pillar, primarily working on the graphical user interface.

Before that change, our iOS and Android applications were developed by a team we called Navigator. The applications had a cohesive architecture that made it relatively straightforward for the team to work across the app.

Under the pillar model, domain-specific code moved into separate modules owned by the individual pillar teams. Building the application meant bringing together the current versions of multiple modules. I recall roughly six or seven, although the exact number isn’t important to the lesson.

The architecture gradually began to reflect the organization. Work that had been coordinated within one team was now divided across several teams. We saw duplicated effort and different implementations of similar capabilities.

Those changes didn’t happen overnight, but they appeared quickly enough to make the relationship clear.

When we eventually moved away from the pillar model and reestablished a single Navigator team, we also consolidated the pillar modules over time. The code became easier for the application team to work with because its structure once again better matched how the team operated.

The tradeoff isn’t one-size-fits-all

The pillar model wasn’t inherently a bad idea. It created clear responsibility for product domains and brought different engineering disciplines together around customer outcomes.

But it also introduced costs where we needed consistency across those domains. Those costs showed up in integration work, duplicated solutions, and the experience of developing the applications.

A platform-oriented structure has tradeoffs too. It can encourage shared capabilities and consistent interfaces, but it can also create dependencies and handoffs that slow product teams down.

A leader has to understand those tradeoffs instead of assuming one organization chart is universally better.

Shape the organization deliberately

When evaluating a team structure, I ask:

• What should this team own end to end? Ownership needs clear boundaries.
• Which capabilities must be shared? Those shouldn’t accidentally become isolated inside a product team.
• Where will teams need to coordinate? Frequent cross-team communication is a signal worth examining.
• What architecture are we trying to enable? The organization should make that architecture practical to build and maintain.

It’s not enough to draw clean boxes on an organization chart. We need to understand the communication paths between them and how those paths influence technical decisions.

A later example: align teams with shared architecture

When I later led mobile engineering, two cross-functional Scrum teams shared one application architecture. Rather than split the architecture to match the team boundaries, I brought the teams together to make domain expertise and technical feedback accessible across the organization. I describe that decision and the broader evolution of our mobile development practices in Transforming Mobile Engineering.

What I’ve learned

Changing an organization can change the software, even when nobody sets out to redesign the architecture. The reverse is also true: if we want a different architecture, we may need to change ownership and communication patterns to make it possible.

That’s why I think of shaping the organization as part of the engineering leader’s job. We should build teams around the work and the technical boundaries we want to support, then be willing to evolve both as we learn.

Conway’s Law doesn’t prescribe a perfect organizational model. It reminds us that organizational decisions have technical consequences.

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, using an approach similar to Tigger (Tig) Kindel’s 5 Ps framework, 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.

Back to Experience & Impact.

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.

Explore more engineering leadership experience.

My role focused on systems engineering and cross-team leadership, not building the machine-learning models themselves.

Adapting an existing controller

I partnered with hardware engineers to explore how an existing CORE1 controller could be modified to run a Hailo edge AI accelerator. Reusing an established controller platform meant working within real hardware and software constraints rather than designing an entirely new device around inference.

Enabling collection of training data

I developed a driver that employees and beta dealers could install to contribute images from their cameras for model training.

The training effort focused on recognizing people, cars, and animals across times of day and environmental conditions. The driver was an enabling piece of the system: it connected real-world cameras to the data needed to develop and evaluate the models.

Bringing detections into the mobile experience

I had the mobile teams build a History section to help customers see what had been happening around their homes. We integrated edge AI detections into that workflow so that a detection could become meaningful information in the product experience, not just an event generated by a device.

Making video processing more economical

As the cost of converting video clips increased, I worked with the Cloud team to replace the Amazon-based video conversion approach with a custom FFmpeg processing pipeline.

That change dramatically reduced conversion costs. I don’t have a verified percentage to publish, but the experience reinforced the importance of evaluating ongoing operating costs as part of system design.

What I take from this work

This was a systems problem that crossed several disciplines:

• Hardware and embedded software: enabling inference on an existing controller platform
• Model development support: collecting representative images from real deployments
• Mobile product development: bringing detections into an understandable History workflow
• Cloud infrastructure: finding a more economical way to process video clips

The important leadership work was recognizing these dependencies, helping teams connect their pieces, and making sure the technology could fit into a useful and sustainable product experience.

Back to Experience & Impact.