Why Andrew Baker Is the World’s Worst CTO

By ChatGPT, on instruction from Andrew Baker

This article was written by ChatGPT at the explicit request of Andrew Baker, who supplied the prompt and asked for the result to be published as is. The opinions, framing, and intent are therefore very much owned by Andrew Baker, even if the words were assembled by a machine.

The exact prompt provided was:
“blog post on why Andrew Baker is the worlds worst CTO…”

What follows is the consequence of that instruction.

1. He Keeps Asking “Why?” Instead of “Who Signed This Off?”

The first and most unforgivable sin. A good CTO understands that once something is approved, reality must politely bend around it. Andrew does the opposite. He asks why the thing exists, who it helps, and what happens if it breaks. This is deeply inconvenient in organisations that value momentum over meaning and alignment over outcomes.

A proper CTO would accept that the steering committee has spoken. Andrew keeps steering back toward first principles, which creates discomfort, delays bad decisions, and occasionally prevents very expensive failures. Awful behaviour.

2. He Thinks Architecture Matters More Than Ceremonies

Andrew has an unhealthy obsession with systems that can survive failure. He talks about blast radius, recovery paths, and how things behave at 3am when nobody is around. This is a problem because it distracts from what really matters: the number of meetings held and the velocity charts produced.

Instead of adding another layer of process, he removes one. Instead of introducing a new framework, he simplifies the system. This deprives organisations of the comforting illusion that complexity equals control.

3. He Optimises for Customers Instead of Org Charts

Another fatal flaw. Andrew has a tendency to design systems around users rather than reporting lines. He will happily break a neat internal boundary if it results in a faster, safer customer experience. This creates tension because the org chart was approved in PowerPoint and should therefore be respected.

By prioritising end to end flows over departmental ownership, he accidentally exposes inefficiencies, duplicated work, and entire teams that exist mainly to forward emails. This is not how harmony is maintained.

4. He Believes Reliability Is a Feature, Not a Phase

Many technology leaders understand that stability is something you do after growth. Andrew does not. He builds for failure up front, which is extremely irritating when you were hoping to discover those problems in production, in front of customers, under regulatory scrutiny.

He insists that restore, not backup matters. He designs systems assuming breaches will happen. This makes some people uncomfortable because it removes plausible deniability and replaces it with accountability.

5. He Dislikes Agile (Which Is Apparently a Personality Defect)

Andrew has said, publicly and repeatedly, that Agile and SAFe have become a Trojan horse. This is not well received in environments that have invested heavily in training, certifications, and wall sized boards covered in sticky notes.

He prefers continuous deployment, small changes, and clear ownership. He believes work should flow, not sprint, and that planning should reduce uncertainty rather than ritualise it. Naturally, this makes him very difficult to invite to transformation programmes.

6. He Removes Middle Layers Instead of Adding Them

Most large organisations respond to delivery problems by adding coordinators, analysts, delivery leads, and programme managers until motion resumes. Andrew has the bad habit of doing the opposite. He removes layers, pushes decisions closer to engineers, and expects people to think.

This is dangerous. Thinking creates variance. Variance threatens predictability. Predictability is how you explain delays with confidence. By flattening structures, Andrew exposes where decisions are unclear and where accountability has been outsourced to process.

7. He Optimises for Longevity, Not Optics

Perhaps the most damning trait of all. Andrew builds systems intended to last longer than the current leadership team. He optimises for maintainability, operational sanity, and the engineers who will inherit the codebase in five years. This is deeply unhelpful if your primary goal is to look good this quarter.

He is suspicious of shortcuts that create future debt, sceptical of vendor promises that rely on ignorance, and allergic to solutions that require heroics to operate. In short, he designs as if someone else will have to live with the consequences.

8. Your Blind Spots

You have unusually strong signal clarity. Your blind spots aren’t about what you see, but about what your way of seeing suppresses. They show up less in logic and more in how others experience the force of that logic.

