By
Comic books have a certain math: for every superhero, there is a villain.
But superheroes and super villains don’t only exist in the comics. They roam the halls of the business community. The heroes are called “movements” and, if you follow them, they promise to benefit not just the bottom line, but the people creating and managing their systems.
In comics, the heroes always win in the end (except for the characters killed temporarily only to be reborn in the sequel).
If only it were that easy in corporate America.
Movements Transform or Fade Away
In the current corporate world heroic movements rise and fall — the villains however seem to have the staying power.
The core of the user experience (UX) movement has already left the building and embraced “service design” and/or “design thinking.” Agile is experiencing an identity crisis with critical books and articles popping up everywhere.
DevOps appears to be an unstoppable juggernaut inside of IT shops of all sizes and shapes, but it seems unlikely that DevOps will be the exception to the rule. All movements meet one of two ends: either their demise or their transformation.
Modern movements in enterprise development, inclusive of UX, Agile and DevOps, are no exception to the rule.
The Flawed Plots and Schemes of Flawed Organizations
Once a movement starts to gain traction, the seeds of it’s eventual demise or transformation have already been planted.
All of the below villains are described in terms of how they are battling with the hero of the day: DevOps. Notice how each one has been around in almost the same form for forever.
If you are young enough to see DevOps as your first paradigm change in technology development and management methodology, don’t fret. Just wait a decade and the cycle will start all over again.
Villain 1: Planting the flag too early, aka ‘We got the DevOps’
What’s the easiest way to kill something in corporate America? Claim “Mission Accomplished!” during an in-process transformation.
Ian Andrews, VP of product for Pivotal, captured the concept best when he recalled overhearing an IT executive in the early phases of a transformation say “Oh yeah. We got the DevOps.”
When the powers that be think of transformation as something you buy in a fiscal year or in a few quarters, the teams on the front lines of development, operations and customer support will pay the price.
A leadership team that underestimates the amount of work and time that goes into completing an enterprise mindset shift will often move the conversation, along with the budget and focus, to the market-facing concern of the day. Once the enterprise gaze shifts, it puts the movement at its most vulnerable state because leadership expectations have not shifted along with the enterprise commitment.
Once a leadership team thinks a goal has been achieved, unwinding expectations on benefits and future required effort to cement the shift becomes nearly, if not, impossible in a system bereft of empathy and shared context.
Once management deems an effort to have overpromised on its value proposition, the machine moves on and the effort is discarded.
Villain 2: Vendor/Community Overplay, aka ‘We are the DevOps’
If I see one more vendor claim to be the DevOps company, I’m going to scream. New vendors. New products. New conferences. New titles. I know DevOps is popular and I also know it is meaningful but I don’t think people understand that nothing can hold its meaning or value if everyone claims it as their own.
This is the poseur paradox. As a movement finds its base and grows in popularity, it by definition attracts people seeking value in it. As more people join the movement and identify themselves within it, the more watered down the movement gets.
A movement cannot be both a) universally adopted, and b) universally consistent.
Given that some people who adopt the DevOps moniker as their title will unavoidably not measure up to the original spirit of the movement, many of the audiences engaged by these people will walk away with a poor impression of the movement.
As more watering down happens and more audiences are left unfulfilled, it leaves the most skilled practitioners with no choice but to start a brand new movement.
The broken hearts and indefatigable souls of the original founders and acolytes team up to make the new movement both as inspiring as the first movement, and harder for the watering down process to repeat. This goal often works against itself, because the abstraction and complexity added to prevent the watering down, just so happens to have the side affect of making it harder for people to attach to.
Villain 3: Class warfare, aka ‘We are the Totem Pole’
The brilliance of Werner Vogels, CTO of Amazon, isn’t as much in the API and PaaS areas as it is in one simple directive — “you build it, you run it.”
This injunction has effectively become religion in DevOps shops everywhere — its the organizing principal that allows DevOps to live up to its promise.
When a shop adopts this motto, automating CICD pipelines and stations becomes simple because you can only reliably achieve the “you run it” part of the equation with the fast feedback loops provided by automated integration and deployment.
Shops not yet following “you build it, you run it,” still embrace the separation of duties concept known as “the Totem Pole.” If you’ve ever worked in a fully siloed shop, you understand the corporate caste system I’m referring to, but if not, allow me to explain.
There are two conceptual areas in totem pole land; upstream and downstream and the borders of each of these territories is defined by the location of the observer. Regardless of vantage point, the job model remains the same: take the partially thought out work product given to you by the teams upstream and make it ready for handoff to the poor souls downstream.
In Development groups, UX and Product shops are “upstream” and Operations shops sit “downstream.” Customer support teams fall “downstream” of Operations, and so on.
Teams view any silo that is not theirs as the perceived source of what’s wrong in the enterprise either because they don’t understand the complexities of your silo (i.e., the people upstream of you) or because they’re not willing or able to hire capable and qualified people (I.e., the people downstream of you).
Once discipline-centric silos form in a shop, totem pole narratives (i.e. Us vs them) become the norm — and this is where the seeds of division bloom into the thousand flowers of disunity, stagnation, blame and “over the wall” delivery to the next group one step down on the totem pole.
Given that the aim of DevOps is to reduce or eliminate these symptoms, a DevOps team set aside in a separate organization (i.e., my group designs it, your group builds it, and their group runs it) has the same chances for thriving as West Berlin did when it was surrounded by iron curtain states: no chance without an airlift from the west.
Divide and conquer is the mantra of the totem pole and this villain is always waiting for the right moment to reintroduce the corporate caste system that starts with “role x is more important than role y” and ends with more siloes, each of which are necessary and none of which are ready to accept that they are mutually interdependent.
Given that DevOps and hardened organizational siloes are mutually exclusive concepts, organizations that attempt to do both will harm the movement, because it can never deliver on its promises without elimination of the upstream/downstream culture.
What Comes Next for DevOps?
In superhero films, the villain gets vanquished, the credits roll and sometimes we get a post-credits preview of the next film for the heroic protagonist.
In the large corporate enterprise, it’s the heroes who are forced to choose between adaptation (UX to service design, agile to lean, etc) or slow death.
One or the other is coming for DevOps.
The only things you can do to hold fate at bay are to measure expectations, ignore the hype cycle and not get too attached to titles. Most of all, don’t let the powers that be divide and conquer. Remember that we are all the same: individual workers trying to get by and make the workplace a better place.