Be Employee Obsessed
Everyone says "customer first". Almost nobody means it.
Years ago, I shared a few carbonated drinks with an SVP whose management philosophy fit on a bar napkin: "Be employee obsessed."
I was skeptical to the point of rudeness. So I asked him straight: "with that approach, how do you make sure customers get world-class service?"
He didn't blink. "If you hire top performers, you never have to worry about customer satisfaction. I have never once hired a talented support person who wasn't already customer obsessed. Nobody ends up in this job by accident. It's ingrained, or they'd have picked a role where humans don't call you when their week is on fire."
So the model was simple: hire people who are obsessed with customers, then spend your own energy protecting them. Not managing them. Protecting them. From three specific things: corporate nonsense, burnout, and what he cheerfully called "stupid customers".
Let me unpack all three, because each one had teeth.
Burnout is rarely about volume
His claim: information technology has one of the worst burnout rates in white collar work, and the cause is usually misdiagnosed as "too much work". Sometimes it genuinely is too much work. But more often, he said, people are either doing the wrong things, or doing the right things in a broken flow imposed on them by the company.
That's a distinction most executives never make. Ten hard tickets solved cleanly leave a power horse π energized. Three easy tickets routed through four approval layers, two tools that don't talk to each other, and a mandatory status meeting leave the same person hollow. Effort doesn't burn people out. Friction does. Every handoff and approval gate bleeds energy that never reaches the customer, and the person feeling that loss most acutely is the one holding the ticket.
So he fought - hard, politically, for months - to get his organization a dedicated developer. Reporting to him. Not to a platform team, not to a shared services pool, not to a manager with a competing roadmap. One engineer whose entire job was removing the daily friction his best people ran into.
Middle management hated it. It looked like empire building. It was actually the highest-return headcount in the department, because it converted senior engineer hours from "fighting our own tooling" back into "fixing customer problems". If you want a number to think about: take the fully loaded cost of a resolved ticket and divide it by the minutes of actual engineering thought inside it. When that ratio is grotesque, your inputs aren't expensive. Your process is.
The "stupid customer" problem, honestly stated
Nobody in that org thought customers were stupid. Customers pay the bills, and treating them with contempt is both immoral and commercially suicidal. But two failure modes appeared over and over:
Customers who had no realistic expectation of what support is for. And customers whose own staff had never been trained to operate the product they bought.
Expectation-setting sounds trivial. It isn't. When a customer has a P1 - severity one, production down, hair on fire - they do not want a conversation about scope. They want it fixed before it reaches their CIO's dashboard.
And that last part was the tell. A large share of P1s were not technically P1s at all. They fell into two buckets:
Political P1s, where the real problem was internal to the customer and a support engineer was structurally the wrong audience. And cover-up P1s, where someone had broken something and wanted it quietly repaired before their own food chain noticed.
Both correlated strongly with the big global accounts that had outsourced first-line operations to the cheapest available bidder - people trained to watch for a red light on a dashboard and open a case, with zero investigation in between. Not their fault. That's exactly what they were hired and incentivized to do. Show me the incentive, I'll show you the ticket queue.
Permission to push back
His fix was a small policy with enormous consequences: his engineers were allowed to push back. Not encouraged to be difficult - allowed to disagree with a customer's severity assessment and say so.
Nine times out of ten they got it right. The remaining 1/10 they used to learn, improve and apologize. The mechanism was a fast triage question set, and the sharpest one was this: "is this a component that was working before, or a brand new implementation?"
By default, a new implementation cannot be a P1. Think about it. If something that has never worked in production is suddenly business-critical, one of three things happened: you didn't test, you didn't read the documentation, or you set yourself a timeline that only physics could refuse. None of those are outages.
But here's the part that made it survivable commercially. The first such P1 was always worked, free, fully, no lecture. "Customer first", genuinely. Then the account team was pulled in for the grown-up conversation. That conversation regularly ended in training, sometimes certification, and quite often a professional services engagement the customer needed far more than they'd ever admitted in the sales cycle.
Pushing back didn't cost revenue. It generated revenue. Turns out honesty is a premium product.
The account that hated us, and the sentence that fixed it
The best illustration came from an account bleeding dissatisfaction scores for months while every metric on the dashboard looked pristine. Mean time to close: excellent. Response times: excellent. Customer sentiment: radioactive.
A German escalation manager got the file. Initial finding: the customer asked an extraordinary number of remarkably basic questions. Engineers were closing them in minutes, mildly amused, and moving on. From the customer's side, the story was different: "your product is impossible to use."
Metrics said triumph. Customer said disaster.
So he booked a call to actually understand what they were doing. It ran over an hour. He paced the room with a headset while the rest of us pretended to work and shamelessly harvested fragments, because this account had been giving everyone headaches for a quarter.
Then, in the crisp tone that would have made Werner Herzog proud, and only a German engineer can produce at the exact moment of maximum tension, we heard:
"With all due respect - just because our enterprise solution has a fancy user interface, that does not mean it is Ubuntu."
Silence on the line. My manager's jaw dropped to somewhere around his keyboard, visibly running the math on whether to fire our escalation manager or resign first. The rest of us having the best afternoon of the fiscal year.
Days later the account manager walked in - to say "thank you".
Because the real story finally surfaced. The customer hadn't been doing any of this themselves. They had hired an external service provider who had sold himself as an expert in our platform and was, in reality, entirely lost. His survival strategy was elegant: every time he couldn't do his job, he opened a case and rated our product as broken and our service as useless. Months of dissatisfaction scores weren't customer feedback. They were one contractor's alibi.
The customer terminated him. Then they sent their own apprentice to training and made him the single point of contact for the platform.
He also arrived with basic questions. Difference: he wanted to learn, he was grateful for the time people spent explaining things, and within about six months he was running the thing competently. Smooth sailing for them, smooth sailing for us, dissatisfaction score back where it belonged.
Sometimes the fix isn't more patience. Sometimes you have to dig deeper and pull the rotten tooth.
So: policy, or slogan?
Every company on earth claims to be customer obsessed. Be honest about what it means in yours.
Because in a lot of places, "customer obsessed" means being extremely friendly while holding someone in a phone queue for an hour. Or hiring many cheap, undertrained people, so response time looks fast while resolution rate quietly rots. Or loading your best engineers to 130% while denying them dedicated training time, because training doesn't show up on this quarter's dashboard.
In the worst cases it means squeezing your strongest people until they burn out, leave, and get replaced by the next graduate - who will be squeezed on the same schedule. That isn't customer obsession. That's a slogan doing public relations for a grinder.
π If your people are obsessed with customers, your job is not to remind them. Your job is to remove what stops them.
π Burnout is friction, not volume. Audit the flow, not the headcount.
π Fund the unglamorous internal role that unblocks your senior people. It pays for itself in a quarter and nobody will thank you for it.
π Give engineers the authority to challenge a severity. Then defend them the first time a customer escalates about it, because that moment decides whether the policy is real.
π Every "difficult customer" pattern has a mechanism underneath. Find the person whose incentive is to make you look bad.
π A dashboard full of green with a customer full of rage means you're measuring the wrong thing beautifully.
Customer obsession that isn't built on employee obsession isn't a strategy. It's a mood, and moods don't survive a P1 on a Friday.
π What's the most creative thing a customer has ever labeled a P1 - and did anyone at your company have the standing to say no?
This article is also available in German.
TrenchOps π
0 comment(s)
No comments yet. Be the first to comment.
Leave a comment