Transforming engine data access

The problem

Aircraft maintainers working with Honeywell engines had a data problem. To diagnose engine health, they had to physically connect a laptop to each aircraft, manually download data one engine at a time, and sit with the connection — in hangars that could be freezing in winter and sweltering in summer — while the download ran. The whole process could take up to an hour per aircraft.

Meanwhile, a competitor had already moved to automated wireless data capture. Maintainers knew it.

Honeywell needed to modernize — and do it in a way that actually fit how maintainers worked.

My role

I led this program as technical product owner, responsible for customer access strategy, cross-functional alignment and delivery. The team was six full-time — design, development and engineering — plus shared research, QA and data architecture, and none of them formally reported to me. That is the kind of leadership I've done throughout my career: authority that comes from trust and clear direction rather than title.

UX design was led by Havana Nguyen. UX research was led by Taylor Kostal-Bergmann, who worked across the program as a shared resource. My job was to set direction, make sure the team had real user access and organizational support, and keep a program with a lot of moving parts pointed at something that would actually work in the field.

Getting close to the problem

Before we designed anything, I wanted the team to understand what they were building for. We started internally, working with Honeywell's own field service engineers to learn the product and the domain before we ever went out to a customer. Then I partnered with our business contact at the Honeywell engines facility, who was instrumental in identifying corporate jet fleet maintainers in the Atlanta area willing to talk with us.

I pushed to get engineers and QA into customer environments, not just design and research. It wasn't standard practice for this team, and it took coordination to arrange, but I wanted the people building the software to have stood in the hangar. We visited 4 customer sites, bringing a rotating team of 3-4 people per visit — always UX design and research, and engineering or QA whenever I could get them a slot. When the people writing the code have watched a maintainer struggle with a physical connection in a cramped hangar, they make different decisions.

I also arranged for the team to tour Honeywell's engine manufacturing facility. Watching these machines being assembled — understanding how many systems had to work perfectly together, how much was at stake if something went wrong — gave all of us a deeper appreciation for what our users were responsible for. Safe flights depend on people like the maintainers we were designing for.

What we learned in the field

Maintainers' primary concern was fast access to fault codes and exceedance data. The current process forced them to download one engine at a time, monitor the connection constantly to catch interruptions, and sit with the aircraft the entire time. Data corruption could happen silently, meaning they might not know a download had failed until they tried to use the data.

The hangar environment shaped everything. Maintainers moved between aircraft, used smartphones and tablets constantly, and worked across multiple manufacturers' tools — each engine maker had its own diagnostic software. If a fleet had mixed manufacturers, maintainers were juggling multiple systems just to get a complete picture.

We visited two different kinds of customer, and the difference between them shaped the design. Corporate maintenance teams used the application for basic diagnostics and to flag potential deeper issues. A maintenance repair organization, or MRO, did far deeper diagnostics and maintenance and relied on a different set of screens entirely. Seeing both told us the product had two distinct usage patterns rather than one. We used that to order the interface deliberately: 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, we also pulled data forward from one screen to another so maintainers didn't 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's 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 — it's a root-cause tool, not just a log. On the legacy system it was a dense, undifferentiated list. At a glance you couldn't tell where one flight ended and the next began, which made it hard to spot a fault code repeating across flights.

The maintainers told us directly what would make the screen more useful. They were bouncing between tabs to assemble a full picture, and they wanted the key data brought onto this one screen. Havana designed to exactly that. She added a visual line separator between flight legs so recurring fault codes became easy to pick out across flights, and she brought the data maintainers had been hunting for onto the screen: ITT and fan speed for more granular insight into engine performance at the moment of a fault, MCID descriptions alongside the fault codes to speed up troubleshooting, and altitude to tell ground-related issues apart from airborne ones. The flight separator is subtle by design, and in testing maintainers singled it out as something they valued.

Before anything was built, we tested the designs with both customer types — the corporate maintenance team and the MRO we'd visited. Testing with both mattered because they used the product so differently; a design that worked for routine corporate checks wasn't automatically right for the MRO's deeper work.

What we built

We designed a web and mobile application that replaced the manual download process with automated cloud-based data uploads via Wi-Fi, with a companion Bluetooth mobile app for quick engine health checks in the hangar.

The web interface modernized the engine data viewer across the board, with the chronology screen above as the clearest example: every change traced back directly to something we'd heard or observed in the field.

The mobile app let maintainers connect to nearby aircraft via Bluetooth, initiate uploads, and check engine status quickly without returning to a laptop.

The connection decision

The hardest technical question was how the mobile app should connect to the aircraft. The hardware box sat inside the aircraft, so a Bluetooth signal had to broadcast 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 the more reliable connection.

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 the software 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 — wasn't intuitive for engineers accustomed to fully documenting a design before building anything physical. Shifting that mindset took ongoing work throughout the project, and it was a large part of what I was there to do.

Running a two-site program

The software team and the hardware team worked in different cities, and keeping them aligned was a steady part of the job rather than a crisis. 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 with me 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.

Handing it off

Partway through, I moved into a management role, which meant I could no longer run this program day to day. I handed it to Xander Boston, a product owner intern I was supervising, who ran the day-to-day for about nine months under my guidance. 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.

The application reached a limited alpha with 5 Challenger 300 corporate customers, and the early data was encouraging — the approach was working. Automated cloud uploads reduced engine data access time from 1 hour per aircraft to 10 minutes, giving maintainers faster insight into engine health and freeing them from monitoring a physical connection through an entire download. We ran the full system test with corporate customers rather than the MRO; the alpha was scoped to confirm the core experience worked and get value into people's hands, and it was too basic to be a fair test of the MRO's deeper diagnostic work.

The program I led became the foundation for Honeywell's Connected Engine Data Service, which launched in 2024. By then I had long since moved on, but the lineage from those hangar visits to the shipped product is clear in the work.

What I learned

Getting a cross-functional team in front of real users is worth almost any amount of organizational effort to make happen. The engineers who visited customer sites made better decisions than the ones who hadn't. That's not a coincidence, and getting them there was one of the more valuable things I did.

The maintainers we worked with were some of the best users I've encountered in my career. They were knowledgeable, passionate about their work, and genuinely invested in helping us understand it. They wanted us to get it right as much as we did. That kind of user relationship doesn't happen automatically — it requires building trust, showing up prepared, and treating their time and expertise with respect.

One broader conversation happening across our aerospace team at the time was the idea of a digital engine logbook. We'd discussed it as a potential future direction, but maintainers in the field were cautious. The logbook is a legal document — it traces the aircraft's entire maintenance history and directly affects resale value. Losing it to a corrupted file wasn't theoretical; it was a real concern. That conversation was a useful reminder that users often have very good reasons for holding onto analog systems, even when a digital alternative seems obvious.