# Thirty years in and the work still surprises me. That's how I know it's real.
I've been doing this long enough that I should probably be bored by now. Thirty years of building systems, fixing operations, untangling the same organizational knots in different industries. You'd think it would start to feel routine.
It doesn't. And the fact that it doesn't tells me something important.
The work is still surprising because the work is still real. The day it stops surprising me is the day I should worry — because that means I've stopped paying attention and started performing expertise instead of practicing it.
When experience stops producing surprise, it's stopped producing learning. And learning is the only thing that keeps experience from becoming dogma.
The trap of the expert
Thirty years of experience cuts both ways. On one side, you've got pattern recognition. You walk into a room and you can feel the shape of the problem before anyone finishes explaining it. You've seen this movie. You know how it ends. That's valuable. It saves time. It prevents mistakes. It gives clients confidence.
On the other side, you've got confirmation bias wearing a lab coat. You're so good at recognizing familiar patterns that you stop looking for unfamiliar ones. You start fitting new problems into old frameworks instead of letting the problem tell you what it actually is. You become the person at the dinner party who already knows the punchline to every story — even the ones they haven't heard yet.
I catch myself doing this more often than I'd like to admit. I walk into a company, spend two days doing discovery, and by the end of day one I've already got a theory. Usually the theory is right. But "usually right" is dangerous, because the times it's wrong are exactly the times the stakes are highest.
What the surprises teach
The surprises always come from the same direction: people. Systems are human. You can architect the most elegant process in the world, and then a real human being interacts with it and does something you never anticipated — not because they're wrong, but because the map you drew didn't account for the territory they actually live in.
A few years ago I was working with a distribution company. Solid operation. I was restructuring their inventory tracking system — clean project, done versions of this before. During the rollout, one of the warehouse supervisors started using the new system in a way I hadn't designed for. She was entering notes in a quantity field. Not numbers — actual sentences. "Check pallet for water damage." "Shipper usually shorts this SKU by 2-3 units."
My first reaction was to treat this as a training problem. She's putting text in a number field. Obviously wrong. Then I stopped and looked at what she was actually doing. She'd built an informal quality-control system inside my inventory system because there wasn't anywhere else to put that institutional knowledge. The information she was capturing was more valuable than the quantity data the field was designed for.
That's a surprise. And it taught me something I should've already known: the people doing the work always have context that the system designer doesn't, and if you don't build a place for that context, they'll find one anyway.
Beginner's mind at year thirty
There's a concept in Zen Buddhism — shoshin, beginner's mind. The idea that approaching something with openness and curiosity, even when you have deep experience, leads to better outcomes than approaching it with the certainty of an expert. I'm not going to pretend I meditate or that I've read more than two books on the subject. But the concept is operationally useful.
Beginner's mind at year thirty doesn't mean pretending you don't know things. That would be dishonest and wasteful. It means holding what you know loosely enough that new information can update it. It means asking questions you think you already know the answer to, because sometimes the answer has changed and you're the last to notice.
I've started doing something deliberately in the last few years: before I present my assessment to a client, I write down three ways I might be wrong. Not as a rhetorical exercise — I actually try to find the holes. What am I assuming that might not be true here? What's different about this company that my pattern recognition might be glossing over? What would this look like if the problem isn't what I think it is?
Most of the time, my initial read holds up. But maybe one out of five times, one of those "ways I might be wrong" turns out to be the real story. And that one out of five is the difference between good work and great work.
The alternative is performance
I know operators and consultants who've been doing this as long as I have, and they've calcified. They have their framework, their methodology, their twelve-step process, and they apply it everywhere regardless of context. They're not solving problems anymore. They're performing solutions. The client gets a deliverable that looks professional and checks all the boxes and doesn't quite fit, because nobody stopped to ask whether the boxes were the right ones.
That's what happens when the work stops surprising you. You stop listening to it. You start imposing instead of discovering. And the results are fine — professionally acceptable, architecturally sound, and spiritually dead.
I'd rather be surprised. I'd rather walk into a warehouse and discover that a supervisor has figured out something I missed. I'd rather be wrong on day one and right by day ten than right on day one and done by day three.
The work keeps teaching me things. After thirty years, that feels less like a confession of ignorance and more like the best evidence I've got that the work is real.