DEV Community: The Engineering Manager’s Desk

Writing the code is no longer the bottleneck

The Engineering Manager’s Desk — Sat, 15 Aug 2026 22:30:55 +0000

The industry's currently obsessed with how fast we can generate code. Every morning in our engineering general channel on Microsoft Teams, someone's posting a link to a new agent or a model that can write a thousand lines of perfect frontend or backend code in seconds. We're treating implementation speed like it's still the primary obstacle to shipping software.

It isn't. Implementation's basically a solved problem.

If I want a new microservice to handle regional tax calculations for our checkout flow, I can have the scaffold, the logic, and the unit tests generated before my coffee gets cold. The bottleneck's shifted entirely. The bottleneck isn't "How do we write this?" but "How do we know this is actually right?"

The evaluation bottleneck

Evaluation's replaced implementation as the hardest part of our jobs.

I saw this play out a few weeks ago with one of our teams. They were trying to optimize the way we index product metadata into the search database. A senior engineer used an automated workflow to refactor a particularly gnarly part of the ingestion pipeline. On paper, it was a miracle. A task that usually takes a full sprint was done in an afternoon. The code was clean, followed our patterns, and the unit tests were green.

But then the mess started.

When we pushed it to our staging environment, the search results for our United Kingdom region started behaving strangely. It wasn't a crash. The monitoring dashboards looked fine. But the relevancy of products was just off. It took us six days of manual digging through logs in the log viewer to realize the generated code would subtly misinterpreted how we handle VAT-inclusive pricing in the search index.

We saved sixteen hours of coding only to spend sixty hours in the Microsoft Teams incident channel trying to figure out why the implementation was technically correct but logically wrong. Actually, it's not even that the code was bad. It just lacked the years of tribal knowledge baked into our legacy order management monolith that it was supposed to interact with.

I've realized that when we're using AI at scale, we have to treat evaluation as a first-class engineering discipline. Most of us are still pretending that a few unit tests and a quick review are enough.

We're measuring the wrong thing. We're still measuring velocity by how many tickets we move to "In Review" and how many lines of code we ship. But in an era where code's free, those metrics are worse than useless. They're dangerous. They're encouraging us to flood our repositories with volume that we don't have the capacity to verify.

The real work now's building the rigs to test these systems. It's about shadow deploys, complex regression suites, and observability that can catch logical drifts before they hit the Microsoft Teams deploy channel. It's about having the discipline to say that even if the code was written in five seconds, it still needs five days of rigorous evaluation before it's allowed anywhere near our customers.

I'm as guilty as anyone. Last Tuesday, I was looking at a demo for a new internal tool that was built almost entirely with agents. I was so impressed by the speed of the implementation that I let it go and pushed it through for a pilot without even looking at a test plan. I wanted the win. I wanted to show that we're being productive and innovative with the new stack.

I let the deadline make the decision for me. By prioritizing that raw implementation speed over a proper evaluation framework, I just added another layer of cognitive debt to a team that's already struggling to keep up with their existing services. I'm complaining about the firehose of unverified code, but I'm the one holding the nozzle.

Your AI-generated post-mortem is just a fancy way of hiding the truth

The Engineering Manager’s Desk — Sat, 15 Aug 2026 22:15:43 +0000

I read a post on Lobste.rs last week about dreading our LLM-written incident report future, and it hit a massive nerve. We've reached a point where the moment production stops burning, our next instinct's to automate the thinking.

I'm tired of reading beautifully formatted incident reviews that read like they're written by a consultant who's never seen a terminal. They've all the right sections, the timelines are perfectly clean, and they explain absolutely nothing about why we actually broke.

This connects to something I was chewing on last week when I wrote about the cultural bankruptcy of tracking developer activity through screen recordings. If you treat engineering like a factory where every input must be logged and optimized, you end up destroying professional trust. Writing incident reports with AI's the same disease, just looking from a different angle. It treats the post-mortem as a chore to be automated, rather than the literal mechanism of how we learn as an organization.

Let me tell you how this plays out in reality.

Last month, we'd a really nasty incident in the Incident Response channel on Microsoft Teams. It started around 4 PM on a Thursday. Our product detail pages started throwing server errors. This was a nightmare because we were right in the middle of a high-profile marketing campaign.

It wasn't a sudden spike in traffic. For the first hour, everyone thought it's a bad deployment from a catalog team. We rolled back their latest release, but the errors kept climbing. The dashboards showed database CPU was at 98%, but our database logs weren't showing any long-running queries, which was weird.

