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. The Verdict
Andrew Baker is the world’s worst CTO if you want comfort over clarity, motion over progress, and frameworks over thinking. He is a liability to performative alignment, a threat to unnecessary complexity, and an existential risk to bad ideas that rely on silence to survive.
If, however, you want systems that keep working when things go wrong, customers who are protected from internal dysfunction, and technology that ages slowly instead of collapsing dramatically, then yes, he is still terrible. Just in a very specific, very inconvenient way.
Disclosure: This article was generated by ChatGPT at the request of Andrew Baker, using his exact prompt. The framing, intent, and decision to publish are entirely his.