Why Mediocre Engineers Get Promoted Over Great Ones, According to a CEO

It's an uncomfortable claim, and it comes from someone who's done the promoting. On the Beyond Coding podcast, host Patrick Akil sat down with Anand Sahay, global CEO of Xebia, to unpack a pattern many engineers have felt but rarely hear named: the most technically brilliant people often aren't the ones who move up. The conversation isn't a put-down of great engineers — it's an argument for why they need to change how they operate, for their own sake and everyone else's.

Everything below reflects what Anand and Patrick discussed in the episode.

The Promotion Logic Nobody Says Out Loud

Anand put the management perspective bluntly: "We are better off with mediocre engineers — at least they will listen to us." His point wasn't that mediocrity is good. It's that the most gifted engineers — often the ones who started coding at ten and made it part of their identity — can become difficult once outcomes enter the picture. Everything becomes about what's interesting to them, and the business outcome takes a backseat.

A more business-conscious, agreeable engineer is easier to work with, so they get pulled up the hierarchy. The catch, Anand stressed, is that "the optimal solution gets lost." Projects finish on time and on budget, but whether they delivered the best possible result quietly disappears. And when those merely-adequate engineers eventually reach CIO or CEO level, the impact on the organization — and, as he kept emphasizing, on society as every function becomes tech — can be devastating.

So What Should Great Engineers Do?

His prescription is not "be less technical." It's to add a business-outcome mindset on top of the craft. Great engineers, in his view, should climb into CTO, CIO, and general-management roles, or go start companies and change the world. The world loses enormously when they don't. But they often need a mentor to learn this early, before they harden into the "it's not for me, I just want to code" posture.

This connects to a humility point Anand returned to repeatedly: engineering brilliance can curdle into arrogance. Strong engineers start believing they understand finance, management, even the CEO's job better than the specialists. His antidote is to respect that people in other fields have their own intelligence — and to genuinely learn how money flows. He said he'd love every great engineer to spend a week embedded in the finance function. The ones who do, he believes, become the future very quickly.

Speak Simply, Especially at the Top

If there's one tactical lesson, it's about communication. The engineering leaders who excel, Anand said, are the ones who can lucidly explain why something needs doing and what real outcome it produces. The moment a pitch turns into a dense "tech doc," he gets worried. His example was microservices: every engineer a couple of years ago wanted to build them, and his question was always, "but do you really need a microservice?"

His blunt rule: don't give a business case in tech language. Make it simple. Compare and contrast the options, then show the savings or value to the customer. Leaders will still do their homework afterward — a bit of reading, a call to a trusted technical friend — but they need to be able to visualize what you mean first.

Context Is the Whole Game

A theme that surfaced again and again was that the same solution has wildly different value depending on context. Automating away five roles in the Netherlands is worth a great deal; the identical application in India, where labor and resources are cheaper, has a different equation entirely. He described a fraud-detection conversation in Vietnam where a customer pointed out that 50 skilled humans caught fraud better than automation could — making the human team the lower total-cost-of-ownership choice. Senior people, Anand argued, have to understand these cost structures and where the money actually flows. Financial architecture has a direct bearing on how software gets built.

AI Doesn't Remove the Need for Judgment — It Raises It

Both speakers see AI sharpening this divide rather than erasing it. Anand noted that polished model output "always looks true," which is exactly the trap. He can tell instantly when someone has pasted a superficial answer, because the cracks show under a couple of pointed questions. The people who do their homework become more credible as others cut corners.

The shared advice was simple: AI is a tool, and your value has to sit on top of it. If you just commit whatever the tool produces, you've added nothing — and if it's wrong, you're worse than nothing. The differentiator becomes strong fundamentals, careful reviews, governance, and "more reading than ever before." You can only interpret an AI's output well, Anand pointed out, if you're a strong enough engineer to judge it.

Conway's Law, Org Design, and Where to Work

One of the most practical ideas was a restatement of Conway's Law: a system ends up mirroring the communication structure of the teams that build it. Split your people into a frontend team and a backend team and you get a frontend architecture and a backend architecture; add a separate security team and security gets bolted on at the end. Anand sees this as a quiet root cause of project failure — and an argument that tech-literate people, not just non-technical managers, should help decide how organizations are structured.

For ambitious engineers choosing where to work, his advice was clear: go somewhere technology is treated as an asset and a partner, because you'll get the room and time to grow. Where the culture is "us versus them" and tech is seen as a cost to be tolerated, he wouldn't even try to fix it — he'd just go elsewhere.

Intuition, Iteration, and Staying Human

Two closing ideas rounded out the picture. First, on staying current as you rise: you can't keep up by running personal projects forever — there's simply too much. You build intuition from strong fundamentals and deep engagement with your team, and Anand found his intuition was rarely far off; the homework just calibrates it. Acting rigidly on ten-year-old experience is the real risk.

Second, on enabling people: he sometimes funds an idea purely for morale, usually as a smaller bet. But his test is elegant — ask people to build the hardest, most important part first. By his account, roughly half walk away the moment they're asked to tackle the difficult core, which makes it a cheap way to test both the idea and the person's passion. As CEO, he keeps his number on WhatsApp and Teams because he's convinced the best future ideas bubble up from the bottom, from "any part of the world," not down from the top.

The throughline of the whole conversation: the craft of engineering is necessary but not sufficient. The engineers who pair it with curiosity about outcomes, money, and people are the ones who rise — and the ones the world most needs at the top.

---

Originally published on Beyond Coding. Watch the full episode: https://www.youtube.com/watch?v=4vmxCzhYmwo