Strategy for the Irretrievably Pragmatic

My Dad used to say that the reason many politicians are so totally ineffectual is because of the ironic and paradoxical fact that to be a good politician you need to be able to wield power wisely, and yet those who are drawn to power are often, by that fact alone, the worst people to be given it. He still says it, but these days I might counter with the thought that it’s just possible some of them go into politics to make the world a better place and get corrupted along the way, having to deal with so many snakes seeking retribution for having had no friends at school.

A place where this paradox does exist, and where there’s no plausible excuse for such ineffectuality, is in producing strategy. There are broadly two kinds of people who make strategy - those who are drawn to it and love it, and those who have it forced upon them.

If you like peddling strategy for a living, or worse like having the word in your job title, then I’d shorten the odds that you’re not very good at it. Sorry about that. It’s harsh I know. I mean we’ve never met and I’ve insulted you in the third paragraph. But please bear with me because I’m sure I can make amends. And even if not, you can rest assured that, according my Scooby Doo theory of consultancy, you’ll never get found out - six months after you publish your strategy someone will be updating it and it will never be measured, so there’s no risk that your last customer will hunt you down with a deer rifle and the promise of a three minute head start. They probably should because I bet you cost them a small fortune and morally that strategy should pay back at least what it cost to produce. But let’s bury the hatchet and move on. Sorry. Bad choice of metaphor.

If you hate strategy and think it’s worthless and irrelevant to your day job then I’m afraid you’ll be equally pissed off to hear that you are exactly the kind of person that should be creating one.

Today’s article is for those who find themselves having to put together a strategy and don’t really know where to start, or for those who lie in bed an night, wondering if the noise they heard outside was just the trees, or the soft click of a Winchester Model 88 in the hands of a recently ousted CEO.

The Strategy Promise

Strategy is sold to businesses as a future-proofing concept. We are led to believe that if we don’t have one we’re doomed. The promise is that if we spend time and money on one (ideally quite a lot of both) then future success is more likely.

And yet most of us can bring to mind a company that’s succeeded in a buoyant market without one. So perhaps it’s not compulsory to have a strategy. Pragmatists would say that the rules of business are simple - you respond to changing needs as they arise and you do your best. The opposing argument is that in hard times the reason some businesses do well while competitors go to the wall is that they are better positioned, due to the fact that they have a well-executed strategy - something that goes beyond meeting immediate needs.

If a strategy enables us to do well in harder times then we can say it has tangible value. That value is whatever revenue we continue to make over what we would earn without one. The value of a strategy in a growing market is harder to measure. It should maximise returns and enable sustainable growth, but only insofar as this prepares the company to survive the next recession.

Strategic Value

Strategic value comes from using it to make decisions. It’s not so much a future concept as advice from the past.

That’s Pragmatic Point Number One - a strategy that doesn’t tell you what to do isn’t valuable. The net result of what you do should be investment in sustainability in the good times so that you can reap the returns in the bad. Reacting to needs doesn’t do this because in good times your immediate thoughts aren’t about sustainability, they’re all about growth. By the time you realise the market is shrinking and your focus shifts from growth to survival it’s too late. Strategy sits on your shoulder and tells you what to do today, not next year.

Here’s Pragmatic Point Number Two - you have to build strategy from the bottom-up, not top-down. If there’s no bottom-up aspect to your strategy, then it will all be about “what-if” and “to-be” and not “as-is”, to use the common architecture terms. With no account taken of the way things are, it can’t possibly be made relevant.

Most strategies end up as expensive ineffectual shelfware because they focus only on the future and are drawn from an idealised worldview.

Strategy Directed

I recently did a presentation on the idea that it should be possible to apply CMMI-like maturity models to solution design. The TOGAF framework contains a section on Architectural Maturity that, in theory, measures how well aligned your enterprise architecture and your business are. Architectural Maturity may be useful for some, but it doesn’t tell me how to assess any one proposed solution to see if it’s helping deliver on the strategy, or even moving things backwards.

So I created my own Solution Maturity Model, that adopts the same principles (repeatability, reusability, adaptive to change, etc).

Pragmatists might scoff and say that having a Solution Maturity Model whiffs of consultant-speak and I’d agree. In fact, it’s just a way of saying that good (immediate) design and mature (strategic) design can be the same thing. By using the same approach for the solution as for the enterprise it is much easier to execute in practice because there’s a common approach from top to bottom.

Take the simple design choices of how to get data from Application A to Application B.

Some obvious examples might be:

• FTP a CSV file on to a shared drive and let application B collect it.
• Put the data into a relational database and let application B retrieve it via SQL.
• Put the data into a relational database and write an API to access it.
• Put the data into a relational database and write a discoverable service to access it.
• Publish the data onto a message bus and have Application B subscribe to it.
• Skip the relational model and put the data as an object into a shared memory grid and have Application B notified of its availability.

The options are roughly in increasing order of sophistication and maturity, each requiring slightly more effort than the last. Each has quite different characteristics in operation. All would work to some extent but, depending on the usage profile, some would fail to meet systemic requirements over the long (strategic) term.

