The Board Doesn't Buy Technology

On a recent Coffee with Digital Trailblazers, Isaac Sacolick asked the panel about AI infrastructure debt: the gap between what companies expect from AI and what their data foundations can actually support. Near the end, he turned to me with the hardest question of the morning: you've got one minute to convince the board to fund the modernization. What do you say?

I didn't talk about technology. I talked about buildings.

You've may recall the news story of a partial building collapse in New York City. The lesson is an old one in engineering. You can't add ten more stories on top of an existing building unless the supporting infrastructure underneath will carry the weight. I spent sixteen years in the construction industry, so this one really hits home with me. Now, put ten 'AI stories' on top of a 'data' foundation that can't support them, and the technology building crumbles.

Boards understand buildings. They don't understand vector databases, and they shouldn't have to. The most important thing is to know your industry and know where the board's head is at, then put the argument into the parlance they already speak. They'll get it.

Liam Yu from Hitachi Vantara, our special guest, made the companion point from the vendor side of the table. "Modernization is a business acceleration strategy," he said. "It should not be positioned as a technology refresh. Avoid that. In fact, put that in red."

He's right, and it's the same lesson. Nobody ever funded a technology refresh with enthusiasm. Boards fund acceleration: speed to market, better margins, faster decisions. If your pitch sounds like an IT shopping list, you've already lost the room.

Liam cited a real-life example. He described a large UK retailer that cut its data preparation time from 24 hours to less than two hours, not by buying fancier AI models, but by restructuring the data foundation underneath them. Fix the foundation first, and everything on top of it gets cheaper and faster. The building holds.

It occurred to me listening to all this that the discipline hasn't changed in thirty years. The capacity conversation I was having a decade ago about racks and storage is the same conversation today about GPUs and power bills. What changed is only the vocabulary, and vocabulary is exactly what the board doesn't need from you.

Your job as a technology leader is translation. Speak in the language they understand, show them the weight the foundation has to carry, and sell them on the business acceleration, not the equipment.

Captain Joe

Follow me on X @JPuglisiLLC

Nobody Remembers the Firewall

This past Friday morning, on Coffee with Digital Trailblazers, Isaac Sacolick put a question to the panel: with ten weeks left in the year, how do digital leaders close it out strong?

The surveys say most organizations now claim measurable value from AI, and yet a good number of CIOs show no transformational value at all. Both can be true. It occurred to me that the problem starts earlier than the budget meeting. It starts with the scoreboard we use at the end of the year.

Here is the typical scoreboard technology teams bring to the year-end review. Every software patch went in on time. The firewall was replaced in under 24 hours without disrupting the network. Uptime was almost five nines.

Yes. Fine work. But nobody in the business remembers the firewall upgrade.

They recognize revenue growth. They chase improved EBITDA. They remember whether customers, external and internal, are happier than they were in January. These are metrics that matter, because our function is BT, not IT. Business Technology and the B always comes before the T. The business is more important than the technology, and the year-end review is where that gets proven or exposed.

So here is how I run my year-end town hall. Whole team, one room, four parts.

1. Start with measurable impact and celebrate it.

First and most important: what did we do right this year in the eyes of the business? Not the technology report card. The business one. We planned it, we executed, it worked, and it had the right outcome. Say it out loud, together. A team that never hears its wins in public will stop believing it has any.

2. Then go to school on the misses.

Some of what we planned did not pan out. Nobody goes to the woodshed. We go to school. Was it something we could have done differently? Or was it software that never lived up to the proverbial demonstration? Keep in mind, the demonstration always works. That is what demonstrations are for. The lessons go on the list for next year, owned by name, no blame attached.

3. Open the floor for winning moments.

Let the whole room name what they felt best about this year. You will hear about saves and fixes you never knew happened, because good people do quiet work all year long. Spirits go up. Nobody walks out of that meeting deflated, and that is the right way to start a new year.

4. The rule that runs underneath all of it.

Golden rule number one: I want to be the first to know when something goes wrong. Not in December. All year. Then I am the one who walks down the hall to marketing, to finance, to the chief operating officer and says: this is messed up, we know it, and we are working on it. That is how a technology leader earns trust with the rest of the leadership team. And trust, not a firewall story, is what gets next year's plan funded.

Close the year that way and January does not start on defense. It starts on a record the whole business watched you build, wins named out loud and misses owned early.

