The Frustration Engine

For today's Adventure, I want to start with an imagination experiment.

Imagine for a moment that you run a Taco Truck. 🌮🌮🌮

One day, the health inspector comes by. You think it's a routine inspection, but... it isn't. Instead, he drops off a new policy document:

To prove you are meeting food safety standards, you must now take a high-resolution photo of every single taco before it is handed to a customer. You must then upload that photo to a portal and tag it with the internal temperature of the grill at that exact second.

Now my question to you is this: Does the new policy make the food any safer?

No, of course not! The new policy is disruptive to the flow of serving customers, which makes the meat cold and the line long. But back in his office, the Inspector's dashboard is glowing green. He has "perfect" visibility. Mission Success!

...and Business Failure.

Blink... you're not here to talk about tacos today, are you?

Yeah... you got me, it's a setup! We're talking about inspectors (well, auditors) but not taco trucks... this is a tech blog, for Pete's sake.

The title of this post is "The Frustration Engine"... and we're going to explore how we accidentally ended up with an engine that creates frustration. (At least, I hope it wasn't the plan all along!)

This is how Audit Compliance seems to work in Enterprise settings:

• The Reviewer wants more "evidence" so they demand it of the engineering team.
• The engineering team, overloaded already, adds manual information-gathering to their backlog.
• The increased workload increases the amount of human error.
• The Reviewer sees the errors, interprets it as process failure, and responds by tightening the noose: asking for even more evidence.

Why the Taco Truck was Tragic

It's not because the inspector's policy was annoying (though it was).

It's not because it stifled the business (though it did).

It's because the policy was designed for the comfort of the wrong person.

When we design a process, there's a sort of unwritten rule that underpins everything we create:

You get what you prioritize.

In the food truck story, we've prioritized the comfort of the Inspector. We did so at the expense of the entire taco business. The Inspector... who didn't have any experience running a taco truck. Who didn't know about cooking, or about how to clear a long line of hungry folks at a lunch hour. Someone who had never "gotten his hands dirty", but stayed distant from firsthand experience while making up rules about how to ensure food safety.

Remember? People without dirty hands...

At first when you read People Without Dirty Hands Are Wrong, you might think "well that sounds harsh". Blink, how can you say they're wrong?

They aren’t wrong because they’re malicious; they’re wrong because they lack context. Without the grit of the work, they solve for the artifact, not the outcome.

Let's think about the frame of "Gathering Evidence for your next Audit". I see two ways to process that request:

The Builder sees an opportunity for a script, an API call, or a Terraform module. They want to automate the truth.

The Reviewer sees a need for a ticket, a spreadsheet, or a screenshot. They want to archive a moment.

And that's the Frustration in "Frustration Engine"

This engine is fueled by a translation error. We force builders to speak the "language of evidence" (screenshots and spreadsheets) instead of their native "language of engineering" (code and logs).

The frustration isn't just the manual labor; it’s the realization that the message will never land because the person across the table doesn't speak the language of the work...

Their hands are just too clean.

If you've ever wondered why your engineering teams avoid dealing with your compliance teams... well, now you know.

A 🌶️ Spicy Take: Hands Get Cleaner Over Time

Just like we discussed back in "Do You Even Belong in Tech Anymore?", I believe that the farther you are from the "dirt" of the work, the less qualified you are to design the process for it. It's not a matter of intelligence, but of firsthand experience.

What's scary is that you can't just "bank" this experience forever, it expires. Someone who hasn't had dirt on their hands for 10 years is no more qualified than someone who has never done it before. If you don't continually use it, you lose it.

Yes, that means that even once you've been promoted to "Senior Regional Associate Vice President and Grand High Llama of the Poobahs"... if you don't continually put in time doing the work yourself, you're becoming less and less useful to the organization. Someone who ran a food truck in 1995 didn't have access to infrared thermometers or modern POS integrations. They are trying to solve modern problems with a 30-year-old toolkit. They haven't kept up... and that makes their perspective obsolete.

Now I want you to realize I'm not advocating that you micromanage, or that you need to keep on being the #1 developer in the organization after becoming VP. I'm just asking you to keep your hands on the keyboard occasionally so you remember what it feels like.

Final Notes

Don't just read this as a rant of a curmudgeonly engineer. Read it as a mental blueprint for how you interact with the engineering team in your organization... I'm hoping that you'll develop some curiosity and get your hands dirty alongside us! I know you probably think "well I'm not super technical, I could never code an application!"...

I'm here to tell you that you're wrong. Try out Season 5 of The Adventures of Blink for a quick guided tour of how to build something!

And the next time you set out to design a compliance process: are you designing a safer grill, or just requiring more pictures of tacos?