DEV Community: Om Keswani

The Async Trap: Why ‘Non-Blocking’ Workflows Are Silently Delaying Every Release

Om Keswani — Mon, 13 Jul 2026 11:52:33 +0000

I wasn’t supposed to be watching. I’d finished my work, closed my laptop, and poured a glass of wine. But some impulse — call it morbid curiosity — made me open GitHub one last time. That’s when I saw it: a tiny pull request, five lines of CSS, sitting open for four days with seven comments, three emoji reactions, and zero progress.

It wasn’t a difficult change. Margins. Padding. A mobile card component that looked slightly wrong on certain tablets. The developer who opened it — let’s call him Rahul — wrote a clear description and tagged two reviewers. He submitted it on a Tuesday morning, his time. By Tuesday evening, nobody had looked. Wednesday morning, a reviewer in a different timezone added a comment: “Could we maybe use a utility class here?” Fair question. Rahul replied within the hour: “Sure, let me check.” Then silence. The reviewer had logged off for the day. Another night passed.

On Thursday, a second reviewer chimed in from yet another continent. “LGTM, but the first reviewer had a good point — maybe we align with the design system?” Rahul, now two days into what should have been a ten-minute fix, dutifully updated the code. The first reviewer came back Friday morning with a thumbs-up emoji. But by then, the CI pipeline had drifted. A flaky test failed. The merge button was grayed out. Rahul re-triggered the pipeline and waited. And waited. The green checkmark finally appeared Saturday afternoon. The fix hit production on Sunday night, during a low-traffic window. Four days and five timezones later, a margin tweak that could have shipped during a single coffee break finally saw the light of day.

I stared at that PR timeline like it was a crime scene. Every interaction was polite, professional, and “non-blocking.” No one had said no. No one had been unhelpful. And yet, the system had conspired to inject days of invisible latency into something trivial. This was our team’s async culture in all its glory: an elegant, well-intentioned machine for manufacturing waiting.

The worst part? Rahul didn’t even complain. He’d learned that complaining about speed in an async-first team is like complaining about the weather — pointless and vaguely embarrassing. Instead, he internalized the lesson: small fixes aren’t worth the overhead. Next time, he’ll batch a dozen tiny changes into one monstrous PR that nobody wants to review, and the queues will grow fatter, and the cycle times will stretch even further. The async trap isn’t just about slow shipping; it’s about the quiet defeatism it breeds.

I started calling it “polite blocking” after that night. The idea that a queue is still a queue, even if everyone in it is being considerate. The belief that we’ve eliminated handoffs just because we’ve replaced “Hey, got a sec?” with an @mention that can legally be ignored for six hours. The collective fiction that fragmented, interleaved attention is the same as deep collaboration, as long as we all reply within a reasonable window.

The truth is, asynchronous work only thrives when we also define synchronous safety valves. Not meetings — I’m not advocating for a return to the calendar hellscape — but deliberate, small rituals that clear the invisible logjam. A daily “sync hour” where the whole team overlaps, not for standup theatre, but for real-time unblocking. A rule that any PR under fifty lines that’s been open for more than a day gets a guilt-free, two-minute huddle. An acknowledgement that sometimes the fastest way to unblock a teammate is to interrupt your own flow for a moment, because the alternative is four days of silent, polite agony.

The next Monday, I brought that timeline to the team. I didn’t present it as a failure. I just asked them to look at the gaps between comments — the long white spaces where nothing happened. You could feel the shift in the room. Someone said, quietly, “I didn’t realize it was that bad.” Someone else said, “I thought I was the only one waiting.” We all realized we’d been so busy respecting each other’s boundaries that we’d built a beautiful, invisible cage out of good intentions.

The async trap doesn’t need you to be rude to work. It just needs you to be busy, spread across timezones, and too polite to tap a colleague on the shoulder when a five-line fix is gathering dust. The escape starts when you stop mistaking “I’m available later” for “I’m working together now.”

The ‘Action Item’ Graveyard: Why Your Sprint Retrospectives Are Just Emotional Theatre

Om Keswani — Tue, 07 Jul 2026 10:54:46 +0000

I have a folder on my phone called “Retros.” It’s just photos of whiteboards. I started taking them six months ago because something felt off, and I couldn’t put my finger on it.

Last Tuesday I scrolled back through them and found the exact same lime-green sticky note in five consecutive photos. “Fix flaky integration tests.” Same handwriting — Sarah’s neat little all-caps. Every two weeks she dutifully rewrote it, because the old one had been taken down, and nobody remembered it existed.

That’s when the word graveyard popped into my head, and it wouldn’t leave.

