After having read some thought provoking books and articles on how the world of Technology works (and their leaders think) and having spent time in a field where I am part of a team that works day in and day out trying to do something that is new/disruptive/innovation/use-your-favoraite-buzz-word in the aviation world, I have some thoughts that I wanted to pen down on how to bring those worlds together.

In a highly regulated industry, like aviation, risk of failure is indirectly proportional to what has been done before and what we can be leveraged from the past to rationally and logically buy off the uniqueness or newness of a new program. In aviation lingo, we call this Means of Compliance or MOC.

A happy path for a ‘clean-sheet-this-will-blow-your-mind’ product in aviation looks like this:

Happy Path for a ‘new’ aircraft project

Happy Path for a ‘new’ aircraft project

For a Part 25 aircraft, like a Gulfstream G500 or a Boeing 737, the period from ideation to Entry Into Service is typically quoted at a decade, give or take a couple of years. By the time EIS is happening, technology has progress many folds and STC’s are already in play for various upgrades: be it a USB 2.0 to a Lightning Port upgrade or a high speed internet upgrade, thanks to StarLink. The bulk of product improvements revolve around customer experience and avionics upgrades since what is achievable in avionics outpaces the current regulatory and best business practices, thanks to Moore’s Law and well established industry practices in the Technology world like ‘Ship it and Fix Later’, ‘Fail Fast’ etc.

• In 10 years, we went from an iPhone that was on EDGE to an iPhone that is on 5G.
• In 10 years, we went from having to hook up multiple computers that house internal data in a LAN mode using Ethernet cables to make use of a Terminal based AI solution to GCP and AWS providing out-of-the-box solutions for AI and ML applications for anyone who wants to use these features on data that they have.
• However, in these same 10 years, there are OEM’s in the aviation industry that continue to ask engineers to use Catia V5 on $800 spec Thinkpads to create certification grade 3D models and Test Engineers to create test reports that are based on MS word templates from the 1990’s. And these engineers continue to deliver high quality certification grade work to get the aircrafts into EIS within their program timeline. In my opinion, this is possible because the projects is following a happy path.

What happens when the project no longer follows a happy path?

What happens when the CCL and MOC document sections cannot be agreed upon because the Certification Standards do not exist?

• What happens when there are technologies in the MVP for which testability standards and techniques are not ratified?
• What happens when traditional pilot in the loop testing is no longer possible because of a design decision on the platform or a business case decision for scale?
• What happens when traditional roles of Leadership, Program Management, Regulatory Team and IC in Engineering no longer make sense in the non aviation Tech world?

Chaos happens.

But that is not a bad thing, at least according to those who wrote How Google Works. IC’s in the Technology world are used to this state of being and actually thrive in it.

But, how does (or should) this work in a highly regulated industry where Engineering, Regulatory Team and Leadership/Program Management have to walk in lock step at each milestone between PDR and EIS? I have some thoughts. Most of it builds on the the organizational advice provided in How Google Works but adapted to make it work on a hardware and regulatory heavy project.

• Program Management should build roadmaps on feature delivery and NOT date driven schedule that promises a EIS date.
  • This roadmap should be built in discussions with Regulatory team that is full of talented people who understands the technology space and is able to work with regulatory authorities directly (and not indirectly via Counsel or Legal).
  • If a date driven schedule is followed that promises a EIS date, you risk of delivering a product that is no longer the MVP. This leads to a much longer lead time in ‘Fix Later’ than what the Technology world is used to.
• Test Engineers and HW and SW development engineers are working backwards from a single truth source.
  • Truth sources matter because it cuts down on assumptions. However, this is not glamorous work. This is tedious documentation that engineers have to create in order to remove any and all iota of questionable requirements (or the intent of requirements). This is vastly different from software focused products where some comments in a code is sufficient for most purposes.
  • This is doubly hard because it requires great skill in technical writing. Experience and exposure to good documentation is a good proxy for this. But, experience comes at a price. The price being that you have to hire experienced SME’s and not college graduates who are willing to burn the midnight oil.
  • Organizations that focus on and takes pride on a great onboarding system that orients an incoming engineer to the state of documentation, standards to meet and what the company goals are in the coming quarters and how their unique contributions will help with each. People want to know what their work is being used for. The more straightforward the answer is, the better you build trust amongst them. The more politically driven or ambiguous the answer, the less you build trust with them. No one can help with this but the Program team. No individual manager can get this answer in vacuum.
• Leadership thoroughly understands the space in which innovation is happening, has prominent presence in regulatory and political discussions enabling appropriate risk acceptance from the regulatory authorities by building trust and negotiating on MOC’s.

  • Don’t seek Part 23/Part 25/insert any existing cert basis equivalency where it is not warranted due to the nature of the Operations that the product will be part of.

  • Identify a certification path early on and enable IC’s to stick with it → This is how you earn your pay.

  • Your goal should be to put a product that has Engineering support all the way from EIS to End of Life, not to meet an EIS date that you have been forced to deliver on.

  • Create goals that are tied to unblocking feature delivery and not a date that promises you a bonus.

  • Educate yourself and people above you continuously on what the TRL levels are and what changes in certification pathways are possible to get to EIS earlier. If at all.

  • Admit when you are wrong. A mistaken assumption at your level can have massive repercussions to a project timeline, burnout (especially in the testing teams) and low morale.

  • Clarify roles and responsibilities. Be very intentional on identifying approvers. Not all reviewers should be approvers. Not all approvers need to be managers. The more you run away from this, the worse the outcomes will be.

    <aside> ⚠️ Software focused products thrive on this chaos since new ideas can come from anywhere and implementing them is not an uphill battle. In my humble opinion, this is not possible in a hardware focused product or a product that has to guarantee safety of human life or personal property when in use.

    </aside>

  • Create a culture where you have people managers and not unicorns who you expect to be proficient at technical nuances and exceptional people leaders. Choose one or the other when you are hiring. In my experience, when you hire someone to do both, you get a mediocre candidate in both realms.