DEV Community: Ben Link

The Adventures of Blink S6e7: Security Response [NIST 800-53 CM(3)]

Ben Link — Thu, 15 Oct 2026 11:30:00 +0000

Hey friends,

Today on The Adventures of Blink, I'd like to know... How do you handle unauthorized security changes without crashing your production environment?

In Season 6, Episode 7 of The Adventures of Blink, we dive into Automated Security Response: moving away from the "shut everything down" knee-jerk reaction and moving toward a resilient, self-healing infrastructure.

Discover how pairing GitOps (Terraform, ArgoCD, Kubernetes) with automated compliance controls lets you detect baseline drift, auto-remediate unauthorized changes in seconds, and stay audit-ready without destroying system availability. Avoid "The Tarkin Effect" and learn how developer and compliance teams can build a true continuous security immune system!

The Adventures of Blink S6e6: Won't Someone Think of Security? [NIST 800-53 CM(3)]

Ben Link — Thu, 08 Oct 2026 04:00:00 +0000

Hey friends,

Are Change Advisory Boards (CAB) and manual security sign-offs slowing down your software deployments? In Season 6, Episode 6 of The Adventures of Blink, we dive into NIST SP 800-53 Control CM-3 (Enhancement 4)... Security and Privacy Representation... and demonstrate how to replace slow, manual approval meetings with automated Policy-as-Code.

Learn how to empower your engineering team with shift-left security guardrails while keeping your compliance officers and auditors happy with automated, tamper-proof proof!

The Adventures of Blink S6e5: Automation [NIST 800-53 CM(3)]

Ben Link — Thu, 01 Oct 2026 11:30:00 +0000

Hey friends! Stop wasting time collecting compliance screenshots! In Season 6, Episode 5 of The Adventures of Blink, we dive deep into NIST SP 800-53 CM-3(3): Automated Mechanism Deployment. While the control statement seems short and straightforward, organizations consistently fail by ignoring the supplemental guidance on data aggregation, alerting, and automated dashboards.

Blink challenges both sides of the aisle in this episode: calling out compliance teams for demanding manual configuration spreadsheets, and challenging developers to give up their "3 AM admin rights" to achieve true GitOps and configuration-drift security. Learn exactly how to translate modern engineering pipelines into audit-ready language that will make your next compliance assessment a breeze.

Remember to 👍🏻, 💬, and subscribe so that we can keep the conversation going and learn together!

The Adventures of Blink S6e4: Testing and Validation [NIST 800-53 CM(3)]

Ben Link — Thu, 24 Sep 2026 11:05:00 +0000

Hey friends!

Stop overcomplicating NIST SP 800-53 compliance! In today's episode, we break down CM-3(2): Testing, Validation, and Documenting Changes. Compliance teams often turn this straightforward control into an operational nightmare, demanding massive staging environments or manual post-implementation sign-offs.

Blink covers the 3 biggest myths surrounding this enhancement, dives into the true cost center of compliance vs. security, and shows you how to implement it correctly using CI/CD pipelines, risk-based tiering, and Git-driven documentation as code.

If this video helps you bridge the gap between engineering and compliance, make sure to LIKE, SUBSCRIBE, and hit the NOTIFICATION BELL so you don't miss next week's episode!

The Adventures of Blink S6e3: The First Enhancement [NIST 800-53 CM(3)]

Ben Link — Thu, 17 Sep 2026 11:29:00 +0000

Hey friends! Today on The Adventures of Blink we're continuing our efforts to repair the relationship between Engineering and Governance as we explore the first Enhancement to NIST 800-53 CM-3. The name of the game today is AUTOMATION.

Do you think "Compliance" means filling out an endless 25-field enterprise ticketing form and waiting for a weekly CAB meeting? Think again. We'll use a little empathy for the Developer Experience as the basis for a new look at our Change Management process that gives us even BETTER audit posture than the Change Advisory Board Meetings while actually delivering requirements that Software Engineers will be happy to fulfill.

...Sounds pretty farfetched? Click below and see how it works! 😉

