The 7 Operations Principles That Haven’t Changed

I went back through every issue of this newsletter looking for the ones that aged badly.

I expected to find a few of them since it’s been four years now. Long enough time has passed that the tools I recommended early on have been acquired, rebranded, or shut down. The AI conversation didn’t exist when I started and now it comes up in nearly every leadership meeting I sit in.

So I went looking for what I got wrong.

What I found was more uncomfortable than being wrong. The problems didn’t move. The shop floor I walked onto last month had the same four issues as the one I walked onto when I wrote the first issue, and the one from more than twenty years ago when I was just getting started doing this work. Different industries, different leaders, different revenue but same problems.

That is either depressing or useful, depending on what you do with it. I think it’s useful. If the same handful of things break in every operation regardless of size, sector, or software, then the list of things worth your attention Monday morning is a lot shorter than your current to-do list suggests.

Here are the seven that keep showing up. Six of them I’d write the same way today. One I got wrong, and I’ll show you where.

## 1. Technology is last. Every single time.

Planning, then people, then process, then technology. I wrote that in the first month and I’ve written some version of it more than any other idea in this newsletter.

It is also the one people ignore most reliably, because it’s the least satisfying. Buying something feels like progress. Mapping a process feels like homework.

Here’s how it actually plays out. A company implements a CRM. It doesn’t work. The data is messy, the workflows don’t match how the team sells, nobody logs anything. So leadership concludes the tool is wrong and starts shopping for a different one. They call the competitor, who confirms that yes, of course the first tool was a bad fit, and of course theirs has been built for exactly this industry.

Six figures and nine months later, they land in the same place. Because the problem was never the tool. It was that nobody defined the process the tool was supposed to execute.

I watched a manufacturer discover their ERP had been configured so that two different customers ordering the identical bolt were pulling from different item numbers. That wasn’t an ERP failure. That was a decision somebody made during configuration and implementation, years earlier, to solve a short-term problem. The software did exactly what it was told, from that day forward.

Technology amplifies whatever it sits on. If the process underneath is sound, it accelerates a good thing. If the process underneath is improvised, it accelerates the improvisation and gives it an audit trail.

Monday morning: before you approve any software purchase, ask the person requesting it to walk you through the current process on paper. If they can’t, you’re not ready to buy.

2. What looks like a people problem is almost always a system problem.

This one showed up in issue five and it has never stopped being true.

A leader tells me their team won’t take ownership. People don’t follow through. Nobody escalates until it’s too late. The diagnosis is always some version of “we need better people” or “they just don’t care.”

Then I go walk the floor and find one person who has become the routing system for the entire operation.

I worked with a company where the second-in-command had turned into the middleman for everything. Facilities requests, workers’ comp paperwork, scheduling conflicts, customer escalations. Not because anyone assigned it to him, but because he was the one person who reliably answered. He described it to me almost exactly this way: he didn’t know how to stop being the middleman when everybody felt most comfortable coming to him.

That is not a character flaw. That is what happens when a system has no gates. Work flows to whoever will raise their hand, and the person who raises their hand most is usually your best person. Then you burn them out and conclude you have a people problem.

The test I use: if you swapped this person for someone equally capable, would the problem go away? If the answer is no, you’re looking at a system.

Monday morning: pick one thing that consistently lands on your best person’s desk without being assigned. Ask why it goes there instead of somewhere else. The answer is your gap.

3. Simple beats sophisticated. Issue one said this. Issue two hundred still does.

The very first issue of this newsletter was about keeping systems simple. I did not expect that to be the idea I’d be defending four years later, but here we are.

The failure mode is almost always good intentions. Somebody wants visibility, so they add fields. Somebody wants accuracy, so they add approval steps. Every addition is individually defensible. The accumulated result is a system nobody will touch.

I worked on a CRM cleanup where the previous management team had built out dozens of pipelines to satisfy a reporting appetite for granular email metrics. By the time I saw it, there were more than twenty-three thousand open tickets in the system. The person who owned it told me he avoided it entirely and worked out of Outlook, because opening the CRM gave him a panic attack.

Nobody set out to build that. It was built one reasonable request at a time.

The cleanup wasn’t clever. Collapse to one pipeline. A handful of stock statuses. Manage by owner and view. Close the tickets and follow up with tasks. The sophistication went down and the usage went up, because a system people actually use beats a system that captures everything and gets abandoned.

Configurability is not a feature. It’s a liability you take on in exchange for flexibility you may never need.

Monday morning: open the system your team complains about most and count the fields nobody has filled in for ninety days. Delete them.

4. Clarity comes before consistency, and consistency comes before accountability.

The sequence is the whole point. You cannot hold someone accountable to a standard that was never made clear, and you cannot make a standard clear once and expect it to stick without reinforcement.

Most leaders try to start at the end. Performance slips, so they go straight to the accountability conversation. It doesn’t work, and it damages trust, because the person on the other side of the table is being held to a line they never saw drawn.