The thing is, Sarah wasn’t lazy. None of us were. Our retros looked great. We had the columns, the dot-voting, the little round stickers with frowny faces. Someone always volunteered to “own” the action item. Sarah would write her name next to it and give a small smile that said I know this is hopeless but I’ll carry it anyway. Then we’d close the retro and sprint headfirst into the next two weeks of feature work, where the flaky tests would fail again, and someone would sigh and hit rerun, and nobody would mention the lime-green sticky note until the next retro rolled around and we pretended it was a new problem.

We weren’t improving. We were performing improvement.

The lowest point came during a retro where a junior developer — two months in, still too new to know which things you’re supposed to say and which you’re supposed to swallow — asked, “Why do we write down things we never fix?” The room went quiet. I watched our scrum master’s face cycle through three expressions in half a second. Then someone said, “That’s a great point, let’s make sure we circle back on it next time.” I wanted to scream.

That night I couldn’t sleep. Not because of the question, but because of the silence that followed it. That silence was the sound of a team that had stopped believing its own rituals. We’d turned retros into a pressure-release valve — a safe space to vent, nod, and walk away feeling mildly better, without ever having to solve anything. And the cost wasn’t just the un-fixed bugs. The cost was that every one of us was learning, every two weeks, that raising a problem was the end of the conversation, not the beginning.

So I did something awkward. At the next retro, I brought photos of the last five boards printed out on actual paper. I spread them across the table like a detective laying out evidence. “Look,” I said. “This exact sticky note appears in every single one. Sarah’s been volunteering to fix it since March. It’s July. Nobody’s given her a single hour to do it. The action item column isn’t a to-do list. It’s a cemetery.”

There was a long pause. Then Sarah laughed — not a happy laugh, the kind of laugh you make when someone finally says the thing everyone’s been thinking. “I stopped writing it in May,” she said. “I just copy it from the photo on my phone because I’m embarrassed to admit it’s still broken.”

We made a rule that day, scribbled on a fresh sticky note with a Sharpie so it would stick: If a problem shows up in three retros, it stops being an action item and becomes a blocker. No new feature work until it’s dead or downgraded to a conscious decision to ignore it forever. The flaky tests got fixed in four days. Not because we suddenly knew how to fix them, but because we finally gave ourselves permission to treat improvement as real work.

I still take photos of our retros. But now I take them because the board actually changes. And when I see a sticky note that’s been there too long, I don’t feel dread. I feel like it’s about to meet its end.

The Day I Realised Our Code Reviews Were Making Us Worse

Om Keswani — Wed, 01 Jul 2026 09:59:05 +0000

Two years ago, I submitted a pull request I was genuinely proud of. It fixed a gnarly concurrency bug that had been causing random 502s in production for weeks. The fix wasn’t pretty—a carefully placed mutex, a refactored retry loop, and a comment block longer than the method itself explaining why the obvious approach would deadlock under load. I pushed the branch, opened the PR, and went to grab coffee, feeling that rare mix of relief and competence that comes from actually solving something hard.

By the time I sat back down, I had six comments.

None of them mentioned the race condition. The first one flagged that I’d named the mutex syncLock instead of mu, which wasn’t our standard. Fair enough. The second suggested I extract the retry logic into a helper—fair, but not urgent. The third asked if the comment block should be a docstring instead. The fourth wanted to know why I hadn’t used context.WithTimeout in a place where it genuinely didn’t matter. The fifth pointed out a typo in a log message. The sixth was an approving emoji on the typo catch.

I remember staring at the screen, waiting for someone—anyone—to ask the hard question. Does this actually eliminate the race, or just shrink the window? What happens if the mutex is held during a pod restart? I had answers, but nobody asked. The review thread hummed with activity, and every single comment was correct in isolation, yet the sum total of that review was zero added safety. It was a masterclass in being technically right while being functionally useless.

That afternoon, the PR was approved. The bug fix shipped, and it worked. But I couldn’t shake the feeling that I’d been let down—not by my teammates, who were smart and well-intentioned, but by the machine we’d built together. Our review process had evolved into a game where points were scored by spotting superficial inconsistencies, while the big, scary questions sat silently in the corner, hoping not to be called on.

A month later, I was on the other side of the table, reviewing a colleague’s PR. It introduced a new caching layer that, on the surface, looked impeccable. Small functions, clear names, full test coverage. My cursor hovered over a section that handled cache invalidation, and a quiet voice in my head said, I don’t think this handles backfill correctly. But I’m not 100% sure, and asking would mean reading a lot of upstream code. Instead, I left a comment about a misleading variable name. It got resolved quickly. The PR merged. Two sprints later, we spent a weekend debugging stale cache entries that were serving wrong data to paying users. The variable name had been perfect, though.

