The Engineering Manager

Read about AI opinion online and you get two camps: those who believe it will fundamentally reshape how software gets built, and those who see it as useful tooling but doubt the transformative claims being made around it. Neither side has a monopoly on insight, and both can point to real evidence (or lack thereof).

I’ve watched this split play out everywhere over the last six months: in conversations with other engineering leaders, in how candidates talk about AI during interviews, and within my own teams. The hostility has been personal too. Over the past year I’ve written several very pro-AI articles, and some of the private messages and emails I’ve received in response have been borderline insulting(!), dismissing me as naive, a shill, or someone who’s drunk too much of the Kool-Aid. It’s been my first time blocking people on Substack.

But the hostility made me think more carefully about what’s actually going on, because the perceived professional risk doesn’t sit where most people think it does. It’s not about whether you’re optimistic or sceptical about AI, it’s about how you hold that view: whether you’ve arrived at it through hands-on experience, or whether it’s become part of your identity, something you defend rather than inquire into.

This article is about finding the right mixture of optimism and scepticism, and learning to hold a flexible, informed opinion that benefits both you and how you’re perceived by others. We’ll look at why there are two very different kinds of sceptic, why ungrounded enthusiasm is just as risky as ungrounded dismissal, and what it looks like to hold your view well, whatever that view happens to be.

If you’d like to dig deeper, here are some related articles from the archive:

• LLMs: an operator’s view was my first attempt to lay out an AI-positive but grounded position: what’s genuinely useful, what’s not, and where to focus your attention.
• Use it or lose it covered the opposite risk: what happens when you lean too far into AI and start outsourcing the thinking that makes you valuable.
• Invert, always invert explores the habit of seriously considering the opposing view, which is central to what we’ll cover here.

Let’s dig in.

The two kinds of sceptic

If scepticism isn’t the problem, what is? The distinction that matters is between scepticism as a conclusion and scepticism as an identity.

You might have used the tools extensively, kept on top of the latest research, and landed somewhere genuinely unconvinced. That’s totally fine. Or you might have absorbed your position through proximity, adopting the talking points of people around you without firsthand exposure, and stopped there. That’s not so fine.

You can often hear the difference: the first person says something like “I’ve been using AI for six months and I don’t think it’s made me measurably faster on the kind of work I do, here’s why,” while the second says “it’s just autocomplete” or “stochastic parrots” or some other meme and leaves it there. Both are sceptical views, but only one has done the real work, and the other is repeating another’s position, not deriving one.

I’ve seen this firsthand, in both directions. Some of the engineers and leaders I’ve spoken with continually dismissed AI as gimmicky, only to watch them completely change their position once they actually got hands-on with tools like Claude Code or Cursor as the models improved. Their scepticism had been inherited, not earned, and the experience exposed that.

But I’ve also seen people use the tools extensively and remain genuinely unconvinced, particularly those working in significantly large codebases or rarer languages where the models still aren’t as good. Their scepticism is specific, grounded, and hard to argue with. It’s the difference between “I looked and I’m not impressed” and “I haven’t looked but I already know.”

In some developer communities, dismissing AI has become a way of signalling belonging, and the position reinforces itself through repetition rather than evidence. Anyone who breaks ranks by actually engaging with the tools risks exclusion from their tribe, or a loss of identity (or both).

There’s a name for this pattern: the crab bucket describes a group where no individual is allowed to escape, because the others keep pulling them down. The problem isn’t that the crabs are wrong about the bucket, it’s that none of them have climbed out to check.

To be clear, climbing out doesn’t mean changing your mind. There are well-documented examples of developers who went from sceptic to enthusiast after engaging deeply and having breakthroughs with the tools, but the goal of engagement isn’t to make you an enthusiast. It’s to give you an informed position, whatever that position turns out to be.

Some of the crabs that climb out will come back down again, and that’s fine. Maybe the bucket is good enough. The view from outside the bucket might confirm everything they already thought, but at least they’d know.