I’ve watched a company cycle through multiple hires for the same role over several years, concluding each time that they’d picked wrong. They hadn’t. The role had never been defined. Every new person was handed the title and left to reverse-engineer the expectations from whatever went wrong first. The owner had genuinely convinced himself it was a hiring problem.

Run it backward when something breaks. Is accountability in place? Was there consistency? Was there ever clarity? The failure is almost always at the clarity level, and it’s almost always further back than you want it to be.

The uncomfortable part is that this makes most performance problems a leadership problem. That’s not an insult. It’s leverage. You can fix a clarity gap this week. You cannot “fix a person.”

Monday morning: take the role you’re most frustrated with right now and try to write down, in five bullets, what success looks like (with specifics). If you struggle, that’s your answer.

5. You are almost certainly measuring the wrong things.

I sat in a leadership meeting where the team was genuinely excited. Win rate was ninety-four percent. Best quarter they’d ever posted on that metric.

I asked how many deals that represented.

They’d won one.

The number wasn’t wrong. It was just random. Any metric with a small enough denominator will swing wildly and tell you a story that feels like performance. The team wasn’t being dishonest, they were reacting to a signal the measurement design had manufactured.

Bad metrics are worse than no metrics, because no metrics leaves you appropriately uncertain and bad metrics make you confidently wrong. Then leadership reacts to the false signal, launches an initiative to address it, and the focus you spent months building comes apart.

Two things fix most of this. Pick a window long enough to cancel out the swings, then look at the trend instead of the point. And separate the leading indicators you can act on from the lagging ones that only report what already happened. A dashboard full of lagging indicators is a newspaper. It tells you what occurred. It gives you nothing to do.

Monday morning: take the metric on your dashboard you’re proudest of and ask what the denominator is. Then ask what action you’d take if it moved three points.

6. Tribal knowledge is not an asset. It’s an unfunded liability.

Every company I walk into has a version of this, and every one of them describes it as a strength. “Jim just knows.” “Sarah’s been here nineteen years, she handles that.”

That’s not depth. That’s exposure you haven’t priced.

A manufacturer I worked with had an international distributor retire. He handed his successor the keys and an email introduction, which is roughly the documentation standard for most of these transitions. Roughly forty thousand dollars a year in business evaporated inside a year. Not because the successor was bad, but because the manufacturer had no idea what the relationship actually consisted of. Every order had flowed through one person for years, so the company was structurally blind to how its own business worked.

I’ve seen a leader’s name written directly into a work instruction. I asked what happens if he isn’t available. The answer was that the process stops. Hard stop.

The fix is not a documentation project. Documentation projects fail, because they ask people to stop working and go write things down for a future benefit they won’t personally see. The fix is capture at the point of friction: when someone has to figure something out, that moment of figuring is the data. Catch it then, while the answer is fresh and the person is already thinking about it.

Monday morning: write down the one question your team asked you twice this week. Put the answer somewhere they can reach without you. Then hold the line the third time they ask.

7. The one I got wrong: I underestimated how much AI would expose, not replace.

Here’s the principle that changed.

Early on I wrote about AI the way most people were writing about it, as a coming capability that would challenge our assumptions about people and process. It was speculative, and it was framed around what AI would eventually be able to do.

I was thinking about it backward.

The interesting question was never what AI can do. It’s what your operation has to be true for AI to do anything useful at all. That reframe took me a couple of years and a lot of failed pilots to land on, and it’s the biggest correction I’d make to my own archive.

What I’ve watched happen since: companies with clean data and documented processes get real value quickly, and companies without them get expensive, confident nonsense. AI doesn’t fix a broken process. It executes it faster and with better formatting. If the path is busted, AI makes the mess bigger and harder to see, because now it has a confident, professional-looking output attached to it.

This is why I ended up building out the intelligence layers as a readiness model rather than a maturity model. Layer zero is your traditional systems: your ERP, your CRM, your quality system. They have to actually work, with data you trust and people who use them. Layer one is assisted use, where a human decides every time. Layer two is AI executing workflows you designed. Layer three is AI making decisions inside boundaries you set.

Each layer requires everything below it. Almost no mid-market manufacturer is ready for layer three, and most are still fighting layer zero. That’s not a criticism, it’s just where the work is.

So the correction is this: I used to treat AI as the next thing on the technology list. It isn’t. It’s a mirror. It reflects the quality of the operational foundation underneath it, at scale and at speed.

Monday morning: before your next AI conversation, ask whether the process you want to automate is documented and whether you trust the data feeding it. If either answer is no, that’s the project.

Final Thoughts

Two hundred issues is enough writing to notice a pattern, and the pattern is not flattering to any of us.

The problems didn’t change. The tools changed constantly, and we kept reaching for the tools.

Every one of these seven principles is boring. None of them require a budget approval or a vendor demo. All of them are harder than buying something, because they ask you to slow down and look at how work actually moves through your building instead of how you assume it does.

That’s the whole job. Not the software. Not the framework. Not the next initiative.

Go walk the process. It’s still the highest-return hour in your week, and it was true in issue one.

That’s it for today.

See you all again next week!

Dave