Remember to 👍🏻, 💬, and subscribe so that we can keep the conversation going and learn together!

The Adventures of Blink S6e2: The Base Control [NIST 800-53 CM(3)]

Ben Link — Thu, 10 Sep 2026 11:30:00 +0000

Hey friends! Today on The Adventures of Blink, we're going to tackle the base control from NIST 800-53 CM-3... on our journey toward a better relationship between Engineering and Compliance teams!

CM-3 comprises a base control and 8 enhancements - today we'll address the base control, and upcoming episodes will dig into each enhancement.

In this episode, we'll explore the concept of a Baseline (well, two different unrelated concepts... 'cause THAT's not confusing... 🙃) and follow this basic format for building a bridge between our teams:

Read the control.
Look at how it's been misinterpreted in the past.
Explore a Developer-friendly means of meeting the control.

If you're a software engineer, you're going to learn how to communicate with "those Compliance folks". If you're "those Compliance folks"... I think you'll be surprised with just how deeply your engineering team actually cares about the stuff you're worried about.

Remember to 👍🏻, 💬, and subscribe... I love having you fellow adventurers on this journey with me and I want to open up dialogue!

The Adventures of Blink S6e1: The Audit [NIST 800-53 CM(3)]

Ben Link — Thu, 03 Sep 2026 11:27:50 +0000

Hey friends, welcome to SEASON 6! We're kicking off this season's Youtube videos on a journey we've been building up to for the past few weeks! We are going to tackle the dreaded beast of Compliance by examining NIST 800-53 CM-3: Change Management!

We've spent years - maybe even decades, at this point - avoiding each other. Devs think that Compliance work is "beneath them". Auditors think developers don't care about safety. They're both only half-right, and this talking past each other ends NOW.

While we're picking a specific set of controls to examine, the real goal of this season is to start thinking about Compliance work differently:

Governance folks need to understand that the ways they've tried to achieve their goals are unsustainable.
Software Engineers need to understand that Governance isn't the Bad Guy.

So even if this particular control isn't something your organization uses, I want you to focus on the APPROACH. You can adapt this to whatever set of controls your organization uses!

Leave me a 👍🏻 or a 💬, subscribe so you won't miss any episodes along the way. It's going to be a good season!

Season 6 Prologue: Let's Be The People With Dirty Hands

Ben Link — Thu, 27 Aug 2026 11:41:34 +0000

Bonus Content this week! Before we get into today’s topic, check out this video I did for my friends over at the DevOps Society!

Next week, Season 6 of The Adventures of Blink kicks off. This season's build is a continuation of what we've been talking about for the past few weeks.

We talked about the "Why".

We talked about the "How".

Now it's time for the "What".

Our mission: Getting our Hands Dirty with Compliance and Governance.

It's easy to create a blog and write a hit piece on how the whole concept of Governance sucks. It's easy to complain about how they get in the way.

But nothing about that actually makes life better.

Next week, we start doing what does make things better: we dig in and start solving the problem. Season 6 will be an adventure where we take a commonly-used audit control... NIST 800-53, CM-3... and we do all the stuff we've talked about for the past few weeks.

We're going to read the control, take it apart, and understand its intent.
We're going to talk about common mistakes and pitfalls in applying the control.
We're going to re-interpret the control from a Developer's perspective.

To My Developer Audience

If you're a developer, you'll know how these controls work, and even if your Governance team uses a different set of controls than the one we're covering, you'll have a template for the way to have the conversation with them.

To My Governance / Auditor Audience

If you're on the compliance team, you'll get to hear a developer's perspective on what you do. We'll walk through a high-level look at how you can assure compliance without introducing friction.

Remember, People with Clean Hands are Wrong

Personally, I've lived this world of talking past each other for far too long. That ends NOW... I'm looking to start a genuine conversation that leads to a win-win situation. So as you tune in, I'm expecting you to be part of a dialogue! Make sure you come prepared to comment, to share your perspectives, to be part of a conversation.

Tune in next week, and be ready: we're going to get in the dirt together.