I started bringing this up in retros, not as an accusation but as a puzzle. Why do we gravitate toward the small stuff? My manager, who had been unusually quiet, finally said something that stuck: “Because the small stuff is safe to be wrong about. If I tell you to rename a variable and I’m mistaken, the worst thing that happens is a slightly awkward follow-up comment. If I ask a question about your concurrency model and I’m wrong, everyone sees that I don’t understand a critical part of the system. Our process rewards looking smart over being thorough.”

That was it. Pedantry wasn’t a character flaw; it was a rational response to an environment where surface-level correctness earned social credit and deep uncertainty cost it. We’d accidentally gamified our reviews to punish the very vulnerability that makes them useful.

We changed one small rule the next week. Every reviewer had to leave at least one comment that started with “I wonder…” or “What happens if…”—a prompt that could only be answered by thinking about behaviour, not syntax. It felt clunky at first, like learning to write with your other hand. But slowly, the nature of our threads shifted. Someone “wondered” if the mutex approach would hold up during a leader election. That question led to a short, productive discussion and a follow-up task that probably saved us another late-night page. The typos still got caught—they always do—but they stopped being the whole conversation.

I still think about that concurrency PR sometimes. Not because the bug fix was brilliant, but because it showed me something I needed to see: a team can be technically impeccable and still be dangerously negligent, simply by letting comfort steer the feedback. The scariest code review isn’t the one with a lot of red ink. It’s the one where every comment is a minor style note and nobody asks what the code actually does when the lights go out.

The "Let's Take This Offline" Trap

Om Keswani — Sat, 27 Jun 2026 12:10:04 +0000

It was a Wednesday morning standup, the kind where everyone's camera is on but nobody really wants to be there. Maya, our backend lead, mentioned she was blocked on the payment service schema. She'd posted a proposal doc five days ago. Twelve comments. Four emoji reactions. No decision.

"Let's take this offline," our engineering manager said, with the practiced ease of someone who'd said it a hundred times. "We don't need to solve it here."

Maya nodded. I nodded. The standup ended thirty seconds early. Progress.

Except there was no progress.

Over the next week, the doc grew like something feral. Fifteen comments became thirty. Someone added a "TL;DR" that was itself too long to read. Someone else proposed a completely different approach in the margin of comment seventeen, and nobody acknowledged it. The thread didn't converge. It branched, tangled, and then went quiet. The last comment was a thumbs-up emoji from Dan, our staff engineer, posted at 11:47 PM on a Friday. We all interpreted it as agreement. Maya later told me she interpreted it as exhaustion.

Two sprints later, the schema still wasn't decided. We were coding against a temporary interface that someone had built "just to unblock things" and that temporary interface was now serving real customers. The payment service had no official owner. The decision hadn't been postponed. It had evaporated.

I remember sitting with Maya after an incident review—something had broken because the temporary schema didn't handle edge cases—and she said, quietly, "I don't even know who's supposed to decide anymore. Everybody's too polite to just say 'this is what we're doing.'" She wasn't angry. She sounded defeated.

That was the moment I understood what we'd built. Our team wasn't async-first. We were conflict-avoidant wearing the costume of good process. The docs, the threads, the carefully worded Slack messages—they weren't making decisions easier. They were making it possible to never make one at all.

The fix wasn't what I expected. We didn't abandon writing things down. We just stopped pretending that written debate alone could close a loop. We started scheduling what Maya later called "decision windows." Fifteen minutes. No status updates. No screen sharing a half-finished document. Just the three people who actually had context, sitting in a call, with one rule: someone has to leave that call having typed the decision into the doc.

The first one was awkward. We disagreed. Someone had to say "I think we should go with A, and here's why I'm not going to wait for more data." There was a pause, and then the decision got written down. It wasn't perfect. It was done.

What surprised me was what happened to the async discussions after that. They got sharper. People stopped writing essays designed to impress nobody in particular. They laid out trade-offs like adults who knew a real conversation was coming. The doc became a pre-read, not a destination. And Maya, who had been silently carrying the weight of every unmade decision, started looking less exhausted.

The "let's take this offline" habit didn't disappear overnight. But now when someone says it, there's a follow-up question baked into the team culture: "Great—who's scheduling the window?" If nobody steps up, we all know. We're not being thoughtful. We're just letting the thing die politely.

It turns out a decision isn't a document. It's a moment. And moments don't happen in comment threads. They happen when two people look at each other—on a screen or across a table—and one of them says the thing that's been waiting to be said out loud.

The Blameless Postmortem That Still Blames You

Om Keswani — Thu, 18 Jun 2026 13:08:13 +0000

