Reading a recent blog about how IT departments struggle with their communication and collaboration with their end users, by Martin McKenna, I can’t avoid the conclusion that many IT departments still don’t get it. That they need to understand more about the business ecosystem they work in, and contribute to, and to adjust their mindsets and ways of working accordingly.

This blog looks at a number of things that need to be considered and addressed if we’re ever going to improve how we deliver corporate IT.

End users are human beings, not IT beings

IT’s response to the end user reluctance to contact the IT service desk when issues occur, is technological rather than relational. A common response is “They need a self-service portal.” No, they don’t. They need somebody who treats them as a human being, not an IT being. Somebody who demonstrates empathy, rather than technical expertise. Somebody who empowers the end users, rather than belittling them. Even after all these years, IT is still something that many users don’t understand, provided by people who they don’t trust.

It takes two to tango – but does IT’s business partner have two left feet?

The recent IT service management (ITSM) interest in business relationship management (BRM) is encouraging. Credit is due to the BRM Institute who have fostered this interest and provide excellent guidance on how the IT function can improve its relationship with its business partners and help them get more value out of their considerable investments in IT.

It takes two to tango, however, and it’s no good having a proficient IT dancing partner if the business partner has two left feet. Improving the business’ capabilities to deal with IT is one of my major interests, and I lean heavily on the body of knowledge that the non-profit ASL BiSL Foundation (where BiSL is the Business Information Services Library) has accumulated. (Full disclosure: they engage me as their ambassador to spread the word around the globe, so I’m undoubtedly biased, but I sincerely believe that this is a neglected area.)

Just consider the following concerns that business people have:

  • How much should we be investing in IT as opposed to other important resources?
  • What kind of investments should we be making?
  • How do we delegate the work to the IT department and make sure that it gets done?
  • How do we ensure that end users are using the information and technology well and actually realizing the intended value?
  • How do we protect our valuable information and information systems from misuse?
  • How do we as business managers ensure that we’re managing our information and information systems in accordance with their value as business assets?

Governance of information and technology from a business perspective

Let’s think about the last point, about good governance. Who is tasked with alleviating all of the other concerns mentioned above? Not the IT department – it’s a business responsibility. The IT department can help with advice, of course, but their primary focus is IT service delivery.

Either formally or informally, the business fulfils roles such as system owner, product owner, information manager, and key/super/power user. But how well are these roles executed? BiSL comprises a set of practices that can be used as a checklist to establish how well information and technology are being managed from a business perspective, and to improve them where necessary.

“IT buddy”?

In his blog, Martin mentioned a concept similar to doctor’s rounds or clinics, where an “IT buddy” visits departments on a regular basis to becomes a trusted advisor and “voice” for that department. He also talked about the power user, usually a colleague who is often asked for help and, as part of the business unit, they therefore understand the business context better than the IT colleague and that they too could become an IT buddy.

I like this principle (and have previously used the term “Super Duper User” for this role). To take the IT buddy concept even further I would suggest that we ask that person to proactively keep an eye on how their colleagues are using the systems and advise accordingly.

Effective business-IT behavior

The collaboration between line-of-business people and IT people is a fascinating topic and I’ve conducted workshops in about ten countries in which participants explore and identify effective collaborative behavior. The main findings are that the business people should:

  • Focus on outcomes, not tell IT which solutions they want
  • Articulate strategy and needs clearly
  • Accept risks, set priorities, and take decisions
  • Understand IT’s limitations
  • Own organizational change
  • Give feedback about the use of systems

And that IT people should:

  • Be accessible, empathetic, communicative, flexible, and quick
  • Understand the business, and IT’s impact on it
  • Talk benefits, costs, and risks without mentioning anything to do with IT
  • Discuss consequences of options and choices
  • Suggest innovations proactively instead of waiting for the business to ask for something
  • Say “Yes, if” not “No”

Equally important, the participants feel that the enterprise should foster a culture in which business and IT share a joint vision and are part of the same story, have an ongoing dialogue, have mature conversations, strike balances, and enjoy working together.

Embracing “shadow IT”

Increasingly, tooling is no longer dictated by the IT function. There’s a power shift towards the end users. They have their own preference for communication – for instance Twitter or Facebook. They have their own preference for devices and apps. Calling this “shadow IT” is derogatory and delusional. It’s just as much part of their lives as the language that they speak. If your end users speak French, it’s no good insisting that they speak Spanish. Instead learn French. Learn Twitter. Learn Android. If you don’t, they’ll walk away – particularly external users/customers.

