I wrote my story.
Now find yours.

At Interscape, we built software the way almost everyone built software back then. Single tenant. One code base, one database, one web server and one database server — all configured, all stood up, all babysat, per customer.

So when we had 300 customers, we had 300 instances of the software.

Read that again, because the weight of it is the whole point. Three hundred separate copies of the same product, each one living on its own little island of hardware, each one capable of breaking in its own special way. It turned out to be very, very difficult to manage. It took an incredible amount of money and engineering just to keep all those instances up to date.

And remember when this was. This isn't today. This is the late '90s, early 2000s. There was no easy button. We actually did figure it out — we could host Interscape on-premise, on our own servers, on our own hardware — but figuring it out and doing it gracefully are two different things. It was very difficult in practice, and we spent a lot of money getting it to work at all.

Here's the part that still makes my stomach tighten a little. To push an update, somebody had to go in and click update — literally, inside the admin area — and run it. One instance at a time. Which meant every release carried this quiet, constant risk: what if we introduced a failure? Because if we did, it wasn't one customer who had a bad day. It was all 300. And we'd have to mobilize every single one of them to go in and run the update themselves.

That is the tax you pay for building the same thing over and over again. You don't just pay it once. You pay it three hundred times, every single time you want to make something better.

Every transformation has to be seen through two lenses at once, and if you drop either one, it falls apart.

The first is bottom-up. The people actually doing the work have to be part of the transformation. Nobody understands the real workflow — the exceptions, the workarounds, the "oh, we never actually do it that way" — like the person living in it every day.

But — and this is where teams get it wrong — being inclusive is not the same as inviting chaos. I once helped a company do an end-to-end transformation across thirteen business units: marketing, sales, service, CPQ, CLM, order management, on and on. In the beginning you'd get fifty people on a phone call, everyone talking, everyone with an opinion, and it was pure noise. You can get so buried in the noise that you can't make a decision. So bottom-up doesn't mean everyone in the room. It means being selective about who represents the work — and having an actual approach for how you gather and honor that frontline voice without drowning in it.

The second lens is top-down. I'll say this as plainly as I can: large transformation programs do not succeed without executive sponsorship — real support, direct involvement, someone who can say yes or no. A lot of times I've seen this work best with the CFO, sometimes the head of sales, now often the CRO. It has to be an executive who can answer the hard questions, absorb the objections, put a path forward, and champion the thing when it gets difficult. Both lenses, at the same time. Sponsor at the top, voice from the floor.

Here's the other story, and this one is subtle — pay attention to the words.

We had merged my company into that same firm. Our rates were $240 an hour. Theirs were $100 an hour. Assume, for simplicity, the same cost per resource.

So I went to my boss and I asked: "If I staff my $240 resource for half a week — 20 hours — and we staff a $100 resource for a full 40 hours, who makes you more money?"

And he said, without hesitation, "The $100-an-hour one. That makes me more money."

I was flabbergasted. Because on the bottom line, it's not even close. Twenty hours at $240 is $4,800. Forty hours at $100 is $4,000. The expensive resource, working half as much, made the company more money — and that person still had 20 hours left over to build assets and accelerators.

It took me years to understand why he answered the way he did. His incentive was utilization. He got a big bonus when utilization hit 90% or above. So a resource billing 40 hours "looked" better on his scorecard than one billing 20 — even though the company earned less.

And here's the part that still gives me chills: I had asked, "Who makes YOU more money?" — not "Who makes the COMPANY more money?" He answered my exact question honestly. His metric and the company's health had quietly come apart, and the incentive was steering him away from the very thing that made us money.

So be careful how you ask questions about numbers. Be careful which numbers you pin on a practice. Because utilization, all by itself, is a blind number.

This isn't just my war story — it's a documented trap. The phrase everyone quotes, "what gets measured gets managed," is almost always credited to Peter Drucker, who never said it. It actually traces to V.F. Ridgway's 1956 paper, "Dysfunctional Consequences of Performance Measurements" — and it was a warning, not a cheer. The fuller version: "what gets measured gets managed — even when it's pointless to measure and manage it, and even if it harms the purpose of the organization to do so" ([Chief Executive](https://chiefexecutive.net/what-gets-measured-gets-prioritized-but-that-may-not-be-a-good-thing/); [Centre for Public Impact](https://medium.com/centre-for-public-impact/what-gets-measured-gets-managed-its-wrong-and-drucker-never-said-it-fe95886d3df6)). That's utilization in a sentence. That's my boss's bonus in a sentence.

The last chapter was about how the software got built. This one is about what it costs to run — and that turned out to be a completely separate education.

Because here's the thing about the list I just gave you, the encryption and the tenancy and the identity plumbing. Those are the decisions AI won't make for you. Hard, but at least they're visible. You know when you're making them.

The lesson in this chapter was sneakier, because it was invisible. Everything worked. The architecture was sound. And the cost went through the roof anyway.

Here's how that happened, and it's worth telling because sometimes the most important lessons come from ending up where you're meant to be — even when it's the last place you expected.

A science teacher — one of those people who see something in you before you see it in yourself — asked me one day, Matt, have you heard of a Georgia Tech satellite school called Southern Tech?

Absolutely not, I said. Never heard of it.

You should apply. Put together an essay. Just apply.

To this day I don't remember writing that essay. I assume I did. I have no memory of it. What I do remember is what came back: essentially a full ride. Because my family had lost everything, I qualified for a Pell Grant — and I'll say it here, I am genuinely thankful that this country invested in my education when my family couldn't. I picked up Rotary Club scholarships. I had the twenty thousand dollars from Walmart. It all stacked together into a full ride to Southern Tech — which became Southern Polytechnic halfway through my time there — taught by Georgia Tech professors who were every bit as hard as that sounds. There were mornings I sat in those classes thinking, what am I doing here?

I started out in textile engineering and materials science, of all things, because I still had NASA in my head and thought that was a way in. Then we took a field trip to a carpet plant up in North Georgia, and I watched fibers hang in the air while a worker coughed, in a place that felt neither safe nor alive — just three people and a lot of machines. And I thought, very clearly: this is not what I want to do. So I switched to computer science, and eventually earned my degree in Management Information Systems. Curiosity, again, doing what it does — refusing to let me settle into the wrong thing just because I'd already started walking down it.

College was, for all of it, a lot of fun. I joined Sigma Nu. I'll tell you straight that I didn't put enough into that fraternity — the brothers were fabulous, the relationships were real, and between building a career and raising kids and being married, I let a lot of those connections go. That's a regret, and it's one I'm actively working to repair, because I've learned the hard way that the people are the point. I bought my first house. I was already running my own company by then, but that's the next chapter, so I'll leave it there.

And I met a woman named Lindsay.

We hit it off. We became real friends first, which is the best way it can happen, and then genuine partners — the kind of partnership that has now lasted twenty-four years and produced a family I love more than anything on this earth. She would go on to become Dr. Lindsay, a Doctor of Pharmacy, and my truest partner in every plan I've made since, including the ones that fell through. Especially those.

I said I'd tell you my regret.

My dad wasn't around to see it.

He was always in technology. Everyone — everyone — knows IBM. And I know, in my bones, that he would have been so proud of that moment. I would have loved to hand him that letter from Arvind and watch his face. That's the one thing I'd give anything to change. This whole book, in a lot of ways, is me building something he'd have been proud of. He'd have loved this chapter most.

Let me name a metric I think misrepresents the value of a practice: bench.

