I once worked with an extraordinarily brilliant Chief Technology Officer who possessed a mind like a Swiss watch and a leadership style that completely redefined how I view the architecture of a team. Among his many pieces of wisdom, the one that stuck to my ribs most permanently was a simple, stark directive he used to issue to his engineers: “Don’t follow criminal orders.”
Now, it’s worth clarifying that we weren’t operating a rogue cartel or smuggling contraband across international waters. We were building software, and nobody was going to jail. But what he meant—and what I now pass down to my own teams—is that the moment you stop thinking critically is the moment the entire system begins to slide into the sea.
Knowledge workers, by definition, are paid for the contents of their minds. We aren’t assembly-line robots designed to stamp out widgets without looking at them. Yet, there is a strange, hypnotic pull in corporate life that tempts people to look at a fundamentally broken instruction, shrug their shoulders, and say, “Well, the ticket told me to do it.”
I’m acutely aware I’m an entirely fallible human being. If I write a ticket for a new user form, and I mistakenly map a field labeled “Searchable” to a backend boolean variable named “hidden,” that isn’t a masterstroke of avant-garde user experience design, it’s plain and simple an oversight. I’ve made a mess, and the last thing I want is an engineer blindly building that monstrosity into the codebase just because my name was at the top of the assignment.
“Don’t follow criminal orders” is simply the more dramatic, slightly more cinematic sibling of “use your best judgment.”
We had a textbook example of this recently. A client approached us with a blueprint for a market prep tool, requesting a complex external API integration. Technically speaking, we could absolutely build it. But it wouldn’t actually be useful in the way they imagined it would.
I had to sit down with the Account Manager and the client to explain the reality of what they were asking for. “Look at us as General Contractors,” I said. “You’ve brought us a blueprint for a lovely three-bedroom, three-bathroom, two-story house. We can absolutely build it to your exact specifications. The only catch is that your blueprint puts all three bathrooms on the second floor, clustered entirely in one far corner. Can we build it? Certainly. Will it be a house? Technically. But is it going to be a functional, pleasant place to live? Absolutely not.”
It’s our job as knowledge workers to think through this kind of architectural plumbing before we ever pick up a hammer.
Take, for another example, the corporate mandate that all new code must be placed behind a feature flag. It sounds clean, simple, and safe. But if an engineer is fixing a tiny, three-line null-pointer exception that prevents the app from crashing on launch, putting that fix behind a feature flag is a form of malicious compliance that adds complexity where common sense should live. There’s always wiggle room, there has to be.
I have absolutely no desire to micromanage anyone, it’s an exhausting way to live, and it produces brittle, fearful software. Instead, I want to build teams where the primary currency is trust and relentless, open communication. I want my team to look at a bizarre requirement, confidently wave a hand, and say, “Hey, this looks completely backward. Should we really do this?”
And perhaps most importantly, this philosophy serves as a vital circuit breaker for those moments of high-octane panic. Just because an executive or a stakeholder wanders into the room bellowing “we’ll do it live!” doesn’t mean we under any circumstances should. Panic is contagious, but common sense is a choice. We’re paid to build things that last, which means our first responsibility isn’t to blind obedience—it’s to making sure the roof doesn’t fall in while we’re looking the other way.