The enthusiasm mirror

If ungrounded scepticism is one failure mode, ungrounded enthusiasm is the other, and it’s arguably done more damage while feeding the very scepticism it dismisses. Sceptics who disengage mostly hurt themselves: they miss opportunities; they look out of touch. But enthusiasts with budget authority can hurt entire organisations, because when they overcommit and underdeliver, they hand sceptics exactly the evidence they were looking for.

Think back over the last few years and the examples aren’t hard to find: Klarna announced AI would do the work of 700 support agents, only to quietly start rehiring months later when quality collapsed; CEOs from Microsoft to Google continually stated the percentage of code written by AI without any clear methodology for measuring whether it was actually any good; and startups promised autonomous AI agents that quietly turned into vaporware.

Each bold claim that didn’t land gave sceptics another reason to disengage, and you can’t entirely blame them given their position.

I’ve heard versions of this closer to home too. Friends and acquaintances have told me about receiving AI usage mandates from leadership at their own companies with zero guidance, no clear examples of leaders using the tools hands-on themselves, and access to only a limited set of enterprise tools chosen by people who clearly hadn’t done any real evaluation or had a single technical bone in their body. This breeds exactly the kind of cynicism this article is about.

But, if we look closely, the pattern is the same on both sides: a position adopted without sufficient evidence, defended as identity, and insulated from feedback. The enthusiast who dismisses every failure as “early days” is doing the same thing as the sceptic who dismisses every success as “cherry-picked.” Neither is thinking clearly, and both are optimising for being right over being accurate. And, if you think about it, AI just happens to be the catalyst for seeing this behaviour, and it’s a big human bug that we need to fix if we want to be clear and rational thinkers.

So if how you hold your position matters more than what the position is, what does holding it well actually look like? Whether you lean sceptical or optimistic, there are a handful of practices that separate a considered view from a reactive one.

How to hold your view well about AI

The first practice is the most obvious, and the one most often skipped: actually use the tools for yourself. Not a five-minute demo, not other people’s opinions on a Hacker News thread (did you read the article, or just the comments?), or a thirty-second YouTube clip of someone building an app. Sit down with the best available model, bring it a real problem from your actual work, and spend enough time to form a genuine impression for yourself.

If you come away unimpressed, that’s a legitimate data point. If you come away surprised, that’s a legitimate data point too. Either way, you’ve earned your opinion in a way that reading about it never provides, because the only truth comes from firsthand exposure.

I went through this journey myself. Years ago, I started with Copilot in Visual Studio Code and ChatGPT as a web-based prompt, then moved to daily usage of Cursor at Shopify, but to me they felt somewhat bounded and only applicable to individual contributors spending all of their time coding. The real shift came when Claude Code let me work entirely in the terminal and interact with the file system directly: suddenly the use cases, especially for leadership and general organisation and productivity, multiplied, and I ended up building an entire daily driver around it.

That progression took months, not minutes. Forming a real opinion takes sustained engagement over a long period of time.

The second is to separate capabilities from claims. “AI can generate working code from a natural language prompt” is an observable fact: you can verify it immediately. “AI will replace most software engineers within five years” is a prediction, and a speculative one at that.

Much of the AI discourse collapses these two categories, treating a genuine capability as proof of a sweeping conclusion. Arguments on both sides conflate these categories in surprisingly lazy ways, and it’s worth training yourself to spot when it’s happening.

The third is to make your scepticism specific. “AI is overhyped” is a slogan. “I’m sceptical that current LLMs can reliably handle complex, multi-step reasoning in large legacy codebases, and here’s what I’ve seen when I’ve tried” is a position worth engaging with. Specificity forces you to think about what exactly you believe, and it gives other people something concrete to respond to rather than a vibe to agree or disagree with.