You’ve been in that retro. The slide already says This is a blameless postmortem. Someone pastes a Slack timeline, a facilitator reminds the room to focus on systems not people, and a fresh Jira epic swallows the action items. You nod along, camera off, and you think the same thing you’ve been thinking for six months: I still feel like I’m being written up.

We got fluent in the vocabulary of psychological safety years ago. Nobody asks “who broke this?” anymore. We ask “what allowed this failure mode?” and we mean it. Yet for a lot of engineers — especially the ones quietly absorbing operational chaos — the postmortem has shape-shifted into something uglier. It’s become a surveillance document that wears a learning-opportunity mask.

Here’s how it actually works. The incident timeline lands in a shared folder, and an innocent question floats up in the thread: “Was the alert acknowledged before the escalation policy triggered?” Sounds factual. But it’s really a timestamp with your name on it, and it’s sitting there while your manager drafts quarterly feedback. The system doesn’t have to point a finger. It just has to record who touched what, and when, and let a well-trained imagination fill in the rest.

The kicker is that nobody set out to build it this way. Teams genuinely believe thorough postmortems prevent recurrence, and thorough means attribution. Who logged in. Who merged. Who approved the rollback. The document collects all of it without malice, then quietly hardens into a competency paper trail. Come calibration season, a pattern of “always being in the timeline” — even if you were the one who caught the bug, stayed up, wrote the fix — gets read as a pattern of being close to incidents. And that’s a pattern that costs you.

I’ve watched people game this in real time. They learn to never be the last person to touch a config change. They make sure the incident commander role rotates away before the retrospective. They write action items so vague no single human can be tied to their completion. This isn’t laziness; it’s survival. When “blameless” means we won’t say it out loud but we’ll sure remember, smart people stop volunteering for the pager shadow rotation. They stop saying “I’ll own the fix.” They stop caring about the system and start caring about their paper trail.

The real giveaway isn’t what happens in the meeting — it’s what happens three weeks later, when a senior engineer quietly asks to be moved off on-call and leadership treats it like a motivation problem instead of a trust problem. Or when the action items that emerged from the incident aren’t new runbooks or circuit breakers, but a private coaching note: “Improve response time under pressure. Communicate more clearly in Slack during degraded state.” That’s not a system improvement. That’s a performance review bullet wearing a postmortem hoodie.

Real blameless culture doesn’t live in a meeting template. It lives in an institutional refusal to let incident timelines become résumé lines. It means postmortems celebrate the person who showed up five times in the log, not flag them as “risk exposure.” It means the overwhelming majority of action items are about automation, not about coaching conversations. Until that’s true, the word “blameless” will just be the new “we’re a family” — something you hear right before the part that hurts.

The Standup Theatre

Om Keswani — Sun, 14 Jun 2026 11:21:28 +0000

It’s 9:15 AM. You’re holding a coffee you didn’t want yet, listening to the fourth person in a row say, “Yesterday I worked on the API integration, today I’ll continue the API integration, no blockers.”

Nobody’s fooled. Everyone knows the API integration has been “continuing” for six days. But we all nod anyway, because the real goal of this meeting is no longer coordination. It’s performance.

Somewhere between the agile manifesto and the daily grind, standups stopped being about unblocking work and started being about proving you’re working. The audience shifted. People aren’t talking to their teammates anymore. They’re talking to the manager, the tech lead, the person who might whisper something in a one-on-one. Without anyone saying it, the three questions became a tiny audition. Can you sound productive in under sixty seconds?

The cost of this theatre is bigger than most teams admit.

Real engineering is messy. You spend a morning falling into a rabbit hole only to discover the problem was a misconfigured feature flag from two sprints ago. But “I traced a bug to an old flag and have no fix yet” sounds like you did nothing. So you paraphrase: “Making progress on the checkout issue.” That sanitised sentence protects you, but it buries crucial context. Your teammate who fixed that flag last month never hears about the fallout. The team repeats the same mistake next sprint because the truth never made it onto the board.

Then there’s the help that never arrives. A standup is supposed to surface blockers. But in a performative standup, admitting you’re stuck feels like saying you’re incompetent. So you don’t say it. You go back to your desk, open the same undocumented internal library, and spend another afternoon staring at the screen alone. The ten-minute conversation that could have saved you never happens, because you learned that the safest thing to say is “on track.”

And management loves it. Every day they hear a chorus of “on track,” and they walk away feeling secure. That’s the most dangerous part. A smooth standup isn’t a sign of health; it’s often a sign that problems are being hidden just well enough to blow up spectacularly three days before the sprint ends. The standup becomes the very thing that hides reality from the people who need to see it most.

