DEV Community: Om Keswani

The Estimation Theatre: Why Story Points Are Just Astrology for Developers

Om Keswani — Sun, 11 Oct 2026 15:02:44 +0000

I once sat in a sprint planning meeting where four engineers spent 35 minutes debating whether a ticket was a 5 or an 8.

The ticket? Adding a tooltip to a form field. One line of JSX. A CSS class. Maybe 20 minutes of actual work.

But we had to consult the sacred Fibonacci sequence. Somebody said, “It’s not about time, it’s about complexity.” Somebody else said, “But it’s also effort.” The product manager nodded like we were discussing astrophysics.

We landed on 5. We felt productive. We had accomplished nothing.

That’s estimation theatre.

Story points were supposed to save us from bad estimates. Instead, they gave us a new religion. We assign numbers to work we don’t understand yet. We average those numbers across a team. We put them on a chart. Then we pretend the chart predicts the future.

It doesn’t. It’s astrology.

Think about it. Horoscopes use arbitrary symbols to make you feel like the chaos of life is manageable. Story points use arbitrary numbers to make you feel like the chaos of software is manageable. Both require belief. Both ignore context. Both fall apart the moment something real happens—a production bug, a sick kid, a dependency that hasn’t been updated since 2017.

And the worst part? The numbers become the point. Velocity stops being a planning tool and becomes a performance metric. Managers ask why velocity dropped. Teams start inflating estimates to protect themselves. Suddenly a 2 becomes a 5, a 5 becomes an 8, and nobody knows what anything means anymore. The only thing story points reliably measure is how long a team can argue about story points.

I’ve seen teams spend more time estimating a ticket than doing the ticket. I’ve seen engineers sandbag sprints so they can look like heroes later. I’ve seen velocity charts used in performance reviews. That’s not estimation. That’s fear with a Jira license.

Here’s the thing: uncertainty is not a bug. It’s the job. We build software in the dark. We learn as we go. No amount of planning poker changes that.

So what actually works? Slice work small. Ship something. Measure how long it takes from “started” to “done.” Track cycle time. Use throughput. Run a Monte Carlo simulation if you want to get fancy. But stop pretending that a room full of tired developers guessing numbers is science.

You want to forecast? Look at what you actually finished last month. Not what you estimated. What you finished. That’s your data. The rest is theatre.

And hey, if you love story points, fine. Keep them. But call them what they are: a shared language for talking about uncertainty. Not a promise. Not a contract. Not a prophecy.

Because the moment you treat a 5 as a commitment, you’ve stopped estimating work and started negotiating anxiety.

And nobody ships software by reading horoscopes.

The Hotfix Pipeline Trap: How Emergency Fixes Became Your Release Strategy

Om Keswani — Sun, 04 Oct 2026 12:41:07 +0000

I used to be proud of our hotfix pipeline.

We could push a fix to production in under ten minutes. No meetings. No approvals. Just a branch, a quick review, and a deploy. It felt like a superpower. We were fast. We were responsive. We were heroes.

Then I realized we weren’t fast. We were just always on fire.

It started small. A missing null check on a Friday afternoon. “Let’s just hotfix it.” We did. It worked. Everyone went home. Then Tuesday, a broken API contract. Hotfix. Wednesday, a CSS bug that made the checkout button invisible on mobile. Hotfix. By the end of the month, our “release train” was just a series of hotfixes with no schedule. We weren’t shipping software. We were fighting fires.

That’s the trap. Hotfixes are supposed to be exceptions. But when they become the norm, they quietly replace your entire release process. You stop planning. You stop testing. You stop doing retrospectives that actually change anything. You just wait for the next emergency, patch it, and move on.

The worst part? It feels productive. You’re constantly shipping. You’re constantly fixing. But you’re not building. You’re patching symptoms. The root causes are still there, buried under a pile of quick fixes that nobody has time to clean up.

And the team? They’re exhausted. Every hotfix is a context switch. Every deploy is a mini-crisis. You start to dread your phone buzzing. You start to associate shipping with stress. The best engineers leave. The ones who stay learn to avoid owning anything critical because owning something critical means getting woken up at 2 a.m. for a problem that could have been caught in staging if anyone had time to write a test.

So how do you break the cycle?

First, admit that you don’t have a release process. You have a crisis management strategy. That’s a hard pill to swallow, especially if you’ve been telling yourself you’re agile.

