Thinking differently about . . . DevOps

Last week, I claimed that technology leaders attempting to change the culture of their organisations should start with themselves. I think that this is especially true for technology leaders who are trying to introduce DevOps to their organisations. I am one of the people who have tried to do just that, and have not always been successful: as usual, this article is inspired by the opportunities I have had to make mistakes.

The concept of DevOps has been around for over ten years now, and has been described by more expert people than me, so I won’t attempt to give a precise definition here. (And I will also take this opportunity to say that, although I work for Google, a company which exemplifies many of the practices attributed to DevOps, the views in this article are my own.) I will, though, offer two ways in which I think about DevOps.

Firstly, I think about it as an accountability model, in which one team is responsible for the development of software and for the performance of that software in production. When such teams are driven by a good set of measures, then all of the magic of tooling, automation and productivity can follow.

Second, DevOps is a concept which attracts technology leaders, as it seems to hold the answer to two of their problems: it promises to help them go faster and break less. Who wouldn’t want that, especially if you have stakeholders who keep telling you that everything takes too long - when they’re not complaining about service?

Unfortunately, many DevOps initiatives fail to deliver this promise. There are many reasons for this, but I believe that one of the most important is that many technology leaders don’t recognise that, in order to adopt DevOps successfully, they must break habits and beliefs that have served them well for many years: they must put themselves at the centre of their own transformation.

As DevOps has accountability at its heart, technology leaders must honour that accountability: they must provide teams with trust, authority and autonomy. They must transfer power from methods and managers to the teams that are often shown at the bottom of the org chart.

The reasons that we must do this - and the reasons that technology managers often find it hard - can be seen in the development of concepts of technology management and organisation I have seen through my career.

The first half of my career coincided with the growth of methods, tools and practices intended to professionalise IT, to make it predictable and manageable. This was the era of heavyweight development lifecycles and service management regimes. One feature of these approaches was that, intentionally or not, they transferred autonomy and authority from people actually writing and running software to methods and managers.

The second half of my career coincided with the growth of the realisation that, although the motivations for these older methods and techniques were not irrational - they were intended to solve real problems - they were also flawed. While they might have delivered predictability and control (and even that is arguable) they were a brake on the pace of change and resulted in performance that was just about good enough. They were gradually replaced with concepts such as Agile and DevOps, anchored on the belief that the most powerful driver of change and quality is the small, accountable, empowered team.

Unfortunately, many of us learnt our habits in the heavyweight methods era, achieved some level of success during that time, and brought those habits with us. I know that, however much I try to internalise the beliefs and habits of newer approaches, my old habits are still lurking, and will come out when I am under pressure. I do not think that I am alone.

How do we address this problem? How do we shed habits that we acquired over years and which contributed to our success? As usual, I don’t have the perfect answer, but I do have a couple of thoughts which may be helpful.

First, as I said above and last week, we can start by recognising the problem and placing ourselves at the heart of our own transformation programmes. We can recognise that, even in a DevOps world of autonomous teams, the role of leader is still important - but its importance lies in creating the conditions for our teams to be successful.

Second (and this one is difficult), I suggest finding time to get back on the floor, to embed yourself in a team for a while, to lay your hands on a keyboard again, and to experience the power and thrill of delivering something within a team. When I have been privileged to have the chance to do that, it has reminded me where the real work gets done.

Of course, your company may sensibly not want a rusty manager building software, so you might need to find a project to do in your spare time. But there is no substitute for placing ourselves in roles and positions that we have not held since the beginning of our careers. It takes us back to a time before we formed those habits we now want to break - and may help us build the habits we need to make DevOps successful.