What does building an effective IT organization require?

We’ve been asking and answering that question for the past few weeks (starting here, with business integration; last week we covered process maturity).

What’s next? Technical architecture, which is to say the stuff IT is responsible for building, installing, and maintaining. To line everything up:

  • Business integration is how IT figures out what it’s supposed to provide to the rest of the business.
  • Process maturity is how IT provides it.
  • Technical architecture is what it provides.
  • We’ll wrap things up with Human Performance – the factors and practices that make sure the best people are in place to make sure IT is integrated into the business.

I covered technical architecture in depth in my CIO.com feature, the CIO Survival Guide. The links are here:

So far as the processes and practices required to achieve and evaluate a strong and resilient technical architecture are concerned, these three articles pretty much cover the ground.

Bob’s last word: What these articles don’t cover is (blare of trumpets) … yes, that’s right: the importance of a culture of architecture to complement the culture of process discussed last week.

And I don’t have anything new to say on the culture front, so just re-read what I wrote there.

That makes this week’s KJR pretty short. Which is okay – I’m trying hard to follow a piece of advice I’ve both given and received over the years, which is that if I don’t have anything to say I don’t have an obligation to say it.

So instead, I’m going to give in to an irresistible temptation: an observation about Elon Musk’s decision to re-brand Twitter as “X”.

My take, based on nothing but speculation, is that Elon Musk must be the smartest person in the room, no matter what the room is, who’s in it, and what they’re talking about.

Among the consequences is an inability to recognize anyone else’s good ideas.

So I’m imagining a meeting of Twitter’s executive leadership team. The subject is how to turn Twitter into a going concern. Of the ideas floated around, the only one Musk could put his name on is changing Twitter’s name and brand.

Because it was Musk’s idea, it was, by definition, brilliant! Also the only brilliant idea spoken, a natural consequence of Musk having to be the smartest person in the room.

Again, I’m just speculating. But on the other hand, can you offer a plausible alternative explanation?

This week in CIO.com’s CIO Survival Guide: “7 IT consultant tricks CIOs should never fall for.” Fixing what’s broken by breaking what’s fixed plus 6 other common consulting misdeeds.

Some weeks are duller than others – this week for example. But then, this week’s subject is IT process maturity, and if there’s anything duller than maturity, it’s process.

Maturity is dull because mature people see all sides of an issue and are less likely to express themselves with the sharp verbal edges that keep an audience’s attention and makes them laugh.

Process is dull because it’s supposed to be dull: It’s about achieving repeatable (dull), predictable (duller), quantifiable (dullest!) results.

Not convinced? Imagine your morning stand-up meeting. This time is like the previous 732 mornings. There haven’t been any system outages or degradations. All projects are green. IT spending is within budget. There’s nothing to talk about.

Dull!

IT has process frameworks – lots of them – to draw on. Here’s mine: Delivery Management, Application Support, Information Management, IT Operations, and Personal Technologies Support (What makes IT work – IS Survivor Publishing, March 19, 2013).

If you want something more conventional, ITIL continues to be a popular alternative. Just ignore the acronym itself – it isn’t an IT Infrastructure Library. It also isn’t a collection of “best practices” because it can’t be: As explained in Keep the Joint Running: A Manifesto for 21st Century IT, there are no best practices, only practices that fit best.

In any event, the process framework you choose really doesn’t matter. What does matter is establishing, encouraging, and perpetually grooming a culture of process.

Lots of business writers toss about the term “culture” as if it has a unified, universally shared definition. Here in KJR-land we define culture as “how we do things around here,” or, with finer grain, the learned behavior people exhibit in response to their environment, understanding that much of their environment consists of the behavior exhibited by the people who surround them.

Which, having thoroughly buried the lede, leads us to understand the nature of a culture of process: It’s a shared, ingrained habit of thought that results in everyone in the organization dealing with the situation in front of them knowing, using, and continuously improving the organization’s documented way of dealing with this sort of situation.

That’s as opposed to a very different, but no less legitimate set of attitudes and behaviors we might call a culture of innovation, in which everyone in the organization figures we’re all smart people whose mental energies are better expended figuring out how to handle things than to look up an approved approach.

Bob’s last word: A culture of process is a good thing. At least, it’s a good thing when what you need are repeatable, predictable, measurable results.

It isn’t such a good thing when the situations you face on Thursday are different enough from the ones you faced on Tuesday that Tuesday’s solutions are square pegs that won’t fit Thursday’s round holes very well.

The hard part of this conundrum is establishing a culture of process that recognizes when following well-defined processes is optimal and when it’s an exercise in square-peg-ism.

Call that a culture of good judgment.

Now showing on CIO.com’s CIO Survival Guide:7 IT consultant tricks CIOs should never fall for.”

I’d have titled it “Confessions of an IT Consultant,” only you’d have thought I was confessing my own sins and not just reporting those I’ve seen other consultants engage in.