Business memes.

“Transformation!” “Culture change!” “Two speed IT.” “Be agile!”

Gotta be careful with these, since the catchy label travels faster than the thinking.

Love them or hate them, most business memes do have something to teach us; you just have to dig for the lesson.

We did some digging into an old meme, “IT enabled growth.”

If you’re feeling grumpy with another part of your org that’s supposed to build you things, or if you are the recipient of such grumpitude, then there might be a lesson or two in here for you.

Before we dive in, consider joining us this upcoming Tuesday for an open space on communication and leadership. Register here. 4th November, 12pm Eastern / 5pm UK. (Not recorded.)

“IT enabled growth” is more or less what’s on the tin. It’s a meme that describes a situation where a business depends in some way, through whatever strategy, on a highly effective technology group building and maintaining capabilities. It’s a relationship of dependence, summarized thusly:

You can imagine that the business would want to try a bunch of different ideas in the market, some of which will be winners, and many of which will not. But, to get a shot at trying any of them, the business asks IT to build stuff.

If IT is “aligned” with the business, it will then build those things. Ideally, quickly.

This is generally regarded as how things should work (“alignment = good!”), but it’s also where the problems begin.

In the ideal case, once IT builds a thing, the business will get clear signal of success or failure in the market, leading to a corresponding decision for IT to either operate the capability ongoingly (as long as the business believes it is profitable to do so) or to wind it down and cease its operation.

But what often happens instead is that the success/failure signal from the market is ambiguous. Without a clear decision, the default takes hold: “Keep it going!”

Proofs-of-concept drag on, temporary things become permanent, and fear and uncertainty keeps IT from turning things off and reclaiming resources like compute, disk space, and (more importantly) time and attention.

Regardless, IT builds and runs more and more different things over time, increasing the complexity of its existence more and more (and almost never decreasing it).

This causes two troubling things to happen:

In a stroke of irony, IT’s tight alignment with the business (i.e., building things the business needs) leads to fewer new capabilities for the business and more waste.

Nobody here gets what they want except the gods of entropy.

(For those of you following along at home, this can happen with any part of the org that builds things for others, and even in the business’s relationship to the market itself.)

Back in 2007, Bain Analysis put forward a 2×2 (which we’ve annotated below) describing this situation as the “Alignment Trap.”

IT is overburdened and less effective, so spend goes way up, delivery slows way down, and the business’s growth tanks.

So, how does a company get out of such a predicament? Bain’s escape path is a pendulum swing away from tight alignment between IT and the business.

To sum up the maneuver: Simplify, consolidate, standardize… fight back against the complexity introduced by everything built to satisfy the business, and to hell with meeting their needs, at least for a little while! Just get things back to a baseline degree of sustainability. Then we can start improving how IT functions and restore its effectiveness (“Well-oiled IT”). Once that’s in place, then we can once again provide new capabilities to the business” (“IT-enabled Growth”).

Our telling may be a slight exaggeration, but it needn’t be so dramatic in practice. We would argue there are likely more transitional approaches that are less flailing in their execution, smaller ways to accomplish the same thing more assuredly. Really, it’s just something you might otherwise know as “refactoring” applied at the organizational / architectural scale.

So, with that in mind, here are a few of the lessons that came up for us as we dug deeper into this business meme.

“IT” vs “the business” is a simple tale that hides how things actually work.

One ought to at least appreciate one layer deeper in the social / functional network in order to have a healthy understanding of what is actually actually going on.

If IT is comprised of different functional areas, like development and operations, then it would be wise to think in those terms. Similarly, “the business” is going to have different functions as well. Marketing will have different needs than sales or product.

The organization is a network of different entangled components, not just two things (business and IT). Regardless of where you are in the org, your relationships are similar; there’s always another layer down to understand.

Once we stop being overly broad about what parts of the organization are involved, we need to make our complaints more specific as well.

“Development is slow and ineffective.” “Product asks for too much.” These complaints are so broad that they interfere with dealing with the actual problems. Instead, it’s better to confront the specifics of the commitments made, things built, how they relate, and how thin folks are spread.

Hiding the mess does not serve us. While we may not always have room in our minds for all these details, the situation must be clearly understood (by someone) to that degree.

Broad brushes do not make for smart decisions. Encourage people to get into those specifics, and to speak in those terms.

“Complexity” is the word used by Bain, but the key thing being manipulated is “variety,” of “Ashby’s law of requisite variety” fame, which loosely states: “in order to be efficaciously adaptive, the internal complexity of a system must match the external complexity it confronts.”[3]

If we reach a state where the business has asked for a million different things, and IT has generally agreed to provide it all, then IT has just signed up for a ton of variety, meaning low sameness, low repetition, low scale, low certainty, high failure. You don’t get any efficiencies across similar capabilities. Each one is its own thing.

Technically, it may be efficacious at adapting to the demands of the business, which itself is adapting to the demands of the market, but all that variety is expensive. Our response to that “external” complexity can be thoughtful and deliberate rather than a work of the raw forces of evolution.

The business is not wrong for wanting those million things. IT is not wrong for wanting to meet the requests. But IT will implode (and the business with it) if it does not find a way to significantly reduce the variety across things it must build and maintain.

Variety reduction restores focus and speed by lowering the burden of operation. Higher sameness, repetition, scale, certainty. Less failure. More efficiencies. Yes, at the cost of being less adaptable to the business’s needs. (For more on this, see Cat’s talk above on variety.)

There is a time to build and maintain.

There is a time to cull, refactor, and simplify.

Is this dynamic balanced, deliberate, regular? Is it small and everyday?

We don’t think these things need to be dramatic maneuvers, but at some point the building has to be countered with at least some tearing down, some restructuring.

If you don’t do it on purpose, the system will correct for you, and at greater cost.

We’ve found that leaders and managers don’t always get the training or experiences they need to feel justifiably confident in how they show up in leadership. To make it harder, many seemingly technical or expertise-based challenges are actually social and organizational messes in disguise. Dealing with this is a lot for any person, let alone someone whose job it is to “have it all figured out!”

That’s why we work with execs and their leadership teams to create efficacy and cohesion in those situations. To face tough challenges together, with clear heads and kind hearts.

Not everyone can be our client right now, but we still want to help you however we can. That’s why you’re invited to join our open space next week on communication and leadership. 4th November, 12pm Eastern / 5pm UK. (Not recorded.) You’ll decide what to discuss with peers, and we’ll make sure it’s a worthwhile experience for everyone.

Thanks for reading,
Ben and David
StrategyTeaming.com