Competence and competencies for safety engineers is, in my experience to date, one of the most under-managed attributes of the profession. The best I can recollect is a bland, and self-complied assessment as to whether a safety engineer considers themselves to be a supervised practitioner, practitioner, or expert at certain tasks (without any robust guidance on what constitutes each level).
Despite a wealth of data ‘out there’ (most notably via White Papers from the Institution of Engineering and Technology), I cannot recall encountering a robust framework for how an individual engineer is mentored or developed up that amorphous sliding scale. My reading of the various White Papers suggests the current framework for safety engineering competence can be represented by the framework in the pdf below.
Clearly this is a very meta-level framework, and doesn’t signify what competence and competencies are required, what format artefacts should be in, nor how specific aspects are to be managed. It does, however, provide us with the first step in establishing a robust competency framework for safety engineers – one on which we can build. As technology changes, however, so must the safety analysis techniques and the respective competence and competencies for undertaking them.
I realise I am perhaps using ‘competence and’ ‘competency’ interchangeably, so I’ll will remind myself (and you, dear reader) of the definitions for both (and suitably chastise myself and promise to get it right for the rest of this article):
COMPETENCE: The ability to undertake responsibilities and perform activities to a recognised standard on a regular basis (HSE).
COMPETENCY: A specific knowledge, understanding, skill, or personal quality that an individual may possess. The sum of an individual’s competencies will make up their competence, and it is these individual competencies that are assessed in order to provide an overall indication of competence (IET).
Right, now that’s clear – to the matter in hand.
A long-running debate with regards to safety engineers, is whether one can claim to be a safety engineer without say a relevant MSc (such as ours at York). The simple answer is yes. An MSc doesn’t make you a safety engineer, nor does the lack of a degree preclude you from such a claim. Our MSc is not designed to deliver safety engineers, it aims to deliver creative and intellectual thinkers (which I shall admiringly refer to as ‘Boffins’) back to their organisations with a sound knowledge of the state of the art, and the ability to apply intelligent thought to emerging issues and problems.
An MSc won’t make you adept at carrying out a HAZOP, FMEA, nor Fault Tree Analysis (though graduates will understand their purpose, application, and rationale). We need an entirely different safety engineer for this (a type of person I do admiringly refer to as a ‘Process Monkey’) – a safety engineer who is second-to-none at rigorously applying process both uniformly and consistently; delivering analysis outputs that can be relied upon.
Both types of safety engineer are required, and none is more important or valuable than the other. Listening to the ‘Safety of Work’ podcast from Drew Rae and David Provan, I was interested to note (forgive my paraphrasing) their findings that those who had a degree-level qualification didn’t value experience (as much as the degree), and those with experience didn’t value degree-education (as much as experience). A sad indictment perhaps, but we need both. We need Boffins and Process Monkeys in equal measure – and I hope to prove it!
Leaving the long-running debate of whether safety should be taught during undergraduate degrees to one side for now, we are embarking on an impartial evaluation of what SHOULD happen for the safe adoption of emerging technologies. We aim to establish what is needed (with respect to the competence and competency of safety engineers) and will consider the stages of education this should start from – ranging from apprenticeships through to postgraduate degrees. Moreover, we aim to establish what is required at each ‘grade’ and ‘post’ in terms of the triumvirate of KSB (Knowledge, Skills, and Behaviours), and experience. ‘Behaviours’ here will also consider what assumptions a safety engineer makes about the KSB of the operator/end user – and whether this needs to change; or whether the KSB of the operators of emerging technologies also needs a competence criteria.
Once we know what good practice needs to be for current technologies, the next step – along with establishing ‘who needs what, who needs to do what, in what format, to what end, by what time’ – is to establish meta guidance on how safety engineers can establish (or adapt existing) competency frameworks robust enough to safely adopt emerging technologies. This, of course, needs to be established from 2 main areas (or disciplines if you prefer) of safety engineering:
- Those safety engineers working in the design space (who will argue the safety of a delivered product).
- Those safety engineers working in the In-Service space (who take the delivered product and argue its safety during ‘run time’).
What we need to establish is the competence AND competencies required of safety engineers for all levels, in both spaces. Anecdotally (and from experience) UK safety engineers are often ‘created’ by sideways entrance from another field or discipline, or stumble into our specialisation and embark on a journey that sometimes culminates in completing our MSc in Safety Critical Systems. I am of the opinion that relying on this entrance route to our profession must stop – not least if we are to reduce the average age of safety engineers to one that bars entry to Saga.
So, once we know ‘what’, we will look at ‘how’, and assess the state of current offerings across vocational and academic institutions. In other words, who teaches what, where, and perhaps establish why. Doing so will also allow us to establish whether there is an impending skills and education gap – and make suggestions accordingly.
As a safety engineer, are you a Process Monkey or a Boffin? Do you agree we need both?