Welcome to The Pragmatic CTO

Some of the best engineers I’ve ever worked with will quit over a meeting. Not a layoff, not a bad review, not compensation — a meeting.

It was an all-hands. The kind that should celebrate the team’s wins and build momentum. Instead, the CEO spent twenty minutes talking about his other company; then he called our 160-person organization his “toy.” Something to experiment with.

The messaging landed about as well as you’d expect. It marked the beginning of that company’s downfall.

That moment crystallized something I’d been circling for years. The things that kill great teams aren’t the obvious disasters — the failed deployments, the missed deadlines. They’re the death by a thousand small cuts. Leadership is losing focus. Processes that protect mediocrity. Meetings that value attendance over contribution. The subtle signals that tell your best people we don’t trust you to do the job we hired you for.

Most leadership content fixates on the dramatic failures. The quiet ones compound faster.

What You’ll Find Here

This publication covers three things: leadership mistakes I’ve made, industry patterns I’m tracking, and frameworks for the decisions that don’t come with playbooks.

I wrote about promoting an engineering manager to director when they weren’t ready — and then spending six months coaching instead of acting, while the team lost engagement and trust. That’s the kind of failure I write about; specific, concrete, with the full scope of damage included. No softening.

On the industry side, I’ve tracked the gap between AI hype and AI reality across multiple pieces. The AI-First Fallacy traced how “AI-first” became a branding exercise rather than a strategy — underneath the slogans, SEC enforcement actions, stock manipulation, and 95% pilot failure rates. The Hello World Test examined Anthropic’s AI-built C compiler: 180,000 lines of code, boots a Linux kernel, can’t compile Hello World on a fresh install. The pattern between the benchmark and the production edge keeps showing up; I keep writing about it because CTOs keep making resource decisions based on the benchmark.

For frameworks, Shielding the Team Doesn’t Mean Silence challenged the common misreading of managerial shielding—where protecting your team’s focus is conflated with keeping them uninformed about the business. Death of a Craftsman tackled what we lose when AI writes the code; not a Luddite argument, but an honest accounting of what happens when the craft that built our tools becomes optional.

Every essay follows the same principle: show the data, state the opinion, acknowledge what I don’t know.

Who I Am

Allan MacGregor. Eighteen years in the industry across ecommerce, travel, HR/payroll, and environmental tech. I’ve been an IC, principal developer, director, VP, and CTO twice. I was CTO at Humi through its C$155M acquisition by Employment Hero — 150,000 workers on the platform and $7 billion in payroll processed. Two exits total. Plenty of failures. Now I’m building StructPR, a tool that reorders code reviews by business impact rather than alphabetical file order, because the review bottleneck is the problem I can’t stop thinking about.

The credential that matters most for this publication isn’t the title. It’s the scar tissue. I’ve hired the wrong senior engineers, built processes that collapsed under their own weight, navigated acquisitions from both sides, and scaled teams from five to fifty. The lessons came from watching decisions play out over months and years — and being honest about which ones I got wrong.

The Promise

One essay, every Tuesday. No listicles about leadership hacks. No breathless coverage of the trend that will transform everything. No humble brags disguised as advice.

I can’t promise I’ll always be right. I can promise specifics — real timelines, real consequences, real data with sources you can check. If you’re a CTO or engineering leader making organizational decisions, this is a peer-to-peer conversation; the kind of advice I wish I’d had when I was figuring it out myself.

Subscribe if that sounds useful. Share it with other technical leaders if it is.