Technology Strategy Patterns

Introduction

This Is Water

My favorite joke is told by philosopher and author David Foster Wallace in his address to the graduating class of Kenyon College in 2005. It goes like this: One morning two young fish are swimming in the ocean. They come across an older fish who waves happily and calls out to them, “Morning, friends! How’s the water?” They nod in acknowledgment and swim on. Once they’re out of sight, one turns to the other and asks, “What the hell is water?”

With this joke, Wallace reminds us that the most obvious, important realities are often the ones hardest to see, that we can lock ourselves in mental models so complete that we don’t even know we’re imprisoned by them.

As technologists, we can be perhaps particularly susceptible to this. Our work is engaging and requires a watchmaker’s attention to detail. Yet, as technologists, we are businesspeople. A hammer doesn’t exist to be a hammer. It’s a tool to construct something else. Technology is one tool with which businesses are constructed, rise, and fall. We operate in wide spheres of ever-farther-reaching impact on the world around us. In a sense, this book is about constructing a new mental model within this water of business.

Discovering Strategy

The roles that are ultimately valued at an organization tend to be the people who do what the boss did. If the boss used to be a salesperson or deal-maker, that’s who she’ll recognize, side with, empathize with, reward, understand, and listen to most. If you want your voice to be heard, you must make a concerted effort to empathize with people, and employ the tools, techniques, and language that they respond to.

At one point in my career I was running the enterprise architecture department of a large corporation. My manager, the CTO, asked me to help him estimate a large project. He wanted me to go off and determine the “incrementals.” I didn’t know what he meant. But in my stupidity, I didn’t want to look stupid, so I didn’t ask him, thereby enthroning myself as truly stupid. So I went off and tried to figure it out myself and came back to him three or four times with something different than he needed. I was a pretty good technologist, but I didn’t sufficiently understand the language of business. And therein lies the problem. It’s hard for people to know what they mean themselves, much less express it to others in a way that achieves their aims. After all, that’s the secret to happiness in life: figuring out what you want, and learning how to ask for it.

As I have progressed in my career from developer to architect to CTO and CIO and Chief Architect, I have been asked to create a technology strategy many times. Concluding that no one asks the not-as-clever people to craft strategies for stuff that doesn’t matter, I was always delighted at the prospect. It felt like an honor, sounded really cool, and seemed important and big, like I had been asked to help make decisions about how to guide the organization. So I was over the moon for a moment. And then suddenly scared. Because I realized for all the times I’d heard people say the word as if they knew what they were saying, I had never seen anything that I thought looked like a strategy. My concern grew as I realized many of my (accomplished and perfectly reasonable) bosses hadn’t either. They didn’t know exactly what they were asking me to do, or what the result should look like. Perhaps the strategists were the only people left in the world with a higher room in the Ivory Tower than architects and academics. Eventually we all bumbled our way through it and got to something good enough. But in some cases this process took a year and wasn’t always optimal.

Yet I was intrigued, in part because it wasn’t lost on me that the clever people, and the people running the organization (only occasionally the same thing), were keenly interested in strategy.

While trying to discover what a good strategy should look like, I grew more concerned at being able to construct this seemingly critical but elusive and mystical document. Companies do not tend to publish their strategies externally since they contain revealing secrets about their plans and fears. So it is hard to find any recent, good, complete, relevant examples. I therefore took it upon myself to go to the source: strategy consultants. They are devoted to publishing their work and excitedly talking about it nonstop to anyone.

But once you’ve devised a strategy, it languishes on the shelf if you can’t make people excited to hear it, understand it, care about it, approve it, and execute it. Any technology strategy is, in a sense, a request to spend millions of dollars of someone else’s money. If you think of your work as a technology strategist in this way, you’ll do it differently. By which I mean better.

I have known many smart people, wonderful technologists, who do not get their ideas heard by upper management. They state what the problems are and where the problems are going to be, write that up, and put it on the wiki—and nothing changes. Once it’s too late and the platform is burning, those same architects get called in to rescue the situation. While people love to say, “I told you so,” no one likes to hear it. These well-intentioned souls may have had the best recommendations, but it never mattered. These folks can become alienated, feeling misunderstood and unappreciated. And the business loses out on their great ideas. This is precisely what I don’t want to see happen to you, and the reason I wrote this book.

Driving Strategy with Patterns

This book employs, albeit loosely, a suggestion of patterns that is likely familiar to you from the realm of software design patterns such as Decorator, Factory, Visitor, and Pub/Sub. They’re used as shorthand for known, proven solutions, to provide an easy way for us to communicate to each other. I chose patterns to represent the ideas in this book because of that familiarity, and because that structure makes it easy for you to look up these ideas for years to come. To aid in this, they’re divided into logical concept architectures.

Analysis

First we explore foundational and general tools for critical thinking that will underpin the other patterns in the book.

Creation

These are the patterns that help you directly create your tech strategy. If you implement all of these patterns, you’ll have a comprehensive, compelling annual tech strategy. But you don’t need to always implement all of them. You can also pick and choose individual patterns to take a strategic approach to more local, specific project work.

Communication

These patterns help you to organize the components of your strategy in a way that your colleagues and executives can understand, get excited about, and support.

I’m sorry to repeat an old saw, but it’s true: increasingly, it is impossible to distinguish between business and technology. But that distinction is still more powerful than it deserves to be, given typical organizational structures and the resistance to change, and an uncertainty about how to do so. I hope that in part this book will help you, your colleagues, and your organization to embrace this cross-pollination. I hypothesize that in the future, people who can learn quickly as synthetic interdisciplinarians will be highly effective, and highly prized, because maintaining that distinction is increasingly a barrier to progress, creativity, and innovation.

This book, I hope, gives technologists, strategists, product managers, executives, technology managers, and the architects who frequently mediate these worlds all a shared language. In this, may you be more fruitful.