Second, slow down. I know. It sounds like heresy. But you have to create space for planned work. Real releases. Test coverage. Feature flags. Canary deploys. Monitoring that actually alerts you before customers do. It’s slower at first. It feels like you’re moving backward. But you’re not. You’re building a system that doesn’t require a hero every other day.

Third, say no to hotfixing everything. Not every bug is a five-alarm fire. Some can wait for the next release. Some can be fixed with a config change. Some can be ignored until you have a proper fix. The discipline to not hotfix is just as important as the ability to hotfix.

I still keep the hotfix pipeline around. It’s useful. But it’s no longer our release strategy. It’s a tool we use when we absolutely have to. And the rest of the time, we do the boring, unglamorous work of making sure we don’t have to.

A hotfix is a tool. Not a lifestyle. If every release is an emergency, you don’t have a release process. You have a crisis management strategy. And eventually, the crisis wins.

The Rollback Religion: Why “We Can Always Revert” Is a Lie Your Team Tells Itself

Om Keswani — Sun, 04 Oct 2026 12:39:19 +0000

I used to believe in rollback. Not casually. Religiously.

Every deploy had the same prayer: “If it breaks, we’ll just revert.”

Then one Thursday at 6:47 p.m., we shipped a “small” change. Forty minutes later, checkout was failing. Not completely down — just enough to be terrifying. Orders were getting stuck in pending. Customers were retrying. Support was already typing in all caps.

So we hit revert. CI went green. Everyone exhaled.

Then we checked the database.

The migration had already run. A new column existed. The old code ignored it, but a background worker didn’t. It kept reading the new column, finding nulls, and doing the wrong thing. We “reverted” for six hours while manually fixing rows and refunding duplicate charges.

That’s when I stopped treating rollback like time travel.

Rollback is not undo. It’s a new deploy that hopes it can clean up after the last one. And usually, it only cleans up the code. It doesn’t clean up:

Data changes. Migrations, backfills, deleted rows, renamed columns.
External side effects. Emails sent, payments charged, webhooks fired, push notifications delivered.
State sitting in queues, caches, third-party APIs, and mobile apps still running last month’s build.
Human decisions. Someone already saw the feature. Someone already changed a config. Someone already promised it to a customer.

The lie isn’t that revert is impossible. The lie is that revert makes you safe.

It makes you feel safe enough to skip the boring stuff. No feature flag. No canary. No backward-compatible migration. No one asks, “What happens if we need to roll back after data has changed?” Because the answer is always the same: “We’ll just revert.”

But that religion has a tax. Teams ship bigger changes because they think there’s a net. They skip dry runs. They treat staging like a ceremony. They forget that the hard part of rollback isn’t the code — it’s the state.

Real safety isn’t a revert button. It’s designing for forward fixes. Expand-and-contract migrations. Feature flags that actually turn things off. Canaries that expose 1% before 100%. Runbooks someone has actually tested. And enough humility to say, “If this goes wrong, we might not be able to go back. So let’s make the blast radius small.”

I still keep rollback in my toolbox. But I don’t worship it anymore. It’s a tactic, not a strategy.

So the next time someone says, “We can always revert,” ask them one question:

Revert what, exactly?

The Green Build Illusion: When CI Passes but Production Is Already Broken

Om Keswani — Fri, 18 Sep 2026 18:01:38 +0000

The build badge was green. Not yellow. Not red. Green. The kind of green that makes everyone close their laptops and go get coffee.

Twenty minutes later, support was flooded. Checkout was failing. The deploy bot had already posted its little checkmark.

CI passed. Production was broken.

That’s the gap I want to talk about.

CI is a liar. Not because it’s malicious. Because it’s answering a smaller question than the one you think you asked. You think it’s saying, “The system works.” It’s actually saying, “This code compiles, these unit tests passed, and the linter didn’t cry.”

That’s not the same thing.

I’ve seen this movie. A team renamed a queue topic. The producer and consumer both had tests. Mocks everywhere. CI was green. In production, the producer started writing to a topic nobody was reading. No errors. No alerts. Just messages piling up. The dashboard stayed green because the app wasn’t crashing.

It was just doing nothing. Customers noticed before the graphs did.

Why does this keep happening?

Because we test code, not systems. Unit tests mock the database. Integration tests hit a staging environment that was built from a different Terraform state. The health check returns 200 as long as the web server is breathing. It doesn’t care that the database connection pool is exhausted or that the payment provider is timing out.

Then there’s config drift. Staging has the feature flag on. Production has it off. Or the reverse. CI never sees it. The code is correct. The environment is wrong. Green build. Broken product.