People were arguing in the Microsoft Teams channel. We almost ran three conflicting recovery scripts at the same time (actually, that's not quite right, we actually had three people trying to run different diagnostic scripts at once because nobody knew who was leading the recovery).

It turned out that a change to our caching logic on the cloud platform had caused a massive cache stampede. Every single product page hit was bypassing the cache and hitting the database directly. It took four hours of stressful, chaotic coordination to write a quick script to pre-warm the cache, rate-limit incoming catalog requests, and gradually ramp traffic back up.

A few days later, we needed to do the post-mortem. Our sprint planning was starting, we were behind on the migration, and the tech lead was drowning in meetings. They did what any busy engineer does these days. They grabbed the Microsoft Teams transcript, dumped a handful of logs from our log viewer, and asked a model to write the incident review.

The document it produced was gorgeous. It'd a clean timeline, a section on the root cause, and five neat action items. I saw the document, knew there's a smell to it, but I was tired and said nothing when I approved it.

That's a mistake.

The problem with an AI-generated post-mortem's that it optimizes for legibility, not truth. An LLM looks at a chaotic chat log and tries to find a clean, logical narrative. But real incidents are messy. They're full of human confusion, false starts, and bad assumptions.

The LLM didn't capture that the only reason we figured out it's a cache stampede's because a senior engineer on the checkout team happened to remember a similar issue from three years ago. It didn't capture that our visualization tool for the cache was showing green because it was measuring the wrong metric (which, to be fair, was running on an older cluster setup). It didn't capture the complete lack of coordination on who was running scripts.

When you feed an incident history into a model, you're asking it to sanitize the friction. But the friction's where the learning happens. If your post-mortem doesn't capture the fact that your team spent two hours chasing the wrong lead because the alerting tool was lying to them, you'll never fix the alerting tool. You'll just keep deploying clean documents while production keeps breaking.

Look, we'll stop treating post-mortems as a compliance exercise. They aren't homework we need to get out of the way so we can go back to shipping features. They're the actual history of our systems. If you automate that memory, you're outsourcing your team's understanding of their own architecture.

The next time we've a cache issue, the engineer who remembers the old outage might be on holiday. The runbook still won't be updated because the LLM didn't realize the runbook was wrong. It just saw a message saying someone's working on it and assumed it was resolved.

So I'm making a decision. From today, I'm rejecting any post-mortem that feels too clean, and I'm personally sitting in on the review meetings for any major outage. I'm going to require that the timeline includes the things we got wrong during the incident, written by the hands of the people who got them wrong. I don't know if this'll slow down our delivery metrics this quarter, and the teams might hate me for adding more friction when they're already busy, but we can't keep pretending we're learning when we're just outsourcing our thinking.

Nobody wants to own the innovation from three leaders ago

The Engineering Manager’s Desk — Fri, 07 Aug 2026 04:25:45 +0000

There's a specific kind of silence that hits Microsoft Teams about ten minutes after a high-profile departure is announced in the Engineering General channel. It's not exactly sadness. It's more like the sound of a dozen different teams realizing they're now the permanent owners of a "strategic pilot" that nobody actually likes.

I've been sitting through our quarterly planning sessions for the fulfillment and catalog pillars, and the pattern is becoming impossible to ignore. We aren't just fighting the legacy order management monolith anymore. We're fighting the ghost of every architectural opinion held by people who don't work here anymore.

The industry is currently obsessed with the idea that CTOs and heads of engineering are burning out and taking long career breaks. I saw a post from Gergely Orosz about this recently, noting how hard it is to fill these roles because the people at the top are just done. But we don't talk enough about what they leave behind. When a leader who pushed for "architectural diversity" or "best-of-breed tooling" exits the building, they leave a sprawl that's essentially a massive, unhedged loan. Executive turnover is the final interest payment on that sprawl.

I'm probably going to annoy some of my peers with this, but the "innovation" we celebrated two years ago has become the anchor dragging us down today.

About a year and a half ago, we had a senior leader who was convinced our SQL Server and a caching tool setup wasn't going to cut it for a specific regional expansion in Europe. They pushed hard for a very niche, distributed document store for our product metadata. At the time, I was distracted by a messy rollout in the checkout flow and I just approved it. I should have pushed back but didn't. It felt easier to let the "visionary" have their win so I could focus on keeping the site up.

That leader left six months ago. Today, that distributed document store is a nightmare. It has its own custom deployment logic, it doesn't surface logs to our log viewer properly, and only two engineers even remember how the consistency model works. Whenever the dashboard starts showing red for that service, everyone in the Incident Response channel just looks at each other. We're paying the "sprawl tax" every single day, but the person who signed the contract is long gone.

The thing about technical sprawl is that it's rarely born out of malice. It's usually born out of a desire to move fast or a belief that the current tools are "limiting." But tools are rarely the limit. Complexity is the limit.

I was looking at our tech debt board yesterday and noticed that nearly 40 percent of the items aren't actually about old code. They're about "rationalizing" systems that were introduced as shortcuts or experiments. We have three different ways to handle event-driven messaging because three different leaders at different times wanted to try something new.

When you have a stable leadership team, you can sometimes get away with this. There's enough institutional memory to navigate the mess. But as soon as that turnover starts, the sprawl turns into a liability. The new person coming in doesn't want to maintain the "innovation" of their predecessor. They want to simplify. Or, even worse, they want to introduce their own favorite tools, adding a new layer to the sedimentary rock of our architecture.

We're currently in the third quarter of our orders-v3 migration, which was supposed to solve the monolith problem. But it's stalling because we keep hitting these pockets of sprawl. We'll try to move a piece of the fulfillment logic and realize it's tied to a "special" service built during a hackathon three years ago that somehow became production-critical.

I'm simplifying this, but it feels like we're running an archaeological dig instead of an engineering org. We spend more time figuring out why someone decided to use a specific library than we do shipping features for the catalog.

There's a temptation to blame the engineers, but that's a cop-out. Engineers will build what the culture rewards. If leadership rewards "shipping the new thing" but ignores the cost of "maintaining the five old things," you get sprawl. And when those leaders leave, they take the context with them, leaving the rest of us to handle the on-call escalations for a system we never wanted.

I keep thinking about a meeting I had last week with a senior on the checkout team. They were showing me a particularly gnarly part of the session handling logic (which, to be fair, is already a mess). They asked if we could just rip it out and move to a standard library. I had to tell them no, because that specific logic is tied to a fraud detection vendor contract we signed during a panic two years ago. We're stuck with it until the contract renewal, regardless of whether it's the right technical choice.

That's the reality of the job at this scale. You're rarely making the "best" technical decision. You're making the decision that keeps the most people happy while staying within the constraints of past mistakes.

I've noticed that our most productive teams are the ones that have stayed boring. The catalog team has stuck with a fairly standard framework and SQL Server pattern for years. Their velocity is consistent. Their on-call rotation isn't a death march. Meanwhile, the teams that were allowed to "experiment" with every new framework that hit the top of the dev news cycles are the ones constantly stuck in the Deploys channel trying to figure out why their build pipeline is failing for the fourth time in a week.

This connects to something I was chewing on earlier about how we look for "savior" engineers. We hope a brilliant hire will come in and fix the mess, but they usually just add to it. They bring their own favorite patterns and the sprawl grows.

I'm not saying we should never try new things. That would be a different kind of death. But we need to start measuring the "departure cost" of our technical choices. If the person proposing this new database or this new architectural pattern left tomorrow, would we still want to own it? If the answer is no, we probably shouldn't be building it.

The most unpopular opinion I hold right now is that we should probably stop 80 percent of our "innovation" projects and spend a year just deleting things. I've suggested this in a few planning meetings, and the look on people's faces is usually one of pure confusion. They think I'm being cynical or that I'm trying to kill the "culture."

I'm not trying to kill the culture. I'm trying to make it possible for people to work here for more than two years without losing their minds. We keep talking about developer happiness, but we ignore the fact that nothing makes an engineer unhappier than being forced to maintain a "clever" solution for a problem that was solved five years ago.

Actually, that's not quite right. It's not just that the solution is clever. It's that it's orphaned. It's a piece of the stack that has no father and no mother, just a series of git blames leading to "User Not Found."

I don't have a tidy solution for this. We're still hiring, we're still growing, and the pressure to ship new features for the holiday season is already starting to ramp up. The temptation to let a team "just use this one new tool" to get a feature out the door is going to be massive.

But I'm tired of being the one who has to explain to a new senior dev why they have to learn a proprietary templating language that we only use in one corner of the fulfillment system. I'm tired of the interest payments.

The honest version of this is: we're currently incentivized to create complexity because it looks like progress, and by the time the bill comes due, most of the people who signed for it will be at a different.