The fourth, and perhaps the most revealing, is to ask yourself a simple question: what would change your mind? If you can answer that clearly, you’re holding a view, which is good. If you can’t, or if your honest answer is “nothing,” you’re holding an identity, which is bad. This is true whether you’re sceptical or enthusiastic, and it’s a useful check to run on yourself every few months as the tools and the evidence evolve.

Honestly, it’s hard for me to imagine changing my broadly enthusiastic position right now. I use AI every day at work and at home, and I have enough practical examples and workflows to talk about for hours. But that’s precisely why the question matters. If my answer is “nothing would change my mind,” I’ve crossed from having a view into having an identity, and I should worry about that as much as anyone.

The fifth is to engage seriously with the strongest version of the opposing view. If you’re sceptical, don’t just dismiss the most breathless hype: find someone thoughtful who’s genuinely optimistic and try to understand why. If you’re enthusiastic, seek out the most articulate critics, not the ones shouting at each other on social media, but the ones who’ve used the tools extensively and still have reservations alongside their praise.

This takes effort, because the most reasoned opinions rarely get the most attention: you’ll have to look past the hot takes to find them. But you’ll either sharpen your own position or discover a blind spot, and both of those are wins.

For me, the strongest opposing argument is the one I worry about most: that outsourcing cognitive work to AI gradually erodes the very thinking that makes you good at your job. I wrote about this in Use it or lose it, and it’s a concern I haven’t resolved. That’s what good scepticism feels like from the inside: not a slogan, but an open question you keep coming back to in order to refine your thinking and engagement with the matter at hand.

What this means for your team

Everything above applies to individuals, but if you’re managing a team, you have an additional responsibility: creating an environment where people can get the most out of these tools. That means resisting the temptation to mandate enthusiasm or punish scepticism, because both of those shortcuts produce compliance rather than genuine engagement. What you want is a team that’s actively experimenting, sharing what’s working and what isn’t, and building on each other’s discoveries.

I try to do this at Nordhealth by constantly finding new ways to use AI and then sharing what I discover with my team.

Take one recent-ish example. I took a recording of a video of someone using our app, had Claude Code split it into screenshots, and then ran UX analysis on each frame to generate a list of improvements, essentially creating an AI-powered friction log. It took minutes, and the output was genuinely useful and found numerous issues I wouldn’t have spotted myself.

Sharing experiments like that, including the ones that produce nothing interesting, signals to your team that this is about curiosity and outcomes, not about picking a side.

Creating an environment where people can be curious means framing conversations around outcomes rather than positions. “Did this tool help you ship faster, and if not, why not?” is a conversation that goes somewhere. “Do you believe in AI?” is not.

It also means modelling the behaviour yourself: share your own experiments openly, including the ones that didn’t work. If your team sees you being honest about what works and what doesn’t, they’ll follow your lead.

It’s also worth acknowledging openly that these tools don’t help equally in every context. A team working on a greenfield web application and a team maintaining a decades-old enterprise system with sparse documentation are going to have very different experiences, and both of those experiences are valid. The goal is a team that can figure out where AI helps them and say so honestly when it doesn’t, not one that agrees with you about it in the abstract.

Your turn

If you’re still sceptical about AI, ask yourself honestly: have you actually used the tools for real work, or have you formed your view from a distance? If it’s the latter, that’s the gap to close. Set aside an afternoon, pick a meaningful task, and see what happens. If it’s been a year since you genuinely tried, late-2025’s models were a huge step change for me.

If you’re enthusiastic, ask yourself the inverse: what would make you change your mind? If you can’t answer that, your enthusiasm might be doing the same work as the scepticism you’re dismissing.

Either way, find someone smart who disagrees with you and have a real conversation. Not a debate, not a performance: a genuine attempt to understand how they got to where they are. You might be surprised by what you learn.

Wrapping up

The people who thrive through this era won’t be the ones who called it right early. They’ll be the ones who thought clearly throughout: who engaged with the evidence as it changed, updated their views when the facts warranted it, and maintained intellectual honesty even when it was easier to pick a side and dig in.

