I’ve been in IT for over 20 years, and many many times I’ve felt the specific kind of tired that comes from working inside enterprise software built for the people who approve the budget, not the people who do the work.
I’m sure you know the feeling. The dashboard that looks great in the steerco deck. The extra fields you have to fill in “for visibility.” The status update that exists purely so someone two levels up can feel informed. None of it makes the work easier. Most of it makes the work slower. But it looks good in a screenshot in a slidedeck, so it continues to survive without a purpose.
A few weeks ago, a company reached out to me to help promote and sell their new product. On the surface, it was polished: nice UI, an LLM woven in, real-time reporting and the whole shebang. But as the demonstration continued and I looked closer, here’s what it actually did: it took data that already existed, repackaged it into new dashboards, and then layered LLM-generated badges and auto-created “actions” on top of them and assigned straight to individual employees, without them asking for it, without them designing it, without them wanting it. To make it even worse, this was all done without ANYONE asking for it or designing for it. Zero value add, but a lot of artificial busywork.
That’s not innovation, nor is it a productivity booster. That’s surveillance with a chatbot bolted on. It’s the same old management-first, engineer-last playbook that we have seen from other vendors, just with a more convincing coat of paint. And of course it has an LLM, so who can be against progress, am I right?
And it’s not just this one company. Look around and you’ll recognize the same DNA in tools we all use every day. Jira, configured by enterprise IT into a maze of mandatory fields, workflows, and approval gates until logging a day’s work takes longer than the work itself. ServiceNow, which was supposed to streamline IT service management and instead became synonymous with ticket-routing hell. Salesforce, endlessly customizable, so every organisation bolts on another layer of mandatory fields and validation rules until updating a single record takes five minutes and three people’s sign-off. None of these tools are evil. But in enterprise hands, they consistently get pointed at the same target: more visibility for management, more friction for the people entering the data.
INITIAL RANT OVER: Here’s the part that actually worries me: this isn’t a one-off. It’s a pattern I’ve watched play out for two decades, and I think we’ve all seen this movie before.
We did this to Agile. We did this to DevOps.
Agile was supposed to be about empowered teams, short feedback loops, and trust. DevOps was supposed to break down the wall between building and running software, so the people closest to the problem could move fast and own the outcome.
Look at what enterprise did to both. Agile became a calendar full of ceremonies nobody asked for, story points weaponized as productivity metrics, and standups that turned into status reports for someone who isn’t even in the room. I’ve sat in “15-minute” standups that ran 45 minutes because a manager wanted a verbal report on every ticket instead of trusting the team. DevOps became a compliance checklist and a wall of dashboards measuring deployment frequency for people who’ve never deployed anything in a production environment. I’ve seen teams slow their release cadence on purpose because a “velocity” metric was being read by leadership as a proxy for effort, and nobody wanted to look “too fast” one sprint and “too slow” the next.
The ideas weren’t wrong. They got captured. Stripped of the trust and autonomy that made them work, and rebuilt as control mechanisms wearing the original name as a costume.
Why does this keep happening?
Because it’s easy to spend money that isn’t yours on things that don’t impact you.
The person signing off on a new “productivity platform” isn’t the one who has to use it eight hours a day. They see a dashboard, a projected ROI, a promise of “visibility” and “alignment.” It looks like control, and control feels like progress. Meanwhile, the actual cost, the friction, the extra clicks, the erosion of trust and of course most importantly, the message it sends to your best engineers that they’re being watched instead of trusted, gets paid entirely by the people who had no say in the decision.
To be fair, I don’t really think it is malicious. It’s just that the pain and the purchase happen to two completely different groups of people. That gap is where all of this bad tooling lives.
So what’s the actual fix?
Here comes the hard and controversial take: Less control. Fewer metrics for the sake of metrics. Full stop.
As an industry we need to stop being activity-driven, task-driven, or worst of all offenders KPI-driven, and we have start being outcome-driven. Not “how many tickets did you close” or “what’s your commit count” or “did you fill in the status field,” but: did the thing we actually care about get better? Is the customer’s problem solved? Is the system more reliable? Did the team remove the obstacle that was slowing them down? Are we in a happier and better place than before?
Outcome-driven thinking trusts people to figure out the how while activity and KPI-driven thinking assumes people can’t be trusted and tries to compensate with surveillance. One of these builds better engineers and better software. The other just builds better-looking slides.
This is exactly why we built Kalibran differently.
At Kalibran, our approach, “Team Topologies combined with AI” moves in the opposite direction from what I described above. It’s not a productivity-measuring tool. It’s not built for management or the steerco first. It’s built for the engineers and the dev teams, to help them resolve the obstacles they actually face, faster and together with the assistance of the AI that’s fully contextualized to their organization and their team, not a generic model dropped in from outside.
The way forward isn’t more micromanagement dressed up as intelligence. It’s enablement and acceleration for the people doing the real work.
So here’s my challenge to leaders reading this:
Next time a vendor shows up with a beautiful dashboard and a slide full of AI-powered insights, ask them the question they don’t expect: How exactly is this going to make life easier and reduce work for the people doing the actual work, every single day?
If they can’t answer that clearly, walk away. And if you want help having that conversation, pressure-testing a vendor, or figuring out what genuine engineer-first enablement looks like for your organization, Kalibran is here for that too.
You don’t need to buy our product. You just need to stop buying the products that make engineers’ lives miserable.
