On DevOps

I’ve been fortunate to work in a very dynamic environment, where I had a lot of free rein to proceed as I wanted and when I wanted to. It gave me a lot of scope to experiment with different ways of working and find a pattern or groove that fitted the way I work, and that delivered the most benefit to both the business and the team I was working with.

Luckily I also worked with some very smart people – people who were genuinely geniuses in their respective fields, although weren’t given the opportunity to bring their talents to bear on some pretty tough projects.

The pattern I fell into most was one of trust – I knew what I knew, they knew what they knew and we both knew what we didn’t know. By accident I had discovered one of the core components of DevOps, the magical unicorn movement that is sweeping through the tech industry.

It’s not hard to understand – I am a grown up, you are a grown up. You are employed to do a job, I am employed to do a job. If I ask you to do something that is within your technical area of expertise then I trust you to do that job and report back the outcome. I may query the outcome to scratch the surface, but I trust you that you will deliver the best technical solution that you are able to, within the constraints that I have specified. On the occasions where I am able to give you a chance to let yourself go, I trust that you will not behave like a child and get carried away – ultimately I have asked you to deliver something, and I expect you to deliver it.

People do their best work when they’re given some element of responsibility, both in the task that they are doing and in the ability to carry out that task. The first step towards making people responsible is to tell them either implicitly or explicitly that you trust them to do something.

The first step on any DevOps road is to to stop mistrusting the people who work with and for you. Once you can do that, then you’re ready to start.

On DevOps