“Two households, both alike in dignity
In fair Verona, where we lay our scene
From ancient grudge break to new mutiny
Where civil blood makes civil hands unclean.
From forth the fatal loins of these two foes
A pair of star-cross’d lovers take their life
Whose misadventured piteous overthrows
Do with their death bury their parents’ strife.” ~ Romeo and Juliet: Prologue, William Shakespeare

For more than 15 years I have watched as they battle. The chasm between the two houses was so wide that I often wondered if it would ever be bridged. I never wavered from my view that we were all one house striving to find common ground for making working solutions for the world around us. Sometimes there were allies beside me. Sometimes I stood alone, For the first time in my professional history, it seems like the blood-feud could be put aside. Is it time for peace? Even more ambitious, is the day of an alliance at hand?

The Feud

For many years, corporate IT and finance were the only voices in the room. Ruled by an unquestioned and unmeasured desire for quantification and linear solutions, design considerations were usually an afterthought. All parties were subservient to the almighty ROI which ruled over all with an iron fist. Claims of possible productivity gains through better tooling were always met with doubt and even when taken seriously, you could not claim productivity gains unless you were willing to commit to lowering headcount. Tooling for technical employees to manage the environment and its operating data was so scarce, that there were more applications with no maintenance tooling than applications with operational plans. Operational changes were made by going into databases by hand and making changes in a “hit or miss until you hit” fashion.

In the late 90’s UX showed up to the party and with a basis in humanism, the equation changed. This was the time that the “great misunderstanding” happened and 15 years were wasted building up a corporate landscape strewn with enmity and false narratives. The “great misunderstanding” goes something like this:

• “Let’s make something that people can use” – UX practitioner espouses user-centric design and introduces new methods and artifacts into the SDLC processes which take interaction design specifications to a new level in corporate America
• “That’s going to take more time and I don’t agree that it’s any better than what I could do myself” – IT staff view this incursion as a mechanism to take what little time they are given to complete projects while also limiting their creative outlet
•  “I don’t care what you think and neither does anyone else” – UX practitioners view the response as a denial of their value proposition and a fundamental lack of care about the people who interact with technology

Several of the basic assumptions in these archetypal interactions between disciplines were short-sighted. For example:

• The “more time” fallacy – adding a design process may take more time if you only think about a single iteration in development and that’s only if you are lucky enough to have a complete interaction model worked out in your head that doesn’t have any design holes in it. Designing interactions on paper saves time in the same way that technical design saves time over “jumping straight to coding”
• The “fighting on the wrong front” mistake – It was never the goal of UX to remove IT budget. The goal was to make things better for the humans that interacted with technology while creating business value. The two different disciplines never saw their goals as aligned. We will never know what the alternate history would have been like had UX and IT teamed up to get larger budgets in an effort to create better and more sustainable experiences for users, developers AND operators.
• The “reductive labeling” error – Both IT and UX created a narrative where the interaction and visual design tasks were the “creative tasks” for “creative people”, while the development was the “technical tasks” for “technical people”. These labels have stuck around for the last 15 years and we are still paying the price for removing the idea that IT staff is fundamentally non-creative and devoid of craft.
• The “self-reinforcing paradox” tragedy – It was never the goal of IT to demean the UX discipline. When one neglected child is joined by another neglected child, the two will almost unavoidably fight over the little attention afforded to either of them. The irony here is that UX’s basis in cognitive science could have possibly seen the hostile response from IT for what it was; a cry for help. Instead, UX took the bait offered by IT and thus we are here 15 years later with a wide chasm between two disciplines that should be united by common causes:
  • a desire to make awesome stuff
  • a desire to create sustainable solutions
  • a desire to express one’s self at work
  • a desire to improve the lives of their customers and employees at the same time

Oh The Humanities

When IT resources and UX practitioners first came together the familiar plot “boy meets girl, boy loses girl” emerged and we may now, thanks to DevOps finally have arrived at the time when “boy gets girl again”. Gene Kim and the folks at IT Revolution Press have hit the target dead center in their manifesto:

“Working in most IT organizations is often thankless and frustrating. People feel as if they’re trapped in an ever-repeating horror movie, helpless to change the outcome The organization abdicates their responsibility to ensure that IT is managed well, plunging the department into relentless intertribal warfare between development, IT operations and information security. And of course, the auditors.

What inevitably results is chronic under-achievement. The life of an IT professional is often demoralizing and frustrating, typically leading to feelings of powerlessness and rife with stress which seeps into every aspect of life. From stress-related health problems, to social issues, to tension at home, it has become clear that the current state of the IT professional is not only unhealthy, but unsustainable.

As people, we’re wired to contribute and to feel like we’re actively making a difference. Yet, all too often when IT professionals ask their organization for support, they’re met with “you don’t understand,” or worse, a barely masked, “you don’t matter.”

As a human being, this is the worst response we could receive. Because the opposite of love isn’t hate — it’s apathy.”

Despite what some IT step-children will tell you, UX is not about making pretty pictures. UX as a discipline was formed to combat apathy and contempt by corporations through a mechanism of introducing empathy. Similarly, DevOps wasn’t formed to “make web pages faster”. DevOps clearly has a tactic of emphasizing performance (as well as other technical tactics), and performance improvements are clearly one of the benefits that come out of a DevOps organization. DevOps was formed to make IT a more sane and human space inside companies for IT employees, it just so happens that DevOps produces other impacts that are financially beneficial for enterprises.

Avoiding The Fates of Romeo And Juliet

Knowing that waters of DevOps and UX flow from the same wellspring allows the practitioners of DevOps several opportunities to repair the tragedies that have already befallen our enterprises before they escalate to the Shakespearian proportions. Three broad categories of opportunities would be:

1. Enroll UX into the DevOps movement – Knowing that we are aligned creates multiple possibilities to bring many industry and enterprise change agents into our cause. How much would the DevOps adoption curve accelerate if people like Don Norman, Jesse James Garret, Alan Cooper or Steve Krug were visible advocates for DevOps? Support from UX at the leadership level in the industry and within your enterprise is an advantage you cannot afford to pass up. The number of consensus driven organizations are just too many to count and the more groups and individuals that believe in advancing our cause, the better.
2. Learn from UX’s travails – Creating artificial barriers to discipline inclusion is ultimately an adoption limiting factor. When we make things pass-fail or turn collaborations into confrontations or competitions for who is DevOps and who is not, we all lose out on the what a wider community could offer. Hold yourself accountable to pivot confrontations into constructive opportunities where learning can happen for people of different disciplines.
3. Take some pages from UX’s playbook –  UX’s biggest lever for creating believers is by involving non-UXers in the research methods and activities (think about the last time you went to a usability test behind the 2 way mirror and saw a person struggle to use a system you were part of implementing). One of the best things we the practitioner community can do is to demonstrate what life is like without DevOps in real-life scenarios. When someone really attaches to how ugly a manual process is, or how soul-crushing it is to not be able to self-actualize in their job, they can’t help but want to be a part of making it better. Problem solving is hard-wired into the human condition, let’s leverage it.