We Need to Talk About Engineering

This article is a reproduction of an article published in HindSight magazine issue 33 in December 2021 (available at SKYbrary)

After many years working in and with air navigation service providers (ANSPs) and air traffic management organisations around Europe, talking about work with almost every kind of role from front line staff to CEOs, I notice a curious thing. Little attention is paid to the nature of the work of those that we rely on to keep all the critical technical systems running effectively: the engineers. There are many studies of the work of air traffic controllers, and, of course, professional pilots. But there are very few studies, either published or unpublished, on the work of engineers in ATM.

Few people – other than engineers and engineering managers – seem to talk to engineers about the nature of their work. What is working well in their day-to-day work? What problem situations do they face? What challenges and dilemmas do these present? How do they respond to these? What do they need to make work more effective? Discussions with engineers are rather more along the lines of whether and when things can or will be done. Like their operational counterparts, engineers tend to be associated with ‘getting stuff done’. But how they do it is given little attention.

These sorts of questions are becoming more urgent and critical, especially with the digitalisation drive. Reflecting on the period when I first dipped my toe into the world of engineering in the late 1990s, until now, I get a sense of how much things have shifted. Engineers’ work is changing in a way and at a pace that they have never experienced before. Few outside of their world really understand it.

In this article, I outline five universal challenges that summarise what many engineers from around Europe have relayed to me. These challenges have implications not just for engineers, but for the managers and other staff who interact with engineers, whether in operational, recruitment, training, safety, quality, or other roles.

Challenge 1. Dealing with change and production pressure

When we talk about ‘workload’ in aviation, we usually think about ‘sharp end’ operational roles such as controllers and pilots. But increasingly in ATM engineers are balancing on sharp edge of workload peaks, partly associated with continuous changes in technologies and ways of working with them. Engineers can struggle with the number, scale, and speed of changes, sometimes occurring simultaneously in major software releases. Many people overestimate what can reasonably be achieved by human engineers in the acceleration of digitalisation. Few people, except engineers and their immediate managers, understand the pressure. Unfortunately, the increase in work – both planned and unplanned – is often not matched by increases in people with appropriate expertise.

And engineers have worries, but they rarely seem to talk about them without coaxing. These worries concern many things. Some relate to the nature of the equipment itself, such as lack of redundancy, system readiness for implementation, and use of technical systems beyond design intent. Some relate to the work, such as backlogs, thoroughness of maintenance, and the capacity to deal with unpleasant surprises requiring intervention. Who worries about the worries of engineers?

There can be a delicate and difficult trade-off between innovation (to provide additional functionality) and maintenance requirements, both planned and unplanned. Shortcuts and workarounds – traditionally often loathed by engineers – can become normalised, as efficiency rules over thoroughness (e.g., time for testing during the night). It should be no surprise, then, that surprises happen, sometimes requiring rollbacks to previous software releases, while engineers hunt for latent bugs that may have been introduced several releases earlier. Engineers juggle demands and deadlines, pressures and priorities, and can end up feeling overloaded, sometimes overwhelmed, and often without the kind of peer support that is available to operational staff.

“There can be a delicate and difficult trade-off between innovation and maintenance requirements, both planned and unplanned.”

Challenge 2. Coping with complexity

Engineering in ATM has always been ‘complicated’, reflecting the nature of the technical systems. But engineering has changed significantly in the last decade or so; it is now much more complex. There are now more goals, relating to safety, quality, security, reliability, availability, etc., which can shift in emphasis over time. Technical system structure now comprises a more diverse mix of new and legacy system elements. Crucially, interconnectivity between these (e.g., routings, data streams) is more complex, along with interdependency between hardware and software elements (e.g., tools and applications). The boundary of the system is less well defined, with multiple system environments (e.g., primary, backup, test), and collaborating systems such as data centres, sometimes outside of the ANSP itself. With older, complicated systems, things tended to work much more ‘as documented’. But with more complexity, it is impossible to document everything as one would imagine.

For all these reasons, technical systems are harder to manage. What will be the unintended consequence of a software update on collaborating technical systems? How can we detect problems with code in a software release when there are no obvious consequences until specific operational conditions occur? How can one know in which release a bug was introduced? Should we roll back to a previous software release (which may itself contain bug fixes), or try to find and fix the bug we are presented with now? Just as air traffic controllers can find it difficult to keep a mental picture of traffic in some situations, engineers increasingly struggle to maintain a mental model even of their own technical systems, let alone how they may interact with other systems. All of this requires staff, expertise, and time; all of which are in short supply.

