The Great Brain Drain

For several decades there has been a concern and a lot of commentary about the loss of “graduate talent” from the UK’s workforce as highly educated and skilled individuals decide to move overseas to pursue their careers. A situation which has a significant detrimental impact on the economy whilst bolstering international competition.

What you do not see discussed as much is the impact of “lower depth and/or quality of understanding and/or skills” which is causing significant challenges to the workforce, especially within the technology field.

By “lower depth and/or quality of understanding and/or skills” I mean that it appears to me that the training IT professionals receive is, over time, becoming shallower as fundamental understanding of how technology works is becoming a “black box” to newly qualified engineers.

The IT sector’s focus has changed to a superficial “fix and move on” mentality rather than engineers fully understanding the systems which they support. Subsequently the training received by new engineers is about how to use existing technologies and not giving them an understanding of how they work.

Initially I just assumed that my observations were a sign I was getting old, that I was expecting too much from young professionals embarking on their careers. But speaking to others I found my peers had a similar concern and then I saw an article in the Telegraph on 29th November which really struck home.

At the recent International Atomic Energy Authority annual conference, Pietro Barabasci, director general of International Thermonuclear Experimental Reactor (ITER) highlighted that much of the knowledge needed to build a new nuclear fusion facility from scratch had been lost. Engineers who worked on the original plants have retired taking the knowledge with them.

He argued that whilst the theoretical scientific papers existed and were well referenced, the steps to turn this theory into reality were not documented as engineers were less likely to document all steps or publish papers.

Barabasci went on to say that the most important work that ITER are currently undertaking is to document how the ITER facility was built with the aim of ensuring that the knowledge of how to rebuild a similar facility from scratch was captured before all knowledge was lost.

Whilst the understanding of Nuclear Fusion is obviously at a different level, there seem to be similar challenges in the provision of IT that fundamentally mirror those highlighted by Pietro Barabasci with Nuclear Fusion.

We can think of the large providers of technology as “The Scientists” providing theory and our core solutions and the local IT provider (external MSP or internal IT team) as “The Engineers” who put that theory / solution into action.

Real World Example #1

• Engineer trying to import thousands of documents to iManage. iManage fails import if document > 255 characters.
• Engineer approach – run import till it fails (waiting hours), fix the one failed file, restart import.
• Result – Process to import thousands of documents requiring potentially thousands of retries taking several weeks.
• No consideration to how to address the file length problem across the board prior to import.

To some extent this situation is driven by the “systemisation” of support functions and the business need / desire to meet SLAs as quickly and financially efficiently as possible. Some of the challenge is generational where the younger workforce wants to “click and go” on what are perceived as mundane work tasks but most of this challenge is about the training these engineers receive and their ability to resolve problems without predetermined “script fixes”

We are essentially training a workforce who are increasingly incapable of basic IT problem solving or lack fundamental understanding of the business applications they are supposed to be supporting or encouraging the best practice use of.

Like the nuclear fusion industry, we are in danger of a situation where a few “scientists” understand the theory but the engineers on the street no longer have the skills to support the solutions if the problems veer off the well documented “normal fix”.  Particularly the skills to analyse problems and develop root cause resolutions are diminishing.

To some extent this is an intergenerational challenge, and it is hard not to be seen as an old-timer harking back to the good old days.

But it is the undeniable truth that the young graduates just starting their careers have a fundamentally different grounding than those of us who joined the workforce 20 or so years ago.

When I graduated as a software engineer in 1998, we had to have a good working knowledge of how hardware worked (hard drives, printed circuit boards, monitors, memory etc) as well as low-level machine code, operating systems and structured programming languages (ok I’m old so this was before the days of Visual Basic etc) and general problem-solving skills.

Most new IT engineers now join the workforce with a strong knowledge of the softer skills such as business analysis, project management, experience in high-level development tools such as python as well as general IT consumer packages.

Some people fall into their first IT job working in a Managed Service Provider on the helpdesk, in which case their induction would likely be addressing issues via scripts and escalating to 2nd line team if there is not a documented resolution. In the world of “quick fixes”, Google, Wizards and “Cut and Paste” coding and scripting, many of our engineers simply do not have the grounding they need to become a fully rounded IT professional.

This is particularly the case with Venture Capital or Private Equity backed Managed Service Providers who have a vested interest in providing commodity services as cheaply as possible. In these businesses the First Line support role will shortly be replaced with a “ChatBox” style solution.

Equally, many of the workforce don’t want to gain those skills. They accept “Level 1 / 2” support roles as a “necessary evil” stepping stone in their career, to be navigated as quickly as possible rather than as a valuable training before moving into more technical or “consulting” roles.

So, what can we do?

As managers and leaders of people we need to consider the environment we are creating. Do we really mean to create a team who just blindly follow documented resolutions, or do we need a team who can understand and diagnose regular challenges.

Spend time with the team.

I would encourage all of the “old timers” who have those “old school” IT skills but are probably now in “off tools” management jobs to spend time shadowing the most junior member of their support team and assess the problem, you may be very surprised how first line support operates.

Initially don’t interfere, just observe but make note of how problems are approached “vs” how you would have approached them.

For example, in our example earlier, exporting a directory list into a CSV to open in Excel to find all files > 255 characters, or mapping the directory tree to a drive letter and looking for exceptions prior to running the import.

Build the culture.

Often there is a culture of “process process process”, the junior members of the team are so used to been managed via ticket numbers / following established procedures and resolution scripts they don’t believe they can think or go off script.

Of course, for common issues it is good practice to have standard resolutions, but we must develop a culture where support engineers have the space to investigate and resolve problems.

Rather than a 1st line “handing over” to a 2nd line to resolve a problem, why not implement a system where the first line retain ownership and work with / shadow the 2nd line engineer to understand the problem and be in a position to address it next time, or at least recognise the issue.

Mentoring

By the very nature of “The Peter Principle” most IT Directors were at one point great technicians or developers, they have a lot to offer in terms of mentoring junior staff.

Instead of mentoring junior staff most IT Directors spend their time with their direct reports (e.g. Helpdesk team leader, head of infrastructure, etc). It may be very insightful for both the junior team member and the IT Director if the IT Director were to mentor first line engineers as well.

Commitment to Training

Managers should closely monitor their team’s strengths and weaknesses and develop training strategies to enhance performance. Training should not just be the standard technical training; it should also entail soft skills such as communication and problem-solving style training.

All engineers should have personal development plans which will enable them to build the skills which will be required as their career progresses. E.g. if a 1st Line engineer’s identified career path is to 2nd line – what technical and non-technical skills do they need to make the transition? Can that training be delivered in advance of the progression?