I once worked on a team where a developer spent two weeks struggling with a flaky deployment pipeline. Every standup he said, “Still working on the deployment stuff.” Nobody asked follow-ups, because the standup was a status broadcast, not a conversation. Two days before launch, the pipeline collapsed entirely. We scrambled, people cancelled weekends, and the fix ended up taking a pair of engineers four hours. If one person had said, “Hey, that sounds painful, let’s look at it together after standup,” the entire crisis would have been a non-event. But the format didn’t invite that. The format invited performance.

How do you break out of it?

I’ve seen one trick work more often than any other: talk about the work, not the worker. Instead of going around the room person by person, walk the board from right to left—closest to done first. Ask about the tickets, not the humans. “What’s stopping this from shipping?” It becomes much harder to perform when the question is about a specific card. You can’t polish a stuck ticket into sounding like progress. You just have to say, “The payment service dependency hasn’t responded,” and suddenly that’s not a personal failure. It’s a fact. And facts invite help.

Another thing: let standups be awkward. A good standup occasionally has a moment of silence where everyone stares at a problem and realises they don’t have an immediate answer. That’s okay. If your standups never feel slightly uncomfortable, you’re probably not surfacing the real stuff. The goal isn’t a clean, reassuring daily ritual. The goal is to make invisible work visible, and invisible work is rarely tidy.

I’ve also seen teams kill standups entirely and replace them with asynchronous Slack threads. That can work, but only if the team already has enough psychological safety to be vulnerable in text. Otherwise, you just get polished bullet points instead of polished monologues—same theatre, different stage.

The standup isn’t the problem. It’s a neutral container. It becomes theatre when people learn that honesty has a cost and performance has a reward. Fix that, and a 15-minute circle can still do its real job: making sure nobody fights the monster under the stairs alone.

So tomorrow morning, when someone says “no blockers,” maybe pause and ask, “Really? Even that nasty logging bug from yesterday?” You might just find that the show is over and the real work begins.

The Slack Dependency: How Instant Messaging Replaced System Design

Om Keswani — Sat, 06 Jun 2026 09:37:07 +0000

A new engineer joins the team.

On their first day, they ask a simple question:

"Why does this service call that API before writing to the database?"

Nobody knows.

The documentation doesn't mention it.

The architecture diagram is two years old.

The code doesn't explain it.

Eventually, someone replies:

"Search Slack. I think we discussed it last year."

After twenty minutes of scrolling through old threads, buried between emoji reactions and unrelated conversations, they finally find the answer.

And that's when they discover a strange truth about modern software teams:

The most important documentation isn't in the documentation.

It's in chat history.

Most organizations believe they have a documentation problem.

Many actually have a dependency problem.

Over time, Slack, Teams, Discord, and other messaging platforms become the unofficial source of truth for technical decisions.

Why was a service split into two?

Search Slack.

Why is that database query intentionally slow?

Search Slack.

Why can't we remove that feature flag?

Search Slack.

Critical engineering knowledge slowly migrates from systems into conversations.

At first, this feels efficient.

A quick message gets a quick answer.

No need to update a document.

No need to schedule a design review.

No need to maintain a knowledge base.

Just ask the team.

The problem is that conversations solve today's question while creating tomorrow's confusion.

Every answer delivered through chat disappears into an endless stream of new messages.

The team gains speed in the moment but loses memory over time.

The result is a hidden form of technical debt.

Not code debt.

Knowledge debt.

The system becomes increasingly dependent on people remembering things.

The architecture exists in someone's head.

The deployment process exists in a private conversation.

The reasoning behind critical decisions exists in a Slack thread from fourteen months ago.

As long as the right people stay on the team, everything appears fine.

Then someone leaves.

And suddenly nobody understands why certain parts of the system exist.

This is one reason onboarding feels so painful in many engineering organizations.

New developers aren't learning the system.

They're learning how to navigate years of fragmented conversations.

Instead of reading clear documentation, they're performing digital archaeology.

Every answer requires digging through old channels, forgotten threads, and messages written for people who already understood the context.

The organization hasn't lost knowledge.

It's simply buried.

Ironically, most teams don't intend for this to happen.

Chat tools are designed for communication, not long-term memory.

But because communication is easier than documentation, the path of least resistance wins.

A five-minute Slack message replaces a thirty-minute design document.

A quick explanation replaces a written decision record.

Eventually, the conversation becomes the system.

The danger isn't that Slack contains useful information.

The danger is when Slack becomes the only place that information exists.

Because chat history is not architecture.

It is not documentation.

And it is not a reliable way to preserve institutional knowledge.

A healthy engineering organization treats conversations as the beginning of documentation, not the replacement for it.

Otherwise, every technical decision eventually turns into a scavenger hunt.