Migrations are another classic. CI spins up a fresh database, runs all migrations, and passes. Production has a table with 40 million rows and a lock that waits until Tuesday. The code is fine. The deploy is not.

And async work? CI tests the happy path synchronously. Production runs through a queue. A worker dies. A retry loop backs off forever. The API still returns 202 Accepted. Everyone high-fives. The work never happens.

The worst part is the psychology. A green build is a permission slip. It tells you to stop looking. It says, “Someone else tested this.” So you skip the post-deploy smoke test. You don’t check the logs. You don’t click the button yourself. You trust the badge.

I’ve done it. You’ve done it. We all have.

So what actually helps?

First, stop treating CI as proof. Treat it as a filter. It catches typos and broken assumptions. It does not prove the system works.

Second, test the real path after deploy. Not a health endpoint. A synthetic user. Can they log in? Can they add an item to the cart? Can they pay? If that fails, the deploy is not done.

Third, make health checks honest. If the app can’t reach the database, it’s not healthy. If the queue is backed up beyond a threshold, it’s not healthy. A 200 status code is not a medical certificate.

Fourth, watch business metrics, not just CPU. Orders per minute. Signups. Messages processed. When those go flat while your infrastructure looks calm, you have a silent outage.

And finally, believe the customer over the dashboard. Every time. The customer doesn’t care that your build is green. They care that the button works.

Green builds are comforting. They’re also cheap. A real working system is harder. It requires you to look past the badge and into the messy, drifting, half-mocked reality of production.

So the next time CI passes, don’t celebrate. Go click the button. The build can be green and the product can still be broken.

That’s not a contradiction. That’s just Tuesday.

The Silent Outage: When Your System Is Up but Nobody Can Use It

Om Keswani — Sat, 12 Sep 2026 08:48:10 +0000

At 3 a.m., every dashboard in your monitoring stack is green.

CPU is fine. Memory is fine. The load balancer is healthy, the database is responding, the p99 latency is sitting comfortably under its threshold. If you got paged right now, you'd be annoyed, because nothing is wrong.

And yet, somewhere out there, a customer is staring at a spinner. Another one is getting a 200 response with an empty array where their data should be. A third one tried to save something, saw the save button go grey, and assumed they did something wrong.

None of them will file a ticket. They'll just close the tab.

"Up" is the wrong question

We built our entire monitoring culture around a binary: is it up or is it down? That question made sense when infrastructure failed loudly — a crashed process, a dead disk, a dropped connection. Machines used to fail in ways that were obvious.

Now they fail in ways that are polite.

The service returns 200. The response body is valid JSON. It's just wrong. The feature flag flipped and 20% of users are seeing a broken variant. The third-party API you depend on started returning empty results instead of an error, so your UI dutifully renders an empty state that looks exactly like "you have no data."

Your health check hits /health, gets a cheerful {"status": "ok"}, and goes back to sleep. It never asked whether a user could actually do anything.

The outage nobody declared

Here's the part that stings: silent outages can run for days.

Not because nobody noticed — because nobody noticed systematically. A handful of users complained in a support channel. Support shrugged it off as user error. An engineer saw a weird Slack message, thought "that's odd," and got pulled into something else. The numbers in your analytics show a small dip in engagement, which is well within normal variance, so it doesn't trip anything.

Meanwhile a full week passes where your product is technically available and practically useless for a slice of your users, and you find out because someone finally posts about it publicly.

That's not a monitoring failure. That's a definition failure. You're measuring the system. You should be measuring the outcome.

Why users go quiet

This is the part engineers consistently underestimate.

Users don't report silent failures. They assume they're the problem. They assume it's their browser, their connection, their account, their fault. Filing a bug report costs them time and makes them feel stupid, and if the thing is broken-but-pretending-to-work, they have no proof anything is broken at all.

So they leave. Quietly. And they don't come back, because the worst kind of broken product is one that looks like it's working. They don't think "your service is down." They think "this tool doesn't work for me," and they go find one that does.

An outage that announces itself costs you a night. An outage that hides costs you customers you never hear from again.

What actually catches these

A few things that work, and none of them are glamorous:

Test the journey, not the endpoint. Don't just check that the API responds. Check that a user can log in, find their data, and complete the one action that matters most. If you can't script that, you don't fully understand your own product.

Assert on content, not just status codes. A 200 with an empty body is a failure. A page that renders without the user's name on it is a failure. Teach your checks the difference between "no results" and "should have results."

Watch for silence. A drop in successful actions is an alert. A spike in empty responses is an alert. Your users' absence is data.

