DevOps and the Human Condition

This article is the second of three on the topic of DevOps

This second post might seem a bit deeper than the first, as it pertains to topics outside of the software development lifecycle.  Fret not; it’s not a bad read and does set the table for the third installment.  Remember, this is my take, so feel free to use or get your own.

I tell people that technology fascinates me, but it’s the human condition that gets me going.  Interacting with people is what it’s all about, and to me that interaction is a key ingredient in leadership.  There are countless books, seminars and cat posters that speak to leadership, but my approach is a bit more simplistic:  leadership isn’t about how many rectangles you have under you on an org chart, it’s about creating individual connections with your people to help them achieve things they never thought possible. In fact, while I always feel a great sense of accomplishment when someone who works for me grows, it’s even more of a rush when you’re able to positively influence people outside of your organization.  They don’t work for you and certainly don’t have to listen to you, but if your message has worth for them, they’ll listen. 

That’s why I believe the hearts & minds component to be the linchpin in making DevOps work.  Let’s face it; if your mission is world domination, irrespective of the damage it causes, you’re not going to have a very compelling message and people won’t want to change for you.  They change their behaviors because they see the value in changing, and the slickest process or most expensive piece of software will be rendered useless if the humans don’t value the change. 

One leadership book popular in DevOps circles is Simon Sinek’s Start with Why:  How Great Leaders Inspire Everyone to Take Action, which uses examples of leaders who determined the “why” behind what they were doing to inspire others to follow.  I prefer a book that Sinek referenced in an interview, entitled Turn the Ship Around, by retired Navy nuclear submarine commander L. David Marquet.  I like it because it talks of changing the old “leader-follower” model into “leader-leader”, giving control to individuals, even in times of crisis, rather than unilaterally taking control. 

Some of my most successful efforts at changing behaviors involved a conversation with an individual, irrespective of his or her position in the food chain, and I created for them that vision of the future where the change would make life better for them.  The vision doesn’t decrease the workload required to make the change, but at least gives it meaning.  And yes, I’ve looked people in the eye and said, “I need you to trust me”, and they knew I was sincere.  It’s great to follow up after a successful change, hearing the individual remark that they never would’ve thought things would work out, yet they did.

Let’s take a moment now to sit back and think, “Dude, I thought you were in IT.  Why are we talking about this touchy-feely stuff?”  My response:  Touché, but if you go talk to other technologists / tech leaders / CIOs, chances are you’ll find out that all across the IT community, they’re dealing with this very topic.

“And how does that make you feel?” asked the therapist...

Straining, you recall (you go, good memory person) that my definition of DevOps creates efficiencies through the principles of Continuous Delivery and a healthy investment in hearts & minds.  We won’t cover the efficiencies that make DevOps so effective until my third post, but that won’t deter us from looking at examples of compelling visions of the future.  These outcomes are what keep people going when the going gets tough.  Again, these are samples and vary according to your people and situation:

 Compelling Vision:  What’s Really in it for Me?

If these are outcomes, it’s important to know the types of behaviors required to get there, or this whole human condition thing won’t make sense at all.  For example, look at DevOps at its most elemental level, development and operations staffs are working together, truly collaborating, understanding what it takes for all to be successful.  That’s what’s known as systems thinking, and here’s my definition:  an awareness and understanding of what goes on outside of one person’s world / team / cubicle in order to help influence successful delivery. 

Contrast systems thinking with, for instance, a Dev team tasked with moving quickly and taking risks, but an Ops team forbidden to make even a ripple in Production.  If you haven’t solved that conflict, save yourself a ton of time and money and don’t bother with addressing testing, project management or alignment with your business partners or customers until you do.  When developers empathize with Ops’ need for things to be vetted properly, and Ops is involved and informed enough to lower barriers to promote software into Production, you’re making progress.  When you apply this same approach to the whole process and all players, you begin to see the magnitude of the positive outcome in efficiency, engaged team members and a host of other possibilities.

Another popular conundrum involving the human condition and addressed by a solid DevOps practice is farther upstream.  It deals with how projects are allocated, funded and prioritized, and who decides.  One of my clients has been very successful in incorporating tenets of a High Performance Management System (HPMS) created by Richard C. Palermo, Sr., using the principle “Do the Right Things Right”.   The process they use continually measures whether the initiatives they want to pursue are in keeping with their mission and organizational shared values.  If so, they’re ranked as part of a “Vital Few” projects that get the full attention and resources of the company.  If not, they’re tabled for reconsideration or dropped.  In that manner everyone in the company knows what’s most important, rather than responding to that loudest scream or squeakiest wheel.  My litmus test, befitting of my lesser intellect, is simpler, and I call it the whiteboard test:  If I gather all the P&L owners of the company together and ask them to put the top 5 strategic IT projects on the whiteboard, will they list the same projects?  More likely than not, I’d see the top 5 for each group, and if IT has to referee what’s most important for the company, it’s a no-win proposition.  On a good note, these days you’ll find more and more CIOs at the strategy table as trusted advisors, helping to drive the vision of the Vital Few.  They’re learning to convince people bent on world domination that it’s actually the same world, and dominating it as a team is much more fun. 

My final post on the topic:  DevOps and The Devil (it’s in the details)