DEV Community: Ben Link

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?

The Architecture of Empathy

Ben Link — Thu, 23 Jul 2026 11:16:00 +0000

I walked into the "Design Meeting" feeling woefully... under-titled, if that's a Thing. Around the table sat a Senior Architect, 3 Architects, the Head of Analytics, and two Principal Engineers. The goal: define the new Compliance Tool we were going to build to automate all the paperwork.

Captain, we're experiencing chroniton waves, or temporal flux, or... some other thing

We're going to look at this through a Temporal Fracture (or something like that, the kind of Science-y thing that drives the plot of a Star Trek episode): We're going to see this as a focal point where two timelines emerge, and see what we can learn from the different choices.

Timeline 1: The Way We've Always Done It

Immediately, the conversation took off. With all that architectural knowledge around the table, the design took shape. One of the architects began drawing up the diagram as we talked, and two full hours later, we had built SO. MUCH. STUFF. (Well, at least on paper!). Our platform design had everything in it... even a couple kitchen sinks.

The diagrams flew through the approval process because everyone in the whole organization was champing at the bit to get access to the new platform because one look at the design convinced everyone it was going to save them so much time and effort. We spun up the implementation project, which was estimated to take six months.

EIGHT months later, we implemented... with tons of bells and whistles. We had... no users.

Eight months in technology might as well be eternity. Everyone was so excited for the design... but those six planned implementation months meant that our users... our customers... our colleagues... were all just standing in the queue, suffering. And then, we were late delivering. People just got tired of waiting for the big grandiose vision to come to fruition.

We got the big design approved and built, but we lost all the momentum because no one saw anything until we had everything.

Timeline 2: A Little Bit of Empathy

Immediately, the conversation took off. We started the journey by asking a simple question: what could we deliver immediately to help our teams improve their footing?

Once we knew the first item on the page, we began iterating - evolving our plan, step by step, with the goal of gradually rolling out more features that could be put to immediate use by the dev teams.

The first sprint ended with a rousing success. It was a small feature delivered into production, but it helped one team save a couple hours.

The second and third sprints delivered progressively more features that addressed the needs of several different teams, such that by the end of the first two months, we had a growing user base who was getting real benefit from the tool.

What's more, we had feedback. That user base was grateful for what we delivered, but it spawned more ideas. We had tons of cool feature requests to prioritize and when we got the hang of prioritizing them, we started delivering even MORE value each sprint. We ended up not actually building some of what we had originally roadmapped because we replaced those features with things that our users wanted even more.

Pick your Timeline

You might be tempted to say "well this is a conversation about The Waterfall versus Agile" or "this is about the dangers of over-designing things".

Both of those are valid observations... but they're not what separates the two timelines from each other. Do you see where the divergence started?

Ego versus Empathy.

In the first timeline, "we designed" because "we knew things". We made assumptions, and we built in a vacuum, with no regard for the fact that our tool was supposed to alleviate user pain. "They'll have to wait until we finish".

In the second timeline, "we designed", but then we held those designs loosely. We focused on delivering something useful to someone, who could give us feedback and help us more successfully alleviate their pain. We wrapped every design decision in the perspective of the person who would use the system. We even abandoned our plans in favor of things that they asked us for.

Hang on friends, I'm going somewhere with this

Every kind of design:

Team/Organizational Structures
Process Maps
Tooling Implementation Choices
Audit Control Interpretations (cough cough, this becomes important later... 😏)

Literally every one of these things can be built with Ego... or Empathy. Your role as a software engineer is to empathize with the people who will use what you build. Thus it follows that you should measure your success in terms of how much friction you remove for others.

That's right, you heard it here first...

Developer Experience is the foundation of successful design.

The next few weeks are going to explore this from a practical perspective. Tune in next week as we talk about something I've observed that needs a dose of Empathy added!

Psychological Safety Should Be Your Performance Metric

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

I once was an engineer in a company that had an Ironclad Process. Everything... and when I say that, I know you're just thinking "well, lots of things" but I really mean Every thing... was documented in The Process Manual. There were pages upon pages of diagrams and charts and walls of prose in lengths that would make War and Peace feel like a ChatGPT "summarize this" prompt.

These folks knew how to codify things.

You might think that the organization was running like a well-oiled machine, and peak efficiency had been reached.

But you'd be wrong.

If anything, the organization faced more than average chaos. There was a culture of fear: you didn't want to be the one responsible for an outage. You definitely didn't want to be the one responsible if your team missed any of the paperwork required by The Process! Throughout the organization, there was a deep desire to "craft the story correctly"... presenting the data from any situation to senior leadership wasn't about speaking plainly and communicating effectively, it was focused on massaging the narrative to protect egos and reputations.

The dashboard lights were green, but the building was on fire.

The problem isn't that the process has problems... or even that so many rules exist... but that it's measured on Compliance over Candor. When we're not safe to speak freely about problems, we can never get to the point where they can be fixed.

The Symptom: Cargo Cultist Compliance

Part of the problem with having The Process codified in such detail? Following it. When everything has to be held to "the standard", you sort of end up with two choices:

Define your standard vaguely (which we'd never allow... that's not secure!)
Define your standard with one or two systems in mind, and then make all the other systems and teams fit their square pegs in the round hole you just made.

Another wrinkle in this situation is something we talked about in People Without Dirty Hands Are Wrong: The Process isn't something that's maintained by the people who do the work of developing software, it's assigned to people who often think of themselves as "non-Technical" folks who read security publications and make decisions about how Developer teams will work.