Re-Interpreting the Law

Ben Link — Thu, 20 Aug 2026 11:36:00 +0000

If you've been following The Adventures of Blink this summer, you've likely noticed a pattern developing as we approach Season 6. The past few posts have explored a deep organizational disconnect that plagues many businesses: namely, that Compliance and Governance is completely divorced from Engineering teams.

One of the core causes of this schism is that the two sides interpret things differently. Additionally, neither side has solid communications with the other, so the perspectives are never shared, except under duress.

I've seen this firsthand: someone from Ops shows up at a developer forum and proudly announces that "we've solved the entirety of Change Management": all developers just have to fill out these 3 forms every time they want to go to production, and attend the CAB meeting a week beforehand. Piece of cake, right? How awesome is that!

...The developers declare war. The "roundtable session" very nearly comes to physical blows.

Afterward, when the two sides have been broken up and returned to their own spaces, the conversation goes something like this:

Unison: "Can you believe those idiots?"

Dev: "It's like their goal is to ensure that nothing goes to Production, ever again!"

Ops: "How could they be so unreasonable about The Process? Those divas..."

Unison: "We're just trying to protect the company..."

These Parallel Conversations Show Us There's Hope

Notice the final line: Both sides want the same thing. They have aligned their goals, but not their methods... so half the battle is already won!

So... what's left to fix?

The Remaining Problem

