A while back I met an old colleague for cocktails. We do this every so often - two people who have seen enough server rooms and steering committees to know that the best incident reviews happen over a Negroni.
He was in a great mood. His company's vibe coding (quickly developing software using AI like Claude without writing (or sometimes even understanding) the code itself) adoption was through the roof. And not just among developers - consultants, architects, support engineers, basically anyone with a pulse and a Claude license was building tools. Management was celebrating. They threw around numbers like trophies: one engineer burned through 100 dollars a day in tokens. Applause. High fives. Slide decks.
And honestly? Fair enough. If a 100-dollar-a-day token bill produces a tool that saves ten hours of engineering time per week, that's the cheapest employee you ever hired. I am not here to rain on token budgets. Fun fact on the side: "vibe coding" went from a casual Karpathy tweet to Collins Dictionary Word of the Year within roughly twelve months. That's faster adoption than most companies manage for a new expense tool.
But while my colleague was celebrating, I was doing what 20+ years in support trenches trains you to do: listening for the alarm underneath the applause.
Picture the annual all-hands. A slide appears: "80% of the company is happy to work here. Our department: 83%. We are 3 points above average!" Applause. Someone books a team lunch.
Now run that logic forward a few years. "50% of the company is happy. Our department: 54%. Still beating the average!" Same slide, same applause, and half your people are updating their CVs during the meeting. That's the beauty of relative benchmarks: you can be the tallest passenger on a sinking ship and still get a trophy for it.
I've watched this ritual for over two decades in companies large and small, and I'm still not sure whether upper management genuinely doesn't see through it or just enjoys the theater. Either answer is uncomfortable. So let me walk you through why your ESAT is almost certainly measuring the wrong things - and what actually tells you whether your people are one bad Monday away from resignation.
Problem 1: You're benchmarking against a falling reference point
Comparing your department against the company average tells you exactly one thing: your relative position in a distribution you don't control. If the whole company slides into misery, your "above average" score slides with it, and the slide deck still looks green.
It looks like a bug, but it's a feature. Every company I've consulted for has one. Some variation of a queue assignment system - either a duty manager eyeballing tickets or some clever algorithm that claims to balance load. And in every single one, there's a small group of engineers who get absolutely hammered with new work. Not by chance. By design.
You try to fix it. Adjust the weights, add a cap, introduce a "max queue depth" rule. It works for a week. Then the algorithm finds its way back to the same victims. The duty manager, faced with pressure to clear incoming tickets, falls back on the one person who actually closes things fast. The poor souls eventually give up and accept that the system just loves them. Or hates them.
These people share one trait: they are power horses 🐎. They work fast. They empty their queue. And as a reward, they get more work. A bigger queue. A fresh pile of tickets waiting for them on Monday morning, while the guy who sits on his inbox for three days gets exactly one new item. The math is brutal.
But the real damage is what this does to their capacity. They never get to participate in projects, initiatives, or cross-team improvements. They can't even start their own. Their entire day is reaction. Meanwhile, the sloths - the ones who prioritize their side gigs or their LinkedIn presence over their actual queue - generate noise. Lots of it. They show up to meetings, volunteer for pet projects, write proposals that never ship. Management loves noise because it's cheap filler for charts and slides.
How Bureaucracy and Broken Recognition Killed Productivity
I walked into a mid-sized tech company a while ago expecting to find a classic story.
They had done everything right. Deployed AI agents. Integrated KCS workflows. Set up sophisticated collaboration platforms. The brochure checklist was complete. Management was baffled because their investment had produced the exact opposite of what they wanted.
Engineers were complaining about high workload. Vehemently. The kind of complaining that kills morale and spreads like a cold in an open office.
But here is where it got interesting. The volume was actually down. Significantly. The AI agents and self-service workflows were deflecting the easy stuff before it ever reached a human. The ticket count had dropped by a healthy margin.
The problem was that the remaining work was harder. The easy fruit had been picked. So each ticket now required more in-depth investigation, more context switching, and heavier cognitive load. But that alone did not explain the misery.
After two weeks of 1:1s and quiet observation, I found the real killers. Two of them. And they are a lot more common than leaders want to admit.
The first killer was bureaucracy dressed up as process.
The company had grown from startup chaos into something that needed structure. That is fine. But somewhere along the way, structure became an end in itself. Every action required documentation. Every decision needed a sign-off. Every change had to go through a review board that met once a week.
You know the scene. Klaus (or whatever name your local power horse goes by) has been carrying the team for 18 months. Bug fixes, feature work, on-call rotations, mentoring the new grad, troubleshooting the architecture mess the previous lead left behind. He does it all with quiet competence. The quarterly IDP comes around. His manager beams: "Klaus, we're promoting you to Distinguished Engineer." Handshake, new title in the HR system, a 7% bump and a vague promise of "broader responsibilities."
Fast forward three months. Klaus is drowning. He still does everything he did before, plus the project planning, the cross-team alignment meetings, the compliance documentation, and the performance review feedback for his peers. He has no more authority. He has no more decision rights. He just has more work. The new title was a horizontal shuffle dressed up as a promotion. And now he's a pack mule, not a power horse.
I watched this happen at three different companies over the years. Always the same pattern: brilliant individual contributors get "promoted" into roles that expand their scope horizontally without giving them any real leverage. They don't get a seat at the table. They don't get budget authority. They don't get a voice in strategy. They get an extra hour of meetings each day and a new section in the org chart that just means more people can dump work on them.
Picture the company wiki on a random Tuesday. It launched two years ago as the single source of truth - clean architecture diagrams, battle-tested runbooks, and troubleshooting flows that actually worked. Everyone cheered at the kickoff. Leadership called it "our knowledge superpower."
Fast-forward to now. The same wiki is a digital landfill. Half the pages are outdated by three major releases. The troubleshooting guide for the most common outage still references a database that was decommissioned in 2023. Search results are 90 percent noise. Your best power horse 🐎 just spent forty-five minutes reconstructing the answer from memory and Slack screenshots because the "official" doc was worse than useless.
You've seen this movie. We all have.
I watched it happen live at a mid-sized SaaS company that prided itself on being "process mature." We built a beautiful shared knowledge base right after a painful outage season. The power horses poured real effort into it - clear language, working examples, even a little dry humor in the edge-case sections so the next person wouldn't want to throw their laptop out the window.
Then the tragedy began.
Nobody owned it.
Sales reps started dumping half-finished notes from customer calls: "Check the log for error XYZ (more details later)." Product managers added shiny new feature overviews that were accurate for exactly eleven days. The sloths - those lovable beige creatures who move at the speed of bureaucracy - discovered they could copy-paste a ticket comment, hit "publish," and call it documentation. No one ever went back to fix, test, or delete the garbage. Why would they? Updating the commons cost them their own time and delivered zero personal points on the performance review.
TrenchOps 🐎 
