No More Vibes in the Efficiency Era

Welcome to the Efficiency Era. Hope you brought your receipts.

🔧 Editor’s Notes (June 2025):
This post has sparked a bigger conversation and has become the anchor for a full series: Field Notes from the Efficiency Era.

Over the coming weeks, I’ll be publishing deep dives on:

• Delegation, Not Abdication (Part 1)

• AI Won’t Save You From Your Broken Systems (Part 2)

• Metrics That Actually Matter (Part 3)

• Beautiful, Irrelevant Things (Part 4)

This story was originally published with light edits on DevInterrupted’s Substack.

Gather Around. It's Story Time.

There was a time—not that long ago—when engineering teams could run on vibes. 🌈 Growth-at-all-costs made hiring the solution to every problem. Feeling productive was good enough. If metrics looked soft? Throw more developers at it, baby. If engagement was lagging? Let's cram some more features into that homepage, fellas. If someone asked "What's your engineering strategy?", you could gesticulate wildly in the general direction of your open reqs and say "we're scaling, fam!"

That era is over.

From ZIRP to AI Whiplash

The ZIRP years (Zero Interest Rate Phenomenon, for the uninitiated) made a lot of bad habits look like good strategy. But as the tide went out, we saw who was swimming naked. The pendulum swung hard. Post-ZIRP brought layoffs, a flattening of org charts, and, suddenly, every engineering manager needed to be coding again. Now? Enter AI. The latest efficiency tonic on the market. Get back to ZIRP-level productivity with post-ZIRP spending.

This whiplash? Exhausting. But here's the thing: for those of us who've always believed in focused and surgical teams, the moment we're in isn't a crisis. It's vindication.

"Every Achievement Has a Denominator"

I recently had a senior leader hand me a "gift": a plan to hire more engineers. I paused. "Why?" I asked. "What problem do we have that hiring solves?" They looked at me like I had passed Go and didn't want my $200. But more people doesn't mean more progress. That's a ZIRP-era assumption. What matters now—and what should've always mattered—is leverage. Outcomes. Impact per engineer. Or as Charity Majors once put it: every achievement has a denominator.

This, my friends, is the Efficiency Era (Did I coin that?.. I’m running with it). And in this era, engineering leaders don't just need to feel productive; we need the receipts.

The AI Mirage

Looks Smart. Acts Dumb.

AI is incredible. No argument from me here. Ask it to write some boilerplate code, generate some unit tests, or explain an obscure SQL function—it'll knock it out of the park. Hell, it might even open a PR or two. Add some doc comments while you’re at it, my robot friend.

But AI doesn't understand your business.

It doesn't know about that weird billing exception you coded around three years ago. It doesn't know what the CEO told the board last week, or how the last time you did a rebrand, it actually decreased conversion. It doesn't know which priorities are real and which ones were tossed out in Slack five minutes after being written.

AI doesn't pause to ask "why are we doing this?".

I once watched a team spin in circles for a week trying to build a system that could browse users' internal networks, only to find out, after a single Slack message, that none of that was even in scope. AI would've done the same thing. Only faster. And now you're maintaining that mess. Building beautiful, irrelevant things.

Junior Engineer Energy

I like junior engineers. Don't get me wrong. But just like junior engineers—they can't help it, they're junior!—AI flails without the full picture. It doesn't ask clarifying questions. It doesn't zoom out. It just... executes.

Maybe not that kind of “executes”

And you know what? That's fine. But only if you give it the right constraints, the right guardrails, the right context. In constrained solution spaces with high-quality inputs, AI is a powerful assistant. But in messy real-world systems, it's like setting a Roomba loose in a cluttered garage: it'll move fast and look busy, but it's going to smear motor oil all over the place and get stuck between your boxes of old collectibles that you're definitely going to be happy you kept for 20 years across three houses and an interstate move.

The real danger zone is where the context is implied, not provided. AI will fill in the blanks whether it should or not. Just like that junior dev we all know who was absolutely sure they "got it" after a five-minute handoff. Oh lord, they didn't. 😭

What's potentially even more dangerous: Expecting that AI in the hands of junior engineers suddenly makes them senior. It just helps them make bigger mistakes, faster.