Which is design decision is “right” depends on two things:

1. The immediate nature of the business operation

   FTP-ing transactional data around might work. It’s still a depressingly common practice but it is quick and very easy to implement. Use of a message bus or a grid may appear overkill. It certainly would if you don’t already have one. Then there are those database options. Still relatively easy to do, but we’ve got to start thinking about object-relational mappings and extensions to the schema etc.

2. The strategic direction of the business operation

   This is where we listen to the voice on our other shoulder. If the business is leaning towards needing this data in real-time, or the data volumes are going to scale appreciably, suddenly the more mature options don’t seem such an overhead.

Strategy is there to help you make choices that aren’t observably valid. It helps remind you that they will be, or rather they might be. There’s no crystal ball.

Confusion around strategy comes about because we mix up words that are related but mean different things. It’s important to make a distinction between what we mean by things like vision and strategy and later, when we do things, between objectives and mission. If you are embarking on that strategic road, you need all four. The best way to show this is by example.

Strategy in Action

Let’s assume we work for Strategy Inc. a top tier consulting firm that helps companies survive in tough times. To avoid any circumstances in which we might find ourselves running through woods in our jammies with the cry of “say hello to my little friend” in the distance, we focus only on strategies that make sense from the boardroom to the development environment.

Our four-step programme is Vision, Strategy, Objectives, Mission.

Vision

Last Christmas I ordered my brother a remote control helicopter from one of those online boys-toys stores. I placed the order about three weeks before the last shipping date and waited. After a week I heard nothing from them so I emailed and asked for a status update. Remote control helicopters were a bit of a craze at that time so I wanted to make sure they weren’t sold out. The web site was still taking orders so I assumed they had stock. Other places had stock so I wasn’t too panicked. But I heard nothing. This email/no-response thing happened maybe twice more. Then just as it was too late to go elsewhere, they cancelled my order because of lack of stock. Appalling customer service.

As a product of one of Branson’s Virgin companies, customer service is something I think about a lot. What’s interesting about customer service is that it’s as much about honesty as it is about things like value for money. People make mistakes. Stock runs out. It happens. Customer service means being open and straight about mistakes and fixing them, because honesty has a value to people, just like half-price discounts do.

So here’s a vision. Let’s say Strategy Inc are consulting to surprisinglyfragilegadgets.com and our vision for them is:

To be ranked highest for customer satisfaction amongst all the purveyors of fleetingly divertive tat.

It’s a good and clear vision because it’s measurable (we either get there, or we don’t) and trying to achieve it can only lead to good things. It’s not clouded by statements about profitability or being “the best”. If customers like us, they’ll be loyal, and spend more. It’s all good.

Strategy

Now. Strategy. I think the reason it’s viewed with such suspicion (at least by pragmatists) is that it’s never made clear that it’s the link between the vision, which is imaginary, and the necessary actions, which are real.

To overload the analogy bucket for a second, imagine you’ve just arrived at Disneyland and for the entire seven hour car trip you’ve been glorifying the vision of a ride on Big Thunder Mountain to the kids. You leave the car park and there’s one of those maps that shows the layout of the park. The vision is Big Thunder Mountain, the strategy is your route to get there. But before you even think about that, the first thing you look for is the familiar you-are-here symbol. Without knowing where you start from (the bottom-up view) you can’t make a plan. Top-down (i.e. vision backwards) can work, but it still has to lead back to where you are to be a plan. Enough with Disneyland. Back to electro-baubles.

There are two things to know about strategy.

The first is that the elements that contribute to it should all be an appropriate ending to the sentence “We’re going to be ranked highest for customer satisfaction by…”. This way you are already introducing activities (and we’ll come on those in a minute) and you relate strategy to vision in a very direct way.

The second thing to note is that strategy is the first front in the war against the competition. Wanting to be loved by your customers isn’t exactly a unique desire, so it’s the role of strategy to begin the process of differentiation. And differentiation is where you get your edge. The best way to get that edge is to turn every question on its head before answering it.

In this example, the obvious way to get customer satisfaction is to do more of the things customers like. But that’s not a differentiating strategy, because that’s what the competition will do. It’s not that doing more of what customer’s like is wrong, it’s just that if that’s all you do you leave differentiation to the execution stage, and that’s risky. Turning the question on its head suggests our focus should be not on more of what customers like, but less of what they don’t like (and more of what they like, but that’s business as usual, not strategy).

In my real world example, I was annoyed because I got told too late the company couldn’t fulfil my order. So I now shop somewhere else. That’s where a strategy would have helped, because whereas it’s impossible to keep all your customers happy all the time, it’s quite straightforward to not piss them off at key piss-off points - hell they could just have given me a voucher and a nice email but instead I spend a few hundred pounds a year with their rival.

So the strategy is to make a list of all the places where customers get pissed off and not piss them off.

