[Reading time: 1 minutes 41 seconds]
No two organisations are alike of course – but here’s a playbook that has worked well for me.
Fundamentally, there are two things you need to balance:
the need to offer clarity on the philosophical underpinnnings of DevOps: what the fundamental considerations and goals are
the need to take concrete steps, actually build something, get your fingers dirty, collect immediate experience
The second – concrete steps – is important because engineers are an impatient bunch. They, generally speaking, will not tolerate theory without practice for long. And they’ve long read that DevOps is about some kind of technology: Jenkins maybe, or Kubernetes, or AWS. So that’s what they expect to see.
Yet technology without the context, the process to bring its power to bear, will result in lots of tires spinning in place: lots of noise and smoke, but we’ll just stay where we are. So it’s important to embed technology in a broader process and culture shift.
So, in the end, this is the trick I like to use to get a new organisation to gradually move towards a DevOps mindset: let them experience first-hand what the tools can do for them. But at the same time, make them feel how not going far enough in adopting not just the tech, but also the accompanying methodical changes, will be not much more than an expensive distraction.
Let them build a pipeline … and feel how items shoot through, only to smash straight into a wall at the pipeline’s end.
Let them build feedback mechanisms … and experience that nobody takes advantage of that wealth of information – because they don’t know it exists, or are overwhelmed by that fidelity.
Once people have seen what could be, they’re eager to talk about what should be, and how to get closer to it.
It’s quite magical to watch.