Use your own product. Nothing catches silent failures faster than an engineer who actually clicks through the thing they built last quarter. It's embarrassing how much this finds.

The uncomfortable truth

Your system was up. Your customers couldn't use it. Those two statements can be true at the same time, and your dashboards will never tell you.

The green light doesn't mean everything's fine. It means the things you thought to check are fine. The silence in between is where your users are quietly giving up.

The ‘Just One More Sprint’ Lie: Why Your Roadmap Is Stuck in Permanent Beta

Om Keswani — Sat, 12 Sep 2026 08:32:26 +0000

There's a slide in your roadmap review that has said "Beta" for fourteen months.

Nobody questions it anymore. It's just there, next to the Q3 goals that have quietly rolled into Q4 and then into a quarter that doesn't exist on the fiscal calendar but definitely exists in your sprint board.

Somewhere along the way, you stopped shipping things and started maintaining the appearance of shipping things.

How it starts

It starts honestly. A feature isn't quite ready. There's an edge case, a permissions bug, a migration that needs one more pass. Someone says the words that will haunt your backlog for the next year:

"Let's get it in front of users, we'll finish it next sprint."

That's a reasonable sentence. It's also a loan. And like most loans taken out by engineering teams, the interest is brutal and nobody's tracking the balance.

Next sprint comes. The team is on something else now — something with a deadline, something an exec mentioned in an all-hands. The beta feature is technically live. It has users. It has some users. Enough to justify not touching it. Not enough to justify investing in it.

So it sits. Half-built. Half-trusted. Fully load-bearing.

Why nobody finishes it

Because finishing work is invisible and starting work is celebrated.

Announcing a new feature gets you a Slack thread with 🎉 in it. Grinding through the last 15% — the error states, the docs, the tests that catch the thing that only happens when two users edit the same record at the same time — gets you nothing. It doesn't demo well. It doesn't go on a slide. It just makes the thing actually work, which is apparently the least interesting thing a feature can do.

Meanwhile, "beta" becomes a shield. Can't complain about the rough edges, it's in beta. Can't expect it to be reliable, it's in beta. Can't ask when it'll be done, because asking that makes you look like you don't understand how modern product development works.

Beta stopped being a technical status and became a political one. It's a way of shipping without committing. Of taking credit without taking responsibility.

What it actually costs you

Here's what a permanent-beta roadmap does to a team, and none of it shows up on a velocity chart:

Customers stop believing you. A beta label used to mean "this is early, tell us what's broken." Now it means "we reserve the right to abandon this." People plan around your software. They don't plan around things that might evaporate.

Your support queue fills with ghosts. Tickets for features that are "released" but not really. Bugs that get closed as "known limitation" because the limitation was never scoped out. Your support team is writing documentation for a product that's still arguing with itself.

New engineers can't tell what's real. They join, they see a codebase where half the features are behind flags, half the flags are stale, and nobody remembers which ones are safe to remove. They ask what the status of something is. They get three different answers from three different people. That's not a knowledge gap. That's an organization that has lost track of its own decisions.

And your roadmap becomes fiction. Not aspirational — fiction. You're planning next quarter on top of a foundation where a third of the "done" work isn't done. Every estimate is built on a lie you told yourselves eight months ago.

The test

Here's a question worth asking in your next planning meeting. Take any feature marked beta. Ask: what would have to be true for this to be not-beta?

If nobody can answer that in under a minute, you don't have a beta. You have a hostage situation.

If the answer is "we'd need to do X, Y, and Z" and X, Y, and Z have never appeared on a roadmap, then you've already decided — silently, collectively, without ever saying it out loud — that this feature will never be finished. You just haven't told the users yet.

The uncomfortable part

Permanent beta feels safe because it avoids the moment of commitment. But it's not safe. It's just a slower, more expensive way of failing. You pay for the feature, you pay for the support, you pay for the confusion, and you never get the one thing that actually compounds: trust.

So either finish it, or kill it. Both are fine. Both are honest.

What's not fine is a roadmap where everything is almost done and nothing is finished, and a team that's been telling itself "just one more sprint" for over a year.

That sprint isn't coming. It was never coming. You just stopped noticing you were waiting for it.

The Meeting FOMO Trap: Why You're Terrified of Missing a Meeting That Doesn't Matter

Om Keswani — Wed, 02 Sep 2026 20:32:07 +0000

Let me tell you about Raj.

Raj is a mid-level developer. Solid coder. Ships clean work. Never misses a deadline. But Raj has a secret fear. It keeps him up at night. It's not production bugs. It's not technical debt. It's not even the legacy PHP codebase that everyone pretends doesn't exist.

