The right argument isn't always a technical one.

Sometimes the hardest problems faced in a technical program are the ones that can't be solved with computers and calculators.  Engineers are human, and the best of us can fall into the trap of defending a position that doesn't need defending.

The System

A large aerospace OEM was finalizing work on the development of a major aircraft subsystem.  This was a DAL A component, under the strictest scrutiny, both from the FAA and from the customer, the aircraft manufacturer.

SafeCode's consultant had participated in the development of the software, as well as many of the activities critical to achieving the certification.  This was a large, complex program with multiple engineering groups.  One of those was the company’s RTOS group, comprised of the engineers who had developed the operating system that underpinned not only this system, but several others within the company. In this respect, the RTOS group considered their contribution to be like high-end COTS, a standardized product that could be used by any aerospace program.  They had no direct dealings with the customers; they just provided their RTOS to the various OEM business units.

The Challenge

The RTOS people had provided a certification packet that included all of the documentation that had been needed by past programs.  It seemed to be comprehensive, and it surely included everything the FAA would scrutinize for certification.  The issue was that the FAA wasn’t the OEM’s customer – the aircraft manufacturer was. 

The aircraft manufacturer had asked to see the detailed results of an analysis that had been performed by the RTOS group.  A summary report had been provided in the package, but the summary didn’t “show the work”.  The development group was accustomed to requests such as this.  The customer had full visibility into the development work processes, contractually guaranteed, but the RTOS group was a separate business unit and not part of that contract.

The request struck a chord with the RTOS group’s leadership.  They took a stand – they had no intention of complying with the request.  The aircraft manufacturer was not their customer, after all.  Why should they be beholden to a contract in which they had no part?  The summary report had been sufficient for the certification of other systems in the past. They took the request as a challenge to the integrity of their work. 

The engineers in the RTOS group were the best of the best.  They were often consulted for guidance on hard problems, even when those problems were not OS-related.  They were true experts in the domain.  Within the OEM, there was really no doubt – of course, they had done a thorough and accurate analysis. They were the experts. There was nothing to prove.

So it was a stand-off.  The aircraft manufacturer insisted on the need for the analysis detail; the RTOS group insisted that it would not be provided; and the system development group was caught in the middle.

The program team had engaged with the RTOS group on the issue multiple times. The teleconferences were increasing in frequency. Sometimes the discussions grew a little heated, and the RTOS group remained immovable. The days passed without resolution, and the pressure from the customer was increasing steadily.

SafeCode's consultant was asked to join the talks. He had been helpful in other cases where the biggest problem was finding common ground.

The Approach

He was in the next scheduled teleconference. For this first conversation, he just listened carefully and absorbed as the same positions were restated, and the conversation went in the same direction it always had.

The next day’s teleconference went a little differently. After the first volleys had been fired and the conversational tones started to rise, the consultant stepped in.

He began by fully and sincerely acknowledging what the RTOS group had been saying all along. He told them directly that there was no question that the analysis had been performed thoroughly and accurately. They had nothing to prove – to anyone in this conversation.

He told them that nobody, and certainly not the customer, was trying to show that anything was wrong with the analysis.  The customer wants nothing more than to be able to prove that it was done right.  If it wasn’t – that would be very expensive for them.  They are just trying to show their certification authorities that they are taking this effort seriously and being diligent in their contractor oversight. 

Then he asked the RTOS group manager a question:  If you hired specialists to perform a critical piece of work for you, and you knew, without a doubt, that those specialists had done the job correctly – wouldn’t you still have more confidence if you could look through the log of what was done? Not to verify the work; not because you doubted the result; but because the written record is what lets you see the effort that they put in to achieve the result, and to demonstrate the value to others.

The consultant wasn't asking him to justify his position. He was inviting them to think like a client and to recognize that the evidence wasn't for the people on the call. It was for the program record. For the next audit. For whoever came after them.

The phone line went quiet for a moment.

“Okay.  We’ll get it to you.”

The Outcome

The RTOS group delivered on the promise the following week.

A prolonged impasse was resolved in a single conversation; not by escalating pressure or invoking authority, but by reframing the request in terms the other party could accept on their own terms.

It was one of several occasions on which SafeCode's consultant was asked to step into situations that had proven difficult to resolve.

Corollary Lesson

Technical expertise and institutional authority are not always sufficient to move a technical program forward. Interpersonal resistance, especially when it comes from a position of genuine competence, requires a different kind of engagement. Understanding why someone is resistant, and finding a framing that allows them to say yes without conceding anything is a skill as valuable as any technical one. Sometimes the most important question isn't technical at all.