Driven to abstraction 

One of my early mentors told me the secret of his success: Throughout his life, he made decisions based on what he cared about and acted accordingly. At the time, I was consulting and writing code. I interpreted his advice to mean that I should constantly re-evaluate technology to find the best fit for my skills and requirements. In a word, specialize. As I moved into management, I relied on my mentor’s wisdom to avoid micromanaging projects that were being handled well by others. In a word, delegate.

I crossed into my first executive position when the ’90s high-tech boom was taking hold. We had sky-high budgets and saw no limit to what technology could accomplish. At my place of employment, IT execs had contentious weekly meetings over platforms, programming languages, emerging technologies, and competing standards. We were so delighted mucking around in the minutia that we glossed over the questions that really mattered. Back then, ROI wasn’t our overriding concern. Technology executives lived in dread of falling behind the pack. I recall wringing my hands over learning that a competitor was doing transfers from its back-end systems twice a day; ours occurred nightly. We never talked about the business implications of that. We were just afraid someone might think we weren’t on the ball. The watchword for that approach turned out to be “bankruptcy.”

How fortunate for all of us that, for a while, the smartest people in IT were more concerned with elegant technology than the bottom line. It didn’t turn out well for some of our employers, but having everybody focused on the details for a few years brought about huge changes in technology. So many things came about because people with better things to do were fussing over angle brackets. I think that lasted as long as it should have. Profits and costs matter again. Business is back in the driver’s seat.

Coming back to business after being completely obsessed with technological plumbing, I have a fresh perspective. Now I see choosing what I care about differently, in a way that incorporates my prior interpretations, draws value from my expensive mistakes, and takes things one step further. We specialize because we can’t know everything. We delegate because we can’t run everything. Today it’s important that we abstract because recent history has forced us to accept that everything is temporary. That’s neither deep nor bleak, just true. People change jobs, companies change hands, customers change loyalties, partnerships are broken and made, and the vendor you favor today could do something stupid tomorrow. Except in rare and unpredictable cases, your company’s individual technology choices will not change how your customers, partners, and suppliers behave.

If the word “abstraction” sets off your meaningless-buzzword detector, silence the alarm for a few seconds while I explain. Abstraction is the underrated process of managing complexity with a whiteboard eraser. You erase the small boxes inside the bigger boxes and the twigs from the trees until the diagram reflects what you can (or should) control. That doesn’t necessarily alter the architecture. It doesn’t send the message that the details are unimportant. What it says is what my boss should have said to me five years ago: You keep your job (or, if you’re a vendor or service provider, get your annual contract renewed) as long as I don’t care about what happens inside this box. If I have to get involved in the details I entrust to you, you will compete with everyone who wants your job (or your contract) to define and implement a solution that takes this off my radar again.

Let’s make the concept simpler by making it personal. I buy the groceries for my family. My wife doesn’t tell me what kind of paper towels to buy. I’m free to choose the brand I like and switch when there’s a sale. But if I switch to a brand that doesn’t work for her or to old T-shirts because that’s the latest thing, she’d applaud my willingness to change but tell me to stick with what works. If I didn’t switch after that, I’d soon be buying the brand of towels she tells me to buy.

If executives are involved in implementation details, they can’t help their companies evolve. Would I reduce every CTO, CIO, vice president, and project leader to a hands-off paper shuffler? Certainly not. But understand that the closer you are to the top of the IT org chart, the more you have to think about business realities such as doing more with less, eliminating dependencies, and keeping track of what your customers and partners actually need. That last bit might be the toughest to accept. What matters most to people and businesses you serve might have little in common with what you think they should care about. And that is the heart of the concept of abstraction. To use abstraction as a tool to focus your effort, whether you abstract technology, roles, or business processes, you have to accept that others will use it, too. They’re not going to map out their worlds the way you think they should. If you’re upset with your customers or users because they won’t use the brilliant technology you’ve put in their hands, it’s likely you are looking the wrong way at them and your role in the company.

When IT execs draw boxes inside boxes and push down decisions for which others are accountable, the business cannot evolve. In that setting, evolution only happens in a crisis, when something breaks, or when someone quits. Why abstract? Why keep raising the line that separates what you care about from what you entrust to others? Because you will never finish dealing with those details. As the IT-planning horizon becomes increasingly shorter, detail-obsessed executives won’t have an answer when the boss asks, “What’s next?”