I’ve been working in enterprise IT for a long time, and a few years ago, I had the opportunity to join a new DevOps team that was being formed. Since then, I’ve learned a lot about what DevOps is, what it isn’t, and how to make it work in a traditional enterprise IT shop.
One thing that’s been great about DevOps is its capacity to free people professionally. Something I see going on in way too many IT organizations is talented personnel getting stuck in silos from the day they are hired. You’re a
It’s kind of like all the folks in Jeeps that drive with the tops on, doors attached and windows rolled up in the middle of summer. I have never understood why people do this. What is the point of owning a Jeep if you aren’t going enjoy the weather in it? Even at 110 degrees Fahrenheit, I’d have the top off and doors detached!
DevOps is a way of working – a way of letting your people do what they do best, but allowing them to interact and explore.
A lot of IT shops are like that Jeep – they hem in talented and bright people who could transform the entire IT shop by never giving them a chance to explore other areas and interact with different people.
They spend half their time in meetings or waiting for “the other group” to get back with them. If they cross a functional boundary – watch out! – there will be another meeting to address it! Is it any wonder companies lose superstars and employees lose their zeal after a while? It’s worse than death by PowerPoint!
What amazes me is that many companies are talking or reading about DevOps but don’t practice it. They read about the benefits of having cross-functional teams and personnel who can come together and knock down organizational barriers, yet they continue to work in the same fashion.
Enterprise IT is waiting for permission to take the top off its Jeep instead of just taking it off and leaving it off.
What DevOps isn’t
The whole philosophy behind the DevOps movements is to get people with different backgrounds to work together on both sides of the IT coin – development and operational – so that decisions can be made quicker, people can cross-train and you aren’t sitting in endless meetings trying to decide whether to take the top off your Jeep.
Are these companies afraid they might actually succeed with DevOps? What is the worst that could possibly happen? At the very least, things will continue to get done the same way. At best, you will see a transformation that will improve productivity, innovation and morale!
There are debates in various circles about what DevOps is, and how you hire DevOps people. Some people think the movement is about getting rid of operational folks and just letting it be a development free-for-all. Others think that you have to be a generalist — good but not great — at everything you do in IT.
Honestly, we know operations is a must-have for any IT organization, and if you want your best and brightest to go somewhere else just let them know you think of them as “generalists.” That should do the trick.
Job postings for IT personnel with titles like "Seeking qualified DevOps candidate!" litter the Web. When did a way of working become a skill set? If I am running an IT shop I still want my Oracle gurus and my Java superstars – I don’t want just a generic database guy and an average programmer.
This is where I think a lot of companies just aren’t getting what DevOps is – just like many companies took a long time to figure out what Agile was all about. They hear the buzzword, read a Wikipedia article and immediately think it’s all about making folks into no-operations-needed-generalists. Yikes!
Do DevOps the right way
DevOps is a way of working – letting your people do what they excel at, but allowing them to interact and explore. It’s a way to help your VMware expert understand and get to know the challenges the Oracle folks have. Now she gets why they are concerned about the shared I/O going on instead of just hearing the pushback all the time without explanation. It’s knocking IT walls down and keeping them down.
Some of the most successful DevOps teams were formed when management stepped back and let people work together instead of forcing them into predetermined teams. DevOps really is the Agile philosophy applied to both programming and operations.
These teams aren’t just “throwing stuff over the wall” and running from the explosion. Since they embrace both the code and the operational side of a project, they all feel the pain when things go wrong just as they share in the success when it goes right. It’s no longer “Joe’s problem” or “Sue’s issue.” It’s now “our issue,” and we’re going to do the right thing to not only fix it, but make it better.
The teams are making it work by getting everyone involved and making decisions knowing the full impact. They let folks explore, innovate and relate.
So go ahead. Take the top off your Jeep. Enjoy the summer – 110 in the shade never felt so good.
ABOUT THE AUTHOR: Robert Stinnett is a data center automation architect who works for CARFAX, Inc. Stinnett has spent more than 20 years in both data center and workload automation, has experience in both the distributed and mainframe side of data center automation, and has written several white papers on data center automation and optimization. Stinnett has also been a speaker at various conferences on the subject of Enterprise automation and has written a number of public domain utilities to assist others in realizing the benefits of end-to-end automation efforts.
This was first published in June 2012