The Boardroom and the Server Room Speak Different Languages

I spent years thinking my job was to make good technology decisions and present them clearly. I was wrong about the second half, and it cost me a million-dollar project in front of a room full of executives.

The job was to make good decisions and then translate them into a language the people holding the money understood. I learned that lesson late, and the hard way.

I was Director of Computer Operations and Technical Services at a major national retailer for years, and now I ghostwrite books for technology leaders. The single most important thing I learned about leadership had nothing to do with technology at all, and I learned it in one brutal moment.

I walked into the executive boardroom with weeks of preparation behind me.

Technical diagrams. Flip charts. Bulletproof projections. I had a proposal that would save the company millions, prevent system failures during peak shopping seasons, and modernize infrastructure that was long overdue for replacement. I knew the systems inside and out. I was ready to dazzle them with my expertise.

Halfway through my first slide, the CEO raised his hand. Not to ask a question. Not to dig into the technical specs. To end it. “Richard, I have no idea what you’re talking about. We’re done here.” Silence. My carefully crafted presentation became worthless paper. My million-dollar project died right there on the conference table, halfway through the first slide.

He wasn’t being cruel. He was being honest. I really did have no idea what I was talking about.

My technical solution was sound, but I never bothered to explain why anyone should care. I gave them a technical manual when they needed a business case. I spoke in code when they needed plain English. I showed them how clever I was when they wanted to know how this solved their problems.

Here was the gap. Leadership wanted information in business terms. Costs, returns, risks, outcomes. I was a technology person, and I spoke in technology terms. System optimization. Infrastructure enhancement. Operational efficiency. Every one of those phrases created distance between me and the people who controlled the budget.

And it had been happening for a long time before that boardroom.

I’d brought proposals to management before and watched them stall, and I never understood why. I had good proposals. The logic was sound. The technology was right. And still things died. I assumed it was budget, or priorities, or politics. It never occurred to me that the people deciding simply couldn’t understand what I was asking for.

That’s the quiet killer of technology initiatives. The proposal gets rejected because the person who has to approve it can’t evaluate it on its merits, and instead of admitting that, they say no. It’s the same dynamic I describe in what a security leader does, where half the job is getting things approved by someone who can’t judge them on the technical merits.

After that boardroom, I understood. If you want financing and buy-in from upper management, they have to understand what you’re asking for. Not the technical details, the meaning. What it does for the business, what it costs, what it risks, what happens if you do nothing. The burden of that translation is on you, the technology leader.

Your job is to speak their language, and they have no obligation to learn yours. A brilliant proposal nobody upstairs can understand is a proposal that dies, and it dies looking like a no when it was really an I don’t follow you. The CEO who stopped me was doing me a favor, though it didn’t feel like one at the time. He told me the truth that every other executive had been too polite to say: I was speaking computer to humans, and the humans had stopped listening.

It’s the same translation problem that sits at the center of every transformation, so I put people and communication ahead of technology in people, process, technology. The technology is never the hard part. The hard part is getting humans to understand it, fund it, and adopt it, and it runs entirely on your ability to speak their language instead of demanding they learn yours.

How does a million-dollar technology proposal die?

It dies early, the moment the people holding the money realize they can’t follow you and nobody in the room wants to say so. I’ve got very little sympathy for technology leaders who blame executives for that, and I include the one I used to be. The translation was our job. The story of the day you learned it, the hand going up halfway through your first slide, is exactly what a leader’s book should carry, because the technical knowledge is everywhere and that moment is rare.

When I ghostwrite for a technology executive, the moment they admit their own blind spot is usually the strongest part of the book.

The reader doesn’t need another expert telling them what to do. They need someone honest enough to say here’s the mistake I made for years, here’s the day it blew up in my face, so you can skip it. You can see how I work on the technology ghostwriting page.

Technology books that only show the author being right bore me, and they shortchange the reader. They teach nothing about the part of the job that ends careers, standing in front of the people who control the money and losing them before the first slide is done.

I ghostwrite books for executives and technology leaders who want their hard-won experience on the page, accurately and in their own voice. If that’s you, here is how I work with technology leaders.

Frequently Asked Questions

From the author

Don’t Live in Fear
I lost the CIO job I wanted because I was too chicken to talk to people. Don’t Live in Fear is about the walls that kept me silent and how to get past yours.