All Posts in Office Politics

|In: Industry Commentary|Last Updated:

The subject: Bimodal (or trimodal, or agile, or high-speed) IT. The challenge: Culture. Culture is a challenge to IT agility. It’s a challenge if you buy into the bimodal model, where systems of engagement need to change and adapt at lightspeed while systems of record need accuracy and stability above all else. It’s just as big a challenge if you embrace the trimodal model described here last week.

Culture is a challenge because it means “how we do things around here.” It’s the set of shared assumptions that let people work together efficiently. Think of culture as an organization’s cognitive infrastructure — a foundation everyone builds their thinking on, confident that if they do, everyone else is likely to agree with their conclusions.

Start with the six dimensions of optimization: Fixed cost, incremental cost, cycle time, throughput, quality, and excellence.

With bimodal IT, systems-of-record employees assume quality, throughput, and incremental cost are what matter most, while systems-of-engagement employees are equally sure cycle time, excellence, and fixed cost are what deserve the most attention.

It’s a recipe for conflict. Now add this: Systems of record are part of the business infrastructure. They’re necessary but not strategic. Businesses invest in them to preserve the value they’ve been delivering for quite a long time.

Systems of engagement are strategic. Businesses invest in them to get new value. One way or another, directly or indirectly, systems of engagement are part of how businesses get the cash register to go ching!

Which means fast-mode IT projects get better and easier funding, and the IT professionals who staff then get more … and more career-enhancing … attention.

The trimodal analysis is a bit different. Understanding its built-in conflicts starts with another property of culture — it’s a big part of how employees define identity, affinity, and, as a natural byproduct, ownership.

The trimodal model isn’t built around the systems of engagement vs systems of record model. It’s built around a progression, from prototype to production-grade, and then from production-grade to part of the core architecture.

In Simon Wardley’s version, described here last week, the progression is managed through a process of theft — “settlers” steal “pioneers'” prototypes to make them production grade; “town planners” steal settler’s production-grade systems to make them suitable for inclusion in the core architecture.

Think pioneers are going to thank the settlers who take over control of their creations and impose strict new rules for their evolution? Think the settlers, who have carefully adapted their systems to support their part of the business, will be delighted when town planners take them over and generalize them so they support the whole enterprise better by imposing one-size-fits-nobody design compromises?

Think again. No matter how what system of governance IT and the rest of the business impose to regulate this process, it’s still going to feel like kleptocracy to those on the receiving end of it.

You’re the CIO. One way or another you need to keep the lid on conflicts within IT. So you instituted DevOps, not only to help speed things up but also to reduce the usual and natural conflicts between Development and Operations. But DevOps exacerbates conflicts between the high-speed culture that uses it and the low-speed one that avoids it.

You’ve already instituted some form of Agile Enterprise Technical Architecture Management (ETAM). (Haven’t you?) With some trepidation you incorporate the kleptocratic town-planner function into it. But you recognize the resentment it will create, and want to minimize it.

What’s the plan?

There are no best practices for this. Not that there ever are, but some fields at least have proven, tested practices. Here, the best we can do is apply what we know to what we don’t know. Three suggestions:

  • Avoid false dichotomies. System of record vs system of engagement is one. These aren’t opposites. They’re the poles of a continuum. System-level governance should establish the proper trade-offs between system-of-record-ness and system-of-engagement-ness for every system IT manages.
  • Rotate staff. No, don’t have them spin in circles. With some exceptions — your deep system mavens who like being deep system mavens — move applications staff from one system to another, and in and out of your ETAM function. Move operations staff from one DevOps team to another, and through ETAM as well. Resenting them is harder when they become we unpredictably and often.
  • Promote “Form Follows Function.” As the first rule of design it’s already at the heart of your architecture (isn’t it?). Those who embrace it are more likely to assume those who do things differently are dealing with different circumstances.

Making it part of how we do things around here will reduce cultural conflict.