I've been in practices where the single biggest metric was bench utilization — how few people are sitting idle. And I understand why; idle people cost money. But bench, all by itself, tells you almost nothing about the value your practice creates. Depending on the organization, the real value of a practice might be:

- Bringing in your technologies — the partner ecosystem. - Learning how your partner builds — how they implement and stand up capabilities. - Go-to-market leverage — especially at companies that don't have a large GTM engine of their own. In those places, the partnership is the go-to-market, or should be treated as an extension of it.

Here's the contradiction I've watched destroy practices: leaders who say, in the same breath, "I want zero bench on my delivery team" and "I want to win huge transformational programs." Those two ideas exclude each other. You cannot run a zero-bench practice and land big transformations that start and stop all the time — unless you staff it entirely with contractors. And contractors are their own category of risk: they leave mid-project for more money, they don't always finish, they're often juggling multiple clients at once. (Sometimes your own employees are, too.) Manage a practice by bench alone and you are managing the one number most likely to lie to you.

This is the KPI trap from Chapter 11, wearing a new suit. Organizations track more KPIs than ever and execute less of their strategy — one analysis of thousands of strategic plans found only about 15% of strategic initiatives are ever completed, and roughly 77% of strategic objectives have no active owner ([ClearPoint Strategy](https://www.clearpointstrategy.com/blog/kpi-paradox)). And a review of fifty organizations found 90% had "KPIs" that weren't direct evidence of their actual strategic goals ([Stacey Barr](https://www.staceybarr.com/measure-up/how-many-organisations-have-meaningful-kpis/)). A number on a dashboard is not the same as a number that drives the right behavior. Bench is Exhibit A.

This matters more right now than at any point in my career, and here's why.

We're living through an era where a lot of people are rightly upset — about books being fed into AI, about music, about their life's work being consumed without a word. I just saw it in the news: I won't name the platform, but a major AI company settled for an enormous amount of money over training on other people's writing. That was the $1.5 billion Anthropic settlement with authors — the largest copyright recovery of its kind, covering roughly 500,000 works ([Reuters](https://www.reuters.com/legal/government/anthropics-surprise-settlement-adds-new-wrinkle-ai-copyright-war-2025-08-27/); [The New York Times](https://www.nytimes.com/2025/09/05/technology/anthropic-settlement-copyright-ai.html)).

Those authors were credible. They did the work. And I think we have to honor their credibility — honor their work. That's the hard, uncomfortable part of today's AI: we're training it on the fruit of other people's labor, sometimes with permission and, too often, without it. Hopefully with.

Which brings me to the single most important thing I ever learned at IBM: get permission.

You're going to use somebody's website content? Get permission. You're going to use their material? Get permission. Be above the fold. Do what's right. Be credible. It sounds almost quaintly simple, and that's exactly why it's powerful. In a gold rush where everyone is grabbing whatever isn't nailed down, the people who ask first will be the ones still standing — and still trusted — when the lawsuits settle.

I've asked a version of the same question in every chapter: what is this whole climb really for? What did the continuation actually mean?

I look back and I can trace the transformation. I went from an owner, to a consultant, to a practice leader, to an executive. In my own opinion, I hit the pinnacle of technical achievement I set out for. And yet — here's the thing I didn't expect to feel — I still think I could be more hands-on. I could be in front of more customers. I could be helping other practices, building the things I love to build. The pinnacle, it turns out, isn't a place you stop. It's a place you can finally see from.

Everything in this book was a rung. Experiment, and become a trusted advisor. Earn the right to own a practice or a number. Build credibility. Learn to speak two languages, business and technical. Question the incentives. Think differently about how we implement and use AI. None of it was the summit. All of it was the climb.

Before any of it, I did the sensible thing. I hired real developers.

Good ones. We worked for months. We built a genuine codebase the traditional way, with a team, with reviews, with all the discipline I'd spent twenty years learning to insist on. And then AI tooling got good enough that I wanted to accelerate it, so I loaded the whole thing into Cursor and started asking for changes.

It failed. Not dramatically — that would have been easier. It failed slowly and confusingly. The model couldn't hold the codebase. There was too much of it, and too much of it was the accumulated sediment of human decisions made across months: conventions half-followed, abstractions that made sense at the time, the ordinary bloat that every real codebase carries and every human team quietly routes around. A developer walks into that and asks a colleague. The model just guesses, confidently, and hands you something that compiles.

So I made the expensive call. I threw all of it away and started over, AI-native from the ground up.

I want to say clearly that this was not the developers' fault. They built what I asked for, the way our whole industry has built things for thirty years. The problem was that I was asking a new kind of tool to work on an old kind of artifact. You can't retrofit AI-native onto a codebase that wasn't built to be read by a machine. I've watched a lot of companies spend a lot of money learning that in 2026, and most of them are still trying to retrofit.

Brooks said plan to throw one away. Fine. I planned for one.

Let me take you back to earlier in my career, to a project that taught me this lesson the hard way.

I was working with a very large telco, hunting for customer data. They were running on a Teradata platform — genuinely great technology, a serious piece of engineering. That wasn't the problem. The problem was that the metadata about the data was completely missing.

Think about what that means. I had the data, but I didn't know where it came from. I didn't know when it was imported. I didn't know how old it was. I was staring at a customer record with no idea whether it was current or a fossil. And when you're talking about customer data, two things are non-negotiable: freshness and source. How old is this? Where did it come from? If you can't answer those two questions, you don't actually have data — you have a rumor with a database schema.

This is the semantic problem, and it's bigger than one platform. When I talk about the semantic enterprise, I mean: how do different parts of the organization describe the data, consume it, report on it? That shared understanding is absolutely critical — for AI, yes, but honestly just for running a company. I see organizations all the time with KPIs that say the same thing but are calculated differently, or off different fields. Two dashboards, same label, two different numbers. (If you read the last chapter, you know exactly how much that one costs.) That's not a technology failure. That's a governance failure.

And by the way, this is why your data scientists are miserable. The old industry rule of thumb is that they spend up to 80% of their time finding, cleaning, and organizing data, and only 20% doing the actual analysis they were hired for ([Pragmatic Institute](https://www.pragmaticinstitute.com/resources/articles/data/overcoming-the-80-20-rule-in-data-science/)). You're paying elite talent to be janitors because nobody upstream governed the data at the point of creation.

The best example of how deep I got is the EMS application I told you about at BellSouth — the escalation management system that consolidated nineteen or twenty separate support tools across nine states into one. I wrote most of it. Call it eighty percent, by my own hand.

And that led to one of the strangest compliments I've ever received.

One day BellSouth came to me and said, in effect: Matt, you wrote this application, and all of the understanding of how it works lives in your head — and only your head. We actually need to pay you more, so we can put someone next to you to start learning it, developing it, shadowing you. Because if something happens to you, we lose support for the entire corporation.

Think about what that sentence means. Nine states. Wireless, landline, DSL — we were just barely starting to touch fiber. And the whole customer-support backbone of a company that size had a single point of failure, and the single point of failure was a guy in his twenties who might win the lottery or get hit by a bus. That is a terrifying thing to hear about yourself. It's also the moment I understood, viscerally, that software isn't just code — it's risk, and good architecture is really about managing that risk so no single thing, or person, can take the whole business down.

We'd actually built EMS with that philosophy from the start, and I'm proud of it to this day. Back in the late nineties and early two-thousands, we engineered it for scalability and for surviving site failures — the same fundamental ideas AWS made famous years later with regions and availability zones. Full disaster recovery. Business continuity. It was one of the only systems in the company that truly had it all, and we built it before the industry had tidy names for any of it.

Now, I'm not going to sit here and tell you the architecture was brilliant. It wasn't. What it was, was clear. Before EMS, if you were a BellSouth customer, you'd call different numbers for different problems, and — this is the part that really got me — there was no single view of how many issues you even had. Your data was scattered across all those disconnected systems. It was completely disjointed. So in EMS I did something almost embarrassingly simple: one customers table. One ticket when you called in. And then each issue on that ticket could be routed and customized to whatever group needed to resolve it for you.

One customer. One ticket. Many issues, each handled by the right team.

That's it. That's the whole trick. But it made the system easy to reuse, easy to scale, and — most importantly — it made the process simpler for the human being on the phone. And that taught me the lesson I've built on ever since: get the data model right, and the process gets easier. Get the data model wrong, and no amount of pretty software on top will ever save you.

Let me tell you about an organization I was in where, at every level you looked, the numbers were different.

Look at it from a market perspective — that number was different from what global thought that market was doing. Look at it from a geo perspective — different again. Every altitude told a different story about the same business. And you know what that creates? Conflict. Endless, exhausting conflict, because everyone is arguing about whose number is right instead of what to do about the number.

The numbers have to come from one source of truth, and they have to be shared across the business, and everyone has to be working off the same set. I think that's absolutely critical — for growth, for understanding, and for communication. It is impossible to align an organization that can't agree on what happened last quarter.

The research bears this out with a vengeance. When digital transformations fail — and by widely cited (if loosely defined) industry estimates, somewhere around 70% of them fall short of their goals (McKinsey and others, traced by Reliable) — the culprit usually isn't the software. Forrester found that in 72% of cases, analytics transformations fail because of data silos (via MarketProvider). McKinsey's study of more than 600 transformations found only 20% achieved even three-quarters of their expected revenue growth, and just 17% hit their planned cost savings — and concluded that culture and data, not technology, were the primary obstacles, with organizations that led with cultural change succeeding at 5.3 times the rate of those that led with tech alone (McKinsey, via MarketProvider). By cumulative estimates across the major consulting firms, roughly $900 billion a year is wasted globally on transformation that doesn't deliver (industry estimates, via MarketProvider). Different studies, different methods — same verdict. The technology usually works. The numbers underneath it don't line up. One source of truth isn't a nice-to-have. It's the difference between the 20% and everyone else.

Back at Interscape, we built a content management system when people were still asking us, with a straight face, "Why would I want to manage my own website? Isn't that your job?"

Then it was, "Why would I want to manage my own e-commerce?" And, "Why would I want to do my own quoting?" And, "Why would I want to take online payments?"

We were handing people the keys to their own technology, and a lot of them looked at the keys like we were handing them a chore.

The funniest version of this happened at my own kitchen table. When online banking was first rolling out — when the world was just starting to get rid of paper checks — I remember my wife Lindsay looking at me and saying, dead serious:

"Why would anybody want to bank online?"

And I love her for it. Lindsay is not a technologist. She's a Doctor of Pharmacy now, and she spends her days helping kids at the Children's Hospital, which is a far better use of a human being than arguing about payment rails. Technology has never been her strong suit, and that's exactly why the moment stuck with me. I said, "Why would anybody still want to write a check?" And she said, "Why would anybody want to bank online?"

Two smart people. Same table. Looking at the same technology and seeing two completely different futures.

She wasn't wrong, either — not for that moment. Checks worked. You filled them out, you licked a stamp, you mailed them, the lights stayed on. The banks were starting to roll online banking out, but "it works fine the way it is" is one of the most powerful forces on Earth. It has killed more good ideas than bad execution ever has.

That's what we were up against at Interscape. We'd tell a small business, "You can log in. You can edit your own site. You can add products, change your pricing, update your hours — you're empowered to do all of it yourself." And people didn't hear freedom. They heard homework.

Here's another. A very big telco — the one that got acquired by another big telco, if you've been reading along, that's your hint.

I was building them a decision support system, a BI reporting platform, all around CSAT — customer satisfaction. It had been in flight for a year or more. Delayed. Troubled. The consultant on it had real issues — I'm not sure he understood the technology, and, most importantly, he did not understand the business.

One day it got heated. I told him straight: if we can't fix this, we're done — there's no reason for us to be here. And beyond fixing it, I needed the business to be able to see the survey reconstructed in the star schema — to see the questions, see how people answered, rebuilt directly from the data, and report on it exactly as it was surveyed.

He told me it wasn't possible.

I said, then we're going to get fired, because no one will ever trust the data. He didn't believe me. Fine — let's get our boss on the phone. Boss said the same thing I did. We will not be doing this much longer if the business can't trust the data, and trust means being able to reproduce it from the star schema.

In the end, I had to erase nearly everything that man had built over a year, a year and a half — and rebuild it so the business could see the data the way it needed to, and trust it. And the only reason I knew what "trustworthy" looked like to them is that I understood what the business actually wanted to see.

So how do we process the noise? How do we understand it, prioritize it, and — this is the part that matters — align it to the actions we should actually take?

Here's the disconnect I kept running into. Most people, when they look at their pile of work, decide what to do based on their own judgment and their own incentives. And that goes all the way back to what we covered earlier in the book — incentives drive behavior, KPIs drive behavior. So the real question underneath every task is: is this best for me? For my team? My division? My company? Individual versus the group. And with this much noise coming at you, most people default — understandably — to what's best for them, or just to whatever shouts loudest.

That's the problem I set out to solve. What if you could bring in all the signals — your emails, your meeting transcripts, your messages (not your family, obviously, not your private life) — and run them through a scoring engine? Not a static one. One that takes feedback from the user and evolves over time, so it gets smarter about what actually matters. And critically, one that scores each signal not against your personal preferences, but against the organization's objectives.

That's the piece that's been missing until now. Companies set objectives all the time. The hard part has always been: how do those objectives actually permeate down into what people do every day and what they choose to work on? There's been no mechanism to connect the boardroom's goals to the individual's Tuesday-morning to-do list. That connection is the whole ballgame — and it's exactly the alignment gap the research keeps exposing.

Because the gap is staggering. In one study, leaders believed their companies had about 82% strategic alignment — but when researchers actually analyzed what employees said the strategy was, real alignment was just 23% (research summarized by Matt Dallisson). Another found fewer than half of employees (48%) even know their organization's strategic priorities for the year, and only 40% of those feel clear on their own role in achieving them (ETHRWorld on the study). Seventy percent of workers can't even see the data tied to their company's strategic goals (80/20 Institute study via Business Insider). No wonder people work on the wrong things. Nobody ever showed them what the right things were.

I was at Southern Tech — which became Southern Polytechnic, which was eventually purchased by Kennesaw State, a fact I find funny because that's the same school my girlfriend Lindsay was attending at the time. The same Lindsay who is now my wife of twenty-four years. The wheel turns.

Lindsay was working at an eye clinic, and the clinic needed some things. They needed an email server. They needed a website. They needed networking — actual wires and boxes and the invisible plumbing that lets a small business function. And they were willing to pay someone to make all of that happen.

Here is the completely honest truth about that moment: I had no idea what I was doing.

None. I knew computers the way a curious kid knows computers — I could take one apart and put it back together, I could fight with a config file until it behaved — but building and running an email server for a real business, standing up a real website, wiring a real network? I had never done any of it. So I did the only thing I knew how to do. I went to CompUSA — which I told you about in the first chapter, and which I still miss; it was a computer nerd's cathedral — and I bought books. A book on website design. A book on email servers. A book on networking. And I read them front to back, and then I went and did the work.

And it worked. I stood up their email, I built their website, I wired their network, and at the end of it I had made real money — good money — for a college kid.

That project taught me more than any class I was taking. It taught me how to start a business. How to provide a service. How to look at a problem I didn't know how to solve, go get the knowledge, and turn it into something a customer would pay for. And it taught me the economics of a specific and generous moment in history: in the late nineties, technology was new. Not everybody had it. Everybody wanted it. And the gap between "wanting it" and "having it" was a place where a person willing to read the books could make a very good living. Putting technology in — that was the business. I was standing in the middle of a wave, and I was young enough not to know I should be afraid of it.

So I started a company. I called it Interscape. This would have been somewhere around 1998, 1999 — right in the middle of college, which tells you something about how I was spending my nights.

And what a moment to be standing there with a modem and a business card. This was the height of the dot-com boom, and the numbers around me were genuinely insane. Between 1995 and its peak in March 2000, the Nasdaq climbed roughly 600 percent (Wikipedia). Investors were so hungry for anything internet-related that companies were getting funded — and going public — on little more than a ".com" at the end of their name and a promise. Pets.com bought a Super Bowl ad and then folded inside a year. It was a gold rush, and like every gold rush, a lot of people who showed up with a shovel got rich and a lot of people who showed up with a mine went broke. I was a college kid selling actual, working technology to actual businesses who actually paid me — which, it turned out, was a more durable place to stand than most of the balloons floating past me. When the whole thing came crashing down in 2000, I was still standing, because I'd been building something real instead of something loud. That's a lesson I'd relearn more than once.

Here's the phrase for what a great consultant actually does: influence without authority.

You're not in charge. You can't order anyone to do anything. And that, I think, makes consulting one of the hardest jobs on the planet — second only to being a parent. I say that from experience.

Being a parent is actually the perfect example of influence without authority. Especially with a teenager. Your whole job is to influence their decisions and hope they choose well — because the day they turn eighteen, you don't have authority anymore. All you ever really had was influence. Consulting is exactly the same. I can't tell my customer what to do. I can only guide them toward what I believe they should do, show them the options, and show them the quantitative data that supports the option I think is best.

This isn't just my instinct — it's a well-studied discipline. The classic framework comes from Allan Cohen of Babson and David Bradford of Stanford, in their book Influence Without Authority. Their core argument: authority is "dead or dying," and getting cooperation from people you can't command comes down to understanding what they value and trading in those "currencies" (Stanford Graduate School of Business). As one summary of their work puts it plainly: "Authority is the cooperation you can demand. Influence is how you get the rest — and the rest is most of it" (Leaders Loop). That's the entire job of a consultant, in one sentence.

Here's a lesson that cost me a decade to fully absorb: there is always a crisis.

Look at the run I lived through as an owner. The dot-com bust in 2000. The Y2K panic, when half the world was convinced the clocks turning over would end civilization. Then the 2008 housing crisis, which is ultimately what broke my company's back. War. Viruses. Some new technology that upends everything. Some piece of Wall Street engineering nobody saw coming. It never stops. If you're waiting for the calm, stable stretch where you can finally build in peace — it isn't coming. This is the weather.

And the data backs up exactly how brutal my timing was. About 20% of new US businesses fail in their first year, roughly 50% by year five, and about 65% by year ten (U.S. Bureau of Labor Statistics, via Commerce Institute). Those numbers are stubbornly consistent across the decades — except in the worst years. The BLS specifically flags 2001 and 2008 as the two lowest survival years on record for new businesses (U.S. Bureau of Labor Statistics). I started and grew a company straight through both of them. I wasn't unlucky. I was just building in the real world, which is always on fire somewhere.

Andy Grove — the man who built Intel — said it better than I ever could:

"Bad companies are destroyed by crisis. Good companies survive them. Great companies are improved by them." — Andy Grove (as compiled by Inc.)

That's the whole game. The crisis is a given. What you do inside it is the only variable you control. So the owner's real job isn't to avoid the storm — it's to be ready for it. Squirrel away savings when times are good. Be smart in the fat years so the lean years don't take your family down with the business. Ask constantly: what's the crisis coming next, and how do I get out ahead of it? Grove had another line for that instinct — "only the paranoid survive" (as compiled by YourStory) — and after ten years as an owner, I don't think that's pessimism. I think it's just paying attention.

But if you ask me what I'm most proud of, it isn't the title or the technology. It's the people at my kitchen table.

I'm proud of my oldest daughter, Ava, in university now and earning a scholarship into the early-medicine program at Mercer University. I'm proud of my son, Landon — in high school, running track, carrying AP and International Baccalaureate coursework and doing it well. And I'm proud of my youngest, Isla, in elementary school, who sings and dances and brings joy and love into every single room she walks into.

I'm proud of my wife of twenty-four years. Dr. Lindsay — I should say Dr. Lindsay. It has been the honor of my life to watch her journey, as a person and as a professional, and to watch what she does at her hospital to help kids.

People sometimes ask if I'd ever run for politics. I tell them the truth: the only thing that would make me run is a broken education system, and the chance to make it fair for everyone in it. Because we've lived on both sides of it. We've been in public school. We've been in private school. And now, with my youngest heading into middle school, I'll be honest — it's scary, and it's upsetting.

In elementary school, kids with special needs get attention. They get foundation. They get services. Then middle school arrives, and somewhere a decision gets made that these kids should be segregated from everyone else — that inclusion and services become secondary, that it becomes closer to babysitting than to teaching. And that is a disservice to children who have worked so hard to read, to write, to talk, and in some cases to walk. My daughter is one of those children. She did that work. She deserves a system that keeps believing in her after fifth grade.

So here is where my hope turns toward technology — not away from these things, but for them.

Back at Interscape, I built a platform. It did content management. It did e-commerce. It had CPQ — configure, price, quote — for building out complex product bundles. It had form-building: you could stand up tables, define fields, and deploy working forms without writing much code at all. It was, if I'm honest, a Swiss army knife. And for its time, it was a good one.

We went looking for equity to grow and scale. And the feedback we got from investors came back the same way, over and over and over again:

You really need to do one thing, and do that one thing wow.

Not two things well. One thing, wow.

At the time it stung, because I was proud of the range. But those investors were not wrong about the world they lived in. They were describing decades of how software actually got built and sold. A company sees a problem. A very specific problem. Create a calendar invite. Draw a diagram. Build a presentation. Run a sales process — and I'd argue running a sales process is not a simple thing at all, but it is one thing, one domain. And they went after it.

And it was simple. Simple for investors. Simple for customers. Simple for the sellers selling it, simple for the marketers marketing it. You could explain it in thirty seconds. "I do this one thing." I get it. I understand exactly what problem you solve. I agree. I'm moving on.

That instinct has deep roots. The most influential idea in the history of software design is a single sentence from Bell Labs: write programs that do one thing and do it well, and write them to work together (Doug McIlroy, via the Unix philosophy). Steve Jobs said the same thing in business terms — that focus isn't saying yes to the thing you work on, it's "saying no to the thousand other good ideas" so you don't build "a big, thick, complicated" mess. Simple, easy, one thing, wow. For a long time, that was the whole game, and it worked.

I think we are at a different place today. And I think the old instinct, applied blindly to this new moment, is about to do real damage.

Let me put the mountain I was looking at into perspective, because the numbers are genuinely staggering.

Out of more than 1.2 million Salesforce-certified professionals in the world, there are only around 475 CTAs — roughly 0.04 percent (Pedro Távora Santos, Medium). Put another way, "you're statistically more likely to become a licensed commercial airline pilot than to earn a CTA certification" (Pedro Távora Santos, Medium). People in the community call it "the Mount Everest of tech certifications," and they are not being cute. Technical Architects are the scarcest role in the entire ecosystem — about 1 percent of global Salesforce talent, where in 2025 demand grew 27 percent while supply grew only 4 percent (SyncGTM).

And the exam itself is a beast. It's universally considered "the hardest credential in the Salesforce ecosystem — and one of the most rigorous in enterprise software" (Trailblaze Prep). The pass rate isn't officially published, but community estimates put it somewhere around 5 to 10 percent on the first attempt (SyncGTM). I'd guessed 10 or 15 percent when I was living through it. It may well be lower.

So I went all in. Not as a slogan. As a way of living for the better part of a year.

I told my wife that on Sundays I was walking myself into a room to study, and I did. I printed every single PDF Salesforce had ever written — hundreds and hundreds of pages. I read them, and then I read them again. I played with the platform. I tried to break it. I was lucky to be on projects that were technically brutal, and lucky to be able to ping the engineering team directly and hear what actually worked and what didn't.

I knew where people died on this exam. The majority fail on security and scalability. So that's where I lived — login flows, the sharing model, internal-versus-external sharing off the account, Experience Cloud (we called it Communities then), batch Apex, triggers, and the endless judgment call of when to use declarative features over programmatic ones. Clicks over code, again and again.

You know those movies where somebody tapes photos all over a wall and runs red string between them until they look completely obsessive? That was me. That was my nine months. On a plane, studying. In a hotel room, studying. At a client, learning. Pinging engineering. And when I wasn't at Salesforce, I was talking to everyone I could, listening, reading — constant reading. This wasn't a simple act. It was a mindset.

Let me make this concrete with something I was working on recently, because it's the whole chapter in one story.

I built a scoring engine, and in the first design it called the LLM for every single record. You can imagine the cost. Our pilot bill went straight through the roof. Every message coming in was getting scored against an LLM, and the meter never stopped spinning.

So we steered. The scoring itself was actually working really well — the results were good. The architecture was the problem. So we pivoted: why not have the AI create a scoring model, let the users give feedback on how it's working, feed that feedback back in, and then have the AI tweak the model going forward? Now every incoming message isn't being scored against an expensive LLM call. It's being scored against a lightweight model that's managed by an LLM.

Very different architecture. Very different solution. Both still AI-driven. One is dramatically cheaper than the other — and, arguably, the results are only marginally different. That's the entire discipline right there: we were steering, we were monitoring the cost, we were experimenting, we were failing fast, and we pivoted. Same outcome, a fraction of the bill, because somebody was actually watching the meter and willing to change course.

Everyone asks me: how does IBM Distinguished Engineer compare to the Salesforce CTA?

The CTA — Salesforce's Certified Technical Architect, the platform's terminal technical credential, earned in front of a review board — proves you can design a system that will not fall over. The DE — IBM's Distinguished Engineer, an appointed rank held by roughly 0.1% of the technical population — proves you can shape what the company builds and sells. One is a certification; the other is a title the company confers on you. They are two very different animals, and the jump between them is the subject of this chapter.

The CTA (Chapter 7) is platform-deep. It's about Salesforce — how you implement it, how you protect the customer and the company, the governor limits, the guiding principles. Heavy technical, very platform-driven. Everybody happy, everybody protected.

The DE is organization-deep. It's executive-level. In fact, I came in at a band where the DE was lateral; had I come in lower, earning the DE would have promoted me. My package leaned much harder on eminence, thought leadership, and — crucially — KPIs that drove real business value, with technical acumen underneath. One certification says "here's our platform, prove you can implement it flawlessly." The other says "prove you can lead technology, thought, and business results across a global enterprise." Both are hard. They just measure different mountains.

Here's what all of this was really teaching me, and it's the reason I wanted to write this chapter at all.

The technology is often the easy part. Scaling it and operating it is the hard part.

There's a classic graphic you've probably seen — the SaaS iceberg. At the very top, that little tip poking out above the water? That's the software. That's the part everyone points at. Everything underneath the surface — the sales, the marketing, the licensing, the servicing, the support, the deployment, the engineering — that's the other 90 percent of the iceberg, and it's the part that sinks you if you get it wrong.

When I think about technology now, I don't just think about building it. I think about the operational side of scaling it. And scaling is always, always a challenge. I've spent a lot of time inside the AI coding platforms — Cursor, Bolt, the whole crop of them — and I watch them work incredibly hard to scale. Some of them do a genuinely great job. But it's still a fight, every day, because that's the nature of the thing. The more people use your platform — more users, more companies — the more resources it demands. That's not a bug in their business. That's the entire story of the data center boom happening around us right now, and the backwash that comes with it.

Now the mistake. Every honest chapter needs one, and this is mine.

I was surrounded by technologists. Brilliant ones — but all of us the same flavor. What I didn't have was sales, marketing, and finance sitting at the table beside me. And a company cannot grow on engineering alone. You need the other halves of the business firing too: a real brand, real marketing, a real sales engine.

You can hear the gap in how we struggled with something as basic as our own name and branding. We tried creative stunts to get noticed. My favorite: we printed up airline sick bags — the little paper bags from the seat-back pocket — with a line that read something like "Sick of your current website? Call us." It was genuinely funny. It was clever. And it drove exactly zero business. That's the perfect little monument to the lesson: creativity without a real go-to-market strategy is just entertainment. We were technologists doing marketing cosplay, and the market could tell.

So here's the advice, and it's simple: surround yourself with the people who are strong where you're weak. If you've got an idea, lean in — but don't staff your company with mirrors of yourself. Find the mentors, the partners, the specialists whose skills fill your gaps. The hardest and most important part of an apprenticeship isn't the work; it's finding the right people to apprentice under and to build with.

Now I'm not a psychiatrist. But you can't work in transformation for two decades without becoming a student of the psychology of it, and AI has brought a very specific kind of fear into the room.

I remember when OpenAI launched ChatGPT. The remarks in the market, in the news, were dire. The end of jobs. The markets collapsing. General intelligence smarter than humans. The end of the world. And that fear didn't evaporate — it settled in and grew roots.

Look at where we are now. Mercer's Global Talent Trends found employee concern about losing their job to AI jumped from 28% in 2024 to 40% in 2026 (Mercer, via Metaintro). Pew found 52% of U.S. workers are more worried than hopeful about AI's future in the workplace (Pew Research Center). One of the largest workforce surveys ever run — ADP's 39,000 workers across 36 countries — found only 22% strongly agreed their job was safe, and among frontline individual contributors, only 18% (Fortune).

This is not a fringe anxiety. This is most of your building.

And it shows up in a way that should stop every leader cold: people are hiding it. Nearly half of employees — 48.8% — conceal their AI use at work, afraid they'll be seen as lazy or replaceable, and among executives it's even higher, 53% (Forbes on the WalkMe survey). Half of Gen Z workers say using AI makes them feel like they're cheating (Yahoo Finance on Employment Hero data). Think about that. Your people are quietly using the tool, feeling guilty about it, and terrified that doing it well is exactly what gets them fired. That's not an adoption problem. That's an emotional one.

Here's the story that taught me what leadership is.

One of the groups whose support system we were trying to replace had built their own custom tool, and they were reluctant to work with us. Reluctant is generous. They were resistant, in the way that people are resistant when you show up to replace the thing they built and are proud of.

My colleague Kevin and I were sitting in a boardroom in the Lenox Park building — this was the snow day, actually — trying to get this group to cooperate. And at some point Kevin reached into his folder, pulled out a single piece of paper, and slid it across the table to the man who ran the group. "Read this," he said.

The man opened it. It said, more or less:

To whom it may concern: You will work with Kevin and Matt Francis. You will do what they say. If you have any problems or questions, please give me a call. And then a name — Duane Ackerman — and a cell phone number.

The CEO of BellSouth.

In that moment I understood something I've never let go of. Leadership isn't the piece of paper. Leadership is what the piece of paper represented: a leader at the very top reaching all the way down to give air cover to the two people trying to move the business forward. He was making it unmistakable that the transformation mattered, that it was going to happen, and that the people doing the hard, unpopular work of change had someone standing behind them. That's what real leadership does. It gives support to the people trying to move things forward. It removes the excuse to stand still.

I've tried to be that piece of paper for the people who work for me ever since.

The most recent lesson is the one I enjoyed the most, because it reframed everything.

We were processing signals — inbound messages, updates, the raw stuff of work. For each signal, we'd hit an LLM to score it against our objectives, and then hit it again to extract a suggested work item out of it. Two calls per signal. It worked beautifully. And the cost went through the roof, almost immediately.

Of course it did. We were hitting a frontier model on every single signal. Let me show you the math, because the numbers are the point of this chapter.

At current mid-tier frontier rates — call it $2.50 per million input tokens and $15 per million output tokens, roughly GPT-5.4-class pricing in 2026 — a single call of about 1,200 tokens in and 400 tokens out costs a little under a penny. Two calls per signal. Now run 50,000 signals a day through it:

| | Per day | Per month | Per year | |---|---|---|---| | Hit-the-LLM-every-time | ~$900 | ~$27,000 | ~$328,500 |

That's one mid-size customer, one workflow. And output tokens dominate the bill — every provider charges three to five times more for what the model writes than for what you send it (Silicon Data) — so the "extract a work item" call is the expensive one, over and over, forever.

So we did something different. We used the AI once — to seed and train a scoring model across a set of messages from a channel. Then we used AI to tune that model with human feedback: was the score right? Was it wrong? Why? We remembered what people said, and we folded it back into a model we built for that application, for that company specifically. And then we cut out roughly 90% of the LLM calls altogether.

The residual — the last 10% — is edge cases and periodic re-tuning that still touch the frontier model. Everything else now runs locally, on a foundation the AI helped us build but no longer needs to run. Watch what that does to the same table:

| | Per year | |---|---| | Hit-the-LLM-every-time | ~$328,500 | | Seeded engine (AI built it, AI doesn't run it) | ~$32,850 | | Annual saving, one workflow, one customer | ~$295,650 (90%) |

That is the pattern. Use AI to create a capability that doesn't have to use AI. The research backs the shape of this hard: model distillation — training a small, specialized model from a large one — routinely cuts per-query inference cost by roughly 10x, taking a workload from about $20,000 a month down to $2,000 (ML Journey). A full optimization stack — right-sizing, caching, routing, distillation — removes 50 to 90% of inference spend (AI Plus Info). Caching alone can cut serving costs up to 90% (AWS). Our 90% wasn't luck. It's what happens when you stop treating the LLM as a runtime and start treating it as a builder.

Let me give you the story that burned this into me.

I was running the Salesforce practice inside the financial-services division of a big consulting firm — a couple hundred million dollars of business. And 95% of it was banking. Insurance was 5% or less.

So I flew to New York to meet our insurance head. I asked him the obvious question: why can't we do more Salesforce in insurance?

And he looked at me and gave me one of the most honest answers I've ever received. He said, "Matt, let me just tell you. One percent of my bonus is tied to alliances or partnerships. Salesforce is maybe one-tenth of that. I'm more than willing to give up that sliver of my bonus rather than deal with the pain of standing up a whole new practice — the hiring, the staffing, the alliances, all of it. We're already killing our numbers."

It was not the answer I wanted. But it was the truth.

His incentive did not push him toward partnerships. His incentive pushed him toward the status quo. And why wouldn't it? A Guidewire implementation (Guidewire being the core software that runs most of the property-and-casualty insurance industry) is a large, multi-year engagement — same as an SAP program in other industries. A Salesforce project, in the beginning, is usually smaller. It can grow into a real transformation, but it starts small. So if his comp rewarded the big, safe, familiar deal, that's exactly what he'd chase.

Which raises the strategic question every practice leader has to answer: do you want volume, or do you want the massive deal? Because — and this is one of the oldest truths in this business — it's just as much work to win a $1 million deal as a $10 million deal. Same pursuit, same effort, same nights. Say it any way you like: $200K versus $30M. It's the same work to win a deal of any size. So why not aim at the larger ones? The answer, almost always, comes back to the incentive.

Every ring — the customer and people at the center, capabilities, offerings, thought leadership — has to be balanced by metrics and KPIs and incentives that drive behavior. (Chapter 11 is the spine of this whole chapter.)

If you're expanding into a new market, incentivize it. If you want your delivery organization thinking about selling — and I believe every delivery team should be thinking about the next deal and where to expand — then build spiffs and incentives (a spiff is sales slang for a short-term cash bonus paid on top of commission to push a specific product for a specific window, from the old British retail term for a salesperson's premium) that reward exactly that behavior. Don't hope people read your mind. Pay for the behavior you actually want. Remember: you get what you reward.

By the time I went in front of the board, I'd actually left to join a company called Innover — a Siebel shop run by a different Adam. And that Adam made one of the gutsiest calls I've ever seen: he decided Siebel was the past and Salesforce was the future, and he flipped the entire company practically overnight. Dropped Siebel contracts. Pulled Siebel RFPs he was in the middle of answering. Went all in on Salesforce. What drew me there was the sheer level of talent — these were people who knew everything about Siebel, everything about CRM, who'd been implementing it for companies for years. Extraordinary bench.

Then I took the review board.

It is like nothing I'd ever experienced. In my past I'd done a pile of Microsoft certifications — I was a Microsoft database professional, a programmer, we were a Microsoft Gold Partner. You studied, you took it, you passed. It wasn't too bad.

The CTA was another universe. Several hours long. In San Francisco, so you traveled to it. All-in — airfare, hotel, the fee — it ran about ten thousand dollars. Your company is making a genuine investment just to send you. (The board review fee alone runs $6,000 per attempt, and most candidates spend 12 to 18 months in intense study after they've already earned all the prerequisites (Pedro Távora Santos, Medium).)

And here's the part that humbled me most. Before you can even get to the board, there's a multiple-choice test. Having worked at Salesforce, you'd think I'd fly through it. Funny enough — I failed that multiple-choice test many times. The last time I sat for it, I told my wife: if I fail this again, I'm just not going to take it.

The hard part wasn't the trivia. It was the rewiring I keep coming back to: I'd been an architect before Salesforce, and now I had to think like an architect for Salesforce and for Salesforce's customers — clicks over code, multi-tenancy, governor limits, SSO, identity providers, mobile, all the things Salesforce leaned into early. Salesforce always leaned in on the technology, but that put the burden squarely on the architect to know how to set it up correctly — and how to advise the customer on what to do, and just as importantly, what not to do.

At the board, at that time, you presented a real client case study and a hypothetical, in front of a panel of sitting CTAs. In my head I took the path of a consultant dropped cold into a customer's mess: here are their challenges, now how would you solve them with Salesforce — thinking about security, scalability, manageability, and the one everybody forgets, adoption. Will they actually use it? I stood at the whiteboards and went as deep as I have ever gone on anything.

Then you wait. You don't find out for at least two weeks. I checked my email constantly, constantly, constantly. Another gentleman from my company sat the board at the same time — and he failed. He found out maybe a day before I did, and I felt genuinely awful for him.

The next day, I found out I passed.

I think I was number 67 or 68 on the CTA rolls. I don't know how many there are now — a few hundred, maybe five hundred — but back then the list was short enough to feel the weight of the number.

Now, what are those objectives? They can be almost anything, and every organization should have the flexibility to define its own.

I love pointing to Salesforce's 1-1-1 model here — the pledge Marc Benioff and the founders built into the company from day one: 1% of equity, 1% of product, and 1% of employees' time given back to communities and nonprofits (Salesforce). That foundation — deciding, as an organization, what you do for society — is genuinely amazing, and thousands of companies have since taken the same pledge. But objectives don't have to be philanthropic. They can be growing your customer base. Using technology to solve a medical problem. Hitting a margin target. Whatever your mission demands.

Here's my rule of thumb, learned the hard way: keep it to three or four objectives. More than that and it splinters — everything becomes a priority, which means nothing is. Be focused. Score against the handful of things that matter most this year. You can revisit them quarterly, but I'd lean toward a twelve-month horizon, because a lot can change in a year and constant re-baselining is its own kind of noise. And one of those objectives, always, should be about keeping the whole thing grounded — a real target around ROI, EBITDA, measurable results. Because if you're not measuring whether it's working, you're just adding to the noise.

But — and this is the caveat that makes or breaks it — if you have conflicting incentives, conflicting promotion guidelines, mixed signals going out internally or to the market, this will not work. You'll get disjointed parts of the organization working against the very objectives the company set. So the design of the organization, the design of the incentives, and the design of the objectives all have to be orchestrated into alignment. Miss that, and the smartest scoring engine on earth just helps everyone run faster in different directions.

Now, here's how you actually earn that influence when you can't give orders: you bring evidence.

Guiding without data is just a stronger person imposing their hunch on a weaker one. Guiding with data is teaching. There's a saying beloved by statisticians — often attributed to W. Edwards Deming, though quote historians trace it back to an anonymous 1970s cliché — "In God we trust. All others must bring data" (Quote Investigator). Deming's own, better-documented version is even sharper: "Without data, you're just another person with an opinion" (Goodreads — W. Edwards Deming). And Jeff Bezos captured why this matters for guiding people who outrank you: "The great thing about fact-based decisions is that they overrule the hierarchy" (Deliberate Directions). When I walked into that IT room with no authority, the data is what overruled the hierarchy. Not my title. Not my resume. The evidence.

And the numbers on why to work this way are overwhelming. McKinsey's research found that data-driven organizations are 23 times more likely to acquire customers, six times more likely to retain them, and 19 times more likely to be profitable than their peers (McKinsey, via Valtech). Forrester found companies that use data tools for decisions are 58% more likely to hit their revenue goals — and 162% more likely to beat them (Forrester, via SharpGrid). And companies with strong data cultures make decisions roughly 5x faster (TechDogs). When you guide a client with numbers like that behind you, you're not selling an opinion. You're de-risking their decision.

Let me pull back from my own story for a minute and put some numbers on why this matters, because I don't want you to take it on faith from a guy telling war stories.

Bad data is not a nuisance. It's a line item. Gartner has estimated that poor data quality costs the average organization around $12.9 million every single year (Gartner, widely cited). Zoom all the way out and IBM has put the cost of bad data to the U.S. economy at roughly $3.1 trillion a year (reported alongside the Gartner figure). Trillion, with a T.

That is what "disjointed data" costs when you let it pile up across an organization — not in the abstract, but in wasted hours, missed opportunities, wrong decisions, and customers who give up and leave. Every one of those dollars traces back to the same thing I saw at BellSouth: a customer no one could see whole, because the data lived in twenty places and agreed with itself in none of them.

And bad architecture is the twin of bad data. When systems are wired together with brittle, point-to-point integrations — this one talks directly to that one, which talks directly to the next one — you've built a house of cards. One system changes, and the whole process breaks. I've watched it happen more times than I can count. It's expensive, it's slow, and it's demoralizing, because the failure is never where you're looking.

The fix has a fancy name now — composable architecture — but it's just building with blocks instead of welding everything into one rigid machine. Loosely coupled pieces you can swap and recombine, so you can change one thing without breaking everything. That's the whole game. And it pays off: Gartner found the companies that build this way ship new capabilities dramatically faster than the ones stuck in monoliths (Gartner, via industry analysis).

I didn't have those words at BellSouth. But "one customer, one ticket, many issues" was me reaching for exactly that idea with my bare hands — modular, reusable, hard to break. Sometimes you build the right thing years before anyone hands you the vocabulary for it.

Let me tell you about a room where speaking two languages changed how an entire company paid its people.

Big global company — seven divisions, massive, I won't name them. Their top sales leader had just sold the most by dollar value. Huge commission check. Big recognition. They flew him out to some wine-and-dine resort in California, sat him across from the CEO. The whole nine yards.

Then we looked at the data in Sales Cloud. And something was missing.

Yes — he'd sold the most by revenue. But there was no margin in the picture. What was the margin on the products he sold? What did those deals actually deliver to the organization?

Everyone said, don't worry about it — the guy who sells the most gets the prize. But we had a data analyst dig in. And here's what came back: he'd sold a pile of very low-margin — and some negative-margin — products. On a net-revenue basis, he was near the bottom ten percent of the entire sales force. The company's "top seller" was actually costing the company money.

So we had the hard conversation. If you want to reward the right behavior, reward your sellers on the net revenue they bring in — the money left after cost — not the gross. They changed their sales compensation plan going forward.

But sit with this: if I had only thought about the technology, I never would have asked about margin. I never would have wondered what the sale was actually worth, or whether we even had the data to expose it. It took speaking business to ask the question, and speaking technology to answer it.

They say time heals all wounds. I'm not sure who said it first, but I've always loved the line.

In business, though, the opposite is true.

Time kills a company. You're bleeding money. You have to grow. You have to sell. You have revenue targets, payroll, responsibilities, people whose mortgages depend on you being right. Time is not your friend when you're early — time is the thing draining out of the account while you wait for the world to show up. And if the idea is too early, then time doesn't just kill the company. Time kills the idea.

This is where the data stops me cold, because it turns out my expensive personal lesson is one of the most reliable findings in all of startup research.

When Bill Gross of Idealab went back and analyzed more than 200 companies — the massive winners and the painful failures — trying to figure out what actually separated them, he expected the answer to be the idea, or the team, or the funding. It wasn't. Timing accounted for 42 percent of the difference between success and failure — more than the team, more than the idea, more than the money (Bill Gross, TED 2015, via Tech.co). Airbnb launched into a recession when people suddenly needed extra income. YouTube took off only once broadband and Flash made streaming painless. Same idea, wrong year? Failure. Same idea, right year? A category (Bill Gross summary, EX NIHILO).

I didn't have that study back then. I just had the wound. But the wound was telling me the same thing the data does: being right isn't enough. You have to be right on time.

So I'll leave you with this. Think hard about the connection between technology and business. Think about profit and loss — what it means for your leadership, and what it means for your brand. Then figure out how you influence it day to day. How do you pick your battles? (We're going to get into governance next — that's coming.) And ultimately, how do you scale this thinking across an organization?

Because if you're going to be all in, you have to understand the numbers. And the good news is that with the tools we have today, you can understand them in more ways than ever before. But it only works on one condition, the same one this whole chapter keeps circling back to:

You need one set of truth. And everyone has to be in line with it.

The world is messy. It's difficult. It's beautiful. So learn to read the scoreboard — because that's how you keep score of all of it.

Are you all in — fluent enough in the numbers to make the technology count?

The second one I did to myself.

Well into the rebuild, I made a decision I should have made on day one: everything gets encrypted. Not the sensitive fields. Not the obvious things. Everything. If this platform was going to hold companies' emails, accounts, contacts, opportunities, cases, and projects, then all of it is sensitive, and I wasn't going to be the guy who sorted it into tiers and got the sorting wrong.

That decision cost me about eighty percent of the application.

Eighty percent. Because encryption isn't a feature you add — it's a property of the whole system, and it reaches into everything. How do you search encrypted data? When the plaintext isn't sitting there for you, how do you handle hashtags, how do you index, how do you make search fast? Where do the keys live? How do tenants stay genuinely isolated rather than isolated-if-nobody-makes-a-mistake? Every one of those questions rewrites your data layer, and your data layer is underneath everything else you've built.

Here is the lesson, and it's the most expensive one in this chapter: these decisions are critical at the start. Encryption. Multi-tenancy. API-first. Identity. They are not things you get to postpone and then bolt on when a customer's security questionnaire arrives. They are the shape of the building, not the paint.

I knew that. I've said it to clients for years. I still got it wrong, because when you're moving fast and things are working, "we'll harden it later" is the most reasonable-sounding sentence in software. It isn't reasonable. It's a bill you're writing to yourself with a later date on it.

And no prompt is going to save you here. AI will happily generate you an encryption library call. It will not decide what to encrypt, where the keys live, how tenants stay separated, or how search survives the choice. That is architecture, and architecture is still yours.

So: two throwaways. Which is why I think Brooks was right the first time — you will throw one away — and also right to take it back. His mistake was assuming you throw away the first version because you learned what the product should do. That's not what happened to me. I threw the first away because it was built in the wrong medium, and the second because I got the foundations wrong. Neither was about the features. Both were about the ground.

Let me back up and tell you how I learned to see this, because it wasn't a lightning bolt. It was slow.

When I started in consulting, we went into the room. An actual conference room. We met with the company and spent hours, days, sometimes weeks understanding how they worked. We wrote it out. And if we were smart, we understood what it cost.

If we were doing a contact-center transformation, we asked the hard questions. What's your average cost per call? What's your average handle time? What's your one-and-done ratio — how often does a customer's issue get resolved on the first contact? What's your NPS? We asked dozens of these, and they weren't trivia. They built a picture of the current state and the business case, from two angles at once: the frustration of the person managing the contact center, and the P&L of the business running it. By the end, we understood the customer well enough to become a thoughtful partner. Not a vendor. A partner.

Then, over time — and partly as my own career moved from company to company, drifting from the strategy side toward the implementation side — I watched something break.

A gap opened up between the strategy of the organization and the implementation of the technology. The strategy was done by one group. The implementation was done by another, typically on a cost basis, not an outcome basis. And here's the part that still bothers me: the implementers were not given the knowledge of what the business case originally was. They were flying blind. The instruction was, in effect: We know we need this. It's in our business case. Go implement it. No, we will not share the business case with you. Just build the technology.

So what got cut? The change management got cut. The governance got cut. And the tying of the implementation back to the actual objective of the business case — which was tied to the objective of the organization — got cut out entirely.

That's the gap. And it is not a small one. The research says roughly 67% of well-formulated strategies fail — not because the strategy was bad, but because of poor execution (Harvard Business School research, via GoalCadence), and about 61% of executives admit their organizations struggle to bridge the space between formulating strategy and running it day to day (Economist Intelligence Unit, via GoalCadence). We didn't have a strategy problem. We had a seam problem — a gap between the people who knew the "why" and the people building the "what."

The good news is that I think we've gone 360 degrees around. We are relearning, the hard way, that to implement AI you actually have to know these things. You have to know the business case. You have to know the strategy. You have to know the ROI — and to develop the ROI, you have to bring what happens on the ground floor all the way up to the strategy, understand the cost, understand the outcomes, and tie them together. Strategy consulting and implementation consulting are still, in most of the industry, two fundamentally disconnected things. AI is going to force them back together, or it's going to fail.

So there I was, in meeting after meeting with clients, and I could finally articulate the pattern I'd seen a hundred times. A customer wants to put 50 million records in Salesforce. A customer wants to know: will it scale with our business? Will it help our sellers sell, our service agents serve? Will this technology actually help my company succeed?

And a lot of the time, I turned the question around on them:

Are you ready for the technology?

Because it is not always a technology problem. Very often it's a business problem. A process problem. I'll never forget standing on stage at one of IBM's Dreamforce keynotes and saying it out loud: it's people, process, and technology — and it always, always goes back to the people first.

• People: Are they ready? Do they want this, or is it being done to them?
• Process: Is there a right process we should be following as people, whether we're using the technology or serving the customer with it?
• Technology: And only then — is this actually the tool we need to do our job and serve our customers?

I was talking with some friends recently about how to phrase what's broken today, and here's where we landed. Right now, we work around our tools. We work around the silos. There's a mountain of research on application-switching and the sheer number of apps in an enterprise — the applications don't talk to each other, they don't work together, and yet we're still expected to perform miracles on top of them.

I think now is finally the time that technology should work for us — not the other way around. And that's the exciting part. But it only happens if the people recommending and building it are credible.

So data governance is number one. But it's not the whole story, because governance isn't only about your data — it's about your people.

Change-management governance is just as important, and it's the second thing that gets cut. Education and AI fluency — from the board down and from the frontline worker up — that is genuinely critical. You can't buy your way to it. You have to build it.

I always like to say CoEs — centers of excellence. But lately I've started thinking maybe we should call them centers of competency, or just think of them as an extension of governance. The name matters less than the habit: we're meeting regularly, we're talking about what we need, what's working, and — this is the one people avoid — what's not working.

Which brings me to retrospectives — the structured team meeting after a project or sprint where you name what worked, what didn't, and what to change next time. I've watched organization after organization cut retrospectives, usually for cost, sometimes just out of misunderstanding. Please don't. Retrospectives are critical, especially when you're running a practice. I've said this throughout the book and I'll say it again: a practice is not perfect; a practice is learning. But it can only learn when it listens — when it hears the experience and actually does something with it. Kill the retro and you've told your team their experience doesn't matter. You've capped how good they're allowed to get.

The other half of change management is finding the right people to carry it. The early adopters. The SMEs who already know what they're doing, who know where they want to go and how to get there. You bring them in early, you let them lead from inside, and you do not short-circuit or shortcut the process.

Here's why this isn't optional. However you slice the research, transformations mostly disappoint — even the honest analyses that debunk the tired "70% fail" myth land on the same uncomfortable place: only about a third of transformations fully deliver, roughly half land in a grey zone of leaked value, and about a fifth fail outright (Rainman Advisory). And when researchers dig into why, one of the most predictive failure factors is the absence of measurement systems linking the change to real outcomes (Macro Consulting's review of Burnes & Jackson). The technology rarely kills the transformation. The people-and-governance part does.