And every new engineer inherits the same challenge:

Building software while searching thousands of messages to understand why it works in the first place.

Why Every "Quick Fix" Eventually Becomes a Core Dependency

Om Keswani — Sat, 06 Jun 2026 09:34:52 +0000

A production issue appears at 4:52 PM on a Friday.

Customers are affected. Alerts are firing. Leadership wants updates. Nobody has time for a perfect solution.

Someone suggests a workaround.

"Let's patch it for now. We'll clean it up next sprint."

Everyone agrees.

The patch goes live.

The incident ends.

The team moves on.

And that's usually the moment a temporary fix begins its journey toward becoming permanent infrastructure.

Most engineers assume technical debt is created by poor engineering decisions.

In reality, some of the most stubborn technical debt starts as a completely reasonable decision made under pressure.

The quick fix wasn't reckless.

It was practical.

It solved the immediate problem, reduced business impact, and allowed everyone to sleep that night.

The problem is what happens afterward.

Nothing.

The next sprint arrives, but priorities change.

A customer request becomes urgent.

A new feature gets scheduled.

Another production issue appears.

The cleanup task quietly slips into the backlog.

Then it slips again.

And again.

Eventually, nobody talks about it anymore.

The workaround survives long enough to become part of the system.

This is where software systems develop a strange kind of organizational memory.

New engineers join the team and see the workaround already in place.

To them, it isn't a workaround.

It's simply how the system works.

Documentation starts referencing it.

Monitoring dashboards depend on it.

Other services integrate with it.

New features are built around its behavior.

Without anyone making a conscious decision, a temporary patch becomes a core dependency.

The most dangerous part is that quick fixes rarely create immediate problems.

If they constantly broke production, teams would remove them quickly.

Instead, they usually work.

Not perfectly.

Not elegantly.

But well enough.

And "well enough" is often all a system needs to survive for years.

The temporary script created for a one-time migration becomes part of every deployment.

The emergency API endpoint becomes a business-critical integration.

The shortcut database field becomes essential for reporting.

What was once considered technical debt slowly transforms into infrastructure.

Years later, someone finally proposes removing it.

The response is almost always the same.

"Are we sure nothing depends on it?"

Nobody knows.

The engineer who created it left two years ago.

The original ticket is long gone.

The documentation is incomplete.

And after years of integrations, assumptions, and hidden dependencies, removing the fix suddenly feels riskier than keeping it.

So it stays.

Not because anyone believes it's the right solution.

Because nobody can confidently prove it's safe to delete.

The irony is that quick fixes are not the enemy.

Every engineering team needs them occasionally.

Production incidents don't wait for perfect architecture.

The real mistake isn't creating a shortcut.

It's failing to assign an expiration date to it.

Because software has a habit of preserving yesterday's compromises long after everyone forgets why they were made.

And if a temporary solution survives long enough, it stops being temporary.

It becomes the system.

The next time you hear someone say, "We'll fix it properly later," remember:

Later is where most core dependencies come from.

Why Most AI-Generated Code Never Survives a Production Incident

Om Keswani — Fri, 29 May 2026 11:21:55 +0000

The code was perfect. Until production met reality.

A few months ago, a developer on a team I knew fixed a bug in under ten minutes.

A quick prompt to an AI assistant. A clean-looking solution. Tests passed. Pull request approved.

Everyone was impressed.

Three weeks later, the same code helped trigger a production incident.

Not a dramatic outage. The worst kind.

Some users were affected. Others weren't.

Logs looked normal. Monitoring dashboards were green. Support tickets slowly started piling up.

The engineer who merged the change opened the code and started reading.

Then came the uncomfortable moment:

"I know this works. I just don't know why."

That's when I realized something.

AI has made writing code easier than ever.

But production incidents were never about writing code.

They're about understanding systems.

The Difference Between Coding and Owning

Most software feels brilliant on the day it's merged.

Production doesn't care.

Production introduces weird customer behavior, forgotten edge cases, network failures, outdated dependencies, and assumptions nobody remembers making.

That's why the most valuable engineer during an incident usually isn't the person who wrote the most code.

It's the person who understands how everything connects.

They know which service tends to fail first.

They remember why a strange workaround exists.

They can look at a symptom and trace it back to a cause.

That knowledge doesn't come from generating code.

It comes from living with it.

The Confidence Problem

The biggest risk with AI-generated code isn't that it's wrong.

It's that it looks right.

The code is clean.

The variable names make sense.

The structure feels professional.

And because it looks convincing, it's easy to skip the hardest question:

Do I actually understand what this is doing?

Most of the time, that question doesn't matter.

Until production breaks.

Then it matters a lot.

Because debugging isn't about reading code.

