DevOps Means Large Organizations Thinking More Like Small Ones

Lots of people were disappointed when Google shut down its Google Reader news and information aggregator in July. Among them was Stephen McDonald, a veteran open-source software engineer and team leader in the Sydney area of Australia.

He decided to do something about it. McDonald, together with fellow Reader-phile Adam O’Byrne, built and launched Kouio, a replacement for the Google product. You can find out more about Kouio here, and get a little color (or “colour,” as the Aussies might say) about its formation here.

In addition to being a Google Reader fanatic, McDonald has an interesting take on one of our favorite topics here on – how large organizations can operate more like small ones in implementing DevOps practices.

We chatted via email. Here is some of what he said:

What is your view of DevOps as a method for getting software development and IT operations to work together better?

It’s great, of course. However, I think one of the fundamental traits of DevOps is removing the distinction between software development and IT operations altogether. For me this is a goal rather than a method, which is a subtle but important distinction.

My ideal development team is one with T-shaped generalists: highly skilled in a small number of areas, with good working exposure to a very broad range of disciplines across the development and operations spectrum. The end result of this is one where autonomy, accountability and ownership are maximized across the team. This is great for developers and it’s great for business.

Is this even feasibly possible? Perhaps not. Every environment will be different. But I think this target is something that all development teams should be aspiring to.

Why do software development and IT operations clash in so many organizations?

Throughout my career I’ve had the luxury working with a wide variety of organizations – from the smallest of startups and agencies, to the other the end of the scale with some of the largest enterprises in my country. One needs to look no further than to the former of these to find the least friction.

It feels like stating the obvious, but one thing I’ve noticed over my time with these organizations is that smaller the group size, the more likely you are to find the key ingredients necessary for smooth coordination across all aspects of development. Things like the requirement for technologists to wear multiple hats in the smallest of teams, as well as more direct lines of accountability by way of reporting directly to company owners, if not already owners themselves.

Contrast this to larger corporations, where technologists generally have a particular hat assigned, it’s all too easy for silos to form and the passing of responsibility to occur. You’ll also find that with more layers of management in place, a much reduced depth of accountability will often be found.

What in your view is the best approach for getting development and operations to play well together, and why?

Given the above, I think the most obvious answer is to follow the natural models found within the smallest of organizations: Wider responsibility with multiple hats, and reduced layers of management.

Both of these areas are incredibly hard to tackle. Organizations need to put their money where their mouths are and invest in the high-end of the market, where the technologists with these broad skillsets and experience levels are to be found. On top of that is the need to look inward and invest in the skillsets of existing staff. Reducing this to paying for certifications won’t cut it either. People need to get their hands dirty. Throw Dev into Ops and vice versa for extended periods of time. Of course, this is simply another cost that many organizations are reluctant to concede to. But look at companies like Google and Facebook, where developers supposedly are able to move freely from project to project.

As for reducing layers of management, I believe the jury is still out on this one. Again, there are some success stories with companies such as GitHub and Valve, market leaders in their respective areas, purporting to implement the flattest of structure with zero layers of management. Again, if this were something that could work, you’d see a stark increase in the depth of accountability.