Is the IT Department Dead?

So over the week I was sent a link to a Wall Street Journal article on the death of the IT department that then subsequently did the rounds on LinkedIn, so I'm going to give some of my own opinion on this.

When I read the article I actually agreed with the majority of what was being said; I live it and see it in my own work daily and for me if a business wishes to use technology to better its competitive advantage, then it must look closely at how its IT department is structured.

TLDR of the Article

IT department isn't "dead" and IT isn't disappearing all together, instead where IT professionals sit within the organisation has to change in order to bring out better business outcomes.

Let's dig a little deeper

    1. Leaving IT decisions and activities to a department that is figuratively and sometimes physically far from the so-called core business is a recipe for disaster.

The article then goes onto say that IT is no longer an option but a necessity for a completive edge. When I was younger, I worked in a small family run Guitar business, the shop had a small loyal cohort of customers, but struggled to compete with "the internet". In fact I still recall the owners tone of disgust when it came to online competition.

"I can't compete with them, they stock the items high and ship them direct to the customers straight from the warehouse". The argument against using the internet was that the shop offered that personal touch, could tune and set up the instruments and take care of them and that may have been true, but the internet business' won, the little shop is no more.

So back to the point, essentially IT if to be a tool for competitive advantage, must find itself embedded alongside the business function that has that technological need.

    1. The problem starts with what I think of as the “partnership engagement model,” which is a natural outgrowth of having a separate IT department that is promoted as a partner to the “business.”

A point that is reiterated here Consider a European mobile-only digital bank I’ve worked with. As the CIO of the company says, not having an IT department means that you never need the phrase “the business.”

In most of my conversations I have about "the business" I try my absolute best to refrain from uttering the phrase "the business", instead I opt in for language like "instore colleagues" when discussing how technology effects store staff, or call a department by name "finance" etc. I think that it's a personal recognition, that IT is no longer a separate function to the operational success of the business. It's not the silent partner, that operates in the shadows like some technological puppet master, instead it's the collaborator and enabler of "better business outcomes".

But it should also be recognised that for the "the business" IT and technology is an in escapable part of normal business operations. I can't think of one single employee in my current employer who doesn't have to use a computer in some capacity to get their job done, technology is already embedded into the business, so why then would the technology people not be?

The difference is that embedding the tech people into the business function means that decisions and moving forward with ideas should be easier and "agile". Instead of the days of yore where a request for a change via the service desk and support would be funnelled into the development team we should be giving that business function technological capabilities to achieve its goals and outcomes. Cut the ticketing flow out.

    1. By setting up a structure that organizes employee groups around missions such as business banking, payments and marketplace, the company is able to embed technology know-how in each of these areas. Leaders can ask themselves a simple question: How do we harness the capability of technology to achieve our particular goals? In doing so, it frees them to use technology in whatever way works best for them.

Okay this point here I love, it's sort of what I said in above, that embedded technological capability is an enabler of "better business outcomes", cut short the time for an idea to turn into a system. Instead of wasting months or years on a project, missing the opportunity or steering way of course from the original idea or problem, embedded technological capabilities should give us short lead times, more room to experiment and achieve that agile bit "inspect and adapt".

    1. It’s important to note that this doesn’t mean anybody can do anything when it comes to technology. Decentralizing technology also requires some centralization. This bank has defined guardrails—everybody has to use the same security protocols and software-programming languages, and conform to a prescribed architectural blueprint when building digital products and solutions.

This point hit me like a ten ton hammer hello Machine Head any one???. I am seeing this very issue unfold before my eyes and it's strengthened in an article from McKinsey on Cloud Adoption in that article they speak of "Cloud Chaos", where by developers have largely lead the cloud adoption, but have lacked knowledge or support in the operability of a given system, the result: disparate set ups in scaling, reliability, disaster recovery and security.

Guardrails on!

I'm sure my colleagues in the department (yes, the IT one) would attest to my speaking of "guardrails". When I first started to learn about DevOps and what not, I was really bought into that idea of teams being able to choose their own tech, the whole "you build it, you run it" mentality, but to just allow a free for all is to invite failure, misery and woe. Instead I like the point in the WSJ article:

The objective is to create “freedom within a framework,” giving staff the canvas and the paint but leaving it up to them to decide what they paint and how.

I've been pushing pretty hard to define some of what that means for the teams here, instead of each team simply spinning up any old thing in the cloud via Terraform, we'd take advantage of the tools (terraform in this case) to define "approved for use" variants and flavours of infrastructure, as well as tooling in pipelines and to a degree folder structure. That's not to say that we dictate what tech is available, I'd regularly encourage open debate for using things, if the tech leads to "better business outcomes" then it should make sense to use the right tool for the job.

But by the very virtue of encapsulating what it means to build something, thus providing an exceptional developer experience and to build to a framework that better supports Operations and Support folk, we should be freeing up time and cognitive load to allow developers to do what they do best, develop. This should therefore bring out better solutions to problems, allow for innovation, allow for ownership and expertise in a given domain, etc.


In many ways I completely agree with the article. The traditional IT department isn't built for the digital age, those companies who are embedding technological capabilities into the business functions will more than likely see better returns on their digital investments, those that don't are destined to be part of a by gone era and much like the little guitar shop, may no longer exist.