It's about understanding behavior.

Production Is Where Context Wins

When systems fail, the answers are rarely sitting inside a code snippet.

They're hidden in things AI can't easily see:

A decision made six months ago.
An undocumented dependency.
A customer workflow nobody considered.
A "temporary fix" that became permanent.

Production systems are full of history.

And history doesn't fit neatly into a prompt.

That's why incident response feels less like programming and more like detective work.

You're gathering clues, testing assumptions, and trying to explain something that shouldn't be happening.

The Real Skill

AI will continue getting better at generating code.

There's no reason to pretend otherwise.

But the engineers who stand out won't be the ones who can generate code the fastest.

They'll be the ones who can explain why a system behaves the way it does.

Because when a production incident starts at 2 AM, nobody asks:

"Who wrote this?"

They ask:

"Who understands this?"

And those are two very different skills.

The future may require fewer keystrokes.

But it will always require understanding.

And production has a way of exposing the difference.

The Myth of “Ownership”: How Ambiguous Responsibility Quietly Breaks Production Systems

Om Keswani — Thu, 14 May 2026 08:15:02 +0000

Everyone talks about ownership in engineering teams.

“We need stronger ownership.”
“Who owns this service?”
“Take ownership of the issue.”

But after working on real production systems, I’ve realized something uncomfortable:

Most systems don’t actually have owners.
They have temporary caretakers.

And that difference quietly breaks production more often than bad code does.

A few months ago, our team had a production incident that looked simple at first.

An API started timing out randomly. Nothing catastrophic — just enough to frustrate users and flood Slack with alerts.

The strange part? Every team involved believed the issue belonged to someone else.

Backend thought infrastructure caused it.
Infrastructure thought the database team changed something.
Database team pointed toward networking.
Networking team said traffic patterns looked normal.

For nearly four hours, everyone investigated the problem while simultaneously avoiding responsibility for the system itself.

Eventually, we found the root cause:
a “temporary” retry mechanism added by a former engineer months earlier.

No documentation.
No monitoring around it.
No clear owner.

Just production code sitting silently until traffic exposed it.

And honestly, that’s when I stopped believing most companies understand ownership at all.

In theory, ownership sounds clean.

One team owns one service.
Responsibilities are defined.
Problems get solved quickly.

Reality is messier.

Production systems evolve faster than org charts do.

Engineers switch teams.
Priorities change.
Services get copied, renamed, partially rewritten, or abandoned halfway through migrations.

Over time, systems become shared territory where everyone can deploy changes, but nobody fully understands the consequences.

That’s where dangerous failures start.

Because unclear ownership creates a psychological loophole:
“If everyone is responsible, nobody feels responsible enough.”

And the scariest production issues usually grow inside that gap.

The biggest misconception is that ownership means writing the code.

It doesn’t.

Real ownership means:

understanding operational risks
maintaining documentation
cleaning up old decisions
responding during incidents
saying “this system is unhealthy” before it becomes an outage

But those tasks are invisible work.

They don’t appear in sprint demos.
They don’t impress stakeholders.
They rarely help promotions.

So teams naturally optimize for visible progress instead.

New features get celebrated.
System maintenance becomes “later.”

And “later” eventually becomes a 3 AM production incident.

What makes this worse is modern engineering culture loves distributed responsibility.

Microservices. Platform teams. Shared tooling. Internal frameworks.

Individually, these ideas make sense.

But combined carelessly, they create systems where critical behavior is scattered across five repositories and three teams.

Now debugging production isn’t just technical work.

It becomes organizational archaeology.

You’re not tracing requests anymore.
You’re tracing accountability.

The hardest lesson I’ve learned is this:

Most outages are not caused by a single catastrophic mistake.

They happen because small unanswered questions accumulate over time.

Who maintains this?
Who reviews risky changes?
Who gets alerted?
Who understands failure modes?
Who cleans up legacy behavior?

If those answers are unclear, the system is already unstable — even if everything looks healthy today.

Because production reliability is less about software architecture and more about clarity.

And clarity is surprisingly rare in growing engineering teams.

The Feature Factory Problem: How High-Velocity Teams Accidentally Kill Good Software

Om Keswani — Tue, 05 May 2026 10:26:53 +0000

There’s a moment in almost every fast-moving tech team when productivity starts to feel… off.

Releases are frequent. Sprint boards are always full. Metrics look great on paper. But underneath that velocity, something quietly breaks: the product itself.

This is the Feature Factory problem.

Shipping More, Thinking Less

In a Feature Factory, success is measured by output—how many features shipped, how fast tickets are closed, how packed the roadmap looks. It feels efficient. It looks impressive.

But here’s the catch: shipping features isn’t the same as solving problems.

