Pilot Recruitment and Robots

7-second speed read:

  • Robots already exist in HR
  • Robots can write your CV for you
  • Only humans can convince other humans that a pilot job is cool
  • HR will focus on high-touch tasks

I recently acquired an iRobot vacuum cleaner to substitute me in house-cleaning. It buys me time to write articles here.

While I may be a late adopter in practice, automata creeps more and more into my prattle on airline operations. That seems to spur from human ingenuity finding applications for robotic process automation away from obvious OCC work, the most recent example being human resources.

Robots are already searching for candidates and interviewing applicants with a recorded video for the human to review. 93% of employees would take direct managerial commands from a non-human manager. So, there’s no obvious reason cost reduction will not further their introduction in human resource management, and more importantly, why the humans shouldn’t already figure out what to skills to specialise in once the androids are a daily part of it.


What’s the robot going to be doing in people supervision in the next 5-6 years? What it’s good at: collecting, sorting, and storing data. It will seek the attributes a human decision maker needs (flight hours, valid ratings, medical validity and so on), reducing the candidate to a variable. Considering existing applications in maintenance, it would then not be far-fetched to suggest that by 2025 these same collectors will not only describe who’s applying but also suggest what to do with them (prescriptive analytics) or contact them again based on a forecast of fulfilling requirements at a future date (predictive analysis).

[Perhaps, you will be able to hire one to build your CV? If recruiter robots seek a set of parameters, there’s no reason why a counterpart automated service can’t generate data in a format acceptable to them. A simple chat bot can ask you questions to create a document that you can submit, so you don’t have to (if anyone monetizes this, please acknowledge that you heard it here first!)]

Furthermore, if an HR specialist spends 65% of their time on automatable rule-based processing, they will have to earn their worth otherwise. The AI will still need supervision, so let’s assume only half of the human’s time will be freed up, likely in the application of “soft skills“.
replace you


Source: Readers Digest

Android lack of these is the butt of many sci-fi jokes (see StarTrek’s Data for more) but witticisms haven’t generated corporate profit yet. HR processes have and humans will need to continue creating employee journey maps. In the pre-employment phase, no robot can reach out to schools and convince pupils that the pilot job is cool. Interviews (“Know me, like me, trust me“) will likely still involve hominid interaction and a “high touch” to assist the high tech.

Later on, during the course of one’s career, management will likely be a mixed bag of algorithm and meat intellect but conflict resolution and motivation talks should remain a spur of a mortal’s emotional intelligence. New roles for employees may be suggested by digital assistant analysis but involving a pilot in tasks not fitting their primary occupation will still need creativity that machines have not demonstrated.

Perhaps some of us will be involved in automating ourselves out of a job and into retirement. At least until now, this path has not been a zero-sum game, leaving undiscovered opportunities to claim.

Flight Operations Challenge…


The Blame Game, Robot Edition

10-second speed read

  • Blame is…you
  • Automation means money
  • RPA is not for everything
  • Brainstorming Culprit ex Machina
  • The accountability concept and no fatalities

I was talking to an acquaintance about an IT system installation project and she identified a most important element of the process being no one getting blamed for delays. As system implementations go, this one had taken longer than planned and at a much higher cost. Did the consultants take the “no blame” aviation concept and adopt it into an IT implementation because of the sector in question?

It seems they kept the bigger picture (having a tool instead of not). “Blaming…is more than just a process of allocating fault. It is often a …[means]…of shaming others and searching for something wrong with them…[providing]…an early and artificial solution to a complex problem….a simplistic view of a complex reality: I know what the problem is, and you’re it.”

The “no blame” concept did originate from high reliability organizations where a high survival rate is essential for the company’s existence and one of which was the subject of our discussion. However, it is not easy to implement even in most such environments – just review search results for “implementing a no-blame culture in medical services.”

One indirect means to remove blame is to replace humans with automation – it’s hard to argue with an algorithm when it does not have instructions how to answer. As aviation-centered high reliability organisations demonstrate, robotisation means results:


Source: Flintsch, 2000

Removing humans does not have to be a seeming “silver bullet” though. The American engineer W. Edwards Deming demonstrates that 95% of variation in the performance of a system (organization) is caused by processes in it and only 5% occurs because of its participating actors. As autopilots and autothrottles show, for the time being robots can replace some mundane tasks: “RPA works best when application interfaces are static, processes don’t change, and data formats also remain stable – a combination that is increasingly rare.” Actually, about one in twelve of the implementation managers are redesigning processes to be managed by the same robots (I had another discussion on robotic process automation with another acquaintance and it seems it’s only appropriate in 30 to 40% of cases).