And happily enough, it will also improve design.

Comments

|In: Office Politics|Last Updated:

I’m writing these words in Denver International Airport. It’s 8:50pm. My flight, scheduled to leave for Minneapolis an hour ago, is delayed until 10:20pm.

Last week I wrote unkind words about the International Air Transport Association and the airline industry in general. They wouldn’t stoop this low to get revenge. Would they?

This isn’t another diatribe about the IATA, although I do have one more suggestion: Instead of tinier carry-on bags it might consider setting a seat engineering standard. What it is: Movable seats and a pay-by-the-inch ticket price. Pick your seat, pick your legroom, and seat spacing dynamically and automatically adjusts to fit.

Okay, there are probably less expensive ways to achieve the same goal, but this would be really cool, don’t you think?

Speaking of preferring really cool for cheaper solutions that achieve the same ends, how much is your Marketing Department spending on social media analytics to find out what your customers are saying about your products and services?

I’m not saying this is a bad investment. Far from it, although I’m far from unbiased. My employer, Dell, has been a pioneer in mining the social web to understand what customers are saying — so much so that Dell Services offers this as one of its consulting specialties.

So: Want to understand what your customers are saying about you? Great idea. Using analytics to do so? Call me.

But before you invest another dime in social media analytics, with us or anyone else, start with a cheaper, easier, and more reliable data source: Customer Service.

Customer Service is the Rodney Dangerfield of business departments. It gets no respect. Way too often its key metric is minimizing the cost per call, and as a result it’s too-often the place your customers go to be turned into your competitors’ customers.

It could and should be a lot more: The place Product Management goes to find out how to perfect your company’s products, and where Marketing goes to turn dissatisfied customers into your company’s best social media evangelists.

Once upon a time there were two semi-reasonable excuses for not doing this. The first was organizational: Customer Service doesn’t usually report to either Marketing or Product Management. I lied about it being a semi-reasonable excuse

The second was that it would have been way too labor intensive, a matter of listening to a statistically significant sample of all of those calls that are “recorded for quality assurance purposes.”

Which isn’t exactly untrue, merely too-limited an explanation. They’re recorded to improve the quality of the Customer Service department, not of the products Customer Service services.

Okay, I lied about that being a semi-reasonable excuse, too, because the only labor needed would have been to ask every Customer Service agent to forward links to the recordings of those calls Marketing and Product Management might find useful.

But imagine this isn’t feasible for some reason. This is, what, 2015? And you’re what, IT? Have you got a deal for them.

See, in 2015 all those recorded-for-quality-purposes conversations between customers and customer service representatives are digital data, and the technology for transcribing them to text isn’t all that expensive. It isn’t perfectly accurate, but you don’t need perfectly accurate. You need accurate enough.

Accurate enough for what? For mining the text, of course. You don’t even need a lot of sophistication to mine it. Mostly you need a list of key words and phrases Marketing and Product Management can use to draw inferences.

This isn’t rocket science. It isn’t even data science. Yes, it’s a couple of blocks outside IT’s comfort zone of databases, screens and reports, but this being 2015 and all, any IT department that limits itself to databases, screens and reports is limiting itself to the ante in a game of winner-take-all poker. And any CIO who waits until Marketing or Product Management asks for something like this has mistaken the job for order taker at Denny’s all-you-can-eat breakfast buffet.

Why does this even have to be said?

The tragedy of IT history took place in the early 1980s, when CIOs believed the so-called thought-leaders who told them IT’s job was to be “business-driven” and as a result stopped doing their best to drive the business.

News flash: The ’80s are over. They’ve been over for 35 years. From this point forward (the only direction worth heading), the CIO’s job … and not only the CIO, but the job of everyone in IT … is suggesting ways technology can address business situations, not waiting for the phone to ring.

It isn’t that the phone won’t ring. It most assuredly will.

It will just be someone else’s phone.

Comments