Teams stop asking why a feature exists. Instead, they focus on when it will be delivered.

Over time, this creates software that feels bloated, inconsistent, and strangely disconnected from real user needs.

The Slow Death of Product Thinking

When velocity becomes the priority, product thinking becomes optional.

Engineers stop questioning requirements. Designers rush through decisions. Product managers become backlog managers.

No one owns the outcome—only the output.

Ironically, the faster the team moves, the less time they spend validating whether they’re building the right thing.

And that’s how good software dies: not with a bug, but with a backlog.

The Hidden Costs No One Tracks

Feature factories don’t fail immediately. In fact, they often look like top performers.

But the costs show up elsewhere:

Increasing technical debt that no sprint seems to fix
Features that overlap, conflict, or go unused
Onboarding that becomes harder with every release
Users who feel the product is “getting worse,” even as more is added

The system optimizes for speed, but accumulates chaos.

Why It Happens (Even to Smart Teams)

No team chooses to become a Feature Factory.

It usually starts with good intentions:

Pressure from leadership to “move faster”
Competitive fear—someone else might ship first
Misaligned incentives (output > impact)
Roadmaps treated as commitments instead of hypotheses

Gradually, questioning slows down. Execution speeds up. And the balance tips.

Breaking Out of the Factory

Escaping the Feature Factory doesn’t mean slowing down. It means building with intent.

A few shifts change everything:

Measure success by outcomes, not output
Treat features as experiments, not deliverables
Create space for engineers to challenge ideas
Prioritize deleting as much as adding
Regularly ask: “Would we build this again today?”

Good teams don’t just ship fast—they learn fast.

The Real Goal

Software isn’t valuable because of how much it does.

It’s valuable because of what it does well.

High-velocity teams don’t kill software because they move too fast. They kill it because they stop listening—to users, to signals, to doubt.

The best teams aren’t feature factories.

They’re learning systems.

And that difference shows up in every product you actually enjoy using.

Why Most Internal Developer Tools Fail (Even When the Tech Is Perfect)

Om Keswani — Sun, 03 May 2026 09:42:25 +0000

There’s a quiet graveyard inside most tech companies. It’s filled with beautifully engineered internal tools—fast, scalable, well-tested… and barely used.

On paper, these tools are perfect. In reality, they fail.

Not because of bad code. But because of bad assumptions.

The Illusion of “If We Build It, They’ll Use It”

Developers often build internal tools the same way they build external products—focusing heavily on performance, architecture, and clean abstractions. But here’s the catch: internal tools aren’t judged by elegance. They’re judged by convenience.

If your tool saves 20% compute time but adds 2 extra steps to a developer’s workflow, it’s already lost.

People don’t adopt tools because they’re powerful. They adopt them because they’re easy.

The Real Enemy: Friction

Every extra click, every confusing config, every unclear error message—these are small cuts that slowly kill adoption.

A developer under deadline pressure won’t explore your perfectly documented tool. They’ll fall back to whatever works right now—even if it’s inefficient or outdated.

The truth is simple:
The best tool is the one that doesn’t feel like a tool.

Built Without the User in the Room

A common pattern: internal tools are designed in isolation.

Engineers imagine the workflow. They predict use cases. They optimize based on assumptions. But they rarely sit with the actual users—other developers—and watch how work really happens.

The result? A mismatch between design and reality.

Real workflows are messy. They involve shortcuts, hacks, and habits that don’t show up in documentation. If your tool ignores that, it won’t survive.

Over-Engineering Kills Adoption

Ironically, the more “perfect” the tech, the worse the adoption can be.

Why?

Because internal tools don’t need to be perfect. They need to be useful immediately. Over-engineering often introduces:

Complex setup processes
Steep learning curves
Too many features nobody asked for

A simple script that solves one problem today will beat a sophisticated platform that promises everything tomorrow.

No Ownership, No Evolution

Many internal tools launch with excitement… and then slowly decay.

No one owns them long-term. Feedback isn’t prioritized. Bugs pile up. Eventually, the tool becomes just another thing developers avoid.

Internal tools aren’t one-time projects. They’re products. And products need continuous care.

The Fix Isn’t Technical

You don’t fix this with better frameworks or faster systems.

You fix it by changing how you think:

Start with the developer’s workflow, not your architecture
Reduce friction obsessively
Ship small, useful improvements instead of big, perfect systems
Treat internal tools like products—with users, feedback, and iteration

Final Thought

The uncomfortable truth is this:

A technically perfect tool that nobody uses is a failure.
A slightly imperfect tool that everyone relies on is a success.

If you want your internal tools to survive, stop chasing perfection.

Start chasing adoption.