If we treat AI like an omniscient engineer, we're in trouble. But if we treat it like a force multiplier, one that still requires human judgement, business acumen, and context, we might actually get somewhere. Lightning in a bottle. All that jazz.

So yeah. Use AI. But treat it like the power tool that it is: deadly in the wrong hands, amazing when handled with care. 🥰 Otherwise? It just mirrors the mess.

The Real Productivity Problem: Context Scarcity

It's Not a Copilot, It's a Tourist

We don't have a tooling problem; we have a context problem.

AI can lint your code. It can suggest a refactor. But it can't tell you why that ancient function exists in the first place. It doesn't know that your entire reporting infrastructure is taped together with a Perl script and a prayer. It has no clue what success looks like for this quarter's top initiative.

We call them "AI copilots", but that's generous. They're tourists. What's missing is local context. Tacit, tribal knowledge. We need context copilots. Tools—or hell, even people, god forbid—that help engineers see the full picture. The architecture, the product strategy, the market pressures. What's real? What matters? What's noise?

Dark Work Still Haunts Us

You know what doesn't get fixed with AI? Dark work. The hidden toil. The hours spent trying to decode tribal knowledge, or divine what some now-departed engineer meant when they scribed:

// don't touch this.

This isn't just wasted time. It's wasted potential.

Even the best and brightest engineers can't produce great outcomes if they're operating in the dark. And the latest LLM? Give it bad context and it'll confidently help you! It's really good at building the wrong thing faster than you!

The ugly truth is that whether it was your caffeine-fueled, furiously typing fingers or a vibe-coded LLM solution, a year from now, both are a liability. Write only the code you need to solve the problem at hand. Anything more is maintenance burden.

The Real Copilot? Clarity.

If you want to move the needle on productivity, start with context. Make work visible. Over-communicate priorities. Share the "why". Do what you have to do to close the gap between business intent and engineering execution.

Clarity is the unlock; context, the accelerant. Until we solve for that, all the AI in the world won't save us from shipping those beautiful, irrelevant things.

Metrics Without Meaning

Numbers Don't Care If You Misinterpret Them

Sprint velocity is up. PRs are merged. The burndown chart looks healthy. Yeah, baby, we're cooking with fire now!

Maybe. Maybe not.

Measuring output without understanding the context is like flying a plane by staring at the altimeter. Have you seen the cockpit of a 737? If you binged The Rehearsal like I did, you probably have. All those gauges, switches, and blinking lights. You might think you're climbing when in reality you're headed straight for a mountain. What's the opposite of the Miracle Over the Mojave?..

We've all seen teams hitting their sprint goals, merging code, and delivering features, meanwhile the business is flailing. Churn is up. Revenue goals come and go. New execs stick around just long enough to update their email signature before their Slack profile shows deactivated.

You cannot measure productivity in isolation. You have to ask: Are we building the right thing? Is it solving the right problem? Are we even aiming at the right outcome?

Drinking Sand

In this Efficiency Era, leadership wants proof. And proof is good! But bad metrics are worse than no metrics at all. They give the illusion of insight while steering you straight into disaster.

We love to measure what's easy to measure. Number of commits. Cycle time. Issues closed. But if we don't pair that with qualitative understanding and business context, we're wandering the desert. We're spotting an oasis. We're sprinting towards the mirage. We're drinking sand and hurling obscenities because our senses deceived us.

Measurement Should Bring Context, Not Confusion

At their best, engineering metrics bring the denominator into focus. More output isn't inherently better if the input (time, money, people) goes up proportionally. Great measurement shows efficiency, not just activity.

I've been a part of a painful offshoring operation that doubled the size of the engineering org and still had us delivering all the wrong things. We had more people doing more things. But the reality? Revenue was tanking. Morale was cratering. Product strategy—can I call it that with a straight face?—was a mess. No one stopped to ask, "What does success even look like?"

Balance Results and Retention

The best engineering leaders I've worked with knew that good metrics are only half the equation. You have to also measure the cost—burnout, turnover, the slow decay of a team's ability to think deeply and solve hard problems.