You see what we created? A Cargo Cult.

This cult learned early on that they can acquire support from leadership by fearmongering:

WE HAVE A MAJOR COMPLIANCE ISSUE THAT THREATENS THE FUTURE OF THE COMPANY!!!

And they became good at doing the things that looked like Good Compliance, but without the substance of actually improving the company's security posture... Security Theater.

It worked, because the lack of psychological safety meant you couldn't question why it had to be this way. A little vigorous hand-waving, and a stack of papers from whatever NIST publication was in the news this week, and anyone who asked "why" was labeled a Security Threat.

The Cause: Trust Issues

Let's take a step back and think about the effects of these choices.

The organization becomes accusatory. When bad things happen, we rush to defend our team from becoming the scapegoat.
Basic behavioral conditioning follows; engineers learn to hide the truth because there's too much Trust Debt accrued.
Auditors uncover the cracks, but the engineers work hard to stay ahead of them. Trust erodes even more as Audit becomes a game of cat-and-mouse rather than an attempt to work together to keep the company positioned for success.
Blind spots in the audit grow. The organization has to continually increase their spending on audits that are less and less effective because the lack of psychological safety means engineers are working harder than ever to avoid interacting with Compliance.

The Cost: Performance Tanks While Everyone Looks Busier Than Ever

Do you see it yet? Your devs work extra hard to tiptoe around the compliance hurdles. Your compliance team works extra hard to add new hurdles. The whole organization slows down while everyone in the organization feels like there's never enough time to actually get any work done.

All because we can't trust each other... because there's no safety between us.

The only way out is for a leader to do something radical: Admit a major knowledge gap or a past failure. But that can't happen because of the lack of psychological safety... even leaders are subject to the pressure that comes from its absence.

The Fix: Psychological Safety

Everyone's incentivized to hide the truth, but we need the truth more than ever. Here are some practical tips for encouraging safety with your team:

Leadership Has To Model It

This isn't a One-and-Done kind of thing... leaders have to start modeling the vulnerability that cultivates trust.

Yeah, I know. That means setting aside egos and admitting "I don't know" or "I was wrong". Nothing awesome was ever easy... but this can be the moment...

Do you have the courage?

Intentionally Practice Accepting Radical Feedback

Ask for feedback, but don't react. Thank them for sharing, work on it... but stop trying to justify why they don't understand.

We are really bad at this, and not just in work relationships! Listening to a critique is one of the hardest things anyone will have to do... and the way we make ourselves feel better in the moment (justifying and rationalizing) actually prevents the critique from working.

Start Measuring Psychological Safety

This one could be tricky; there's no "safety meter" that you can look at to know how much trust there is in your team. But you can measure a related concept...

MTTR (Mean Time to Report, not Resolve). In a safe culture, the gap between a mistake and a report is minutes. In an unsafe culture, it’s days (or until an Audit stumbles upon it).

Blameless Postmortems. A team that feels safe will share details that the organization can learn from. A team that feels unsafe will work to spin the narrative.

Response to Candor. In a safe organization, the response is curiosity. In an unsafe one, you'll find defensiveness.

The Wrap-up: Thinking Backwards

Most leaders will default to a dispassionate sort of ideal. "We don't have the time to think about Psychological Safety, we just need people to get the work done. We have deadlines!!!

They completely miss that building that layer of trust and safety into the organization provides the foundation for velocity. If you aren't afraid to make mistakes, you'll try more stuff. You'll push harder and go faster.

Today, I'm asking you to take the time to set up some metrics that help you understand how safe it is to speak up on your team. I bet you find that when those metrics are aligned, your productivity metrics will improve too. 😉

Explain It To Me Like I'm... Well... Me, But Dumber

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

I once knew a guy who derived great pride from writing clever code...

All variable names were reduced to single characters because "long variable names slow me down".
Log messages were cryptic things like "a < 5" which required you to know why that mattered.
Zero comments. Zero READMEs. When I asked for documentation, he said "well just look in the main function and follow it from there".

He was absolutely wizard-speed at debugging his work... but literally no one else could help. I once had to fix a problem while he was on vacation - it took me 6 hours to decipher the messages so I could fix a 5-minute problem.

We All Do This (To Some Degree)

Oh, maybe we're not quite that extreme in your coding habits, but you and I often make a major assumption when we write code:

We assume that we're going to be at our best when we have to maintain it.

It's an incredibly improbable assumption, isn't it? I mean, sometimes we joke that the surest sign an application is "sentient" is that it breaks at the most inopportune moments: at 3 AM, or right before a demo. You know, at stressful moments when we might be distracted or sleep-deprived.

And THAT's Who We Should Write Code For

If we write our code to be clever, we're writing for our best self. We are making the assumption that we'll understand that cool trick when things break and we're trying to decipher and diagnose. We choose not to add comments around the logic, thinking "Well it's obvious why this is here"... but at 3:00 in the morning? It might not be.

Blink That's So 2021

I know you're probably thinking like an AI-bro right now. "Dude, I haven't written any code in 6 months, I just tell Claude to do it. Your sermon on Clean Code is outdated."

If you've followed the channel for any length of time, you know my answer to this. If you haven't, I suggest you go check out Requiem for a Species: How AI Destroys Humanity.

Even if AI doesn't end up destroying humanity, think about how you help Claude improve: you add context. Even if you've completely handed the keys over to the bot, you still owe it to yourself to write this stuff out.

The Wrap-up

At the end of the day, there are two types of developers:

Those who write code to show how smart they are.
Those who write code to show how much they respect their time.

The first guy is a "wizard" until the first bug hits. The second guy is the one who actually gets to enjoy his vacation.

Optimize for the 3:00 AM version of yourself. Everyone else—including the AI—will thank you.

Your Tech Stack Belongs On "Hoarders"

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

Remember when you first subscribed to Netflix? It was a different world back then...

You had a single subscription. It was easy to keep up with. It probably saved you a bunch of money if you cut the cable cord at the same time.

Fast forward only a few years, and you probably have subscriptions for streaming services that you've forgotten you had. (Go check your bank records now... I bet I just helped you save some money! 🙃)

I believe we'd find the same aura emanating from the average company's tooling purchases. There are probably a ton of tools invoicing you each month that you're not using.

Regaining Control

There's the obvious advice: stop the bleeding. Start cancelling subscriptions for tools that haven't been used lately. Add processes and approvals for purchases.

It's not going to help, though. We're just treating the symptom, we haven't addressed the underlying motivation for tool sprawl.

Why This Happens

We've talked about this a little bit previously here on The Adventures of Blink, but in the context of "Culture Change". I believe that this pile-up of tooling is the result of that Cultural Compartmentalization Paradox.

Management sees a cultural (DevEx) problem, and thinks that they can shortcut the solution by buying a tool. Think about it: Each one of those invoices is a historical document, providing evidence that someone passionately worked to convince leadership to buy in.

The problem is that they bought a technical solution to solve an interpersonal problem... and now it's in the graveyard, used by a tiny percentage of teams (if at all), getting paid out while not delivering the value we thought they would.

The Myth That More Is Better

This seems like a no-brainer, but organizations fall for it constantly.

We need an AI Feature. Friend, it's probably going to hurt when I say this, but I mean it with love: You likely don't. This is a hype cycle, and right now the sales and marketing pressures have never been higher. Consider factors like your team's capacity and look around for higher-ROI work first.
Adding this tool will improve our environment. It might... but is it worth the added complexity?
We just need a bigger Roadmap / Backlog. Organizations love to fall into this trap. Annual budgeting practices (implemented that way because Accounting prefers it) lead us to believe we need to plan much farther into the future than we actually can.

The Courage to Delete

In a similar vein, we thought we'd fully dispelled the myth that "Lines of Code Produced" was some sort of valid productivity metric, but the Slop Cannon approach to development work has resurrected it as some kind of badge of honor.

It's not just about lines of code, either: Architects produce a "Reference Architecture" to solve a problem, and then apply it... often in cases where it's overkill. Every single utility app in your company doesn't need a full observability implementation within it, but I bet there are "official designs" in your org that recommend it!

That's a problem that I'd sum up like this:

Simplicity is a Prerequisite for Security

When something is overengineered, it increases the attack surface. Now you have extra work to secure and protect, and no real additional value gained by doing so. (Side Quest: Think about the sheer volume of code that AI is producing every time you fire that slop cannon. From your security team's perspective, that's a massive amount of attack surface added!)

The Health Inspector's Toll

Think of your architecture like a professional kitchen. If the counters are cluttered with gadgets you don't use and the pantry is overflowing with expired "innovative" ingredients, the kitchen is gross. When the Health Inspector (or in our world, the Auditor) shows up, they aren’t just "being annoying", they are reacting to the chaos you've allowed to fester.

You cannot secure what you do not understand, and you cannot understand a system that is buried under the weight of a thousand "shortcuts."

Wrapping up with a little perspective

I think it's worth noting that regaining control is an act of bravery. It takes zero courage to say "yes" to a new tool that promises to fix your culture, because everybody already wants to be on board with the next big thing... But it takes immense courage to stand up in a stakeholder meeting and suggest that you replace a microservice with a simple function.

It takes similar courage to admit that the "innovative" feature you championed six months ago is actually just technical slop that’s making your team slower and your surface area wider.

Your Challenge Today: Go look at your "menu."

Find one tool, one "standard" architectural requirement, or one abandoned service that is currently serving as nothing more than a historical monument to a cultural shortcut.

Delete it. Not because you're trying to save $50 a month, but because you're reclaiming the mental overhead required to actually build something that matters.

Simplicity is the foundation of Progress.

Taco Stand Engineering

Ben Link — Thu, 25 Jun 2026 11:35:00 +0000

Blink squinted at the diagram, full of tiny boxes and arrows and a color key that looked like one of those giant boxes of crayons he used to have when he was in kindergarten. Something about it seemed familiar, he just--

"Wait, we built something just like this 2 years ago, didn't we? The Burrito."

The Architect looked exasperated.

"No, Blink. This is a Crunchwrap™️. It has a tortilla, meat, cheese, and sauce."

Blink... blinked. (Ha, get it? 😏)

"What's changed?"

The Architect's exasperation grew, if that was even possible. He was very nearly literally beside himself.

"That was completely different. Tortilla, meat, sauce, and cheese. Honestly, Blink: some of us are building the future while you're over there ordering off the Value Menu."

Idea Laundering

Most of what we call "Architecting" looks a lot like Taco Bell: same core ingredients, rearranged to be "new menu items". Don't believe me?

Ingredients

Compute
Storage
Network
Data Structures

Menu Items

Microservices
Serverless
Event-driven
“Platforms”
"Agentic"

It's right there in front of you. Instead of inventing new ingredients, we're just endlessly recombining... folding the same ones differently and calling it innovation.

And That's Not a Bad Thing™️