Zealots are loud, but they’re brittle: the moment the evidence shifts, they break or double down. The people who hold their views lightly enough to update them are the ones you actually want to work with, and work for.

Buddhism has a name for this: the middle way, a path between extremes that favours clear seeing over fixed positions. You don’t have to be a Buddhist to recognise the wisdom in it.

That’s true for AI. It’s true for everything.

Until next time.

This month, we’re going to explore a practical technique for learning from leaders you’ll never have access to: distilling their thinking into an AI role you can query on demand.

Throughout history, those who’ve succeeded the most have often had something in common: access to the best people, whether as mentors, advisors, or sounding boards. That access has always been scarce and unevenly distributed. But now there’s an opportunity to democratise it: you can create your own coaches and advisors from some of the smartest minds out there, using nothing more than their interviews, podcasts, and talks.

You’ve probably experienced this: you read an interview with someone whose thinking you admire, the insights resonate deeply, and for a few days you see your work differently, but then the ideas slip away, dissolved into the background of the day-to-day. This technique is about making that wisdom stick, not by memorising it, but by creating something you can return to whenever you need a different perspective on a problem.

To be clear, this isn’t about impersonation, and it’s certainly not about outsourcing your judgment to someone else’s thinking. It’s about having a different set of questions available when you’re stuck: the questions that someone you admire might ask, applied to your own context.

It also opens the door to something else: trying out your thinking with people you’d find challenging to work with, without the friction of actually being in the room with them.

We’ll start with how to choose who to distil, then cover how to gather the raw material from interviews and podcasts, and walk through the step-by-step process for turning it into something usable. Finally, we’ll look at how to build and use the role in practice, and I’ll hint at how the same technique works in reverse: extracting your own thinking from your own body of work.

If you’d like to dig deeper, here are some related articles from the archive:

• Councils of agents: group thinking with LLMs explores a lighter-weight version of this idea: using AI to simulate multiple perspectives in a single conversation.
• Use it or lose it covers the importance of not outsourcing your thinking entirely to AI, which is relevant here: this technique augments your judgment, it doesn’t replace it.
• Coaching is a reminder of what coaching looked like before AI: the push and pull of directive guidance versus helping someone work through their own problems. What we’re building here is a version of that, on demand.

I’ll be honest: this started as a bit of fun. I was curious whether I could make an AI channel the thinking of a founder I admire, and the initial experiment was more novelty than anything serious. But, actually, it turned out to be genuinely useful.

Having those questions available when I’m stuck on a decision, or when I want to stress-test an idea, has changed how I work through problems. What began as an experiment became a tool I actually reach for.

Let’s get going. Or, as Jeff would say: it’s Day 1.

Choosing who to distil

Not every leader is a good candidate for this. The technique works best when three conditions are met: there’s enough source material to work with (a few hours of interviews, ideally more), you genuinely want to apply their thinking to your own context (not just consume their content passively), and their frameworks are somewhat transferable (they think in principles, not just anecdotes).

Founders with extensive podcast appearances are often good candidates, as are authors who’ve done multiple interviews about their books, and executives who speak at conferences. The pattern to look for is someone who’s been asked similar questions from different angles, which surfaces their underlying principles rather than rehearsed soundbites. You want enough material to triangulate on how they actually think.

To give you a sense of what works: Claire Hughes Johnson has Scaling People plus hours of podcast interviews on Lenny’s Podcast and First Round Review, and her thinking is structured enough to extract clear frameworks. Charlie Munger’s “latticework of mental models” is perhaps the most codifiable leadership thinking available, spread across shareholder letters and his Acquired interview. Naval Ravikant has been interviewed extensively on Tim Ferriss and The Knowledge Project, and his ideas on decision-making are applicable to any field or domain.

