Thread by @RaeKnowler

The next #DevopsDays Geneva speaker is @nat_remez: Fail fast, Fail often - make safety a prerequisite for your team devopsdays.org/events/2019-ge…

When I skimmed over the title originally, I assumed this was about safety as in security, but actually it’s psychological safety—much more interesting, I think!

Looking for a story to link Switzerland with her country, Sweden, the first thing @nat_remez found was the NYSE hanging a Swiss flag to celebrate Swedish company Spotify. Great for a talk on mistakes!

We as humans and programmers are full of fears, and fear kills innovation. The opposite of fear is psychological safety, belief that we won’t be punished for speaking up or making mistakes. @nat_remez #DevopsDays

From the management side, how can we make people feel this safety? For example, root cause analysis (the five whys). Or the exercise ‘Just like me’: imagine yourself in the other’s position, at every step. Or allowing safe, quick failure. #DevopsDays

Whatever you choose, it’s important to remember you can’t fix people: only the processes and systems around them, to make things safer and protect from huge consequences of failure. #DevopsDays

More engineering-focused processes for safety! First: lightweight, quick releases. Also, decouple releases (coordinated across depts, may need planning) from deployments (can be quick and easy). #DevopsDays

Blue-green releases are great. ✅ (I love how this works with CloudFoundry.) Also useful: canary releases: release to a small group of users first. #DevopsDays

Facebook used a ‘dark launch’ for their chat in 2008. They changed the UI first, for a handful of users. By seeing how the users interacted with the UI, they decided how to build the backend. (Then used feature toggles to roll it out when done.) #DevopsDays

It’s important to get feedback and see what works/fails at every step. Dogfooding is good for this; CI/CD can be too. You can fix the issues in each step before charging on with the next. #DevopsDays

Finally, some interpersonal tips for devs: pair programming and mob programming can help break down barriers and build up relationships, so you can feel safe bringing up ideas. They also get different perspectives on problems. #DevopsDays

Q: what about fear of negative comments on pull requests?

A: pair/mob programming can help here, because you can discuss problems with the code face-to-face. That’s always better than trying to have that conversation in writing. @nat_remez #DevopsDays

Also, remember that comments on PRs are a social phenomenon: if someone leaves a harsh comment, there’s often someone else saying, “That was not so polite!” #DevopsDays @nat_remez

Q: how to combine root-cause analysis and blameless post-mortems safely? Surely you will always find someone who can be blamed?

A: the five whys are the first step of Google’s blameless post-mortem template, but you have to do it right. (Cont) #DevOpsDays @nat_remez

Remember you can’t fix people, only systems; it’s not worth focusing on a person in the root-cause analysis, but on the system around them where the problem occurred. #DevopsDays @nat_remez

@threadreaderapp Unroll, please.