The Best Advice I Ever Got Told Me, In One Sentence, How Wrong I'd Been for Six Months

The best consultants I ever worked with could listen for twenty minutes and then tell me, in a single sentence, how wrong I'd been for the previous six months.

That's a real skill and I have enormous respect for it. At Paramount Farms I worked directly with people who came out of Bain, Boston Consulting Group and Latham & Watkins — sharp, fast, and completely unbothered about telling a room full of executives something it didn't want to hear.

But the sentence wasn't why those engagements worked.

What the good ones actually did

Here's the part I didn't appreciate until much later: with those people, I didn't just receive the thinking. I watched them work the problem their own way, and then I watched them push the change through the organization — and I was in the room helping do it.

That distinction turns out to be everything.

They sat in the meetings where it got difficult. When reality pushed back — and it always pushes back, usually around week three — they adjusted the plan instead of defending it. They kept showing up after the interesting part was over and the tedious part had started. What they owned wasn't a document. It was whether the thing actually changed.

That isn't a Bain trait or a BCG trait. It's a staying trait, and it separated every engagement I've seen work from every one I've watched evaporate.

And then there was the other kind

Early 2000s, Time Warner Cable. We brought in a Big Four firm to look at inventory security and waste — real money was going missing across a large distributed operation, and we wanted to know how much and why.

The team were bright and good to talk to. Young, but you could see the training. They were thorough, they worked hard, and after six weeks they came back with a convincing, well-built story about exactly how much we were losing and where.

They were probably right. None of what follows is a claim that the analysis was wrong.

The recommendations included a significant capital investment in new technology. No cost-benefit analysis ever reached me. Six weeks, roughly a hundred thousand dollars, and a very pretty process chart.

I knew exactly what that meant, because at Cox I had spent my days on the other side of that decision — building the cases for capital projects that had to clear an 18% hurdle rate. A recommendation without a return attached doesn't get argued with. It gets deferred.

I've thought about that chart for twenty years. It wasn't a bad deliverable. It was an honest picture of how things worked. It just wasn't something anyone could act on come Monday.

What a complete recommendation actually contains

Here's where I've landed after being on both sides of this. A recommendation isn't finished when it's correct. It's finished when it answers three things, and most of them answer one.

If you're recommending we spend money, bring the cost-benefit and the breakeven. Not a range of benefits and a separate capital number on a different page. The actual math: what it costs, what it returns, when it pays back. Without that, the person in my old seat has nothing to take to a budget meeting, and the idea doesn't get rejected — it gets deferred. Deferred is how good ideas quietly die with everyone still agreeing they were good.

Say who inside this company would actually do it, given what's already on their plate. Not "the operations team." Which people, with what capacity, alongside which of their existing responsibilities. Half the recommendations I've read assume a spare person who does not exist anywhere in the building.

And if it needs more people, say how many and what that costs. This is the one almost nobody puts in writing. A recommendation that quietly requires two new hires has a price tag that isn't on the invoice — and the company finds out about it in month four, when the project stalls and someone finally works out why. That number belongs in the recommendation, not in the aftermath.

Those three aren't a higher standard. They're what makes the difference between a document that describes a better company and a document that produces one.

What I'm actually looking for

People hear "operational review" and picture a cost-cutting exercise. Most of what I find isn't cost. It's friction that got accepted a long time ago and stopped being visible.

Some of it looks like this:

• A number somebody spends two days a month assembling by hand, that could arrive on its own every morning.
• Three systems each holding a slightly different version of the same customer, and no agreement on which one is right.
• A process that only works because one person remembers the exception, with no plan for the week they're out.
• A report that exists because somebody asked for it in 2019 and hasn't been read since.
• Two subscriptions doing substantially the same job, both renewing.
• Something everyone does by hand because "the system can't do that" — and either it can, or a small tool could.

None of these are dramatic on their own. Together they're usually a good part of why a business feels harder to run than it should.

The cadence is old. The lever is new.

Here's what has genuinely changed, and it's why I do this now rather than fifteen years ago.

The way I look at a business hasn't changed since Milgard. Walk the process, talk to the people doing it, find what's fixable now, schedule the rest honestly. That cadence is old and it still works.

What's changed completely is what "fixable now" includes.

Twenty years ago, if the answer to a problem was a piece of software that didn't exist, that was the end of the conversation. It meant a vendor, a procurement cycle, a capital request, an integration project and a year. It failed the hurdle rate before anyone finished describing it.

A lot of those same fixes are now a few days of building. Not everything — I'm not going to pretend a real system is trivial. But the category where the right answer is "something small, built specifically for the way you actually work" has gone from unreachable to routine.

Which means the same diagnosis produces a different answer today than it would have in 2004. Some ideas that correctly failed a cost-benefit test back then pass it now, because the cost side collapsed while the benefit stayed exactly where it was.

The skill isn't building things. Plenty of people build things. It's knowing which of three answers applies: buy the thing that already exists, build the small thing that doesn't, or leave it alone because it isn't worth either. Getting that wrong in the second direction is how businesses end up with expensive software nobody opens.

What I do about it, and why I start small

I'm not interested in whole-company transformation. That's not modesty about scale — it's that I've watched the big-bang version fail more often than it works, and I learned a better sequence on a factory floor.

At Milgard Manufacturing I ran and took part in Kaizen events. The method is simple: get the people who actually do the work in a room, look at every part of the process, and fix the things you can fix this week. Not next quarter. This week.

Two things were consistently true.

The quick changes were clean and immediately impactful. Small, visible, owned by someone in the room, done before anyone lost interest. They almost always worked.

The long-horizon items were hit and miss. We'd identify the bigger-ticket things, put them on a timeline, and schedule follow-ups to keep everyone in sync. Sometimes that held. Sometimes it didn't. I'd rather tell you that than pretend otherwise, because it's the single most useful thing I know about how change works: the further out you plan, the more of it evaporates.

So that's how I work. Look at all the parts. Do the quick and easy first, because those are the ones that reliably land and they buy the credibility for everything after. Then put the bigger items on a real timeline with real follow-ups — and go into those clear-eyed about which ones are likely to survive contact with the year.

One honest note on the method: Kaizen, at least as I used it, was built for taking cost out. It didn't naturally generate revenue ideas. I was there just over a year, so I can't tell you whether that changed later. What I can tell you is that the cadence — fix what's fixable now, schedule the rest, follow up — works just as well on the growth side, and that's how I apply it.

What I can't do, since we're being straight

I'm one person. I can't restructure a global division, I can't put forty analysts in a data room over a weekend, and I'm not going to sit in your offices for six months.

There's a size of problem where a large firm is genuinely the right answer, and when you're at it I'll say so. What I close is the specific gap between "here's what should change" and "it changed" — for businesses where that gap is the whole reason nothing has moved yet.

One question to ask anyone

Whoever you're about to hire, ask this: after you hand me this, who does it?

Then watch. If the answer is a confident description of what they'll build, configure, write or run, and what your people would need to do alongside them — good. If it's a vague gesture toward your team, you now know what you're buying. It might still be worth buying. But you're also buying yourself a project, and you can plan for that.

That one question would have saved several of the smartest engagements I've ever been part of.