Sometimes, recombination is a valuable step. It makes us evaluate whether things are needed in large quantities or small (or perhaps whether they're needed at all). It makes us "improve the packaging"... are we being judicious in our delivery? Sometimes the context of the business changes, and what used to work doesn't anymore.

To return to the analogy briefly, Taco Bell isn’t scamming you with the recombination process. It’s efficient. It’s scalable. It feeds a lot of people while keeping prices down.

And that's the story of most companies with their IT Departments. They aren't supposed to be inventing new ingredients, they're supposed to be delivering what their business needs them to do.

It Can Create Problems, Though

Taco Stand engineering becomes problematic when we allow it to distract us. Think about the "recombination" activities that occur in typical software development:

Endless redesigns
Renaming things to fit the latest Leadership Framework
Debating patterns and processes
Re-platforming for marginal gains
Chasing a Hype Cycle instead of addressing Business Value

We technologists are arguing about whether it’s a burrito or a Crunchwrap AND NOT REALIZING THAT THE KITCHEN IS ON FIRE.

The Billowing Smoke We Ignore

We'll have multiple design meetings to build out a better architecture diagram, or redefine service boundaries, or implement a new framework, or pontificate on "the right pattern"... but across the aisle, our development team contends with slow CI/CD pipelines, flaky tests, unclear ownership, poor observability, contentious and/or brittle local dev environments, and unreliable deployments.

Your diagram's arrows aligning with the box corners aren't going to make your bottom line go up by one penny... but that's where the time and attention gets spent, instead of fighting for a better Developer Experience.

In Taco Bell terms, your burrito isn't failing because of how it got folded. It's failing because you filled it with junk, but spent all your time and effort worrying about the folds.

Imagine for example a huge effort to turn a monolith into 50 microservices. If you don't fix the fundamental problems, you'll just end up with 50 slow builds instead of 1.

Better is Possible

A good architect isn't afraid to ignore the menu and remodel the kitchen sometimes.

What does that mean?

Faster feedback loops. Don't spend an ounce of energy building something that isn't the highest priority... which means you have to know what that highest priority IS... ALL THE TIME.
Reliable tests. You can only deliver as fast as you can validate. Your test suite is your very best friend. (interesting lesson here for you Agentic whiz-kids... the speed of writing code isn't as important as the speed of testing code...)
Clear interfaces. Boundaries should be well-defined, people should know what they're responsible for and what they're not.
Great developer experience. Do you want to spend your development cycles overcoming friction, or delivering value?

Making new menu items out of old ingredients isn't "improvement", it's "novelty". Making better ingredients means that every single menu item improves at once.

(Crunch)Wrapping it Up

A while back, we examined The Fundamentals... today, I want to leave you with a more pointed summary in the same vein:

Stop redesigning the menu. Go fix the kitchen.

The Winner of the AI-Pocalypse? The Full-Stack Generalist (But Probably Later Instead of Sooner)

Ben Link — Thu, 18 Jun 2026 11:10:00 +0000

We've been told since late 2022 that "within 6 months, we won't need software engineers anymore". I think that's half-right.

I also think it's just the AI flavor of an old Holy War.

Remember the Olden Days

Think wayyyyyyyyy back to... 2010. (I have children older than this, and that makes me feel a sense of existential dread 😱)

Businesses were weathering an economic downturn and trying to "do more with less".
We were starting to realize that deeply-specialized "Silos" were (at best) problematic and (at worst) causing harm to our productivity.
More powerful Javascript frameworks were becoming super-popular, and more "traditionally backend logic" was moving its way into the "traditionally design-only frontend".

This led to the rise of a concept called the "Full Stack Engineer" - someone who could generalize and interact easily with the development stack at multiple layers. Need some SQL? They can give you a passable version. Need to integrate with a vendor API? They've got you. Have a CSS bug that's causing the widget to be invisible only on Thursdays? They'll pair up and help you find it.

Half the tech community said that FullStack engineers were unicorns, that nobody could keep that much in their head at once. Half the community said that every software engineer should become FullStack if they wanted to survive the downturn with a job. Half the community (who apparently struggled with arithmetic on multiple fronts 🤔) advertised themselves on LinkedIn as FullStack Engineers with 20 years of ReactJS experience.

FullStackers: Plausible (but with a caveat)

In fancy management and corporate leadership courses, there's a popular concept of "Professionals of Certain Shapes".

There's the "I" shaped person, who has chosen to obsess over a single topic and dived deeply into it. They're not often super aware of other topics and disciplines, but they know their one thing inside and out.
There's the "T" shaped person, who knows a single topic very well but has basic general knowledge about several others. We tend to call them "generalists"... jacks of all trades, master of... well... one or less.
There's a "Comb" shaped person, who knows several topics very well while having a passing knowledge of many others. These tend to be your generalists with a little more career time, who have potentially moved around the organization a bit and held a few roles on different teams.

The more prolific HR folks probably have other shapes of people out there, but that feels to me like splitting hairs and these 3 shapes probably suffice for most of us to work with.

I'm of the opinion that the "FullStack Engineer" is just someone who's moved into the "T" or "Comb" shaped realm. I'm also of the opinion that anyone can become one of these shapes with curiosity and study time. It's not something reserved for the elite, so much as defined by the eliteness of people who do it.

Get to the Part Where They Survive the AIPocalyse, Blink

I know, I know -- I digress.

The common trait among all "T" and "Comb" shaped people is that they're adaptable. Generally, they started as "I" shaped people who knew a lot about something, and then they started to attend to things adjacent to their specialty.

They weren't experts in those other things, but they were curious about them. They got just good enough to solve the basic problems, and then lean on the experts when things got too deep.

Which Leads Me to AI

AI in the software development lifecycle is going to eat the "I" shaped people for breakfast. When you can give all the world's knowledge to a language model and let it answer questions, generate code samples, and sniff out bugs, an "I" shaped software engineer isn't really going to be needed. The value of that one language, of that one specific niche technology, is eliminated.

But you know what AI can't do? Understand its surroundings. Even as context windows get larger and inferences get faster and cheaper... people can out-think them any day of the week. I think one of the greatest human characteristics is the ability to solve a problem based on a completely different set of unrelated data that just happens to kinda pattern-match... like when Mr. Miyagi tells Daniel to "Paint the Fence", in an effort to help him learn Karate.

This happens to be a speciality of people who are good at... Adapting. When they immerse themselves in a new technology for the first time, everything seems weird and different. But instead of being confounded by it, they notice patterns of the same "shape" as other technologies that they do know well, and it helps them learn.

It's something the bots can't do. Bots need direct correlations, they need pre-training.

And That's Why The Generalists Will Win

If the hype about AI holds true (I don't believe it will, but let's game this out), The "I" shaped people are going to struggle because they're easy to replace with a model. Pre-train it on "technology X" and boom, they're done. The "T"s and "Comb"s on the other hand will be able to leverage their lateral-thinking advantage to survive.

If the hype falls apart, we're going to have a big need for those generalists. They're going to have to unravel a bunch of code, likely touching multiple technologies in the stack, and pay off tech debt along the way.

But it's gonna be a while

We probably have another year or two before we see the full effects of this AI stuff... which is rough if you're looking for work in tech right now. I'm sorry to be the bearer of bad news but it's gotta get a little bit worse before it gets better. If you can just hold on, though... and spend the time learning a few new technologies, you'll be in a really good place when the demand curve bends its way back in a favorable direction!

The Moral of the Story: Avoid Hype, Focus on Fundamentals

Yeah, you can try to replace all SaaS companies with a $200/month Claude Code subscription and maybe get-rich-quick. But you'll get better return on your investment if you spend that time, money, and effort on broadening your knowledgebase. Are you a coder? Learn a CI/CD stack. Are you a SysAdmin? Take a course in Python or Rust or Go or whatever language you'd like to play around with. Are you an AI bro? Make sure you know how to do all of the things you scream "AGENTICCCCCCCC" about, but with your WiFi turned off.

There are ultimately two kinds of technologists: those who enjoy the challenge of growing and learning, and those who are doing it all to hit a jackpot. I know which one I am... do you?

"It Works" Has Never Been Good Enough

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

It all started when the Senior Architect dropped by the daily standup. The team lead had the backlog up on the big screen and there was a story about code quality marked "behind schedule".

"What does that story mean?" the architect asked.

"We have the static analysis tool implemented in the CI/CD pipeline, but enforcement is turned off because the findings are going to take a long time to fix." They weren't lying... Cyclomatic complexity scores of 154 (when the target is 15) are scary, and there were at least 10 different modules with methods scoring that high. Test coverage was weak... maybe 40% when the goal was 80. Duplicated code was about 4-5x the allowed 3%.

The architect frowned. "We need to start enforcing ASAP. Things are never going to get better until we develop some discipline about what we push up."

So... they turned on enforcement. No PR could be merged unless it passed the scan.

You could hear the screaming from the next county

Less than a week later, one of the developers brought up a complaint at stand-up. "The new feature is ready, but the existing code's duplication percentage is preventing us from pushing it up. Can we change the allowed percentage of duplicated code?"

Why This Is a Slippery Slope

On the surface, the request to revisit the duplication percentage threshold seems harmless. Heck, it might even seem prudent. But the question that's being overlooked in this conversation belies a deeper issue:

Your architecture's wrong.

If you remember back to your college-level Computer Science courses, you heard some terms:

Polymorphism: The ability of an entity (like a function) to exist in many forms.
Inheritance: The ability of a new class to derive from an older class.

Code duplication occurs when you have identical blocks of code in multiple places. So if you're duplicating blocks of code, you're probably not implementing with an eye toward those core principles.

You have a design flaw, and the longer you let it linger the harder it will be to address it.

The Rules Are The Rules For A Reason

The story thus far is just about a developer asking to change the rules, not realizing there was a design flaw causing the scan to fail.

It betrays a dangerous assumption, one that many software professionals make too often:

It works, and that's good enough.

I can hear the arguments already: "But Blink, the point of writing software is to get it to work! Think about business outcomes!"

But really, y'all. Good design principles are necessary to make code maintainable. To increase its longevity.

Making something that works (but is of poor quality) is short-term thinking at its best. You'll the instant win, but without any thought to next quarter. The expression "cutting off your nose to spite your face" comes to mind.

And This Is What Freaks Me Out About Agentic Engineering

If there's any community who demonstrates its absolutely fanatical dedication to short-term thinking, it's the Agentic Coding community. We're currently hearing things like "Writing Code is over".

What they're not taking into account, though, is that we're living in an artificially deflated token economy. A $200/month Claude subscription is actually spending $5000/month in token costs, but those costs are being subsidized by investment money in order to set the proverbial hook. When the VC dollars dry up... you're going to have a mountain of code that "works", but is poorly architected and full of maintenance risk. And the cost of letting AI maintain it for you just went 10x.

...And having a Claude.md file that says "You are a Distinguished Engineer with 50 years of experience architecting VueJS applications" isn't going to save you. Knowing your architecture and having your hands directly on the code is what will.

People Without Dirty Hands Are Wrong

Ben Link — Thu, 04 Jun 2026 11:15:00 +0000

A Tale of Two Managers

Erin

Erin was a newly-promoted manager over a software engineering team. She had been hired 5 years ago as a junior developer and worked on 3 major projects in her time with the company - one of them a multi-year build that moved the company's flagship application to an altogether new stack, saving hundreds of thousands of dollars in licensing and infrastructure costs.

Once she was promoted to manager, the normal corporate leadership pressures took over and she of course had a ton of new responsibilities to learn... but within 6 months of her promotion, she was spending her lunchtime building her first AI application because she wanted to see how to use LLMs to find evidence in her mailbox and Slack history for filling out her team's performance reviews.

James

James joined the company 15 years ago as a sysadmin assigned to handle a special operating system audit being performed as part of trying to win a new contract. After that audit was completed and the contract was won, he was promoted to supervisor of "the Audit Team", which then formed the foundation of a Governance and Compliance organization. After several years as a supervisor he was offered a promotion to Manager of the organization.

As a Supervisor, James spent most of his time in meetings, coaching his Audit Team and providing meticulous attention to the details of changing audit controls. While he was the first to admit that he was "not technical at all anymore", he regularly went toe-to-toe with all of the Software Engineering Directors across the organization, ensuring that everyone in the organization followed every Audit Guideline to the letter. He was immensely proud of The Audit Handbook, a 1,400-page PDF that documented with laser-precision everything that Developer Teams were absolutely required to do to stay compliant.

The Epilogue of the Prologue

Erin's lunchtime experiment uncovers a need in the organization: to provide context for the glowing reviews she wants to give her team members. She talks about it with the engineers on her team, and they exchange ideas; they even possibly collaborate on it some! Through the excitement she generates, she's building relationship... and importantly, respect. Engineers love a manager who can "get in the weeds" in a helpful way, and Erin's experiment is keeping her technical skills sharp in a way that helps the organization. Her curiosity is infectious. While she knows she's not writing mission-critical code like her team members, her team comes to respect her because she can relate to their day-to-day struggles.

James, on the other hand, is building something different: DISTANCE. Every audit finding report, every mistake found across the organization... they all become a new Rule, or Checklist, or Procedure, added in perpetuity to the all-consuming Handbook. And as the Handbook grows, the distance between the Governance Documentation and Engineering Reality grows too.

You could sum it up like this: The more Governance Processes James creates, the less he actually understands the work he's "Governing".

Erin got closer to the work.
James built systems that kept him farther away from it.

Leaders Who Never Touch the Work Are Doomed to Misunderstand It

Think about it: Technology moves incredibly fast. The state-of-the-art systems we built 5 years ago are dinosaurs today. With that kind of half-life on knowledge, staying current requires effort. And just like the old "telephone game" we played when we were kids, every time the knowledge passes from one person to another without firsthand experience, errors multiply. In James's case, policies created far from execution accumulate friction.

And before you say "Hey Blink, your example is fictional and contrived and unrealistic"... answer a couple questions for me:

Has the person responsible for your CI/CD Pipeline policies actually run a build in the past 5 years?
Has the person delivering the work estimate for your project ever actually done the things they're estimating?

The farther you are from the work, the easier it is to be confident about things that aren’t true.

Good Leaders Have Dirt on Their Hands

Erin is a model manager because her curiosity shines through. But did you notice what she didn't do?

She wasn't pulling tasks off the team's board and doing them herself.
She wasn't micromanaging them to death.
She wasn't shirking her management duties in order to write production code all day long.

She picked a task that would be of benefit, but that wasn't in the critical path. It gave her the ability to touch the system, to feel the friction. This gives Erin a taste of the reality that her team faces every day. When she has to put on her manager hat and make decisions about how work gets done... she's built EMPATHY by experiencing the friction herself.

Most Companies Are Designed To Produce James (Accidentally or Otherwise)

They'd be loath to admit it, but... companies in general incentivize their management to "grow" in this way. Oh sure, while things are small and lean and scrappy the managers remain hands-on (possibly too much... it's a delicate balance), but when an organization reaches a certain size, management-hierarchy politics finally catch up to the growth curve. Then the org has to start "cultivating" managers, and they start setting up rewards for stuff like:

Process Enhancements
Meetings
Governance Artifacts

Now none of these things are problems by themselves (as much as I hate meetings 🤮), but they're supposed to be means to an end, not the end itself.

As a manager's job becomes more abstract and less rooted in the actual work, the organization encourages them to become "more T-shaped" and broaden their exposure... so they start managing adjacent teams.

Or even non-adjacent ones. 😱

Soon, the people designing the system are the ones least affected by it; even worse, they have absolutely nothing concrete to connect all their abstractions to.

Leaders with "Dirty Hands" may not be an expert in whatever their team does, but they could perform at a "junior level"... but leaders with "Clean Hands" can't even fall back on that. And that leads me to the accusation I'm leveling at you leaders today:

If you don't ever do what your team does, you probably don't understand it. And if you don't understand it, you shouldn't be in charge of it.

Hear me out: I'm not just doing this to throw shade, and I'm not saying you're in a pickle you can't get out of.

I'm saying you need to engage. Start doing the kind of work your team does... in a low-stakes environment, inconspicuously... but get your hands in the dirt a little bit, just so you know what the dirt feels like.

Consider it "Professional Development"... that actually develops you.

What Awnings Taught Me About Developer Experience

Ben Link — Thu, 28 May 2026 11:15:00 +0000

Here in the U.S. we have a fast-food chain called Chick-fil-A. Its claim to fame isn't actually its food (though it's quite tasty!), but its commitment to the perfect customer experience. And whatever they're doing, it's working - most of their locations have incredibly long (but also extremely fast-moving) lines.