Both teams want their organization to be successful (we all like getting paid!)
Both teams know that chaos in software engineering is a Bad Thing®. (Except for Chaos Monkeys, but... that's a blog post for another day! 😏)
Both teams know that auditors want to see a Process that is defined and followed.
(This may surprise you, but...) Neither team wants to sidestep the process.

The disconnect that needs to be solved comes down to Interpretation.

Audit Controls Are Always Up For Interpretation

Developers are used to things being airtight. We get requirements from our customer, spelled out with specifics. Our User Stories have Acceptance Criteria, and can't be closed until we meet them. Most of our life is spent dealing with the deterministic.

Audit Controls, though? They're written with a little vagueness. This is necessary because they have to be applied by many organizations with different tech stacks and different team structures. The statements made in the control are therefore generic, purposefully.

And that's the first place that the conversation falls apart

Governance teams (whose hands are probably "clean", technologically speaking) pore over these controls and craft an interpretation based on their knowledge, skills, and experience. But that knowledge, skills, and experience doesn't actually contain software development work... and the interpretation they create doesn't include optimizations for that world.

Developer teams, who have historically avoided compliance work because it wasn't directly tied to customer feature requests, feel ambushed when the Governance team shows up with their interpretation. Maybe they were asked to participate long, long ago and ignored it. Maybe they weren't asked. It's hard to say what happened, specifically- but either way, an interpretation of the Law shows up on the doorstep, already approved and rubber-stamped and implemented. But because it was created without developer context, it's clunky. It doesn't fit with their workflow. It creates friction for developers.

If it wasn't patently obvious, the real solution here is Collaborative Interpretation... both sides work together to map out the interpretation of the Law so that we can move forward. But... we gotta figure out how to do that without throwing fists.

Secret Sauce: Play to the Strengths

Governance is good at the "What". They can dissect the controls and get to the heart of what's important in them.

Development is good at the "How". They were born to innovate technical automation solutions to all sorts of mundane tasks.

So that's the trick: let the Governance side of the house figure out the intent of the controls, and work on communicating that to the Dev teams. Then watch as the Developer Magic figures out how to do that with automation.

In short? Audit controls aren't a mandate to be handed down to the Engineering org. They're a puzzle that we have to solve together!

It's going to take Trust

You've got two departments who speak different languages. Bridging this gap is going to require to you extend some trust to each other:

Devs need to understand that Governance is fighting for them. These folks sit with annoying, pedantic, humorless auditors so you don't have to. Show them a little gratitude... and in particular, arm them with the information it takes to be successful.
Governance needs to understand that Devs crave efficiency. Developers are used to creating efficient solutions to complex problems. Let them show you how to make the entire audit prep automatic... and continuous. Teach them the intent and extend a little trust, and they'll exceed your expectations.

Some Ground Rules for Teamwork

If your solution for a control involves a meeting, a form, or a spreadsheet, you're setting yourself up to feel the full ire of the Development organization. Agree not to have these items in your process except as a last resort.
Development is probably going to want "Compliance as Code". Do yourself a favor, follow that link and realize that it's not an outlandish concept... it's widely accepted. Hear each other out.
Don't encroach on each other's specialty. Remember: Governance == "Intent", Development == "Implementation". Approach conversations with Curiosity... does the Dev team understand the intent? Does Governance understand the automation plan?
Everyone comes prepared. The problem to be solved is an Audit Control... it's a known quantity. Governance can't move the goalposts by surprising everybody with a new control, and Development can't dredge up all the times they've felt ignored in the past. Come with focus, do the homework, be ready to solve a puzzle together.
The solution isn't "done" until both sides' goals are met. Compliance is a necessity; the auditors aren't going away. Development can't afford a bunch of friction in their daily work; revenues depend on it. You have to solve both sides of the equation, or you've solved nothing.

Thinking Win - Win

What does it look like for everyone to win?

Auditors get their "proof" without having to chase people down.

Developers go back to doing what they love: building features without feeling like the compliance department is the "Department of No."

The Business becomes faster, safer, and more resilient.

Conclusion: Realigning the Mission

Compliance and Development aren't supposed to be enemies, but they've allowed themselves to become so because they didn't stop to translate for each other. Without this critical partnership, the Law was misinterpreted, and the organization suffers.

Today, I'm challenging you to have some courage: the courage to listen, to empathize, and to forge a path together that helps us both achieve.

If you're brave enough... stick around. The Adventures of Blink is going to show you how!

The Tragedy of the Clean-Handed Auditor

Ben Link — Thu, 13 Aug 2026 11:15:00 +0000

"I could save them if they'd only listen..."

Hey, you. Yeah, you: the compliance or governance person who stumbled across this blog. Who isn't part of the "usual" audience for an Adventure of Blink, but somehow the algorithms aligned to serve this up to you today. Today's post is just for you. I'm not going to speak developer-speak today... it's just you and me, chatting in a safe space.

I want you to know that I SEE YOU.

I know your pain. I know that you're doing everything you can to keep the company safe and secure and protected. That you carry the burden of dealing with those auditors. That their pedantry and desire to find fault shapes how you have to approach everything in the organization.

I know that you're fighting the Good Fight. You want the organization to succeed, and keeping those nitpicky auditors away is how you can help us reach that success.

I want that too.

Let's talk about the Disconnect

You know it's there. I know it's there. We haven't seen eye-to-eye for a long time on how to achieve safety and compliance while still delivering for our customers.

Your perspective is that I'm a cowboy coder who hates all forms of authority; I'm reckless and impatient and generally unconcerned with safety as long as I can sling things into production.

My perspective is that you're a Vogon, who wouldn’t even lift a finger to save your own grandmother from the Ravenous Bugblatter Beast of Traal without orders signed in triplicate, sent in, sent back, queried, lost, found, subjected to public inquiry, lost again, and finally buried in soft peat for three months and recycled as firelighters. (Before you get offended by this, take a minute to realize that it's hyperbole... Look it up 😉. It's also a quote from Douglas Adams, and if you didn't recognize it you need to read "The Hitchhiker's Guide to the Galaxy", you uncultured swine. 🐷)

There. We got that out of the way. Let's talk about the Tragedy of the Clean-Handed Auditor.

What You Do

Your job, as you would generally describe it, is to secure the environment against threats. You do this by relying on the latest Security Audit Controls, published by highly respected bodies who have declared themselves the standard for, well... standards.

You spend your days reviewing these Controls and mapping them to documented Processes within the organization. The general thinking is that if we can adequately explain how our Processes meet all of these Controls, we will be certified "Secure and Compliant" to these bodies' Official Standards.