It's the calendar invite.

Specifically, the calendar invite that arrives at 4:47 PM on a Thursday, titled something vague like "Quick Chat: Next Steps on the Dashboard Refresh."

Raj stares at it. His cursor hovers over "Accept." His heart rate increases slightly. Who else is on this invite? He checks. There are 14 people. Fourteen! That's not a quick chat. That's a small wedding.

But here's the thing. Raj doesn't want to go. Raj has three PRs to review and a database migration that's slowly eating his afternoon. He knows, deep in his gut, that this meeting will be a 45-minute discussion about whether the "Refresh" button should say "Refresh" or "Update." A decision that could have been a Slack message. A decision that will probably be reversed next sprint anyway.

And yet, he clicks "Accept."

Why?

Because of Meeting FOMO.

The Disease We Don't Talk About

We joke about useless meetings. We share memes about "this could have been an email." We nod sagely when someone says "meetings are where work goes to die." But we still attend them. All of them. Religious. Like showing up late to a family function you didn't want to attend, but you go anyway because you're scared of what your aunt will say about you behind your back.

In tech, that aunt is your career.

Here's what actually runs through Raj's head when he sees that 14-person invite:

"If I decline, will people think I'm not a team player?"

"If I'm not in that room, will they make a decision about the dashboard that affects my work without my input?"

"Will someone mention my project while I'm not there? Will I lose ownership?"

"Will the Product Manager notice I'm absent and think I'm disengaged?"

"If I skip this, will I miss the one moment where the VP says something actually important? Like a reorg? A new tool? A free lunch?"

So he accepts. And at 2:00 PM the next day, he sits in a stuffy conference room (or a pixelated Zoom grid), silently dying inside while two senior engineers argue about button labels for the third time this quarter.

He contributes exactly one sentence: "Looks good to me."

And he leaves the meeting 47 minutes older, with no new information, three unread Slack messages, and the database migration still waiting for him.

The Real Cost of Showing Up

Here's what we rarely admit: the cost of Meeting FOMO isn't just wasted time. It's the mental load of recovery.

You don't just lose 47 minutes in that room. You lose another 20 minutes afterwards trying to remember what you were doing before you went in. You lose the flow state. You lose the deep focus that writing good code requires. You lose the will to live (slightly).

The meeting ends at 2:47 PM. By the time you've gone to the bathroom, refilled your water bottle, answered those three Slack messages, and opened your IDE again, it's 3:15 PM. You have maybe an hour and a half of decent work left before your brain starts feeling like scrambled eggs.

And for what? So Raj could say "Looks good to me" in front of 13 other people who also didn't want to be there?

The Magic Question

Here's what I've started doing. It's dangerous. It's radical. It might get me fired. But it works.

Before I accept any meeting invite with more than 6 people, I ask myself one question:

"If this meeting happened without me, would I care about the outcome?"

Not "would I be curious?" Not "would I have opinions?" But would I care?

If the answer is no, I decline.

Here's the script I use:

"Hey, thanks for the invite! I think this one might be better suited for [Project Lead] to weigh in on. I don't have much to add on this particular topic, but I'd love to see the notes afterwards. Let me know if there's anything specific you need from me."

That's it. That's the whole thing.

Nine times out of ten, the organizer replies with "No problem! I'll share the notes." And guess what? The notes never mention anything about the dashboard refresh. Because nothing was decided. Because it was a status update disguised as a decision meeting.

And Raj? Well, Raj still attends every meeting. He's still terrified. He still thinks showing up is the same as contributing.

But he's starting to notice something. The people who get promoted aren't the ones in every meeting. They're the ones who ship work between meetings. The ones who have time to think. The ones who protect their calendar like it's their last remaining brain cell.

And slowly, very slowly, Raj is learning to let go.

The Takeaway:

Your presence is not your contribution. Sitting in a room while other people talk doesn't make you valuable. It makes you furniture.

The next time a vague calendar invite shows up in your inbox, resist the urge to panic-accept. Ask yourself if you'd care about the outcome. Ask yourself if the meeting has an agenda. Ask yourself if the same information could be shared in a two-paragraph Slack message.

And then, if you're feeling brave, decline.

Your database migration will thank you.

The “Quick Sync” Black Hole: How “Just 5 Minutes” Is Quietly Eating Your Sprint

Om Keswani — Mon, 24 Aug 2026 18:27:41 +0000

It started with a Slack ping.