Captain Joe 

Follow me on X @JPuglisiLLC

Know Before You Ask

On Friday morning’s Coffee with Digital Trailblazers, Isaac Sacolick’s 191st episode, we spent an hour on why AI adoption stalls. The panelists all made excellent points: redesign the work, win the middle, measure adoption, not activity. All good advice and mostly aimed at the people doing the work.

Listening, it occurred to me that we were skipping the first step. What about the board? What about senior management? What about the CIO?

In thirty years of running technology organizations, I never asked anyone to do something I wasn’t willing to do myself. “Do as I say, not as I do” isn’t leadership. It’s a memo.

Yet that’s exactly what most companies are doing with AI. Board members read about it. The CIO saw a demo. And now everyone else is told to embrace AI and magically transform the company.

We used to call it airline magazine syndrome: you read an article at 35,000 feet and land thinking you’re an expert. Today it’s social media syndrome. You watched a three-minute video and suddenly you have an AI strategy.

Here’s the problem. If you haven’t touched it, seen it, and felt it, you don’t understand it. And AI isn’t one tool that does everything. Generative models, machine learning, agents, and a dozen other things are each good at some jobs and terrible at others. On Monday I wrote about the Department of Know. This is what it looks like from the top of the org chart.

The order matters. There are four steps:

1. 
   The CIO goes first. Start with yourself. Not a briefing, not a vendor demo. Hands on the keyboard until you can speak intelligently about what these tools are and what they aren’t.
2. The middle layer goes next. Give your managers the same chance to play. They will make or break every rollout you attempt, and right now most are on the sidelines.
3. The board and senior management get their hands on it, then set strategy. Same keyboard, same rule. Now the expected outcomes are grounded in something real, not an airline magazine.
4. Then the strategy goes to the rank and file.

A note on step 4. The sandbox is open to everyone from day one, and I’ll keep saying so. Curiosity needs no permission slip. The sequence governs who sets the strategy and the mandates. If the people setting them have never used the tools, you get a mandate nobody can follow.

I’ve been saying a version of this for fifteen years. You don’t earn the seat by holding it. You earn it by knowing the business and knowing the technology, in that order, and never asking people to go where you haven’t gone yourself.

I practice what I preach. Over a week and a half ago I started working with Muse, The AI agent that now handles a few regular chores for me, including posting my weekly LinkedIn invitation for our SIM Members in Transition session. This Friday morning Muse looked at my calendar, saw that I am at a conference next Thursday morning. It asked me whether I still wanted the post to go out. When I suggested we check with my co-host, it drafted and sent him an email. Muse later reported back that it had received no reply and was going ahead with the post. 

Nobody mandated that. There was no strategy deck. I played with it until I understood what it could do. This happens to line up with the first of my Three Golden Rules : I always want to be the first to know. This applies to agents too.

That’s the whole point. Know before you ask.

Captain Joe

Follow me on X @JPuglisiLLC

The Department of Know

This past Friday morning I appeared on Isaac Sacolick's "Coffee with Digital Trailblazers." The topic was "Vibe, Buy, or Automate? Deciding How to Build AI Agents." There were several of the finest minds in the business on the panel, another 25 or 30 sharp people in the audience, and everybody was making excellent, valid points.

Listening to all of it, it hit me that the conversation itself was the message. Oh, my word, this is a complex problem. Nobody on that call was wrong. And that's exactly the trouble.

When everybody's right and the problem is still confusing, you don't have a tooling problem. You have a knowing problem.

So, I told the group that we, the people who lead technology, have to become the Department of Know (K-N-O-W)—not the Department of No (N-O).

Our job as technology leaders is to be the guiding light that looks at each proposed use and says one of three things:

1. Vibe It: Yes, AI makes sense here, but it can be done with a short, well-defined program. Vibe-create it in a small blast zone and move on.

2. Automate It: The process is stable and boring. Use deterministic automation. Boring wins.

3. Engineer It: Whoa, this is going to need a whole array of agents collaborating to create new value. Let's engineer the living daylights out of it, get the data right, put the guardrails in, and keep a human in the loop.

You can't do that with a policy memo. And you definitely can't do it by handing people the tools and saying, "Here, create value, save time." Give them a sandbox, sure. Let them play, let them get familiar. But a sandbox doesn't generate purpose. Purpose comes from somebody who knows which tool fits which job, carefully evaluating case by case.

