We talk. No one understands. Why?

Share twitterlinkedinmail

It’s still there. After all of the investment in training. After all of the implementations of tools and processes and methodologies. After all of the progress and achievements.

There’s still that one thing that we’ve yet to overcome. One of the aspirational goals that each wave of tool implementation, process designs, and adoptions of methodologies set out to solve.

We still work in silos. And we’ve done it (and continue doing it) to ourselves. As a result, we talk, but no one understands.

The way we’re working encourages and reinforces a silo mentality. We talk in terms of “IT” and “the business” (yes, I’ve done it too). When did IT “leave” the business? Instead of acting as “one IT team”, we often refer to ourselves as “development” or “operations”. Aren’t we on the same side?

Then there are the nearly “religious” debates about this methodology vs. that framework.   Take a look at social media on any given day…you’ll find them. (I wrote this article about it.)

What do all of these things have in common? In each case, it’s “us” vs. “them”.

Do you recognize it? And if we in IT can recognize it, what do you suppose our business colleagues are seeing? What is the message that we in IT are sending to our business colleagues? What is the impact on our business?

Do you know what would be even worse? If you aren’t recognizing it.

We have a lot of smart people in IT – why haven’t we figured this out?

Need some examples?

  • “Product Owner” vs. “Customers and Stakeholders” – In Scrum, the “product owner” represents the voice of the customer (business). In ITIL®[1], “customers and stakeholders” represent the business.  In either case, we are referring to people who define and receive value from IT.
  • “Sprint” vs. “Release” – A Scrum or Agile “sprint” describes a unit of development that results in an integrated, fully tested, documented working product…. just like a “release” in ITIL.
  • “Project Manager” vs. “Design Coordinator” vs. “Release Manager” – Various project management methodologies describe a “project manager” that ensures project results are delivered on time, with good quality, and within budget. The project manager deals with schedules, resources, and resolves project conflicts. In ITIL, the “Design Coordinator” coordinates design activities across projects, manages schedules, resources and conflicts. Just for good measure, ITIL also describes a “Release Manager” that plans and coordinates all resources needed to build, test, and deploy a release. So, who is accountable for the implementation of a project?
  • “Scrum task board” vs. “Kanban” vs. “Schedule of Change” – In Scrum, the “task board” is a visual representation of work. Lean refers to this as a “Kanban”. The concept is that anyone viewing the board can quickly see what work is being done, along with the status of that work. ITIL has a similar construct with the “Schedule of Change” …. except in my experience, IT organizations often don’t make the Schedule of Change publicly visible outside of a CAB meeting.
  • “DevOps engineer” – What is a DevOps engineer? Here’s what I found from an internet search: “A sysadmin that likes scripting and coding and moves into the development side to improve planning of test and deployment; or a developer that gets interested in deployment and network operations.” [2] Well, I’m glad I’ve gotten that cleared up. Let’s see if colleagues outside of IT understand it as well.

Now put on your “business hat” and try to navigate through this within your IT organization. Assigning a business relationship manager, signing a service level agreement and then calling it a day won’t fix this.

What causes us to continue to work in silos?

How are we in IT continuing to perpetuate our silos? There are several reasons.

  • No common language or vocabulary
  • No understanding or recognition of how components work together
  • No “big picture” view
  • No common reference framework
  • No clear “line-of-sight” from individual contribution to the organization’s mission, vision, and goals.

Do any of these sound familiar? Weren’t some (or all) of these issues going to be solved with the last thing we rolled out?

It’s not the framework’s fault

Make no mistake. Leveraging standards, frameworks, and methodologies within an IT organization can be good things. But every standard, framework, and methodology has strengths and weaknesses. I’ve yet to find a single approach that addresses every issue or concern an IT organization may encounter.

We also must recognize that people are people and we’re counting on them to think, then do…. not just do. But instead, IT organizations have often implemented frameworks and methodologies in a never-ending pursuit to implement the latest and greatest thing without identifying and defining outcomes that support tangible business objectives. In other words, they’re just “do-ing”.

Getting out of the silos

Getting out of the silos will not be easy. Let’s face it, IT organizations have been working in silos for a long time, so it’s not going to stop overnight. It will take an investment of time and resources. It will take planning that includes communication and training. It will require a shift in the culture in the organization, so effective organizational change management is a must. But most of all, to get out of the silos requires commitment by the entire IT organization.

Which means that IT organizations must identify what needs to be done, define what the results need to be, adopt best practices that will help achieve those results, and then adapt them for use at the organizations being served.

Therefore, if an IT organization truly wants to rid itself from silos, it must be driven from the top-down. The bottom-up approach that has been attempted so many times before will not work.   It must be inclusive – no one from IT can be excluded. It requires a clear well-defined strategy. It must be directly related to the vision and mission of the business, with clearly defined measures that support business goals and objectives. And, if IT is to remain relevant within the businesses it serves, it must start now.

In other words, IT organizations must define and follow a way to work holistically. Piecemeal adoptions of frameworks and methodologies do not work. What would be the impact of an IT organization without silos?

Click here to subscribe to my newsletter!

[1] ITIL is a registered trademark of AXELOS Limited.

[2] https://puppet.com/blog/what-a-devops-engineer

Share twitterlinkedinmail

4 thoughts on “We talk. No one understands. Why?”

    1. Thanks for reading the post and for your comments. So much of the misunderstanding that occurs between IT and the business it supports is actually caused by IT itself! When IT doesn’t agree on a common vocabulary internally, those external to IT feel the effects!

  1. I fully share the view that the mess in ITSM does not help its success. Perhaps it is a good idea to turn ITSM into a science direction in order to put terminology, classifications and so on.
    Perhaps this situation helps to do good business with newer frameworks, metologies, approaches and qualification schemes, and just the time of a unified approach has not yet come.

    1. Thanks for your comments, Al. I don’t necessarily have an issue with IT shops adopting and adapting different frameworks and methodologies in order to deliver services needed by businesses, but at least take the time to define a business-oriented vocabulary to enable good communications!

Leave a Reply

Your email address will not be published. Required fields are marked *