A few days ago, I made an introduction for colleague Jason Dixon (@obfuscurity) over email, and described Jason as “a leading supporter of the DevOps movement”. A mere 17 minutes later, Jason replies to me, “Are you trolling me?”.

I was aghast. Granted, I haven’t known Jason terribly long (measured in months), but I’ve been well aware of his impact and contributions to the technical community (pulling together Monitorama , for starters). I couldn’t fathom the visceral reaction. But it did get me thinking… Why would someone so impactful want to distance themselves from the description?

For Jason, and many like him, it’s a question of intentions. To explore that, we’ll have to go back to the beginning, and for me the beginning was 5:20pm PST on June 24, 2010, in the last session on the last day of Velocity CA… a “choose your own adventure” talk by Adam Jacob (@adamhjk ), answering the question “what is DevOps?”.

I happened to have my flip cam handy…

http://www.youtube.com/watch?v=Fx8OBeNmaWw

“So here’s the thing: DevOps is a cultural and professional movement. Period. That’s it… There’s no technology, you can’t patent ‘devops’. Can you market a DevOps compliant toolset? You cannot.”Adam went on to describe the evolution of the system operation profession, and the challenges he personally found. Then came the org chart of a traditional silo approach to a technical organization hierarchy: software developers

Adam proceeded to challenge this approach with an alternative. “So this is everybody in a big pile. What we are is peers, and friends, and mentors, and we are having fun!”. Hysterically live in one silo, reporting into a director who reports into a VP, network engineers live in a separate silo, reporting into a separate director, system administrators in a third silo, and security engineers in a fourth. Proverbial walls erected between technical contributors, isolated from one another through a formal hierarchy. Need to communicate across to a peer? Better go up the stack to go back down.

Our hypothetical example continues of a conversation in the big pile: “Hey security dude, what’s that you’re doing?!?”, and he’s like “I’m breaking into the web site.” And you’re like “How’d you do that?!?”, and he shows you and the network engineer is like “I can stop you,” and you’re like “How?!?,” and he’s like “Firewall rules.” And you’re like “Whoa! Firewall rules?!?” and the security engineer is like “Why did you need to do that anyway, that’s a protected network”. And then everybody is having a good time. And the Directors. They’re just helping you out. They’re propping you up.”

While improvised, comical, and at best a generalization of an industry in a hypothetical example, one key point stuck in my mind from Adam’s talk: DevOps was about people, and how they were most effective and happiest working together. That was the point of the cultural and professional movement: to be more effective and happier as a team, embracing a “shared outcome.” Software developers, network engineers, system administrators, security engineers, directors, VPs, etc., we all succeed or fail together.

That’s not something you can sell. (In this context, I’ve specifically referring to selling a tool or service.) Nor is it something you can pin down to one definition applicable everywhere. Nor is it something that you can transplant wholesale from one company to another and expect the same level of effectiveness and happiness. You can’t “bolt on” DevOps to your existing organization with only tools and services. You can’t buy a toolset and expect your challenges to be alleviated. You have to understand the role improved tooling has played for those that have found success in this field.

Tools can certainly be enablers and facilitators, particularly when they free up person hours from manual tasks (assuming you can channel the new found time in an enabling direction), and particularly when they increase transparency as to where technical problems exist, helping to avoid the “It’s not my servers, it’s your code. It’s not my code, it’s your servers” blamefest. How we interact with them, and the patterns of behavior they impose on us as people, can lead to drastically different results from one organization to the next, even if those organizations have identical tools.

When our tools look like the first silo org chart example above, with a different set of tools presenting different perspectives to different teams bound together by a shared outcome, the tools end up dictating and reinforcing the silo organization hierarchy for how people work together.  To break down the proverbial walls, our tools instead must help define how people should work together.

Tools enabling configuration management, automation, improved monitoring, metrics collection, and source control won’t ensure success in isolation, because the DevOps movement isn’t ultimately about the tools. It’s about the people, and how they will work best together to succeed. The right tools can go a long way toward removing barriers, enabling the right conversations, and setting the stage for success.

Part of the challenge is that the tools are one of the more tangible and visible aspects of how we work. In can be easy to take a stroll through a peer organization and take note of the different tools, and attribute their success accordingly. You might be sold on the idea that a tool they have has been the missing piece to your success all along. Fight this first impulse to the tangible and visible, and remember that it’s hard to see how folks really interact. It’s hard to see how well their people, processes and tools work together to produce results in sunny-day scenarios. It’s even harder to see when the sh*t hits the proverbial fan. That’s where the real test is though, and that’s where the real lessons are to be learned. 

So let’s all be a little more focused on the lessons learned in ways to work together supported by tools than on the merits of one tool over another in isolation. No doubt, it’s a harder and deeper conversation to have, but the value is tremendously greater. If we keep it up, maybe we can make Jason proud to call himself a leading supporter of this professional and cultural movement.

Or maybe I was trolling Jason Dixon all along.