One of my favorite bosses said something in his interview that stuck with me all these years. He said, "My job is to balance results with retention". Deliver positive business outcomes and take care of your people. If your metrics don't reflect that dual mission, they're incomplete at best; harmful at worst. Thanks for that lesson, Hal! 💗

Delegation, Not Abdication

You're Not a Senior Engineer If You're Drowning in Toil

Hot take, but it shouldn't be: Truly senior engineers don't get pulled into low-leverage tasks. That's literally what makes them senior.

They know when something is risky, complex, or a stretch—and they take it on themselves! They know when to delegate. They also know when something is noise, a distraction. The edge case that's out of scope? The low-priority bug that's been open for a year and affects three users? They know how to say "not worth it" and move on.

This 👏 is 👏 the 👏 bar! Not negotiable!

Not "knows the internals of every system". Not "writes the cleanest code". Senior engineers understand the business. They raise their head up from the keyboard and ask: What are we trying to achieve? Is this the highest-leverage use of my time?. They ship the right thing quickly. If you can't do that? You are not ready yet.

Don't want to "gatekeep the title"? Shove off. This is the job.

High-Leverage Work Isn't Writing More Code

For me, as a leader, high-leverage work doesn't mean tracking PRs or counting points. It means giving my team context. It means helping them understand how their work connects to the company strategy, the competitive landscape, and their own career growth. This is how you get people doing the best work of their careers. Remove blockers. Protect focus time. Create systems and processes that scale.

Writing code? Only to sharpen my own understanding or to tighten a feedback loop—not because I think it's the best use of my time.

High-leverage work is the stuff that only you can do well. The same is true for engineers. Use AI to write the boilerplate, sure. Delegate low-stakes tasks to others who are learning. But save your energy for the things that matter: thinking clearly, building leverage, and driving outcomes.

Don't Delegate Thinking

You can (and should) delegate tasks. But you can't delegate thinking. You can't outsource understanding. And you definitely shouldn't let ChatGPT write your Slack messages.

I've seen people use AI to draft all of their internal communication. Folks, hear me out: It's obvious. It's a mistake. You don't build trust with your team or your peers by sounding like a generic thought-leader bot. If you want influence, if you want to build mutual trust and respect with your teams, use your own voice.

This also applies to: Strategy. Tradeoffs. Decision-making. Don't abdicate those to AI. Use it to speed up your research. Use it to bounce ideas around. But keep the knowledge work. That's what separates the truly exceptional performers from the folks playing one on TV.

From Productivity Theater to Real Outcomes

You Need a Strategy. And Receipts.

If you lead an engineering org today, you've probably been asked some version of this:

• What's your AI strategy?

• How are you measuring productivity?

• What are you doing to make your teams more efficient?

Gone are the days of "trust me, bro". The ZIRP money dried up. The vibe checks have bounced. Now, everyone wants proof. Board members. Execs. Investors. And honestly? Good. We should have to show that the money we spend is returning value.

But here's the kicker: AI isn't the strategy. It's a tool. Your strategy is how your org creates leverage, removes friction, and delivers outcomes. AI can help. But if your systems are broken? It will help you break them even faster! If your product vision is lacking? It will hold the blindfold even tighter! If your teams can't connect the work they're doing to positive business outcomes? Neither can AI. How's that for strategy?

Context Is the Unlock

Want your AI investment to pay off? Start by making your systems legible. Make context flow through your organization like oxygen. Write things down. Share what's in your head. Help your teams understand not just what to build, but why any of it matters.

I've written about this before: My weekly "working in the open" habit; the value of metrics with context; the breakthrough moment when technical leaders realize they need to look up from their IDEs. This is all part of the same thing: building a system that enables engineers to do great work. AI can accelerate that. But it won't replace it.

The Efficiency Era Is Just Getting Started

We're not going back to the old way. There's no safety net of endless hiring. No free pass for "engineering as a black box". The companies that thrive in this new era will be the ones who get serious about focus, leverage, and results. That doesn't mean burning people out. It means finally getting smarter about how we work.

Use AI. Leverage your metrics. Use whatever tools give your teams superpowers. But stop pretending that vibes and velocity are enough.

The future belongs to teams who understand the why, not just the what.