It's a fine goal, to be sure.

Today, though, I'm here to tell you why you've got it all wrong.

Screenshots Don't Create Security

"Clean-Handed" Auditors have fallen in love with a proxy for reality, to the point of completely ignoring that reality.

Imagine being on an airplane where the pilot spends the whole flight looking at his checklist instead of, well... you know, flying the plane.

Your screenshot of a settings page isn't a secure configuration. It's not "proof" of anything, except that I know what settings page you're talking about. And no matter how complex your documentation process is, that screenshot isn't the configuration... it's just a moment in time, something whose expiration date is the second after the timestamp on the image.

Here's the kicker though: getting you that screenshot (and a bunch more, let's face it you're not going to just ask me for one, are you? 😏) is going to eat into a significant portion of my workday. I don't have time to make my system secure because I'm busy "proving" it with screenshots and signed PDFs... you know, the ones that we talked about in the last paragraph that DON'T actually prove anything!

Your developer teams use the term "Security Theater" for this. We know it isn't actually making us secure, but we have to do it to satisfy you. It's a major part of why we're so disconnected.

Your Clean Hands Are Problematic

There's a better-than-50% chance that you would say something like this:

"I'm not a developer"
"I'm not super-technical"
"I focus on the Process, not the Implementation"

I'm not suggesting that you have to become a full-time developer. But I DO think you need to realize that refusing to touch the work is causing you to fail at the very thing you're trying hardest to achieve: Securing the System.

Stay With Me, We're Going Somewhere With This

Friend... I don't blame you. The system taught you that it was ok to do it this way. It was designed by people who didn't know the pain they were causing, either.

I think there's a better way. I think we can find it together.

And I'm asking you to follow along as we figure out how. Next week we're going to talk about the beginning of that "how", and then set ourselves up with a challenge that leads us right into Season 6.

See you next week, my friend. We're about to change the world!

Embrace the Ick

Ben Link — Thu, 06 Aug 2026 11:30:00 +0000

I have several friends who are U.S. Marines. Frequently in conversation with them, I've heard them refer to "the Suck". The Suck, as they call it, is a label for anything undesirable or unpleasant, something they have to do but don't necessarily want to do. It goes something like this:

"Yeah, I broke my collarbone in a motorcycle accident and I haven't been to the gym in 3 months. Gotta embrace the Suck before I lose this 6-pack."

"I just got deployment orders, I'm leaving next Thursday. Heading back to the Suck."

While a software engineer isn't likely to face anything with quite as much "Suck" as deploying to a combat zone, I think we do have a similar reaction to certain tasks... one of them being Compliance work. I'd like to call this "the Ick".

The Developer who enjoys working on Compliance or Audit Evidence-gathering is a pretty rare unicorn... Most of us treat it as a distraction from work rather than understanding that in a regulated environment, it IS the work.

What's more, the Ick is invasive: If you don't control the "Ick", the "Ick" will control you.

How We Got the Ick

Long ago, when the company was either smaller or less-regulated (or maybe both), audits were rare enough that they didn't disrupt the development teams' work. But somewhere along the way, the time between audits narrowed (and/or the complexity of the requirements increased) and we started to feel the effects. Management didn't like the lost productivity of the dev teams, and they took it upon themselves to solve the problem... by carving out organizational space to deal with audits.

Once an "audit team" existed, developers interpreted compliance work as "less-desirable", or "not worth their time". Gradually they were conditioned to ignore -- and then to avoid -- the audit requests. "Let the Compliance Team figure that out, I'm not getting involved."

The Ick began.

But they were all of them deceived...

Every time a developer thought like that, every time they neglected the audit requests... they abdicated control of their environment to someone who, as we talked about last week, had clean hands.

And those folks, well-meaning but uninformed, did the best they could to make audit decisions without the experience of being a software engineer. Their desire is to achieve security through control... set up enough rules and restrictions, lock all the doors, and...

If something escapes control? Fight back the one way we know how: paperwork. Build a process, schedule a meeting, add another line to the spreadsheet... lock down the change so that it can be subdued.

