[SystemSafety] Safety Culture redux

[Martin, BJ]

That there is a great argument package Les - told in a very enjoyable read. Slip it into a professional Engineers journal virtually as is, to broaden the argument on STEM teaching priorities.

--
BJ Martin
MIEAust, CPEng (Mech, Leadership& Mgt), NER 
Safety and Certification Capability Lead
   

Nova Systems
12 Mildura Street
FYSHWICK ACT 2609 Australia
www.novasystems.com
M +61 1 414 354 487
   
-----Original Message-----
From: systemsafety [mailto:systemsafety-bounces at lists.techfak.uni-bielefeld.de] On Behalf Of Les Chambers
Sent: Tuesday, 27 February 2018 11:25 AM
To: systemsafety at lists.techfak.uni-bielefeld.de
Subject: [SystemSafety] Safety Culture redux

Hi

I started this thread referring to the Harvard Business Review, Jan-Feb,
2018 reflections on culture. I was referring to the definition of culture.
This is only half the story. At the end of the article there are some thoughts on " 4 levers for evolving a culture". Here are my thoughts on the how-to as applied to software development - in the context of the preceding discussion on bugs and defects. 

The skinny on the '4 levers 'from HBR is:
1. Articulate the aspiration. Talk about attitude change in the context of real world business imperatives.
2. Select and develop leaders who align with the target culture. Your leaders have to walk the walk - be exemplars of required cultural norms.
3. Use organisational conversations about culture to underscore the importance of change. People need to be given time to discuss and reflect.
4. Reinforce the desired change through organisational design. Your organisational structure should allow people to contribute, top-down and bottom-up.

So thinking it over:
A seatbelt can save your life but only if you are wearing it.
The software engineering body of knowledge is also a wonderful thing but it will not further the cause of humanity if developers don't buckle up.
All the posts on this subject seem to be saying, "Let's make this BOK more beautiful, more precise, more shiny; if it's logical they will come." This is classical engineering thinking, defining the world not as it is but only as it should be relative to us. We persist in taking our logical knives to cultural gunfights; ignoring the reality that "culture is inextricable from the emotional and social dynamics of people in the organisation"[Harvard Business Review, Jan-Feb, 2018].
My point is that persuasion is required and this is a whole different field of activity; one that is not wholly informed by logos. How do you convince someone to embrace a discipline? We don't know. I submit that we should know. Foxes hypnotise cats by swaying in front of them. All engineers should be part shaman. We're already dealing with advanced technology that is 'indistinguishable from magic'. It should be second nature.
This is an important social issue. I hold it to be axiomatic that: 
"In the limit everything is become software." Every day it seeps further into more critical aspects of our lives. But we lack the skilled people to create it. It will therefore be the work of unskilled developers. This is creating an unstable society.  
In 43 years of attempted persuasion I've noticed that culture change doesn't happen without a compelling reason. And the more complex and rigorous (and
expensive) the target discipline the more life and death the reason has to be. 
Try:
1.	If you don't follow proper process you can't work here any more.
2.	If this system is hacked the company will be out of business.
3.	Do you want to be personally responsible for killing someone?

In contrast. If you call it a "bug" instead of a "defect" what evil will befall you. None. 

The case for culture change therefore needs to be unambiguously tied to tangible problems, company strategy, personal ambitions, required outcomes , consequences and avoidance of unfortunate events  - for us, death. History has proved we react well to existential threats. We tend to snooze when reading dictionaries.

So I return to the code review. Yes it can find defects in code but it's higher purpose is "cultural event". To show by example the thought processes that are acceptable around here and those that are not. Senior people become exemplars. There is discussion on why code quality is important. 

So what other cultural events do you run that give people pause to reflect on the life and death necessity of discipline? 

Shamans persuade through metaphor and story. It's black magic. The legend of error 1202 comes to mind. Sway while you tell it. The good shaman knows
that:
    they never remember what you say only what they were visualising while you were talking. 

A colourless tech term won't cut it, you need to put images in their minds.
Neil Armstrong, 384,000 km from home, thrusters kicking up moon dust, 20 seconds of fuel remaining, looking for a place to land. Don't explain, dramatise.

The secret persuasive sauce in storytelling is "aesthetic emotion". 
DEFINITION (ha ha)
Aesthetic emotion is an emotional response to a situation when thought and feeling come together to create meaning. "When an idea wraps itself around an emotional charge, it becomes all the more powerful, all the more profound, all the more memorable. ... It harmonises what you know with what you feel ..." [Bob McKee, Story] Steve, how do I get this into IEEE 610. Can I fill out a form?

We experience aesthetic emotion while watching a movie. We don't have this experience in normal life. The thought and the emotion come to us separately, we have the experience then reflect on it later and through this reflection our attitudes change. Most enduring attitude changes come from lessons learnt in blood. But a good story well told can convey the lesson without the blood. 

I am an advocate for code review because very early in my career I failed to implement a rigourous code review process with inexperienced programmers and nearly destroyed $6,000,000 chemical reactor. That was the year that made me
- 1981. An emotional experience, fortunately a near miss, but it could have been a career ending event at age 33 for a kid that never wanted to be anything else but an engineer since the age of 11. I've reflected on it ever since. So there you go, the idea that code reviews are good wrapped around an emotion - fear of career death. This experience turned the code review process into a religious rite for me. Don't let me catch you skipping code review, I'll come over and let down your tyres!

So the dog's bark but the caravan moves on. I recently spent some quality time amongst good people. They write software that fires missiles. Frankly I wasn't telling them anything they didn't already know but we had fun reviewing the BOK and playing with the pencils on the bench. One thing they told me was depressing. It turns out that the youngest guy in their shop is
40 years old. They can't retain young people. What they're doing is viewed as "... it's like sooo uncool ..."

This is the essence of the problem for the future of the planet. And we won't solve it by slinging a dictionary at these kids. So I'd encourage the engineering profession to think bigger and search wider. Let's pull our collective heads out of tech and put more think time into what feeds the soul - where the attitudes live.

Les

--
Les Chambers
les at chambers.com.au
+61 (0)412 648 992




_______________________________________________
The System Safety Mailing List
systemsafety at TechFak.Uni-Bielefeld.DE