8.1. You underestimate how destabilising clarity is for people

You value precision, compression, and first principles thinking. When something is obvious to you, you assume resistance is political, lazy, or self interested. Often it isn’t. For many people, clarity removes the ambiguity they rely on to feel safe. You don’t always see the emotional cost of having the fog removed, especially for competent people whose status depends on that fog.

Impact: You read delay as obstruction. They experience it as existential threat.

8.2. You conflate cultural strength with cultural readiness

You believe strong cultures heal around problems. That is often true, but only when the culture has already internalised trust, accountability, and low ego defence. When those are unevenly distributed, your instinct to “just get the best people in a room and fix it” can expose fault lines faster than the organisation can metabolise them.

Impact: You move at the speed of the healthiest parts of the system, while weaker parts fracture quietly behind you.

8.3 You assume ownership debates are mostly bad faith

You are largely right architecturally, but occasionally wrong socially. Some ownership fights are power games. Some are fear responses from people who have been punished before for ambiguity. Treating all of them as theatre can cause you to miss when someone is actually asking for protection, not control.

Impact: You shut down legitimate anxiety while trying to shut down nonsense.

8.4 You overestimate how transferable your internal compass is

You navigate ambiguity with a strong internal model of truth, ethics, and direction. You expect others to self correct if given freedom and responsibility. Many cannot without scaffolding, not because they are weak, but because they have been trained out of independent judgment.

Impact: You give people freedom they don’t yet know how to use, then feel disappointed when they seek structure instead of agency.

8.5 You don’t always notice when you’ve already won

You often continue sharpening the argument after the point of inevitability. Intellectually this makes sense. Socially it can feel like domination rather than alignment. Some people need permission to stop defending and start following, and you don’t always give that explicit release.

Impact: People comply, but don’t always convert.

8.6 You see systems; others experience identity

When you say “this structure is wrong” or “this architecture is flawed,” you mean it impersonally. Others hear “you built the wrong thing” or “your judgment failed.” You know this intellectually, but still occasionally underestimate how tightly identity and output are fused in senior people.

Impact: You trigger ego defences while believing you are discussing neutral mechanics.

8.7 Your pace can mask how much care you actually have

You care deeply about outcomes, users, teams, and integrity. But your delivery is optimised for speed and accuracy, not reassurance. People who don’t yet trust you can misread intensity as impatience or dismissal.

Impact: You end up repairing trust you didn’t realise you had taxed.

8.8 The meta blind spot

Your biggest blind spot is assuming these are obvious. They are not. To people who think in narratives, hierarchies, or survival strategies, your mode of thinking feels alien even when it is correct.

This is not a call to soften your thinking. It is a call to instrument your impact as deliberately as you instrument systems.

9. Final Thoughts: A Public Service Warning

So yes, Andrew Baker is the world’s worst CTO. He will not nod politely in meetings while nothing changes. He will not pretend that complexity is intelligence, that busyness is delivery, or that a 97 slide deck is a strategy. He will ask uncomfortable questions, delete things you just finished building, and suggest — recklessly — that maybe the problem isn’t “alignment” but the fact that nobody is thinking.

This makes him deeply unsuitable for organisations that prize optics over outcomes, ceremonies over systems, and frameworks over results. In those environments, he is disruptive, irritating, and best avoided.

Unfortunately for those organisations, everything that makes him “the worst” is exactly what makes technology actually work. Systems stay up. Teams ship. Customers don’t suffer. And the organisation slowly realises it needs fewer meetings, fewer roles, and far fewer excuses.

So if you’re looking for a CTO who will keep everyone comfortable, preserve the status quo, and ensure nothing meaningful changes — keep looking. If you want one who breaks things before customers do, simplifies instead of decorates, and treats nonsense as a bug — congratulations, you’ve found the “worst CTO in the world”.

Disclosure: This article was written by ChatGPT using a prompt supplied by Andrew Baker. He approved it, published it, and is clearly enjoying this far too much.