Attitudinal, behavioral, and cultural challenges

So where does this leave us? With attitudinal, behavioral, and cultural challenges. I’d recommend spending some time thinking about the end users’ experience when dealing with IT, building better relationships, and helping your business partners to become better dancing partners.

Guidance is readily available (e.g. BRMBOKTM and BiSL®), as are workshops and business simulations that explore, identify, and improve communication and collaboration. But don’t approach this as a project in the IT department to decide what to do for the end users – do it with them. This in itself is a major step in the right direction.

My presentation at the upcoming itSMF UK conference is the latest iteration of my “Kill DevOps” talk. I presented the first version in 2014 in Beijing and have probably gone through 20 changes of it since then. This process of continual refinement is completely consistent with the message behind the cryptic title. “Kill DevOps” refers to an ancient Zen saying about a monk’s journey towards enlightenment and awakening. If you think that you’ve found it, think again, because you never will. It’s the same with DevOps: it’s about continuous experimentation and learning.

In terms of practical guidance, I’d like to share a few major takeaways in terms of critical questions to ask yourself.

What problem are you trying to solve?

Most people invest in DevOps in order to speed up their development and deployment processes, while not compromising – and often even improving – the operational behaviour of their information systems and services: reliability, availability, security. Whether DevOps will save costs is up for debate. Yes, it makes several activities more efficient, but on the other hand it’s quite an investment to adopt DevOps culture and practices. It won’t really help you come up with ideas for new functionality – that’s more in the Agile domain. It does however, have the potential to make IT a better place to work. Treating people like human beings is one of DevOps’ tenets. So if you’re after higher speed of change, better operational behaviour, and fun, read on.

Can you afford the benefits?

People are using DevOps’ cultural norms and technical practices in various ways and in various kinds of organizations, but the common success factor seem to be an inner drive and conviction that things need to change radically. Although many have gone before, it’s still a leap of faith. I often make the comparison of the transition from the dark ages to the age of enlightenment. The dark ages of IT were characterized by rigid project plans and processes , backed up by service levels agreements that polarized the relationship between the business and IT. The age of IT enlightenment is more responsive, emergent, and inclusive. Multidisciplinary collaboration is the name of the game, with a high degree of trust between all involved. This includes managers, who are now challenged by managing with their hands behind their back – not all are up to the job. So the question to ask yourself is whether you’re prepared to go through some pretty rigorous organizational and cultural change in order to get value out of DevOps.

Is the DevOps horse suited to your course?

DevOps flourishes in conditions of organizational complexity. I’m using the term complexity to denote a loose coupling between cause and effect. One of the experts on this field is Dave Snowden. Referring to his Cynefin framework, Snowden distinguished between five domains:

  1. Obvious, in which the relationship between cause and effect is obvious to all
  2. Complicated, in which the relationship between cause and effect requires analysis or some other form of investigation and/or the application of expert knowledge
  3. Complex, in which the relationship between cause and effect can only be perceived in retrospect, but not in advance
  4. Chaotic, in which there is no relationship between cause and effect at systems level
  5. Disorder, which is the state of not knowing what type of causality exists.

The deterministic domains Obvious and Complicated are pretty good territory for structured project plans and processes, because you know more or less how things respond. When the conditions are less predictable however, a more emergent approach works better. Snowden calls this Probe – Sense – Respond. Because the non-deterministic nature of the “system” means that a fail-safe solution is unrealistic, it’s about taking small safe-to-fail experiments. This corresponds with DevOps’s culture that fosters continual experimentation, taking risks, and learning.  Under conditions of complexity, you’ll get the most benefit from riding the DevOps horse. Or unicorn, if you work at a spangly company like Amazon, NetFlix, Google, Spotify, or Etsy.

If this blog has piqued your interest in my presentation, then there’s still time to register for the itSMF UK conference. With my presentation just one of many that will help you to consider your company’s status quo and provide guidance on where it will need to be in the future.

Finally, please come and have a chat if you’re at ITSM16, or feel free to get in touch with me on LinkedIn, Twitter, or by email – mark@smalley.it.