Over many years of delivering technical training to the embedded systems sector, two questions have always bothered me:
- Why, when the economy gets difficult, are training budgets one of the first things to get cut?
- Why do delegates, who have waited months (sometimes years) to attend training, get pulled off mid-course?
Even though a myriad of articles tell us why businesses should invest in training during an economical downturn (Why Invest in Training During an Economical Downturn?) funding for training is very hard to come by. So why does this happen?
In reality there are only two types of training:
Must-do training is unavoidable or compulsory training that a company must provide for its staff. Must-do training often has some legal requirements and typically has some form of test or certification of attendance. The most common example is First-Aid at work; in the UK Employers have an obligation under the Health and Safety to make adequate and appropriate First Aid Provision for their workforce (First aid at work; The Health and safety (First Aid) Regulations 1981). If a company doesn’t do this then they are liable for prosecution. Another example often considered must-do is company induction training. The consequence of not running induction training is the potential of grievance tribunals for unfair dismissal, etc.
Ultimately you cannot run a business without Must-do training. The upside is that this type of training does not get cut and it is rare to get people pulled off this mid-course. In addition, Must-do does not require justification such as Return-on-Investment (RoI) calculations. Nevertheless, cost is seen as a major factor, so companies often attempt to do this type of training as cheaply as possible, to as many people as possible as shown by the growth of e-Learning in this area (however I do know of cases where bosses have got their PA’s to do the on-line training for them just so they are certified!).
That then leaves us with Everything-else training From a business perspective there is no compelling regulatory or legal reason to perform this training; it is therefore considered non-essential. Typically this training is improvement based training.
So which category does training related to embedded software development sit in? Quite clearly there are no legal requirements to be able to develop software. All technical training is therefore “not essential” and falls under the improvement training umbrella. Unfortunately, many managers (and indeed, companies) see this type of training only as an overhead, which they have to do to keep people happy. Their aim in providing training is to reduce staff turnover and absenteeism whilst keeping cost to a minimum. The classic give-away is any company which allocates $X/engineer/year for training.
The root problem here is that training is seen only as a cost. No attempt is made to understand its true value. Non-essential training is therefore easy to cut funding for and easy to justify pulling people off due to “project pressures”. So how can we attempt to redress this?
Given that most technical training isn’t classed as business critical, let’s investigate why we do improvement training in the first place.
Clearly we have a job to perform: developing embedded systems. This is a collection of tasks that we have to perform; ultimately unsupervised. To perform these tasks we require a set of skills and knowledge appropriate to the task in hand. Thus we can define someone with the appropriate skills and knowledge to take on a task unsupervised as being considered competent.
Unfortunately most people entering the embedded software industry ( including graduates) today don’t have the core competencies to develop software for embedded systems unsupervised. Typically knowledge and skills are developed through the euphemism of on-the-job (OnTJ) training. This ‘training’ typically entails little more than examining existing code, asking questions and modifying or building-on this existing codebase. OnTJ training has been shown to have many problems, most notably (Hands-On Training: A Simple and Effective Method for On-the-Job Training):
- It is inconsistent – typically no goal is defined
- It is inefficient – the hidden cost associated with checking the work
- It is ineffective – engineers inherit poor practices which are then passed on
This leads to engineers developing live projects with a lack of foundation knowledge and unfortunately their mistakes often go into business-critical software.
Herein, companies may look to develop competency through “off-the-job” training (typically through a third party training company such as Feabhas) with an implicit justification that post-course the engineer will be more productive, make fewer mistakes, ultimately leading to less testing and rework.
Hopefully this is all pretty straightforward. Unfortunately here in lays one of our root problems. To engineers, developing and extending their skills through training is a “no-brainer”; yet we still see this type of training being cut. The problem is that we haven’t yet move from a cost-model to a value-model. Even though everyone in the engineering department knows this is a good idea, the accountancy team may believe that attending Stress Management Training is essential to their function and appropriates the training budget (and yes, this has happened again recently).
Central to moving to a value-model is understanding the concept of a value-chain. This is underpinned by a business credo:
Well run commercial companies spend money for one of two reasons:
- to make more money
- to reduce overheads
This may appear very callous, but holds true for the majority of companies.
At the bottom end of our chain is the cost and expense of a commercial technical training course, at the other is our credo. Ultimately we have to link one to another, no mean feat. How do you do it?
Niall has been designing and programming embedded systems for over 30 years. He has worked in different sectors, including aerospace, telecomms, government and banking.
His current interest lie in IoT Security and Agile for Embedded Systems.
Latest posts by Niall Cooling (see all)
- An Introduction to Docker for Embedded Developers – Part 2 Building Images - October 12, 2017
- An Introduction to Docker for Embedded Developers – Part 1 Getting Started - September 7, 2017
- ‘Abusing’ the C switch statement – beauty is in the eye of the beholder - February 2, 2017