While “no blame” is not frequently used even during the IT implementations that lowered the fatality rate, the fashionable “accountability” alternative concept has emerged: “viewing…[errors and shortfalls]…as opportunities for learning and growth.” And one first area where this can be applied is in programming the robots (just ask any engineer in charge of software loadable parts). There are still ways to find culprit ex machina:

  • Programming bias – “the machine we build reflects how we see the world…consciously or not
  • You get what the data gives you – your training sample will teach only what it has, not more
  • Further on that, once the automation/robot has made a decision, whose responsibility are the results of this choice? Drones, for example, require a human commander – for now.
  • In that vein, will robots have to get together and invent a set of governing laws for themselves?

Will using robots be the ultimate no-blame implementation because it will lead to a 0% fatality rate?



The Bot, the Airline, and the Airport

Fifteen-second speed read:

  • Airport aeronautical revenue could be increased through service improvements
  • Bots may be best-suited for this challenge
  • AI initiatives face three main limitations
  • Becoming data-driven will have side effects

The term “airport” first appeared in a newspaper in 1919, referring to Bader Field in New Jersey, a pioneering parking spot for both sea and land-based craft. Since inception, this infrastructure point has been associated with dynamism and development both in popular culture and in business studies. Now it may continue its leadership by providing a perfect base for developing artificial intelligence systems close to resembling magic and earning more money from it.

Understanding this claim requires a bit of background. A well-run airport extracts as much as possible from its two revenue sources: aeronautical and non-flight operations fees. Charges in the latter have been argumented by among other reasons improvements in service quality (eliminated flow bottlenecks, easier shopping, needing finance for better connectivity to the port, and others). Pricing for the former has been growing for some time in search for market equilibrium and since there is a lack of substitutes for places to land or refuel an airplane unlike, e.g. leaving a passenger’s car at home instead of at a long-term parking closer to a runway or city centre versus duty-free shopping.

The two direct users of an airport’s services, airlines and passengers would of course like to get value for being charged more. Service improvements constitute one reason to raise fees. But while focus on serving the consumer qualitatively may justify markup and serve marketing goals well, the business-to-business segment does not usually make the news. Could it be because not much changes in it?

Probably, since elements of service demand from one business to the other have not changed much since Bader’s Field opened. Here’s a proposed list of Service Level Agreement items required from airports by airlines:

0. Infrastructure at quality (no potholes, clear NOTAMs, reasonably reliable weather predictions)
1. Efficiency – speed of ATC handling, quick provision of ground power, higher electrical supply on demand,
2. Punctuality – a delay minimisation approach,
3. Space to grow passenger volume (including baggage belts, check in desks, security checkpoints),
4. Security of its assets while on premises.

Demand details may vary, depending on the full suite of services on tender. Charging for their quality of provision has been studied already but without detailed consideration of IT multiplier effects. Here is a short attempt: Information Technology cannot increase the amount of space offered (some are trying to circumvent the need for extending it altogether by outsourcing services to people’s homes). It can certainly assist in analysing what to focus on and how to effectively manage infrastructure quality (0), punctuality (2) and asset security (4).

Another potential means of raising charges could be efficiency increase in aircraft handling (1) to improve customer satisfaction. This would include optimal parking and ground handling vehicle organisation with statistical proof that the airline operation gains revenue from the process.

To illustrate, let’s take the example of an aircraft arriving late with a large number of connecting passenger: the planes customers have to run and connect to could be automatically clustered at adjacent gates for shorter sprints. Meanwhile, ground handling units approaching from behind and right of the parked plane could be automatically queued, so the PRM service goes first, reaching the front right airplane door where the special passenger is before others; the catering one could be last as it has to reach the rear left door; and all their movements could be tracked via image recognition on existing apron-side cameras and in-vehicle GPS. QED with enough digital data sources combined with an analysis engine.

All this has already been possible but at the profit margin diminishing expense of hiring additional staff to supervise operations. Now, the Big Data challenge could be automated with the coming of age of self-learning bots, so more one-time technology purchases and not a continued highest cost element (direct personnel) increase.

