Why Mediocre Engineers Get Promoted Over Great Ones (CEO Explains)

Key Insights

1. 1

   The uncomfortable logic of who gets promoted

   Anand voiced the perspective of non-tech management: "we are better off with mediocre engineers — at least they will listen to us." He argued great engineers often fixate on what's technically interesting to them while business outcomes take a backseat, which makes them harder to work with — so the more business-conscious, agreeable engineers tend to move up.

2. 2

   But the loss from that is enormous

   Anand called this pattern a huge loss to organizations and society, because the optimal solution gets lost when non-technical managers run the show. His conviction: great engineers should grow into CIO/CTO and general-management roles (or start companies), and they need mentoring early to think in terms of outcomes rather than retreating into "it's not for me."

3. 3

   At senior levels, lucid simplicity wins

   He said the engineering leaders who excel are the ones who can clearly explain why something needs to be done and what real outcome it delivers. Drowning people in complexity — turning a pitch into a "tech doc" — is a red flag. His blunt advice: don't give a business case in tech language; just make it simple.

4. 4

   Context is everything — total cost of ownership

   Anand stressed that the same application has different value depending on context. Automation that removes five people in the Netherlands is worth far more than in India, where labor is cheaper; in a Vietnam fraud-detection example, keeping 50 skilled humans had a lower total cost of ownership than automation. Senior people must understand these cost structures.

5. 5

   AI is a tool — your value sits on top

   He warned that polished AI output "always looks true," but superficial pasted answers reveal cracks under questioning. If you just copy-paste the tool's output, you add no value and become replaceable — or worse, if it's wrong. The edge comes from fundamentals, reviews, and "more reading than ever," taking ownership of the outcome.

6. 6

   Two career paths, both multipliers

   Anand and Patrick framed two routes: stay a senior individual contributor (people come to you, you stay hands-on, you sit in the org's "think tank") or climb into management/C-level (an amplified multiplier). The example of staff engineers taking the highest-risk projects showed how senior ICs deliver org impact without managing people.

7. 7

   Beware engineering arrogance

   A recurring caution: strong engineers can start believing they understand finance, management, or the CEO's job better than the specialists — bordering on arrogance. Anand argued you must respect that people in other fields have their own intelligence, and learn their point of view; he'd love every great engineer to spend a week inside the finance function.

8. 8

   Conway's Law: your org becomes your system

   Anand described how a system mirrors the communication pattern of the units that build it — a separate frontend and backend team produce a frontend and a backend architecture, and a separate security team bolts security on at the end. He sees this as a root cause of project failure, and an argument for tech-aware people shaping org structure.

9. 9

   Choose an organization where tech is an asset

   His advice to ambitious early-career engineers: join a company where technology is treated as a partner and asset, because you'll get room and time to grow. Where it's "us versus them" and tech is seen as a cost or liability, he said it's often too far gone to fix — better to go elsewhere.

10. 10

    As you rise, trade hand-checking for grounded intuition

    Anand noted that senior leaders can't stay current by running personal projects — there's too much. Instead you build intuition from strong fundamentals plus deep engagement with your team. He found his intuition was rarely far off; the homework afterward just calibrates it. Acting rigidly on decade-old experience, by contrast, is the real danger.

11. 11

    Fund passion sometimes — but test it with iteration

    He admitted sometimes funding an idea purely for morale even without a compelling case, often as a smaller bet. His filter: ask people to build the hardest, most important part first. By his account, roughly half walk away when told to tackle the difficult core — a quick, cheap way to test both the idea and the person's passion.

12. 12

    His path: tech to sales to CEO

    Anand traced his route from engineer through sales (after an MBA) to CEO rather than CTO. Understanding what customers actually wanted — and being pragmatic about whether their funding was for maintenance or revenue generation — made his proposed solutions attractive. As CEO he stays accessible (his number is on WhatsApp and Teams) because, he believes, future revenue ideas surface bottom-up.

Chapter Breakdown