Reflections on a Career in Safety, Part 3

In 'Reflections on a Career in Safety, Part 3' I continue talking about different kinds of Safety, moving onto...



Projects and Products



Then moving on to the project side, where teams of people were making sure a new aeroplane, a new radio, a new whatever it might be, was going to work in service; people were going to be able to use it, easily, support it, get it replaced or repaired if they had to. So it was a much more technical job - so lots of software, lots of people, lots of process and more people.



Moving to the software team was a big shock to me. It was accidental. It wasn't a career move that I had chosen, but I enjoyed it when I got there.  For everything else in the Air Force, there was a rule. There was a process for doing this. There were rules for doing that. Everything was nailed down. When I went to the software team, I discovered there are no rules in software, there are only opinions.



The 'H' is software development is for 'Happiness'



So straight away, it became a very people-focused job because if you didn't know what you were doing, then you were a bit stuck.  I had to go through a learning curve, along with every other technician who was on the team. And the thing about software with it being intangible is that it becomes all about the process. If a physical piece of kit like the display screen isn't working, it's pretty obvious. It's black, it's blank, nothing is happening. It's not always obvious that you've done something wrong with software when you're developing it.



So we were very heavily reliant on process; again, people have got to decide what's the right process for this job? What are we going to do? Who's going to do it? Who's able to do it? And it was interesting to suddenly move into this world where there were no rules and where there were some prima donnas.



Photo by Sandy Millar on Unsplash



We had a handful of really good programmers who could do just about anything with the aeroplane, and you had to make the best use of them without letting them get out of control.  Equally, you had people on the other end of the scale who'd been posted into the software team, who really did not want to be there. They wanted to get their hands dirty, fixing aeroplanes. That's what they wanted to do. Interesting times.



From the software team, I moved on to big projects like Eurofighter, that's when I got introduced to:



Systems Engineering



And I have no problem with plugging systems engineering because as a safety engineer, I know if there is good systems engineering and good project management, I know my job is going to be so much easier. I’ve turned up on a number of projects as a consultant or whatever, and I say, OK, where's the safety plan? And they say, oh, we want you to write it. OK, yeah, I can do that. Whereas the project management plan or where's the systems engineering management plan?



If there isn't one or it's garbage – as it sometimes is – I’m sat there going, OK, my just my job just got ten times harder, because safety is an emergent property. So you can say a piece of kit is on or off. You can say it's reliable, but you can't tell whether it's safe until you understand the context. What are you asking it to do in what environment? So unless you have something to give you that wider and bigger picture and put some discipline on the complexity, it's very hard to get a good result.



Photo by Sam Moqadam on Unsplash



So systems engineering is absolutely key, and I'm always glad to work with the good systems engineer and all the artifacts that they've produced. That's very important. So clarity in your documentation is very helpful. Being , if you're lucky, at the very beginning of a program, you've got an opportunity to design safety, and all the other qualities you want, into your product. You've got an opportunity to design in that stuff from the beginning and make sure it's there, right there in the requirements.



Also, systems engineers doing the requirements, working out what needs to be done, what you need the product to do, and just as importantly, what you need it not to do, and then passing that on down the chain. That's very important. And I put in the title “managing at a distance” because, unlike in the operations world where you can say “that's broken, can you please go and fix it”.



Managing at a Distance



It's not as direct as that.  You're looking at your process, you're looking at the documentation, you're working with, again, lots and lots of people, not all of whom have the same motivation that you do.



Photo by Bonneval Sebastien on Unsplash



Industry wants to get paid. They want to do the minimum work to get paid, to maximize their profit. You want the best product you can get. The pilots want something that punches holes in the sky and looks flash and they don't really care much about much else, because they're quite inoculated to risk.



So you've got people with competing motivations and everything has got to be worked indirectly. You don't get to control things directly. You've got to try and influence and put good things in place, in almost an act of faith that, good things in place and good things will result.  A good process will produce a good product. And most of the time that's true. So (my last slide on work), I ended up doing consultancy, first internally and then externally.



Part 4 will follow next week!



New to System Safety? Then start here. There’s more about The Safety Artisan here. Subscribe for free regular emails here.

#Careerinsafety #ishealthandsafetyagoodcareer #ishseagoodcareer #issafetyagoodcareer #issafetymanagementagoodcareer #Lecture #Part3 #reflections #safetycareer #safetyguideforcareerandtechnicaleducation #SystemsEngineering

Simon Di Nucci https://www.safetyartisan.com/2021/07/14/reflections-on-a-career-in-safety-part-3/