By the time the developers realized what had happened, they were bound by Security Theater: draconian rules and policies that did little to keep the organization secure while making it harder to keep the organization successful. And when anything unexpected occurs, the noose tightens just a little more, until we've strangled the organization completely in the name of keeping it safe.

Vulcan Proverbs

This problem can only be solved if developers get directly, deeply involved in the audit compliance process again. No one else in the organization has firsthand knowledge of how the organization actually delivers its work. But they've been conditioned for years now to think of compliance work as "undesirable". We have to change the mindset... to "Embrace the Ick", if you will... so that when the new regulation rolls out, it can be addressed in a way that satisfies all of us.

Embracing the Ick: Some Practical Steps

How can Developers "embrace the Ick"? What specifically can we do? Let's look at a few ideas:

Learn the Language of Compliance

This is table-stakes. Compliance Controls are just words, y'all. They might seem intimidating as they have all these fancy "family names" like CM-3 and RA-5 and other things that sound like Star Wars Droid Characters... but if you crack those open, inside you'll just find WORDS. Read them. Understand what they're asking for. Ask your favorite AI to summarize them like you're 5. But you should be fully acquainted with the contents of all the controls you're bound to follow in your organization.

...That means getting someone in Compliance to tell you which controls are in your standards. Go track them down and ask them. If they survive the heart attack of a developer wanting to know more about their world, I'm sure they can put together a comprehensive list (probably in a spreadsheet 🙄) for you to keep as a reference.

Take your time to digest

Yes, I know your goal is to replace those annoying compliance officers with very small shell scripts. I'm not even saying that's a bad goal to have. But you're going to address a system that has spent years evolving into the beast that's consumed so many good dev cycles.

You should be methodical about your process here:

Read and understand the goal of the control.
Imagine automatic ways to achieve it.
THEN imagine ways that your automation can be poked full of holes.

Assume the ride will be rough

You'll need to expect resistance to your automation suggestions... just as you've spent a long time developing mistrust for auditors who don't know an npm install from a helm chart, you're communicating with people who have spent years dealing with developers who treated them like 💩 instead of explaining themselves in ways that the layman could understand.

It's almost like... a little empathy would be valuable. Crazy, huh?

The Developer's Mental Shift

The real hurdle for the Developer is realizing that Audit Evidence is just automated testing for adults. Just like you "prove to a linter that your code won't break the build", you can "prove to an auditor that your deployment won't break the company". When you "Embrace the Ick," you stop providing "screenshots of a ticket" and start actually providing real evidence. You just need to show them how your real evidence is an improvement over the screenshot!

Take Your Trip to China

Once you speak the language and have the empathy, you can do what no one else can: Negotiate.

Instead of the Ick's manual "Change Approval Board"?
Offer a signed GitHub Action that enforces peer review.

Instead of the "quarterly manual access review"?
Offer an automated daily report from your Identity Provider.

You don't "go to China" to surrender; you go to sign a treaty that replaces their manual shackles with your automated gates. And when they're automated, I guarantee that you'll exceed their manual process's resolution.

You have a manual API key rotation rule of 90 days? Our script can rotate them weekly. Or even daily. --See what I mean? 😏

Conclusion

We’ve spent a decade trying to "shift left" on security and testing... but now it’s time we shift left on Sovereignty. If we continue to treat the regulatory requirements of our industry as "someone else’s problem," we are consenting to live in a world built by people who don't understand our craft. We are effectively choosing to be governed by the least informed people in the room.

The "Ick" isn't going away. The regulations aren't getting simpler. But the "Sovereign Engineer" knows that the only way to maintain the speed and freedom we love is to own the boring stuff ourselves, while ensuring that we bring our compliance folks along with us as we automate it.

Don't just survive it... OWN the Ick. Build the system so well that the audit becomes the easiest part of your week.

After all, if you don't define the controls, the controls will define you.

The Frustration Engine

Ben Link — Thu, 30 Jul 2026 11:45:00 +0000

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?