“quick sync? 5 min.”

I was three levels deep in a refactor, holding a mental model together with sheer willpower. The notification popped up like a jump scare. I typed “sure” because saying no feels like being difficult.

Forty-three minutes later, I was back at my desk, staring at the same line of code, trying to remember what I was doing before the interruption.

Then I did it again after lunch. And again before standup.

The calendar said I had three meetings that day. The calendar was lying.

Here’s what nobody tracks: the quick sync.

It doesn’t show up in velocity charts. It doesn’t appear in cycle time. It’s not a Jira ticket. It’s just a Slack message, a tap on the shoulder, a “you got a sec?” that feels harmless because it’s short.

But the cost isn’t the five minutes. The cost is the twenty minutes after — the context rebuild, the mental stack collapse, the quiet “where was I?” that happens when you finally return to your code.

Six quick syncs a day. That’s two hours of deep work gone. And your focus metric still says you’re fine because focus time only measures calendar blocks, not actual attention.

The dashboard is green. The work is bleeding.

The uncomfortable truth is that most quick syncs aren’t urgent. They’re a workaround for broken systems.

The answer wasn’t written down, so someone asked.
The decision wasn’t logged, so someone called.
The ownership wasn’t clear, so someone pinged.

The sync becomes the API for tribal knowledge. And every time you answer one, you’re not fixing the underlying problem — you’re just making the undocumented system feel a little more official.

I once watched a “5-minute alignment” with a PM turn into a scope change that never made it into the ticket. The developer implemented the new thing from memory. The old ticket said something else. The QA engineer flagged it as a bug. Three days of confusion, all because someone didn’t want to type out a decision in a comment thread.

So I started treating interrupts like incidents.

For one week, I logged every unplanned sync. The average was six per day. The total lost deep work was two hours. I showed the list to my team. Nobody had any idea.

The fix wasn’t more discipline. It was better defaults:

If it can be written, don’t say it.

If the answer lives in someone’s head, it’s not an answer — it’s a liability.

Protect deep-work blocks like you protect production uptime.

Before you type “quick sync?”, ask yourself: Is this actually urgent, or am I just avoiding writing it down?

If you absolutely must talk, batch it. Office hours for questions. A daily sync window after lunch. Not a dozen one-off interruptions disguised as collaboration.

The quick sync is a small tax that compounds quietly. It feels productive in the moment — you answered something, you helped someone, you were responsive. But it steals the one thing that actually ships software: uninterrupted thought.

If your team’s default answer to ambiguity is “let’s hop on a quick call,” you don’t have a communication culture. You have a documentation failure with a calendar invite.

Now if you’ll excuse me, I’m putting Slack on DND and writing this down.

The Documentation Lie: Why Your Wiki Is Actually Technical Debt

Om Keswani — Sun, 16 Aug 2026 08:45:28 +0000

The Confession

I didn’t sleep that night.

At 2:00 AM, my phone buzzed with a PagerDuty alert. The authentication service was down. Again. But this time, it wasn’t a code issue. It was a documentation issue—and it nearly cost us a $50,000 client.

Let me back up.

A junior dev named Arjun had joined the team three weeks earlier. Bright kid. Sharp. Eager. I pointed him to the "Getting Started" wiki and patted myself on the back for being such a thorough mentor. "Just follow the setup guide," I said. "It’s all in there."

He nodded, opened his laptop, and disappeared into the conference room.

Four hours later, I walked by and saw him staring at his terminal like it had personally insulted his ancestors. His face was pale. The screen was red.

"What’s up?" I asked.

He didn't look at me. "It says I'm missing the legacy environment variables. But I copied them exactly from the page. I even restarted twice."

I leaned over, glanced at the README, and felt my stomach drop.

That variable had been deprecated eighteen months ago. We had migrated to a new secret manager in Q4 of last year. The wiki still referenced the old vault. Arjun had been typing a dead API key into his .env file for three hours, thinking he was the problem.

He wasn't the problem. I was. The team was. The culture was.

The Genesis of the Fossil

I remember the day we wrote that wiki. It was the Friday before a major launch. The PM said, "We need documentation for the handoff." So we all grabbed a page, slammed some bullet points into Confluence, and called it a day.

It was never meant to be permanent. It was a temporary artifact to get us through the release.

But temporary artifacts in software engineering have a terrifying habit of becoming permanent infrastructure. The release happened. The pressure dropped. The team moved on to the next fire. And that wiki page—the one with the deprecated keys and the outdated Docker commands—sat there, untouched, gathering virtual dust.