They’re working in completely different worlds, but the pattern is the same: there’s plenty of material to work with, their thinking is rooted in principles rather than anecdotes, and what they’ve learned travels beyond their specific context.

Gathering the raw material

The simplest approach is YouTube. Most podcast interviews end up there, and YouTube has a built-in transcript feature: click the three dots below the video, select “Show transcript”, and you get the full text. I copied each transcript into its own file, one per interview, which made it easier to process them separately before synthesising across sources.

If you want to go deeper, there are more elaborate options. Some podcasts publish their own transcripts: Tim Ferriss has an archive of over 800 episodes, and Lex Fridman publishes full transcripts on his site. Aggregators like Tapesearch let you search across millions of podcast transcripts to find every appearance by a specific person. But for most purposes, YouTube and a few tens of minutes of copy-paste will get you everything you need.

Here’s what a raw YouTube transcript typically looks like when you copy it:

0:00
today I want to talk about something that
0:02
I think is really important which is the
0:04
idea of working backwards and so you
0:07
know at Amazon we we famously start with
0:10
the customer and work backwards from
0:12
there and I think that's that's
0:14
something that a lot of companies say
0:16
but don't actually do right they they
0:18
sort of pay lip service to customer
0:20
obsession but then when push comes to
0:22
shove they optimise for something else

It’s not pretty: timestamps interrupt every few seconds, there’s no punctuation, and sentences break mid-thought across lines. Don’t worry about cleaning this up yourself: we’ll do that next. What matters is capturing the full conversation.

The distillation process

The work now is to turn those messy transcripts into something structured: cleaned up, synthesised across sources, and organised into principles you can actually use. The good news is that this can happen in a single conversation. Feed your transcripts to an AI with a prompt like this:

I have transcripts from several interviews with [name]. Please:

1. Clean up each transcript: remove timestamps, fix punctuation, and mark who's speaking (interviewer vs [name])
2. Extract the key principles, mental models, and decision-making frameworks that [name] articulates
3.Identify patterns that recur across multiple interviews — these are likely their core beliefs
4. Organise the output by domain (e.g., decision-making, people, product, strategy)
5. Include direct quotes where they're particularly memorable
6. Output everything as a structured principles document I can reference later

The transcripts are below.

Founder Lens

Description: Applies the mental models of [leader name] to my current context. Not pretending to be them, but using their frameworks to surface angles I might miss.

Core questions:

- Is this derived from first principles or copied from others?
- Does this require courage? If not, is it ambitious enough?
- What would someone who genuinely cares do here?
- What are the unstated assumptions?

Mental models:

- First principles thinking starts from atomic building blocks
- Change your opinion when you get better information
- The best ideas often feel uncomfortable

Reference: See context/founder-lens/principles.md

Tone: Direct, challenging, focused on clarity over comfort. Asks questions rather than giving answers. Pushes for specificity.

If you’re using Claude Code, this role definition goes in your CLAUDE.md file, and the principles document lives as a separate file in your project. I keep mine in a context/ folder with subfolders for each role.

Activating a role just means asking for it: “founder lens on this decision” or “what would [name] think about this approach?” The AI reads the role definition and the principles document, then applies that perspective to your question. Other tools will have their own way of handling system prompts and context files, but the structure is the same: a role definition that points to a richer source of material.

Using it in practice

What it feels like in use is less “chatbot pretending to be someone” and more “having their guidance available when you’re stuck”. So I often find that it surfaces an angle you wouldn’t necessarily have considered on your own, because they may see the world differently to you. The value isn’t in the answers, it’s in the reframing: the questions force you to articulate assumptions you hadn’t examined, or to defend choices you’d been making on autopilot.

I find it most useful before committing to a significant decision, even when I have consensus with my own group, because I want to stress-test my thinking before it becomes expensive to change course. It’s also valuable when I’ve been circling the same problem for too long and need a way to break out of my own perspective.