At the one nearest to my house, I noticed something interesting: an awning was built over a section of the drive-through line. This wasn't just some canvas cover; it's a full metal roof. It even has fans and heater units installed... for people to drive their cars through. It's not something cheap - it's clearly an investment.

The Origin of the Awning

In a traditional fast-food joint there's a sign in the back with a speaker unit that you can drive up to, place your order, and then drive around to the side of the building where they'll open a window and hand you your food.

But at Chick-fil-A, the lines were so long that they were losing customers. So they created an operations technique they call the "Outside Play". The Outside Play sends a couple of employees with tablet PCs out to stand in the line of cars and take orders. This allows the kitchen to prepare more orders in advance, reducing the time that a customer has to spend waiting at the window. Throughput can increase dramatically by putting those two employees out there.

An Unexpected Problem

The Outside Play works flawlessly, except for one thing: The Weather. If it's raining, the tablets might not work. If it's really hot or cold outside, it isn't safe for the employees to stay out there for extended periods.

At first, they tried just rotating people in and out, and it worked for a while. But where I live, our summers get disgustingly hot and humid... even with short outside shifts, like 20 minutes a pop, employees were still in danger of suffering from heat exhaustion.

The Awning Solution

Chick-fil-A leadership realized they needed those people out there. So they elected to invest - and built the awning. And they put the fans in it for the summertime, and they put heater units in it for the wintertime, and they put quality work into it so that their employees can still keep the Outside Play running regardless of the weather.