“With more complexity, it is impossible to document everything as one would imagine.”

Challenge 3. Planning and coordination

In operational roles, planning and coordination tends to be over the timeframe of minutes or hours. In technical roles, coordination can be over minutes and hours (for maintenance and testing) through to months and years (for projects). With growing complexity, planning and coordination has become much more difficult, with many stakeholders, both internal and external, who have different demands, knowledge, understanding, tools, terminology, and languages. Because of the interdependencies between systems, where systems depend on other systems to be able to function, systems are more affected by failures of other systems. Without effective planning, engineers can end up overloaded, diverting from one activity to another, and losing track of what they were originally working on. Without effective communication, there can be assumptions and misunderstandings about who is doing what, when, why, where, how, with whom and for whom. This can result in unpleasant surprises.

Challenge 4. Maintaining expertise

Engineers involved in projects and maintenance face a heavy burden in terms of the knowledge and skills required. The knowledge requirements are not fully known, however. And in ATM, much of the needed expertise is developed ‘in-house’ via experience. Engineers obviously need to understand the hardware and software directly relevant to their work now, and the tools, procedures and processes that (should) assist their work. But they also need to have some understanding of emerging technologies that may be relevant to their future work, interdependent aspects of collaborating internal and external systems, and new tools (e.g., for ticketing, communication, reporting). And with increased complexity and interdependency, engineers need to understand at a ‘good enough’ level the system architecture as a whole. Each engineer has a mental model of the structure and behaviour of interconnected subsystems, which may be more or less complete and accurate.

Increasingly, there is also a need know and use new and fundamentally different development approaches and processes that were rare even a few years ago in ATM (e.g., agile software development, compared to the more established waterfall model of system development). This creates a need for different philosophies and practices for different systems. But engineers often lack dedicated time to attend training courses, or even group discussion and reflection.

There is another pattern at work in engineering that does not affect operational staff in the same way: with a need for deep expertise, there is a tendency for some engineers to become ‘single points of expertise’, who are not easily replaceable. This, in turn, affects the resilience of organisations to function in case engineers change jobs, need to attend a course, are off sick, or retire.

Finally, there is an additional trade- off when it comes to expertise. With the need to hire engineers quickly, without the commitment of a long-term contract, contractor engineers help to fill important gaps. But, of course, once contractors leave, they take their existing and acquired expertise with them.

“With a need for deep expertise, there is a tendency for some engineers to become ‘single points of expertise’, who are not easily replaceable.”

Challenge 5. Learning from experience

Learning from experience is as critical to engineers as it is to operational staff. But, in some ways, it can be more difficult. Technical systems for ATM tend to be very reliable, thanks to expertise in design, implementation, testing, and maintenance. When things do go wrong, engineers need to be deeply involved in learning from incidents. This is unplanned work that takes time away from planned work, which may already take engineers to full capacity. Additionally, while a low failure rate is, of course, very welcome, an implication is that learning from failures alone gives a narrow base of experience for learning. This presents a corresponding need to learn from everyday work.

Without such learning, many questions go unanswered. What has worked well, that we should continue or extend? How is work-as-done drifting from work- as-prescribed and work-as-imagined? What has surprised us recently? Again, complexity and production pressure create difficulties for learning from experience, because of difficulties in understanding the technical system, and lack of time and opportunity to invest in learning.

We need to talk about engineering

As managers, air traffic controllers, recruitment specialists, training specialists, legal specialists, or safety, quality and security specialists, how much attention do we really pay to the work of engineers? How much time is spent understanding their work, and our impact on their work? How much effort is spent making it easy for them to do a good job? Whatever your role, it is worth spending some time reflecting on how your decisions impact them, and how you can help them, while they try to help us.

---

Cite:

Shorrock, S. (2022, February 9). We need to talk about engineering. Humanistic Systems. https://humanisticsystems.com/2022/02/09/we-need-to-talk-about-engineering/

Shorrock, S. (2021, December). We need to talk about engineering. HindSight, 33, 36-38. https://skybrary.aero/articles/hindsight-33