With that in mind, it’s worth considering whether there are any founders or notable people out there who would have a very contrarian perspective to yours. Including them as part of this exercise can surface blind spots that a like-minded advisor never would. The role doesn’t tell you what to do, but it does make you defend your reasoning to a different persona.

Here’s what this might look like in practice. Imagine you’ve distilled Elon Musk’s thinking into a founder lens, and you’re using it to stress-test a timeline your team has given you:

You: Founder lens on this: my team says migrating our payment system to the new provider will take six months. I’ve pushed back but they’re confident that’s realistic.

[Founder]: What’s actually in those six months? Break it down for me. Not the project plan — the actual work. If you had to ship something in six weeks instead, what would you cut?

You: We’d probably skip the automated rollback tooling and do manual rollbacks if needed. And we’d run the systems in parallel for longer rather than building a full reconciliation dashboard upfront.

[Founder]: So the core migration is six weeks, and the other four and a half months are de-risking. Is that de-risking based on something that’s actually happened before, or is it fear of something that might happen?

You: Honestly, it’s fear. We’ve never had a payment migration go wrong, but the consequences would be severe.

[Founder]: Severe how? Quantify it. What’s the actual blast radius if you migrate and something breaks? Are we talking about lost revenue, angry customers, regulatory problems? And what’s the cost of moving slowly — four months of carrying two systems, delayed features, team context-switching?

You: I hadn’t thought about the cost of delay that concretely.

[Founder]: That’s the question. You’re insuring against a risk you haven’t priced, with a premium you haven’t calculated. Maybe the six months is right. But you should know what you’re buying with that time.

The lens didn’t tell you what to do, but it made you defend your reasoning to a different set of priorities.

The mirror

The same technique works in reverse. Instead of encoding someone else’s thinking into a role, you can extract your own: feed your writing, decisions, and documentation to an AI, and ask it to identify your patterns. The output is a principles document that captures how you actually think, not how you imagine you think.

I recently ran this process on my own writing: several years of newsletter articles, fed through the same extraction steps. The output was a set of principles organised by how often they recur. Some I expected to find: “constraints are superpowers” shows up repeatedly, as does the conviction that managers should stay technical. Others surprised me: I hadn’t realised how consistently I return to the idea that autonomy and ownership are non-negotiable, or how often I argue recently for being in the details rather than delegating everything, which is a marked change from how I used to be when I first started out in management.

The value isn’t just in having the list. Your previous writing, whether internal memos or public articles, tends to represent your best self: considered, articulate, thoughtful. The messy day-to-day often pulls you away from that. Having your principles explicit means you can check whether you’re still aligned to what you actually believe, or whether you’ve drifted without noticing.

This is another reason to write, even if only to yourself. Writing has always been a tool for thinking, but now it’s also a tool for self-knowledge: the more you write, the more material you have to analyse, and the clearer the picture of who you actually are. This month’s subscriber edition goes deeper into the inward-facing version of this technique: how to gather your own material, what prompts to use, and what to do with the principles once you have them.

Your turn

The technique is straightforward enough to try this week. So why not give it a go?

• Find your candidate. Have a look through all of the podcasts and interviews that you’ve read, listened to, or watched recently, and see whether anyone that you found particularly inspiring could form a coach that can be your go-to in your day-to-day.
• Gather the material. Find two or three interviews with them and run them through the distillation process: clean the transcripts, extract principles, and organise them by domain.
• Build a simple role. Create a role definition with a handful of their core questions and mental models, and don’t worry about getting it perfect on the first pass.
• Try it on a real decision. Pick something where you’d value a different perspective and see what surfaces.
• Iterate. Refine the role based on what’s useful and what isn’t: the first version is never the final one.

Wrapping up

And remember: this isn’t about hero worship, and it’s certainly not about replacing your judgment with theirs. It’s about making the wisdom of people you admire more accessible to yourself, on demand, when you need a different perspective. The insights you read in interviews don’t have to fade anymore; they can become tools you reach for.

Until next time.