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 actually 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’d 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, not because my technical solution was wrong, but because 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’d 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 doesn’t get rejected on its merits. It gets rejected because the person who has to approve it can’t evaluate it, and instead of admit that, they say no. It’s the same dynamic I describe in what a security leader actually 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, not on them.

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.

This is the same translation problem that sits at the center of every transformation, and that’s why I put people and communication ahead of technology in people, process, technology. The technology is never the hard part. Getting humans to understand it, fund it, and adopt it’s the hard part, 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?

This is exactly the kind of lesson that makes a leader’s book valuable, and exactly the kind that almost never gets recorded. The technical knowledge is everywhere. The real job is translation. That understanding is hard-won, and the story of the exact moment you learned it, the hand going up halfway through your first slide, is rare and personal and useful.

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.

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