A disclaimer must be considered when evaluating this idea since this feat does not appear to serve every operation equally well. Scale, Skills, and Data are essential:

  • The problem will need to be well-defined and narrowed in Scale. The one suggested here is an algorithm directing aircraft and ground handling vehicles optimally around an airport to increase passenger service quality,especially in irregular situations.
  • In combination, there should be about one hundred thousand aircraft movements per year for learning Scale (an arbitrary number for illustration; each provider must seek their own data threshold). If the airport serves ten airplanes per month, the investment into a bot to learn past aircraft and ground vehicle movements and direct new ones based on estimated quality increase will likely not repay itself.
  • Sufficient internal or external Skills talent – the AI field has not blossomed as quickly and diversely as one would expect because of a 50% lack of talent supply.
  • There should be a large enough input stream of Data for the bot to process – automated tracking of movements through camera images, recording of action start and end times, passengers reporting satisfaction levels continuously and so on. And once it gets going, the software agent will need supervision.
A concluding consideration and the key takeaway may not be the artificial intelligence application itself but its effect of driving digitisation – once process inputs become binary (i.e. the airport is data-drivennew use cases will spring up. And if a bot is faced with a well-defined problem to apply data to, answers about better customer service from both airlines and airports as well as means of increasing revenue from them might just emerge.

Flight Operations Challenge…


What Are You Going To Do When They Come For You?

Like most people, I think the ubiquitous robot future is exaggerated. While headlines about machines going to take over our lives are everywhere, the associated artificial intelligence challenges abound and history suggests the economic party always continues with the machines going hand-in-hand with labourers anyway.

But, for the sake of a hype’s devil’s advocate, if you were leading a flight operations department in a reasonably-sized airline (not your uncle Tom’s Air Taxi with a PC-12 but an enterprise where 20+ aircraft can form an actual line in the air), where would you start to replace humans? After all, your basic job is maintained adherence to safety standards and optimisation of processes (and a potential 30% return on investment within a year): the soulless, salary-free, 24 hour-a-day working product of robotic process automation, once set on “repeat”, never stops for a bathroom break. Assuming a constant rate of scientific and engineering evolutions, you’d focus on standardised, high-volume, low time-consumption task and in 10 years we’ll have:

  • Flight-related tasks at 40-80% without human intervention, depending on willingness to invest.
    • Pre-flight preparation: manual tasks on the way out (or almost completely replaced through management by exception).
    • In-flight monitoring: minimum intervention and management by exception through constant connectivity and adapted aircraft (i.e. with intermediary adaptation layer installed even on older equipment because of the benefit of process efficiency and resulting competitive advantage).
    • Flight and cabin crew: difficult to replace in the foreseeable future for varied reasons (required human interaction by other humans, currently manufactured equipment standards, security issues, insurance requirements).
    • Post-flight processing: completely automated with no paper involved. Humans would only be needed for final decisions and to talk to other humans.
  • Regulatory compliance/manuals updates/documentation follow-up: automated, partly through higher levels of external auditing.
  • In cooperation with the head of ground operations: 90-100% process automation within 10 years (a USD 100 billion market without robots).
    • Baggage vehicle drivers, loaders, unloaders: replaced by self-driving vehicles and robotised assistants.
    • Fuelling service: same.
    • Toilet service, cabin cleaners: what’s not to automate and reduce costs by?
  • Together with the head of maintenance – 60% human-free by 2030:
    • Routine checks: droned already.
    • Fault analysis: much less engineering staff required through automated sensor processing and automated situational analysis. Final intervention by humans by exception.
    • Repair: depends on the devil in the details but can certainly be automated.
  • Emergency situation response teams: used in specific situations such as explosive device dismantling but generally a high degree of interaction with people required, so still largely human. 20% of decision support (and possibly a degree of manual coordination) could be removed in 10-20 years.


Source: Robotics Tomorrow

On a side note, that means that, save for maintenance downtime, airspace congestion, and airport regulations, operational expansion would become considerably cheaper (I’d estimate 27% in labour cost reduction of the average 34% airline expense with a corresponding direct operational cost (fuel, depreciation) increase).

So, what’s an honest flight operations worker to do in 10 years? The robot may not have a plan but you do:

Step 1: list your job’s functions in great detail, from the mundane (“create weekly punctuality chart”) to the highly complex “negotiate new ground-handling KPIs based on repeated delays due to their statistically-substantiated understaffing policy”.

Step 2: Look for high-volume highly standardised low time-consuming actions to figure out what can be automated initially. I’m not referring to reading e-mail but e.g. approving reimbursement claims, driving a GPU to an airplane – same process day in and day out and therefore soon to be performed by a being that does not tire or require pay. Cross these out.

Step 3: The entries without a line through them show your upper hand.

(Step 4: Assess if your manager and his/her manager is a risk taker since this outsourcing will take some entrepreneurial initiative to start).

dilbert robot

Source: Dilbert

I can start: can a robot write this blog? Probably not. It can seek examples of safety improvements in other industries and suggest other new information while I sleep (compiling information lists) but to apply concepts such as RPA to flight operations requires me. The recipient (could it be an automated posts crawler?) should not see the difference but hopefully they will have enough time to create something of their own based on my conjectures (that’s why I look forward to your comments below!).

All this panic seems to me misses another point: the future may not be AI-based but IA-focused. History suggests the machines will augment your intelligence in order to free your time and liberate cash to e.g. implement customer service in-flight initiatives (that is what emotionally deprived sentinels can’t do). So, if the robots could allow you to create your own job of the future what would your Kraftwerk be? Start drafting it now and get background preparations ready (i.e. study for it) because they’re already here.

Flight Operations challenge…accepted.

What Has an App Ever Done for You?

A Wish List

There’re two ways to go about appifying your professional pilot life: the overhaul approach and the immediate gratification, solve-an-issue-at-hand one. Most (including this post) fall in the latter.

Incremental innovation has already started in general aviation: you can now handle most aspects of VFR flying through your phone, log your hours and use your tablet as an extra pair of instruments (I’m only linking to apps I use). And why not? 21st century pilots have a different set of skills for the more technologically-sophisticated machines coming off factory lines (those deep in IT front lines I’ve talked to don’t use such adjectives because the specs are five-plus years old).

But we all know this. Instead of a list of my lifestyle choices, I would like to offer a set of ideas what would solve real airline flight operations challenges using a connected tablet or smartphone now part of everyday operations. I hope someone will comment that most already exist.

  • FOC app 1: Which runway? We’ve all been there: parked at a stand near the midpoint of a single-runway airport and weather conditions permit either direction for departure. Personal experience usually resolves this (aka your gut feeling) but I vouch that it can be quantified with a combined crunch of your company’s past fuel burn (operational statistical database) along either direction, a quick weather analysis along one’s route, and current ATC traffic data.
  • FOC app 2: What delay remedy? The possible actions pilots can take if their departure gets delayed are not monumental. Given situational data at the last point of connectivity, a tablet can offer optimal solutions for such a situation (or at least an operations control centre recommendation): higher cruise speed, rerouting, delaying departure even more, diversion (perhaps through a subscription on-request-based charge?).
  • FOC app 3: Which airport? When it comes to computing outcomes from a large set of restricting conditions, machines are unbeatable. Given the right data, a tablet should be able to provide the most adequate and suitable aircraft destination in case of an engine fire (a performance model, current aircraft position and status, weather and facilities at reachable options). The only major issue would be of data quality.
  • FOC app 4: Extra instrument backup – in an ideal world, the tablet’s screen can be connected to the ARINC 629 bus and therefore an additional stand-by instrument backup for electrical supply failure can be created. If the fabulous expense for such a Type B application does not justify the “nice-to-have”, maybe using the device’s internal accelerometers could be a compromise? I agree the instrument replications are not very reliable (though my test flight of an app that claims to provide this in a glider was great fun!) but I see this as a question of engineering over time.
  • FOC app 5: Digital NOTAMs: Survey a group from all walks of pilot life about one adjective to associated with Notice to AirMen: unreadable. Eurocontrol’s initiative to digitize these from 2010 got nowhere. Portable devices can handle graphical representation (e.g. closed taxiways on an airport chart; active restricted areas mashed on Google Maps) and briefing systems can track whether a pilot flew the same route the day before and has read the text. The best explanation on this so far is as with many other ideas that it’s too high development cost for a nice-to-have.
  • FOC app 6: Where are the flight’s ground services/luggage/passengers? If applications can direct ground staff to flight assignments, they could also report service status to a pilot-in-command. Better yet, there could be two-way communication.

Most of these require a large store of statistical data and extensive computational analysis locally, which does challenge the available portable hardware. Still, they are already possible.

Yet, is there any point in “nice-to-haves”? If you take three of your airline’s pilots, one data analyst and one app developer in a room to see what the front-end operator group needs that the back-office could deliver – the results should save you time and money (and I’d be glad to hear about it!).

Flight Operations Challenge…Accepted.

EFBs Don’t Matter

When you need to hang a painting, you don’t think about the nail, you just hammer.


Once upon a time (2003), the Internet was full of jokes about the iPad. Just the name, containing the word “Pad” gave way to innumerable memes (disclaimer: one was mine).

The little tablet that could did not die in humour heaven but grew into a “didn’t know you needed it till you got it” general users’ unicorn. And then, five years later (2008), it appeared as a tool in the pointy end of an airplane (disclaimer: I still don’t own one but my superiors force its use).

It’s now been 11 years since MyTravel (later part of Thomas Cook) pioneered the use of an iPad as an electronic Technical Log (ok, trialed), so a review of the success score of these devices is in order. However, Googling “EFB project failures” and related terms does not yield an obvious answer (why look for successes when planning an IT transformation of operations?).

Either EFBs provide an implementation unicorn as well, or the question is phrased incorrectly. If “the average large IT project runs 45% over budget, 7% over time, and delivers 56% less value than expected.” (McKinsey and The Project Management Institute), how does this magic bullet work?

To paraphrase Nicholas Carr, it doesn’t because the ammunition does not matter. You don’t think about a nail when hanging up a painting, you just hammer.

Perhaps the failure as such does not exist, only the efficacy of utilisation of the iPad (or Windows, or Android tablet). Does the EFB fit with a general operational digitisation strategy as an end-tool of two-way communication? If paper provides the same result, why change?

I would eagerly like to know how the following experiment goes for you: put an IT analyst, a Flight Ops engineer, a Pilot, and a Business Analyst in a room to find out how tablets fit in your operation (disclaimer: I’ve yet to hear of an airline that’s done this). Do not let them leave the room without 6 milestones the devices should deliver on.

What’s to fear? The technology will be obsolete in 3 years (MyTravel assumed so already in their pioneer project) but the addiction to convenience will not fade. A designated project owner (an EFB Manager) would be able to transform an implementation into a learning experience (since clearly, there’s no documented failure).

While we’re brainstorming possibilities, how about suctioning from this digital data source via a central enterprise data service bus? What if the iPad could feed data into a standardised format for a live company health dashboard, together with devices for technicians (eTechLog), sales agents (order log), customer feedback terminals (at the airport, online), on-board sale web-based order forms?

Flight Operations Challenge…Accepted.

Big Data, A Stick

dsc05804Airplanes streaming half a terabyte of data per flight…83% of travellers having a smartphone and generating three gigabytes per month…every backoffice system storing eons of log files…

“The Big, Complicated Tomorrow has arrived” say business theorists. “It’s data-driven.”

“What’s brown and sticky?” say I.

A stick.

Because technically, tomorrow becomes reality at midnight every day. And Big Data is just a stick.

Wooden poles have been around for a very long time and so has the idea of the data-driven enterprise (the 1970s, oddly a date some iPhones consider The Big Bang of computing, meaning they crash if you try to reset them to any earlier time). Now, however, there are more sources with an increased volume flowing per information channel.

And if we live in the information age, that of tidal waves of data continuously crashing over (and into) us, what are we so well informed about? Well, I say it depends on how you apply the wooden tool.

A stick pokes, digs, and uncovers unseen gaps. Let’s take an imaginary 6-hour sector which arrives late 65% of the time in the last 2 months. Reports to Operations Control dispatchers indicate that ground staff does not have enough time to prepare the aircraft during turnaround. Ground services have reported that police have to first remove at least two drunken and unruly passengers per arrival, hence the rotational delay.

A more involving question would be “Why in the last 2 months?” Let’s expedite the imaginary discussion: catering has started to load 30% more alcoholic drinks since the start of the new season combined with “in-your-face special offer” adverts, hence higher sales and QED.

Investigating this has taken two full weeks of the OCC manager’s time. Correlating the digitalized data sources (delay times, load factor, cause of police intervention, cost of postponed ATC slot) with the (initially unsuspected) catering company reports has been a manual task, not least because incoming and outgoing merchandise gets noted using pen and paper (a copyrighted process). This assembly has been required to answer the next and most important question: how much to reduce the volume of alcohol available without impacting sales considerably and simultaneously reducing the delay which started the investigation.

Here, a digitization gap cracked open without even focusing on Big Data’s preferred fuzzy source milieu (in this example, product placement).As with all digital fads, Captain Obvious would suggest to first establish where the enterprise should be in order to create senior-level guidance.

To get you started on creating magic with The Stick, I propose an action plan:

  1. Call in an Ops Engineer, a Technician, an IT Analyst, a Flight Dispatcher, a Sales rep,
  2. Ask each one to name the biggest (in terms of volume) source of data they would not be able to live without on a Post-IT. Even better, make the preferred origin an unstructured one.
  3. Stick these on a white-board table with the following columns:
    1. name, source, size, data type, transmission mechanism, storage point
  4. Ask each one to name what that parameter could be used for if anything could be done with it. Inter-connected (aka chewed) with others into a KPI,printed on a banner at the entrance, fed to an unstructured data analyser: anything.
  5. See if (and let me know if) anything interesting comes out.


Flight Operations Challenge…Accepted.