Here is the curriculum—the three questions I brought to the show that you should teach your people to ask before they build anything:

1. Can you state the job concisely? Vibe coding is cheap when the ask is crisp and brutally expensive when you're exploring as you go. If you can't name the exceptions the business actually runs, you don't have an agent project—you have a guessing project with a credit card attached.

2. Is the process stable, or still being invented? If it's stable (rules known, inputs clean, exceptions rare), automate it. Agents earn their keep where judgment lives: places where you deal with messy inputs, exceptions, and decisions that need context and data lineage.

3. Who owns the swarm when it grows? Every agent needs three things on day one: an owner, a cost line, and a kill switch. An agent without an owner is just shadow IT with a better vocabulary.
   

Our host, Isaac Sacolick, published a sharp 2x2 matrix: buy vs. build, rules vs. judgment. My footnote: the "buy judgment" quadrant is where the swarm breeds fastest, because buying feels like someone else's problem. It isn't. 

Here are two quick examples from my own work last week:

• Task 1: I keep a spreadsheet with attendees of the weekly Thursday morning SIM MIT session. Updating it by hand is tedious, and writing macros isn't my strength. But I didn't need an agent; I needed Gemini to write a simple macro. I pasted the code into the sheet, and now it automatically sorts and highlights rows on every entry. Deterministic problem, simple tool.

• Task 2: In contrast, I gave Muse access to LinkedIn and instructed it to post my weekly meeting invitation every Friday around 8:15 AM, advance the date to the following week, and skip holidays like Thanksgiving. It posted a test on Thursday. Then, on Friday morning, it recognized it had already run, skipped the duplicate post, and confirmed it was set for next week. That requires context and judgment.

That's the whole sermon. The technology leaders who win the agent era won't be the ones with the most tools. They'll be the ones who built the Department of Know—the people everyone comes to with an idea, a need, or a concept for guidance. And they will teach their organizations to ask these three questions for themselves.

Start with a sandbox. Follow with office hours. End with people who know.

Captain Joe

Follow me on X @JPuglisiLLC

An EMP elevates Transformation to Reinvention

I've been saying for years that every major technology wave brings with it a new set of acronyms and a new generation of enthusiasts eager to deploy them. ERP. CRM. SCM. We built careers orchestrating the implementation of these systems. We transformed companies, changing the way employees worked, how customers engaged, how products moved through supply chains. We were proud of it, and rightly so.

But I want to propose something different today. A new frame. A new acronym. Allow me to introduce the concept of an EMP, an Enterprise Management Platform.

Here's why it matters, and why it's categorically different from everything that came before.

When we implemented ERP, we were transforming a company. We were changing how people worked.
Humans were still there, in greater numbers than before, in fact, just working differently, more efficiently, supported by technology. The technology served the workforce. The workforce ran the business. That's been the paradigm for decades.

AI in general, and agentics in particular, changes that equation entirely. We are no longer talking about orchestrating a transformation of select processes, or even an enterprise-wide transformation. We are talking about orchestrating the operation of the business itself through agents and robots. Technology doesn't support the workforce in this model. In many cases, technology becomes the workforce.

Think about what it meant to implement an ERP. You had a business. You had people running that business. You were asked to improve how they operated. Success was measured by adoption, efficiency gains, cost reduction. You were, in essence, a very sophisticated tool-giver. And a good one at that.

Now think about what the EMP requires. You're not being asked to improve how people work. You're being asked to envision an organization where the agents are the workers. Your procurement agent negotiates. Your finance agent approves. Your logistics agent schedules. Your customer service agent resolves. The CIO, or whoever owns this portfolio going forward, is no longer primarily a technology implementer. They are an organizational architect. They are designing and operating a digital enterprise.

That is a fundamentally different job description.

This mean for those of us who have spent our careers implementing ERPs, managing CRM rollouts, optimizing supply chains? It means we need to elevate our thinking. The era of the technical specialist, the person who is valuable because they know SAP modules or Salesforce configurations, is giving way to the era of the digital enterprise architect. Someone who can envision a company that runs on agents and robots, design the oversight structures that keep it honest, and preserve space for the human creativity that no model can replicate.

That's the EMP. And if you're a technology leader today, you'd better start getting comfortable with it.

The horizon isn't ten years out. It's next quarter.

Captain Joe Follow me on Twitter @JPuglisiLLC