The problem
Maintainers spent 30 minutes to an hour sitting with each aircraft for manual engine downloads, and a competitor had already automated it.
Honeywell is a multinational technology and manufacturing company. At the time, its aerospace business made aircraft engines, avionics and related software, and this program covered software for the HTF7000 and TFE731 engine families, which power business jets.
To diagnose engine health, maintainers had to connect a laptop to each aircraft and download data one engine at a time, sitting with the connection in hangars that could be freezing in winter and sweltering in summer. Customers told us the download took 30 minutes to an hour, and the maintainer had to stay with the aircraft the whole time.
The tool ran only on Windows 7 laptops that were hard to get IT teams to support. Pulling data needed a kit of cables and connectors attached to ports inside the aircraft, and the laptop and cables had to be carried aboard in case of a maintenance issue, adding weight and taking cargo space on a small business jet.
In our research, 2 of 3 corporate flight departments found the manual download tedious. All of them moved the data by USB stick and email, a file could corrupt without the user finding out until the end of the process, and one user said a channel would not download about 1 in 3 times. A competitor had already moved to automated capture, and maintainers knew it.
"Requiring manual connection for engine downloads is obsolete."
A maintainer, early in our researchHoneywell needed to modernize, and do it in a way that actually fit how maintainers worked.
My role and the team
I led a nine-person program and its customer access without a reporting line; design and research were led by teammates.
I led this program as technical product owner. I directed the work of design, research, engineering and QA without managing the people; I managed products, not people. I was responsible for customer access strategy, cross-functional alignment and delivery, and I managed to the $1.3M program budget, which was mostly staffing.
The team was nine people: six core (design, development and engineering, with design dedicated) plus shared research, QA and data architecture. UX design was led by Havana Nguyen and research by Taylor Kostal-Bergmann. The software team was in Atlanta, and the engines hardware team, who owned the physical unit, was in Phoenix.
My job was to set direction, secure and coordinate the customer site visits and keep a program with a lot of moving parts pointed at something that would work in the field. I reviewed Havana's designs, sat in on sessions with field service engineers and helped shape the research, including the follow-up visit to the repair organization. Taylor wrote the test scripts and ran the tests.
Three constraints shaped the work: a two-site, two-discipline team; a highly regulated industry, where security concerns shaped the connection choice; and a team that built machines, not software, so agile working was new to many of them.
Getting close to the problem
Getting engineers and QA into customer hangars, not just design and research, changed the decisions the team made.
Before we designed anything, I wanted the team to understand what they were building for. We started internally with Honeywell's own field service engineers, learning the product and the domain before going to a customer, so that customer time went to real questions. Then I partnered with our business contact at the Honeywell engines facility, who identified corporate jet fleet maintainers in the Atlanta area willing to talk with us.
I secured and coordinated the customer site visits and pushed to get engineers and QA into customer environments, not just design and research. That was not standard practice for this team and it took coordination, so I treated it as part of my job and pushed for slots. We made 4 customer site visits with a rotating team of 3 to 4 people, always UX design and research, plus engineering or QA whenever I could get them a slot.
I also arranged a tour of Honeywell's engine manufacturing facility. Watching the machines being assembled gave the team a feel for how many systems had to work together and how much was at stake for the people we were designing for.
What we saw
Maintainers' main concern was fast access to fault codes and exceedance data. We saw downloads that could fail silently, constant monitoring of the connection and a work environment where maintainers moved between aircraft with phones and tablets and juggled several manufacturers' diagnostic tools.
One engineer had been skeptical of some of the design work we were doing. After he saw what customers were working with in the field, he became much more interested in the work and more proactive about talking through what he was building with UX.
Turning field findings into design
Two customer types used the product two ways, so we ordered the interface for both and built the chronology screen from what maintainers asked for.
We visited two kinds of customer. Corporate maintenance teams used the application for basic diagnostics and to flag deeper issues. A maintenance repair organization, or MRO, did far deeper diagnostics and relied on a different set of screens entirely. One product served two usage patterns, and a design that worked for routine corporate checks was not automatically right for the MRO's deeper work.
Havana ordered the interface around those two patterns. The first tabs were the ones corporate maintainers reached for in routine work, and the deeper-dive tabs came after, where the MRO would live. Where it made sense, data was pulled forward from one screen to another so maintainers did not have to hunt for it.
A screen shaped by what maintainers asked for: the chronology view
The chronology screen shows everything that happened with an engine from takeoff to landing, and it is a critical screen for both field service engineers and maintainers. They use it to track how faults recur across multiple flights and to line that up against maintenance records. On the legacy system it was a dense, undifferentiated list, and at a glance you could not tell where one flight ended and the next began.
Maintainers told us they were bouncing between tabs to assemble a full picture and wanted the key data on this one screen. Havana designed to exactly that. She added a subtle visual separator between flight legs so recurring fault codes became easy to pick out, and she brought onto the screen the data maintainers had been hunting for. ITT and fan speed give more granular insight at the moment of a fault, MCID descriptions alongside the fault codes speed up troubleshooting and altitude tells ground-related issues apart from airborne ones. In testing, maintainers singled out the flight separator as something they valued.
Every change on this screen traced back to something we heard or saw in the field. Before anything was built, we tested the designs with both customer types, the corporate maintenance team and the MRO we had visited. Testing with both mattered because they used the product so differently.
What we built
Maintainers got a phone alert when an upload finished and could review engine health from anywhere, not just in the hangar.
We built a web application and a companion Bluetooth mobile app that replaced the laptop-and-cable download with automated cloud uploads. The web interface modernized the engine data viewer across the board, with the chronology screen as the clearest example.
The mobile app let maintainers connect to nearby aircraft by Bluetooth, check engine status and fault lists and start uploads, with clear states for uploading, failed (with retry) and complete. The aircraft uploaded to the cloud once it connected to Wi-Fi, so data collection could start as passengers deplaned. Maintainers got a phone notification when an upload finished and could check high-level engine health in the mobile app. Anything concerning they could review in the web app from anywhere.
Leading the build across two sites
I kept a two-site program aligned through weekly cadence and logistics, and put my disagreement on the record when the Bluetooth call was not mine.
The hardest technical question was how the mobile app should connect to the aircraft. The hardware unit sat inside the aircraft, so a Bluetooth signal had to pass through the aircraft's metal skin, which made reliability a real question. I asked our lead engineer, who had deep hardware and software experience, to evaluate the options. He made the case that Wi-Fi would be more reliable.
The engines hardware team, who owned the physical unit and the connection decision, ruled Wi-Fi out over security concerns in a highly regulated industry and designated it for cloud upload only, once data had already left the aircraft. I disagreed with that tradeoff and raised it, but the decision sat with their team, not mine. A separate team built the box; we built the software. So I made sure my concern was on the record, and then we built around Bluetooth because that was the call that had been made. Leading without authority means knowing the difference between the calls you own and the ones you can only influence.
The other challenge was cultural. This team built machines, not software. Agile development (build something, test it, learn, iterate) was not intuitive for engineers accustomed to fully documenting a design before building anything physical. Shifting that mindset took ongoing work throughout the project.
The software team and the hardware team worked in different cities, and keeping them aligned was a steady part of the job. Key people traveled to Phoenix frequently, I ran a weekly call with the engines team's leadership and filed a weekly program update, and their leadership came to Atlanta often. The engineers had sample units in Phoenix that we needed to test the software against, and on one of my trips I brought units back so the team could keep working. A lot of program leadership is that kind of unglamorous logistics: making sure the people doing the work have what they need to keep moving.
Testing, running the alpha and handing off
I ran the limited alpha, then handed the program to a junior product owner I supervised.
We tested internally first, deploying the software to Honeywell test aircraft for real-world evaluation and refinement. Then we took it to customers in a limited alpha with 5 Challenger 300 corporate customers.
I ran the alpha in January 2020, while Xander Boston, a product owner intern I was supervising, onboarded. In March 2020, I moved into a management role and could no longer run the program day to day, so I handed it to him. He ran it day to day under my guidance until he left in August 2020, when the Phoenix team took over the program. We synced at least once a week, and he reached out whenever he had questions. All the in-field design and testing had happened while I was leading. COVID arrived around the time of the handoff, so no further field visits happened and the program slowed as the industry adapted.
Delegating a live program to a junior person, and staying close enough to support him without taking it back, was its own kind of leadership, different from running it myself and in some ways harder.
Outcome
In the alpha, a 30 to 60 minute manual download became an automatic upload of 1 to 10 minutes, with a phone alert when it finished.
Alpha maintainers timed the work themselves. The old download took 30 minutes to an hour, with the maintainer sitting with the aircraft. The new upload ran on its own: about 1 to 2 minutes per upload for fewer than 10 flights of data, and 5 to 10 minutes for the larger batches maintainers used to download about twice a month. These are self-timed numbers from alpha users, not a controlled measurement.
The alpha ran in January 2020, and I ran it while the intern product owner was onboarding. The full system test used corporate customers rather than the MRO, because the alpha was too basic to be a fair test of the MRO's deeper diagnostic work.
The program became the foundation for Honeywell's Connected Engine Data Service, which launched in 2024. I had long since moved on by then, so that is lineage, not an outcome I delivered, but the line from those hangar visits to the shipped product is clear in the work.
What I learned
Put the people building the product in front of the people using it.
- Get the builders to the users. Getting a cross-functional team in front of real users is worth almost any amount of organizational effort. The engineers who visited customer sites made better decisions than the ones who had not, and the skeptical engineer became one of the most engaged people on the team.
- Earn trust with expert users. The maintainers we worked with were some of the best users I have encountered. They wanted us to get it right as much as we did. That kind of relationship is built on trust, preparation and respect for their time.
- Respect the reasons for analog systems. We had discussed a digital engine logbook as a future direction, but maintainers were cautious. The logbook is a legal document that traces the aircraft's entire maintenance history and affects resale value, so a corrupted file was a real risk. Users often have very good reasons for holding onto analog systems, even when a digital alternative seems obvious.
- Know which calls you own. Leading without authority means knowing the difference between the decisions you make and the ones you can only influence, and making sure your concerns are on the record either way.