Management loved it, though. They saw a full wiki and checked the "Knowledge Transfer" box on their quarterly roadmap. We looked organized. We looked professional.

We were neither.

The Slow Rot

Over the next year, we pushed forty-seven hotfixes to that service. We refactored the database connection three times. We switched CI/CD pipelines.

Guess how many times we updated the wiki?

Zero.

Every new hire got the same script: "Read the docs, ask questions if you get stuck." But "asking questions" just meant bothering the one guy who actually wrote the original service—a senior dev named Priya. She became the human search engine.

"Hey Priya, where's the new config?"
"Hey Priya, why doesn't this migration work?"
"Hey Priya, the staging environment is throwing a 500, any ideas?"

She handled it with grace for about six months. Then the grace turned into terse Slack replies. Then the terse replies turned into silent mode. Then she updated her LinkedIn profile to "Open to Work" and vanished into a competitor's office across town.

We threw a farewell party. We bought her a cake. We said, "We'll miss your expertise."

We never said, "We'll miss you because we forced you to be our living documentation, and we never wrote a single useful word to save your sanity."

The Climax (2:00 AM)

Which brings me back to 2:00 AM with the PagerDuty alert.

That night, the authentication service crashed because a new microservice was trying to read a token from the old secret location—because the developer who built the microservice read the damned wiki. He trusted it. He built his entire integration around a fossil.

When the token rotated, the microservice couldn't authenticate. The cascade failure took down user logins for three regions.

The fix took five minutes. It was just changing one environment variable.

But the damage—the lost sleep, the client screaming into the phone, the junior dev crying in the breakroom, the senior dev who quit because she was tired of being a walking encyclopedia—that damage took years of trust to rebuild.

The Brutal Realization

Documentation isn't a nice-to-have. It's not a "sprint 0 task." It is the UI of your team's brain. And if your UI is broken, your users (your developers) will hate you.

We made a new rule after that night. It wasn't complicated.

First, no PR gets merged if the corresponding wiki page doesn't get updated in the same branch. Same diff. Same review. Docs rot when they're decoupled from code. We coupled them with violence.

Second, we assigned documentation to the freshest person on the team. Not the senior. The junior. Because if a junior can't understand it, it's not clear. And if they update it, they actually learn the system in the process.

Third, and this was the hardest one—we killed the "just in case" docs. We deleted hundreds of pages. If it hadn't been viewed in six months, it went to the trash. We treated it like dead code. Because it was.

The Payoff

Six months later, a new junior joined. I walked over, opened the wiki, and watched him run the setup script.

It worked. On the first try.

He looked at me, confused. "That was it?"

I shrugged. "That was it."

He didn't know the war. He didn't know Priya. He didn't know the 2:00 AM panic. All he knew was that the documentation worked. And that, right there, was the most beautiful thing I'd seen in my entire career.

Documentation isn't about preservation. It's about liberation. It's about setting your seniors free to do actual architecture instead of answering DMs. It's about letting juniors ship without feeling like frauds.

Your wiki is either your greatest safety net or your greatest technical debt.

There is no in-between.

Got a "wiki horror story" that keeps you up at night? Drop it below. Let's trauma-bond.

The "Productivity" Dashboard That Measures Everything That Doesn't Matter

Om Keswani — Tue, 04 Aug 2026 16:11:39 +0000

The VP of Engineering stood at the front of the all-hands meeting, beaming as he projected the new "Developer Productivity Dashboard" onto the massive screen.

Lines of code committed per developer. Pull request cycle time. Tickets closed per sprint. Active hours in the IDE.

"Look at this," he said, gesturing triumphantly. "We've increased our output by 37% since last quarter."

Nobody clapped. The developers in the room exchanged glances—the kind that said we all know what's actually happening.

So I'll say it out loud.

We've built an entire industry around measuring things that don't matter.

The Dashboard Didn't Show

It didn't show the four-hour debugging session caused by rushed, untested code.

It didn't show the architectural debt accumulating because story points reward shipping, not designing.

It didn't show the junior developer who took three days to fix a bug caused by the senior's "efficient" work.

It didn't show the silent exodus of senior engineers who knew productivity theatre wasn't worth their sanity.

We're not measuring productivity. We're measuring activity. And we've convinced ourselves that's the same thing.

The Metrics That Actually Kill Teams

PR Cycle Time — Fast reviews mean shallow reviews. The best code review I ever received took four days. It found a race condition that would've taken down our payment system.