Sir, this isn't a Wendy's... it's a Technology Blog

You might be wondering what any of this has to do with technology... but let's talk about Developer Experience. If your company's leadership didn't grow up around the concept of DevEx, they probably wave the "ROI" flag at you any time you suggest initiatives to focus on improving things.

"That's just frivolity. We need to work on increasing revenues, or on cutting costs."

That sounds like:

"We don't need metal-roof buildings, heaters, or fans. We need more chicken nuggets out the window."

Chick-fil-A realizes that the awning isn't a perk; it's a throughput multiplier.

Without it:

The Outside Play shuts down in bad weather.
Order velocity drops.
Lines grow longer.
Revenue leaks.

With it:

The system works every day.
Employees can operate safely.
Throughput remains high.
Revenue increases.

Their investment protects the system that makes money.

Now think about that with some DevEx words replacing the chicken nuggets:

Without good DevEx:

Builds fail randomly.
Local environments are inconsistent.
Onboarding takes months.
Engineers context-switch constantly.
The “Outside Play” shuts down when conditions are bad.

With good DevEx:

Engineers stay in flow.
Deployments happen safely and quickly.
Bugs surface earlier.
Throughput increases.

The awning doesn’t make employees happier for happiness’ sake... Its purpose is to keep the system producing. And for your business, Developer Experience is the awning that keeps your delivery pipeline running.

