Building and Evolving Engineering Organizations
Much of my engineering leadership career has been spent adapting organizations to the software and products they need to build. Sometimes that means creating a team for a new technology. Other times it means bringing teams together, improving delivery habits, or helping an inherited team find its footing.
Bringing iOS and Android together
When I started, iOS and Android operated as two separate Scrum teams. The applications needed to behave and look nearly identically across the platforms, but engineers on the two teams weren’t communicating enough. Separate Scrum structures made it harder to coordinate the details that mattered to a consistent customer experience.
Conway’s Law says that the structure of an organization influences the systems it produces. In this case, the organizational boundary worked against a product that was supposed to feel like one experience. I combined the teams into a single Scrum team to remove that barrier.
This did not mean eliminating platform expertise or platform leadership. iOS and Android kept separate managers for their respective disciplines, while the combined team shared one Scrum master and worked together on sprint planning, reviews, and demos. The structure created a shared delivery forum without losing the horizontal management of each platform.
We continued adjusting the process as the team matured. Eventually, we reduced full-team standups to two days a week, while continuing shared sprint planning and reviews. The goal was to maintain the conversations that mattered across platforms without requiring everyone to attend the same daily meeting.
We also raised the quality of our demos. The QA team presented both the iOS and Android demos, making it easier to see and evaluate the two platform experiences together. We put significantly more effort into their polish instead of treating demos as an afterthought.
The leadership lesson for me was not that every iOS and Android organization should use one Scrum team. It was that team boundaries should support the product and the communication it needs. We kept the technical disciplines distinct while removing an unnecessary barrier between them.
Changing the mobile release cadence
The mobile teams were releasing at most once per quarter. A major constraint was testing: QA had thousands of regression tests available but typically had time to run only a few hundred before a release. Larger releases accumulated more changes, which increased the scope of testing and the risk of defects. Waiting longer between releases wasn’t making the software safer.
We changed both how we delivered software and how we validated it:
- Smaller release payloads. We reduced the amount of change in each release, which narrowed the regression testing needed for a given delivery.
- Automated regression testing. We made substantial investments in test automation so thousands of tests could run as part of each build. That freed QA to focus on scenarios and features that were difficult to automate.
- Trunk-based development and feature flags. We moved toward a shared development trunk and put unfinished features behind flags. This allowed us to ship releases to everyone every two weeks, including bug fixes, without exposing new features before they were ready. We could run feature betas on their own schedule.
- Faster bug resolution. We improved the time it took to resolve bugs and reduced the open bug backlog from hundreds to around 25.
These changes made a biweekly release cadence practical without requiring every new feature to be finished on the same schedule. Releasing the software and enabling a feature became separate decisions.
Building a feedback loop with telemetry
We also needed better visibility into how the applications behaved after release. I developed our feedback approach using New Relic telemetry and analytics.
We standardized and documented the events and data recorded by the iOS and Android apps so the platforms measured the same things. We then built dashboards for different areas of the application.
This gave the teams a common set of signals to investigate behavior, identify problems, and improve the product. It also reinforced the value of treating testing, deployment, and observation as parts of one engineering system, rather than separate activities.
Forming the OSD team
When Control4 moved its on-screen display from Flash to Qt, I built a team dedicated to the new GUI work. As the needs of the product organization changed, that group evolved into the OSD and Remote Control GUI team in Belgrade.
The lesson I take from this is that organization design isn’t static. Teams should evolve with their responsibilities and with the architecture of the products they build.
Building a self-sufficient Remote Control team
A new Remote Control GUI team had been hired in our Belgrade office without consulting my organization. The team had a first-time engineering manager, several early-career engineers, and one senior engineer. There was very little Qt experience and limited C++ experience across the team, despite those being central to the work.
We had tried to give the team a technical head start. A principal engineer working on our Qt-based on-screen display (OSD) had prepared the OSD source so the Remote Control GUI could reuse it with a different view layer. Instead, the new team removed that work and forked the code. That increased the amount they had to own at a time when they lacked experience with the underlying technology.
By the time I became directly involved, the team was struggling and two engineers no longer wanted to work under the existing manager. I traveled to Belgrade to address both the organizational and technical problems.
Separating platform work from the remote GUI
I moved the senior engineer and one associate engineer into a newly formed UI-Platform team. They reported to a proven manager with substantial C++ experience, rather than remaining under the Remote Control manager. That manager already led another team and took on this additional responsibility effectively.
UI-Platform had its own technical purpose: extending the Core shared library used across Qt, iOS, and Android. This gave the engineers a productive mission while establishing clearer ownership for cross-platform capabilities.
Once UI-Platform was established, I transitioned it to my Senior Manager, who already oversaw the mobile teams. This helped align shared UI platform work with the teams that relied on it, rather than keeping it as a permanent direct report to me.
Supplying the experience the team needed
I brought a Staff engineer and a Principal engineer with OSD/Qt experience into the Belgrade effort. The Staff engineer became the team’s Scrum master, helping establish a development rhythm where Scrum had not been functioning effectively. The Principal engineer worked full-time on the Remote Control project, providing hands-on technical guidance and substantial mentoring.
That support helped the team make progress and ship the remote control. But the technical improvements did not resolve every management issue. I continued working with the first-time manager; when the problems persisted, we replaced that manager with the experienced leader who had already taken on UI-Platform.
Under the new manager, the Remote Control team continued to improve. Eventually it could operate without the temporary Staff and Principal support, so I reassigned those engineers to other teams where they were needed.
The goal wasn’t to keep senior experts embedded indefinitely. It was to build a team that could stand on its own.
Introducing ADRs through UI-Platform
UI-Platform also became a starting point for an engineering practice I wanted to introduce: Architecture Decision Records (ADRs).
Rather than mandate a new process across every team at once, I had UI-Platform trial it. Their first ADR was, appropriately, an ADR defining the ADR process.
After that initial adoption, I rolled ADRs out across my engineering organization. I then brought the practice to the broader on-device software organization through our Principal Engineering Committee, which included the principal engineers and engineering managers in my manager’s organization.
The process was well received. More importantly, it provided a shared approach to recording technical decisions, alternatives, and tradeoffs while keeping engineers involved in decisions close to their work.
This experience reinforced my preference for piloting changes with a team, learning from the trial, and scaling practices through trusted engineering leaders rather than treating process as an end in itself.
What these experiences taught me
There isn’t one team structure or process that works everywhere. Before changing an organization, I want to understand what it does well, where it’s struggling, and how its boundaries affect product development. The goal isn’t organizational change for its own sake; it’s helping people do better work and creating a system that can adapt.
These experiences are part of the thinking behind my Engineering Operating System.