Ticket Closure Rate — We celebrate the developer who closes twenty tickets, ignoring that twelve of them were "fix spelling error" tasks. Meanwhile, the dev who closed five solved the root cause of fifty future tickets.

Lines of Code — My most productive week? I removed 3,000 lines. The dashboard showed "underperforming."

Active Hours in IDE — We don't track the two hours of thinking while walking around. We don't track the whiteboard session that saved three weeks of work. Thinking is the work. Coding is just how we capture it.

What Actually Matters

Here's what I wish we measured instead:

How quickly new engineers make their first meaningful contribution
Time wasted on context switching across poorly documented systems
How much cognitive load is required to keep things running
How many shipped features actually get used
Hours spent in flow state versus interrupt-driven chaos

You'll never see this dashboard. Because you can't put these on a slide deck. You can't show "cognitive load reduction" in story points. So we measure what's easy, optimize for what's measured, and wonder why everything feels broken.

The Quiet Truth

The most productive teams I've been on didn't have productivity dashboards. They had:

Senior engineers who said "slow down, let's think"
Cultures where asking questions was celebrated
Time for refactoring in every sprint
Reviews that were substantive, not fast
Permission to say "this isn't ready"

They looked slow by every metric. They shipped features that worked, rarely broke, and made customers happy.

So here's my question to every engineering leader:

The next time you look at your productivity dashboard, ask yourself: Am I measuring the work, or am I measuring the activity?

Because right now, we're building the wrong incentives. And real productivity—the kind that builds great software, grows great engineers, and makes customers actually happy—is quietly dying, one dashboard metric at a time.

P.S. — The dashboard was green. The product was failing. Customers were angry. And nobody asked why the numbers looked so good while everything felt so wrong.

The Dashboard Was Green. The Customers Were Angry.

Om Keswani — Wed, 29 Jul 2026 20:21:24 +0000

It started like every engineer hopes an ordinary Tuesday will.

No alerts.

No red graphs.

No pager notifications.

I opened our monitoring dashboard, expecting another quiet morning. CPU usage was steady. Memory looked healthy. Response times were comfortably within limits. Every service was glowing green, almost proudly.

Five minutes later, our support channel turned into chaos.

"Customers can't place orders."

"Payments are failing."

"The app keeps loading forever."

Within minutes, social media was filling with complaints.

The confusing part?

Our dashboards still insisted everything was fine.

For nearly an hour, we chased the wrong problem. We restarted services, checked logs, compared deployment histories, and searched for infrastructure issues that simply didn't exist.

The servers were healthy.

The product wasn't.

That day completely changed how I think about monitoring.

As engineers, we're taught to measure systems.

CPU utilization.

Memory consumption.

API latency.

Database connections.

Error rates.

These metrics are valuable because they tell us how our infrastructure is behaving.

But customers don't experience infrastructure.

They experience products.

A checkout page that spins forever because of a third-party integration might never trigger a server alert.

A search feature returning irrelevant results won't increase CPU usage.

A payment flow taking 25 seconds may technically succeed, yet the customer has already closed the tab and ordered from a competitor.

Your graphs stay green.

Your users quietly disappear.

And that's far more dangerous than a server crash.

A server outage gets everyone's attention.

A slow, frustrating user experience slowly erodes trust without making much noise.

After that incident, we stopped asking one question.

"Is the system healthy?"

Instead, we started asking a better one.

"Can a customer successfully do what they came here to do?"

That single question changed everything.

We began monitoring complete user journeys instead of isolated services.

Could a new user sign up?

Could someone complete a purchase?

Could a customer reset their password?

Could a user upload a file without retrying three times?

These weren't infrastructure metrics.

They were business metrics.

And surprisingly, they revealed problems our dashboards had been missing for months.

One of the biggest lessons I learned is that engineering teams often optimize for what is easiest to measure, not what matters most.

It's easy to build a dashboard showing CPU usage.

It's much harder to measure frustration.

There's no graph labeled "Customers almost gave up."

No alert saying, "Someone clicked the payment button six times before leaving."

No notification that says, "Your users no longer trust your product."

Yet those are the failures that cost the most.

Good monitoring tells you whether your servers are alive.

Great monitoring tells you whether your customers are succeeding.

Those are very different things.

The next time every graph is green, don't celebrate too quickly.

Open your product.

Walk through it like a first-time customer.

Try signing up.

Try making a payment.

Try searching for something.

Because sometimes the most expensive production incident is the one your dashboards never notice.

The dashboard was green.

The customers were angry.

And in the end, only one of them was telling the truth.

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.”