Pragmatists at this point should be thinking that put in those terms our strategy sounds so bleeding obvious as to be worthless. Again, I agree. That’s precisely what I meant when I wrote The Death of Architecture. A strategy (and architecture and anything else that’s intangible) is worthless. But if we do it, if we move straight from the plan to the action, then it’s not. It’s not worthless because the world is full of companies that really suck at customer service and strategy. The goal is not to polish the strategy until it gleams. It’s to suck less than our competitors. As Paul Graham said:

Since start-ups make money by offering people something better than they had before,
the best opportunities are where things suck most.

Most businesses stop after they’ve made a strategy. And move right to suckland. Even with great strategies like (ahem) mine, many businesses think that publishing the piss-off points is where the journey ends.

The fact is, for pragmatists, it’s only just begun.

Objectives

Objectives are easy. They’re the things we’re actually going to do. You will have heard of these before - they’re called projects.

Project [noun. proj-ekt]. Something that is contemplated, devised, or planned; Should contain these logical steps: take a business problem, define it well, evaluate alternative solutions, determine the one with the best business case, do it.

You ever noticed how businesses publish their strategy, IT lines up to execute it, and then the business sponsors kick off a whole range of projects that have nothing to do with the strategy? Partly that’s bad management on the business side and partly it’s because IT isn’t explicit enough in the discipline of Portfolio Management.

Here are some rules they don’t tell you:

• Never name a project after the solution, always name it after the business problem - how many times have you started work on a project called something like “new customer database”, assuming that someone somewhere took a business problem, evaluated some solutions, and determined that a new customer database had the best business case? They didn’t. And if you’re not focussed on the business problem you won’t be fixing it.

• Never let the business create IT projects - there are always bits of IT that need fixing. That’s IT’s job. Nobody in the business should use phrases like “message bus” or SAN. The business asks for business things and IT delivers a service to provide them. If the business is focussing on IT problems, no one’s addressing business problems.

• Force priority calls. Is it not remarkable that 50 projects can all have a priority of one at the same time? If the business can’t decide, add a project attribute called something like strategic value, and make those that show clear alignment higher priority, or run them as time-boxed agile initiatives and let the business prioritise as they go.

• Monitor the business case of everything. Business case doesn’t imply only business people can do one. It means more benefits coming out than cost going in. If a project doesn’t have a business case it should be questioned.

Our (example) projects might be:

• Web site usability - to address five things customers hate about our web site (too many pages in the order process, not enough proactive communications to the customer, and so on)
• Order fulfilment - to address the things customers hate about our shipping service (no gift wrap option, slow courier)
• Customer service - to address all the things customers hate when they need to complain (ignored emails, hard to find phone number).

We’ll also increase our stock range, add promotions and advertise but we won’t pretend that makes us unique we’ll just call that doing the basics.

Mission

And finally the mission. This is how you ensure great execution of those projects.

The technology staff at surprisinglyfragilegadgets.com are a bit disillusioned. IT gets the blame for poor results because the systems aren’t always fully functional. Everybody knows that the truth is half the projects represent the business grasping at straws, with obvious consequences, yet nobody blames marketing for the promo that lost money, or finance for the bad debt. We might have a new vision, a strategy to get there, and some projects to work on, but that won’t mean diddly if the people that work on them would rather watch a chicken-cam all day than get excited about the day job.

David Taylor, the only motivational speaker I have any time for, said in The Naked Leader Experience:

People will only ever do something to the best of their ability for one reason, and one reason alone, and that is because they want to.

Not rocket science, you might say, but what he means by that is incentives (bigger bonuses, promotions, etc) and penalties (no bonus, performance improvement programmes) don’t work. If they do they only work for the very short term.

What surprisinglyfragilegadgets.com needs is motivated people. Telling them how crap it is now won’t help. That’s either going to be insulting (because it’s not like they aren’t working hard) or not news. Motivation comes by meeting two core needs: people need to know how to add value and then to be valued when they they do it. And that certainly isn’t rocket science.

Add Value? Easy. Link everyone’s daily, even hourly, activity back to the vision. When one developer chooses one integration option to get that information to application B over another, they are contributing to making customers happy (or pissing them off less). Show how a business analyst can re-engineer requirements to make them more effective and not just meet them as they are. Show how a Project Manager can think beyond meeting some arbitrary deadline and make it more likely that the objectives will be met. Do this for all roles (after all they must all be there for some reason).

Be valued? Easier. Say thanks. All the time. Financial incentives are fine, especially if everyone is seen to be getting the same share of the proceeds, but there’s no substitute for recognising a job well done. That also means not criticising when the job isn’t well done. Criticism is rarely productive, showing how to do things better is. Who in IT doesn’t want to be a better expert than they currently are?

And that’s it. Strategy isn’t hard at all. It’s also not vague or useless. It does need vision, objectives and mission too, but they’re not particularly onerous when you think about it.

Now if you’ll excuse me, I feel the need to go and buy a USB clock pen that doubles as a Winchester Model 88 deer rifle.

After all, you never know.