The Leader's Challenge

If you're a leader who's asking for ROI when your engineering team asks for some Developer Experience improvements, ask yourself instead: "What's going to happen to your throughput when the weather gets bad?"

"Bad Weather" in a Software Engineering context can strike in a lot of different ways:

A surprise price hike from a core services vendor. (Copilot token billing, anyone?)
A major security vulnerability exposed in your supply chain. (Can't wait for Mythos!!!!)
An urgent business need to deliver something before a competitor does.

You can keep rotating engineers...

Or you can build an awning.

What if Everybody Were Suddenly... Better?

Ben Link — Thu, 21 May 2026 11:05:00 +0000

We (and by we I often mean 'me' 🙃) spend LOTS of time talking about how to improve our work. LinkedIn-fluencers (even the crappy AI-bot ones) talk about optimizing and improving and making things better all the time. It's great to have goals like this: self-improvement is admirable, and I fully believe that the best people at any given task (software engineering, plumbing, music, you name it) are the ones who are always working to improve what they do.

To absolutely no one's surprise, though, we don't often see the organizational improvements we advocate for (or maybe some of us are surprised by this? idk, let me know in the comments!). Working with people is a messy business: sometimes they're politically or financially incentivized to follow "The Old Way", and no amount of logic will change their minds. Sometimes we do a crappy job of stating our case and they don't understand the change we want to make. Sometimes "this is suboptimal, but I don't have to put in additional effort" wins out over a better idea that requires a little sweat equity. We might give the needle a small nudge, but often we put in a lot of effort and glean relatively little progress from it. It can be maddening at times.

Fever Dream Fantasy: The Thought Experiment

There's an amazing dude named John Cutler over at DotWork who, at the end of 2025, proposed a really intriguing thought experiment. As I'm drafting this almost two full months later, I've had some time to think about what he suggested for a while now...

Here's a link to his original post, but if for some reason LinkedIn decides to eat that, I've copied the text below for posterity:

Here’s a fun little thought exercise. Suddenly everyone in your company is 30% more capable, more competent, more skilled, more experienced.

What would actually happen?

That kind of outcome feels too good to be true. (Which is probably why it's a thought experiment!) I mean, imagine showing up on Monday morning and EVERYONE IN THE WHOLE COMPANY is leveled up like that! Wouldn't it be great? We'd be SO profitable and SO efficient and we'd absolutely CRUSH it every day, wouldn't we?

...wouldn't we?

The Answer Lies in What DIDN'T Improve

Our 30% improvements were in:

Capability
Competency
Skill
Experience

But think about what isn't in that list:

Incentives
Priorities
Decision-making latency
Trust levels
Clarity of ownership
How work flows
How conflict is handled
How failure is punished

Oh, sure, you've increased the Talent. But you've left them in a broken system. Think about it like this: your engineer is 30% better at shipping things, but if you still have problems with prioritization, they're shipping the wrong thing 30% faster.

Did you really gain anything by that?

What if your approval process takes weeks, or even months? Making the engineers work faster doesn't really help. (BTW: This is a concept codified forty years ago, called the Theory of Constraints. Nothing new!)

What if your team struggles with psychological safety? Even if you increase their skill overnight... they're still not going to contribute more when it isn't safe to speak up.

Leadership Always Falls for The "Get Better People" Trap

Listen to senior leadership discussions, and you'll realize that many (most? maybe all?) have fallen for it:

"I only want A players on my team."
"We need more Senior/Staff/Principal Engineers."
"We need higher standards in the organization."
"We're going to outsource {some competency} because it will be more efficient than investing in our teams developing the skill."

It's tantalizing to think this way:

"Oh, well Bob isn't working out for us - he's competent, but he's just too slow. Let's cut him and hire one of those 10x guys I keep hearing about."

This kind of thinking feels natural to us. If you grew up playing TECMO Bowl, you remember Bo Jackson. He was that 10x Running Back that you and your siblings always fought over - because whoever had him was going to win.

On the surface, managers and directors think like this because it feels like meritocracy. "We gave Bob a chance, he couldn't hack it here." It's tangible - something they can see and do, so they feel like they're hands-on "managing" their team. But I think they're actively destroying their team by doing this.

Wanna know why?

The revolving door "Bob couldn't hack it" approach is easier than doing the culture work that fixes what actually kept Bob from succeeding.
Bob gets the blame that rightly belongs to the leadership system... and every other engineer sees that management will cut people instead of admitting a fault.

Here are some "translations" you might want to consider:

Easy Story	Hard Reality
We need A-players.	Our environment suppresses B+ players instead of helping them grow.
We need more Seniors.	Our decision process is chaotic.
We need higher hiring standards.	We don't protect focus, or prioritize well, or communicate well.

For Senior Leadership, it can be psychologically safer to blame their people than to honestly assess the management system.

Environment Shapes Your Team's Productivity

If you've ever read anything on the Adventures of Blink, you know I firmly believe that good Developer Experience is the foundation of your engineering team's ability to increase revenue... but judging from what I observe around me, there aren't many in senior leadership roles who've made that connection.

Let's consider it like a simple equation:

Impact = Talent × Environment

So if everyone were 30% more talented, 1.3x talent seems pretty exciting, doesn't it?

Set your environment to 0.5, and even your extra-talented team underdelivers.

Now let's look at it a different way: If you provide a great environment, even your average talent looks incredible!

Why we can trust the equation

Blink, you just made that formula up. Well... you're right about that... but I think it works anyway! Here's why:

Clear priorities → Fewer wasted cycles

Strong trust → Faster decisions

Tight feedback loops → Rapid improvement

Psychological safety → Better idea-sharing

Good DevEx → Skill converts to output

Providing a safe, empowering, collaborative environment clearly acts as a force multiplier across all these dimensions.

The Right Questions

The easy question for leadership is "How do we get better people?" It's an alluring question because people in management fantasize that the answer is found in hiring practices, in clever interview questions, in asserting themselves as "high-performance leaders" who go and get things done.

But the right question to ask looks a little different:

What would need to change for our current people to operate at 130%?

That's a tough pill to swallow because it reframes the responsibility.

In order to answer that question, you can start by looking for the answers to these:

Where do good ideas go to die?

You might actually have lots of great ideas coming from your staff... but they get strangled before they're realized. Find out why that is, and fix it.

Where does energy leak?

I've watched a highly motivated team absolutely burn out because they spent as much time fighting the system as they did innovating.

Where does friction accumulate?

You didn't wake up one morning and say "hey let's implement a painful cumbersome process" (well, at least I hope you didn't!). It's been compounding in the shadows for a while. Ask the team where it is, and listen carefully. They'll show you.

What behaviors are we quietly (and/or accidentally) rewarding?

I once knew a manager who obsessed over his team's compliance scores. If a finding came out for his team, he insisted on dropping ALL planned work to deal with it.

Governance and Compliance learned that if they needed something from him, they could rattle the Findings saber and instantly move to the front of the line.

His team learned that their innovation wasn't as important as their Compliance scores.

Think about how that affected everyone's choices.

Not to put too fine a point on it, but...

If 30% more capable people wouldn’t radically transform your company, that’s not a talent problem; it’s a system problem.

The fantasy is that better people will fix the system.
The reality is that the system shapes what people can become.

Wrapping Up

I get it: managers want to manager. They see a quick path to "fixing the problems" and it tempts them with their own agency:

"You can fix this broken team, just get rid of the low performers and get some rockstars in there".

I've felt like that before. And it's hard to tell the difference between a B+ player who's been hamstrung by a bad environment and a C- player that's genuinely a bad fit. All I'm saying is that maybe we need that trigger-finger to be a little less itchy, and apply a little introspection first.