DevOps and Culture

So here we are, yet again it seems, at another industry change in IT.

Today, I read this article and was gratified to imagine that Culture is finally getting the recognition it deserves in IT circles. 

Like agile, DevOps maybe something that we will attempt to pass off as purely process, and yet will stall at people, change and culture. 

And so I have to wonder… What is this perennial failure my industry has regarding people, change and culture?

While we pride ourselves on pattern recognition, it appears that history majors we are not. 

It appears that for an industry hell bent on preaching “learning environments” to others, that we have ourselves yet to learn from the lessons of our own cyclic failures.

1. Take some same old problem (in this case, developers supporting code in production)
2. Give it a new name (DevOps) 
3. Create new processes
4. Create new names for said processes
5. Create new roles and job descriptions around new process(es)
6. Bring in a “coach” for new processes/roles
7. Completely. Ignore. People. Culture. Change. 

To make up for the fact that IT is not professionally qualified to handle people and culture, we scream #1-#5 ad nauseam hoping for “emergent behaviors” that produce change.

And frankly, who wants to see IT professionals arriving with advice on people, change and organizational culture…? Actually, only other IT people. 

IT change agents are lazily hoping that they can completely avoid the burden of addressing people (with a change management plan) in order to get the processes they want. 

This reveals our biases: Change is easy (so no plan is required.) And, the processes are really the most important thing, because that’s where WE feel the most pain (waterfall v. agile, lean and now DevOps.)

Change seems to be an inconvenient obstacle to the greater IT process narrative. 

How is the rest of the organization going to react to your changes?

Don’t know. Don’t care. "Get comfortable with change” seems to be the IT narrative for change management. 

Unsurprisingly, “get comfortable with failure” has been the response to IT led initiatives.

The gaping holes in IT led initiatives remain: people, culture and change. 

And to the Industrial Organizational Psychology (IO) community watching these IT led change initiatives, we must appear like small children attempting to address wildfires with simple home-made aluminum hats and sand-buckets.

Evidently for IT, the 15,000 known human behaviors, the vast topic of organizational culture and the entire field of change management can just be Googled like Stackify code snippets and woven into solutions…

Yeehaw.  (And don’t get me started on this culture hacking junk.)

Hypocrisy of Silos and Collaboration

For a field that’s awfully preachy about breaking down silos and hot for collaboration, it appears we’ve failed miserably at both. We’ve confirmed a stereotype that we prefer those two things – but only on our own terms.

Evidently, no body understands our problems and no one feels our pain, quite like us…

We are an insular field. This big decade+ long agile movement has seen IT (coaches) eventually pulling knowledge from fields like psychology behind our own curtain for experimentation and dabbling, rather than simply attempting cross-disciplinarily collaboration. Keeping-all-the-toys, as it were. 

That’s the sort of arrogance that can arise from intellectual insularism. The current tone of agile/lean (and now DevOps) pundits, is that this is the very first time in business history in which people, change and culture have been an issue. Because they are feeling it for the first time. 

So ask yourself: This time, are we going to call this IT thing a “Change Initiative” ? 

If we are, would it be professionally responsible or irresponsible to be half-assed about people, change and culture? 

This time, should your executive sponsors be asking IT for a Change Management plan, process or framework?

If they’ve watched your last 10+ years of attempts they should.