Incepting DevOps at Red Hat

A few short months ago, I was managing an operations team at another firm. There had been a sea change in executive leadership over the summer, and the DevOps transformation that I’d helped to kick off was quickly being unraveled by the sorts of executive shenanigans that can ensue when a C level departs and leaves an opening. I was open minded to a change in scenery and got the call of a lifetime from a Red Hat recruiter.

You see, I’ve been involved in the Linux community since around 1998. I helped grow the Triangle Linux Users Group in its early years, and served a term on the steering committee as Vice Chair. When the community was looking for an enterprise class Linux distribution without the cost of a subscription model, I joined the cAosity project (now gone) and helped deliver CentOS to the Linux community. Open Source was in my DNA, and living in the Raleigh area the success of Red Hat was always right there for me to admire. “Someday I’d like to work there,” I often thought to myself.

This DevOps thing has gotten a lot of traction with me. I’ve been a volunteer co-organizer at Triangle DevOps, and have even given a few public talks on the subject, too.

When the call came, I wasn’t too sure at first that it was the right opportunity for me. I had, after all spent my recent experience in a management role that I was deeply invested in, and had a lot of passion around Agile coaching and DevOps transformation. But Red Hat was looking to fill a Principal Systems Administrator role, and I wasn’t sure that I was ready to go back to engineering just yet. I really thought there was something to this DevOps thing, and I wanted to hold out a little longer for a position that would allow me to keep leading in that field. I said as much to the recruiter, thinking that was going to end our conversation.

But the recruiter was tenacious, asking if I would please just take 15 to 20 minutes to talk to the hiring manager directly, hear him out and learn a little more about the role. I didn’t want to burn any bridges with Red Hat, and a 20 minute phone call is certainly not too much to ask. Who knows, maybe it would lead to a position inside of Red Hat that was a better fit for my professional ambitions.

I talked to the hiring manager, Bill Montgomery, on the phone. Bill presented to me a vision for something new he was trying to foment. You see, Bill was kicking off a DevOps transformation inside of Red Hat IT, and already had the investment of the leadership team on up to the C suite, including CIO Lee Congdon who was very much on board. My outlook on this position had done a 180 in the first few minutes of this call, and I now found myself seriously considering this opportunity.

Things happened pretty quickly. I met with other members of the leadership team, other engineers that I would be working with, and recognized that not only was there a serious desire to take Red Hat IT to the next level, but that Red Hat already had the cultural DNA via its rich Open Source heritage to nurture great success in such an endeavor.

I’ve been at Red Hat for just under three months now. I worked closely with Bill at first to help frame out what a DevOps enablement team might look like at Red Hat IT, how it would be staffed, what the core mission should be, what its values ought to be. Bill brought a lot of great ideas and experiences into this, too, Together we came up with something we were both very invested in, and then he went out and started cherry picking the right people to fill out this team and further improve upon our shared vision. One by one, engineers started transitioning out of the teams they were on and the strength of this new team was undeniable. Each brought something special, some new insight, and our vision became stronger, clearer. I expect you’ll be hearing from some of them here on Developer Blog, as well.

We started working with another team inside of Red Hat IT, SOA Services & ESB (aka “SSE”), a team that many other teams depend upon. Any success we find here will be multiplied across the organization. We met with our stakeholders, started fleshing out a backlog, digesting everything we’ve discovered in our conversations.

And we also decided to reject any corporate sounding team name. No acronym would do for us.

We, the team, decided on “Inception” as our name.

Inception: The implantation of an idea deep in the subconscious that will bear future results.

It became clear that we should be rallying our efforts around Continuous Integration and Continuous Delivery. Not only did this give us a specific area in which to produce measurable impact, it’s the perfect cultural lever for introducing other changes. Our Product Owner, Jen Krieger, came back with a great suggestion that we adopt the maturity model outlined in Continuous Delivery by Jez Humble and David Farley. This would represent the framework for our backlog, give us specific objectives to strive for that will elevate all of Red Hat IT. We borrowed heavily from the teachings of other leaders in the DevOps community like John Willis, John Allspaw, and Gene Kim. Ben Rockwood‘s LISA talkon “The DevOps Transformation” got passed around virally and was spoken of reverently by all who watched it. Something special was happening here. We were indeed to be a DevOps Enablement Team, and not a “DevOps Team” (there’s no such thing, right?). We’re going to enable DevOps across Red Hat IT, and when we reach a tipping point, we’ll go off our separate ways and take on new missions at Red Hat.

We made a very conscious decision early on that we would share stories of our successes, and of our failures, not only with our stakeholders in Red Hat IT, but also with the DevOps community. When we started telling our story inside of Red Hat IT, we were invited to contribute to Developer Blog which made all the sense in the world to us. I hope you’ll join us on this adventure, learn a few things with us along the way, and share with us what you’ve learned on your DevOps journey.


Join the Red Hat Developer Program (it’s free) and get access to related cheat sheets, books, and product downloads.

Share