Most experienced leaders I’ve worked with operate on principles they can’t quite articulate. They make consistent decisions, give consistent advice, and have strong instincts about what’s right, but if you asked them to write down the ten things they actually believe, they’d struggle. The principles are implicit, revealed through behaviour rather than stated outright.

This article is about making them explicit, using the same distillation technique from this month’s free article, but pointed at yourself. Because once your principles are visible, you can check decisions against them, share them with your team, and notice when your thinking has drifted without you realising. You might even surface beliefs you didn’t know you held.

The end product is a document: a tiered list of ten to twenty-five personal leadership principles, extracted from your own writing by an LLM, organised by strength of conviction, and mapped to the tactical frameworks you already use.

But it’s not something you file away and revisit occasionally: the real power comes from dropping it into your AI assistant’s context, where it becomes a living part of your workflow. Every decision you draft, every strategy you review, every piece of writing you produce can be checked against what you’ve said you believe, automatically and on demand.

Here’s what we’ll cover:

• Why bother? How your principles can drift without you noticing, and why making them explicit changes that.

• The raw material. What counts as your body of work, and why writing is uniquely powerful for this kind of extraction.

• The extraction process. A step-by-step walkthrough, including the actual prompts I used.

• What I learned. The results of running this on my own archive of two years of newsletter articles.

• Principles as a daily driver. How to integrate the output into decisions and daily workflows.

• Keeping principles alive. Why they go stale, and how to maintain them.

• The conversational alternative. A different path for those who don’t have an archive to work with yet.

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

• Gather, decide, execute describes the kind of second-brain system that naturally generates the archive this process could feed from.

• Invert, always invert explores how principles help you know what not to do.

• Heartbeats: keeping strategies alive covers why frameworks need maintenance cycles, which applies to principles too.

• A weekly mind meld shows how sharing your thinking at scale builds alignment, which a principles document enables.

Let’s get into it.

Why bother?

So, what’s the risk of leaving these principles unspoken? Because your team doesn’t just observe your principles, they absorb them. The decisions you make, the things you reward, and the behaviour you tolerate become the template for how everyone around you operates.

Guy Kawasaki, Apple’s former chief evangelist, once described Apple as “Steve Jobs with ten thousand lives” in Leander Kahney’s Inside Steve’s Brain: Jobs had imprinted his principles so deeply that the company became a mirror of its founder. The same dynamic plays out at every level, because every leader shapes the culture around them, whether they’re doing it deliberately or not.

The problem is that consistency drifts, often without you noticing. You don’t wake up one morning having abandoned a principle: it happens gradually, one exception at a time, until what you’re doing no longer matches what you think you believe.

There’s an important distinction here between evolution and drift. Evolution is when you consciously revise a principle because your thinking has genuinely changed: you’ve seen new evidence and arrived at a different conclusion. Drift is when you contradict yourself without realising, because you’ve simply forgotten what you used to believe.

When I ran this process on my own writing, one of the surprises was a principle I’d call scepticism, not cynicism: the idea that new technologies deserve critical evaluation, but blanket dismissal is intellectually lazy. I’d been applying that distinction without ever articulating it, which meant it was invisible to the people around me.

The first step is figuring out where those principles are hiding, which brings us to the raw material.

The raw material

Where do your principles actually manifest? They’re embedded in the things you’ve written, the decisions you’ve made, and the advice you’ve given, scattered across long-form documents, emails, proposals, and messages.

All of it is an externalisation of your thinking process, and that’s what makes it useful: your body of work is the raw material for this extraction, and the richer and more varied it is, the clearer the picture you’ll get.

Not all sources are equal, though. Writing is uniquely powerful for this kind of extraction, because writing is thinking: it forces a clarity that speaking rarely does, and it leaves a permanent record of what you actually believed at the time, not a reconstruction after the fact.

Larry McEnerney’s famous lecture on writing from the University of Chicago captures this perfectly: you don’t think first and then write, the process of writing is the thinking. The clarity comes afterwards, when you revise what you’ve produced into something the reader can follow. That’s why your writing is such a rich source of principles: it caught your thinking in the act.

Writing also tends to represent your best self, which makes it especially useful here. Whether it’s an internal memo or a public article, you probably took time to think through your position, choose your words carefully, and present a considered view. The messy day-to-day pulls you away from that considered version, but the writing preserves it, which makes it useful as a source of raw material.

So, what’s the minimum viable corpus? Ideally, two or more years of documents across different contexts: technical decisions, people management, strategy. But you can get a useful extraction from as little as six months of significant writing, whether that’s internal strategy memos, promotion cases, project retrospectives, decision records, or even detailed interview feedback you’ve written for hiring panels.

One thing to keep in mind is recency weighting: your most recent writing reflects your current thinking, while older material shows where you came from. Both are useful, but they serve different purposes. When I was thinking about doing this, I found that two years was a good cutoff for work that still felt present to me, both in terms of the articles I’d written on here and the capacity I’d been operating in at work.

If you don’t have much of an archive yet, don’t worry: there’s an alternative approach later in this article. But if you do have the material, let’s walk through how to turn it into something useful.

The extraction process

You’ve got a body of work: documents, articles, decision records, emails. It’s sitting in various folders and inboxes, and somewhere inside it are the principles that actually guide your behaviour. The question is how to get them out. What follows is the process I used on my own newsletter archive, but it works on any collection of writing where you’ve been thinking out loud: for example, weekly journal posts, weekly brag docs, or regular writings you’ve shared with your team.

Gather and organise

Since the LLM is going to do the heavy lifting, the format of your documents doesn’t matter much, though plain text works well. The first step is to get everything into one place: export your documents into a folder you can navigate, and organise them by date so you can weight recent material more heavily.

You don’t need every email you’ve ever sent, just the ones where you were genuinely thinking through a problem, making a case, or articulating a position. Strategy memos, decision records, proposals or RFCs you’ve written, project retrospectives, internal blog posts: anything where you were doing real thinking and having your leadership embodied in your writing, not just relaying information.

First-pass extraction

Point the LLM at the folder and give it a prompt that explains what you’re trying to achieve. Here’s the one I used:

Read more

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.

Within minutes, you’ll have a working principles document. Resist the temptation to have the AI research further or expand on each principle: the value is in capturing their thinking from their words, not generic material found online about the same topics. I’ve found it useful to keep the distillation specific: it makes the role you create from it more pointed and useful as a coach.

Building the role

Once you have a principles document, you can turn it into a role: a structured definition that tells the AI how to apply those principles to your questions. If you want to see how this fits into a larger system of roles, I covered my full daily driver setup in the April subscriber edition, but here’s the core structure you need.

A role typically includes:

• Description: Who this persona represents and why you’re using it

• Core questions: The questions this person tends to ask when evaluating ideas

• Mental models: The frameworks they apply

• Tone: How it should behave (direct, challenging, supportive, etc.)

• Reference: A pointer to your principles document so the AI has the full context

Here’s a short generic example to give you a flavour of what to aim for:

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.

In February, I showed you some tools I’d built with AI: a bragdoc generator, a planning tool, and a few others. This month, let’s go even wider and deeper into tooling.

I don’t mean broadening to more individual tools, but zooming out to see the whole system I’ve constructed around them: a personal workspace that’s become central to how I work day-to-day as a CTO. Think of this article as a peek behind the curtain: it’s what my setup actually looks like, how it evolved, and why it makes me more productive than I have ever been.

Here’s what we’ll cover in my Claude Code setup:

• What is a daily driver? How it differs from one-off AI interactions, and why persistence matters.

• How the workspace is organised. Directories, information flow, and the central configuration file.

• The roles. Eleven different personas that Claude can adopt, from Executive Assistant to Sparring Partner, each with distinct behaviours and triggers.

• The integrations. What’s connected and why: Linear, Notion, BetterStack, and more, all working together.

• The workflows. Daily bookends with /morning and /eod, weekly operations reports, and ad-hoc commands for triage and tracking.

• The composability insight. Why the whole is greater than the sum of its parts, and what this enables that separate tools don’t.

• Evolution. How it started, what’s changed, and how to know when to add something new versus just doing it manually.

If you’d like context before diving in, Just build the tools yourself from February covers the topic of using AI to quickly roll your own internal tooling. For related themes, Being in the details explores why staying close to what your teams are building matters, and Should managers still code? tackles the perennial question.

Let’s get into it.

What is a daily driver?

In February’s article, I mentioned that I use Claude Code as my “daily driver”: a unified interface for managing tasks and complex workflows, doing research, drafting documents, and synthesising information from a multitude of external sources.

But I glossed over what that actually looks like in practice. What does a daily driver look like? How is it different from just using Claude Code to interact with Linear or Notion?

At its core, it’s the creation of a continually improving system tailored to you. Consider the opposite: when you use Claude Code for a one-off task, you open a session, do the thing, and close it, and all of that context disappears.

A daily driver is something different: it’s a personalised workspace that has memory, both internally via files and externally via other systems that act as sources of truth. It has your opinions baked in, and it’s less a tool you pick up than an environment you quite literally drive your whole day from, one that only gets better with time.

Here’s what that looks like in practice. On Friday mornings, I run a single command that queries all of our Linear teams for bugs by severity, separating production issues from internal ones. It checks all of our production monitors for uptime across regions, calculates availability percentages, and pulls from our incidents database. It identifies any SLAs at risk of breach, then delivers a formatted briefing based on a template I’ve defined, ready to share.

This is just one of many composite operations the daily driver performs. For example, there’s /morning for a start-of-day briefing, /eod for capturing thoughts before logging off, /triage for processing my inbox into structured tasks, /check-sla for spotting at-risk bug fixes, and /dora-report for deployment metrics. And that’s not mentioning the numerous different roles that help me with analysis, writing, dissecting ideas, and planning.

What used to take an hour of clicking around now takes thirty seconds, and the fact that it is now so easy to think, pull data, derive insights, and be creative is game changing. It’s the result of structure, integrations, and workflows that have accumulated over time. Let me show you how it’s built.

How the workspace is organised

If you haven’t used Claude Code before, here’s the short version: it’s a terminal-based interface to the Claude models, which means it can directly read and write files on your filesystem and connect to external services like Linear, Notion, and monitoring tools via something called MCP (Model Context Protocol).

The key to making it useful isn’t just having access to these capabilities, though; it’s steering Claude’s behaviour so it knows what to do with them. That steering happens through a CLAUDE.md file: a markdown file that defines how Claude should behave, what roles it can adopt, what context it has access to, and what workflows it can execute. When I open a terminal session in my workspace, Claude reads this file first and orients itself accordingly.

The structure is a little like a codebase: you organise it into modules using a file structure that makes sense, then you tell Claude what each part does and how to interact with them. My workspace is organised into distinct zones, and I’ll walk you through some of them before we dig into the details in the rest of this article.

There’s an inbox.md file for quick capture: anything I need to get out of my head goes there first, unstructured and raw. There’s a bragdoc/ directory where wins get logged week by week, a decisions/ directory for significant decisions with their rationale, and a context/ folder containing reference material like team rosters, writing style guides, and even synthesised wisdom from leaders I admire.

Reports flow to reports/, organised by cadence. The structure reflects how I actually think about information: some things are temporary and need processing, some things are permanent records, some things are reference material I’ll query repeatedly. All of my interactions with these modules happen through natural language in the terminal: I don’t click around in different apps, I just ask Claude to do what I need. The whole thing is backed by a private repository on GitHub, which keeps everything in sync and versioned.

One pattern worth highlighting: I deliberately separate quick capture from task tracking. inbox.md is temporary and unstructured; it’s where thoughts go when I need to get them out of my head quickly. Linear is our ticket tracking system at work, and I have a private team on there called CTO that I use as the backing store for all of my todos.

The distinction matters because it removes friction from capture. I can dump anything into the inbox without worrying about whether it’s a real task, what priority it should be, or which project it belongs to. Later, when I run /triage, Claude helps me process the inbox: categorising items as actions, reference, or done, converting the actions into Linear tickets, and clearing out what’s no longer relevant.

The result is a system where information has a natural lifecycle: capture in the inbox, triage into tasks or reference, execution tracked in Linear, wins recorded in the bragdoc, and decisions logged for future reference. The CLAUDE.md file ties it all together, defining not just where things live but how Claude should behave when working with them.

What I find most useful is that it specifies eleven different roles Claude can adopt depending on what I’m doing, from Executive Assistant for routine tasks to Sparring Partner for stress-testing ideas. It defines slash commands that orchestrate complex workflows across multiple systems. And it encodes working principles, so Claude’s default behaviour aligns with how I actually want to work.

At a very high level, this is my information loop:

That’s the architecture at a high level, but I’ve skimmed over a lot of the detail. Through the rest of this article, we’ll dig deeper into how it all actually works: what the roles do and why they matter, how the integrations combine to produce real outputs, and what the daily workflows look like in practice.

The roles

I’ve always liked the idea of having a council of advisors available around the clock: people I can consult when I’m stuck, who can challenge my thinking, help me prepare for difficult conversations, or just sanity-check a decision before I commit to it.

In practice, of course, that’s not how leadership works: your peers have their own priorities, your exec isn’t available at 11pm, and your team shouldn’t be your sounding board for everything. But you can build that council synthetically, and defining roles is how you get there.

Read more

After years of post-Covid layoffs, hiring has slowed across the board as companies wait to see how AI efficiency gains and the economy play out. Unfortunately, juniors are caught up in that slowdown: it’s a hard time to be graduating with a computer science degree.

Meanwhile, AI is absorbing the small changes and bug fixes that used to be perfect training tasks for junior engineers, and the managers who traditionally developed early-career talent are stretched thin or being cut entirely. When viewed purely as profit and loss, some short-term rationale can be derived. However, the long-term consequences are worrying.

We’ll start by looking at the pipeline we used to have: how senior engineers traditionally emerged through years of mistakes, mentorship, and low-stakes learning. Then we’ll examine what’s replacing it, and hypothesise whether AI will actually fill the gap. We’ll explore three possible scenarios for 2035, and finish with what this means depending on where you sit in the industry.

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

• Coaching explores how managers develop people at different experience levels, and why the approach needs to change as someone grows.

• Delegation creates career progression looks at how handing over tasks is an act of trust and an opportunity to learn.

• Use it or lose it covers the risk of skill atrophy in the AI era, and why deliberate practice still matters.

Let’s explore.

The programmer’s path

For decades, the path was well-worn: you got hired as a junior, paired with someone more experienced, and were given tasks that existed as much for your development as for the work itself.

As part of your ramp-up into real-world programming, you’d follow this loop: write some code (often pairing with others), submit a pull request, get feedback that made you rethink your approach, fix it, and learn something. Over time, through repetition and correction, you built judgment: one of the key skills that separates senior engineers from those with less experience.

Learning with other people was not the only path. Some of the most influential figures in computing taught themselves to code before they were adults, tinkering with whatever hardware they could access; learning through curiosity and obsession rather than formal training. I was no different (although I do not claim to be influential): I learned to code on our family computer, building websites with HTML and simple tools in Visual Basic.

Yet, although they may have begun alone, many autodidacts eventually joined or created teams and companies, and there they learned a different set of lessons: how to collaborate, how to navigate trade-offs, how to build things that outgrow your singular contributions. And these are things that are very hard to learn in formal education or on your own.

However, what both paths shared was this: you had to do the work yourself and with others, and the doing was the point.

What’s replacing it

The traditional pipeline is breaking down in several places at once. Hiring freezes, driven by post-pandemic correction and uncertainty about AI’s impact on headcount, mean fewer junior roles: entry-level tech postings have dropped 67% since 2022, and a Stanford study found that employment for software developers aged 22-25 has declined nearly 20% from its late 2022 peak.

A Harvard study found the effect is even sharper in firms actively adopting AI: junior employment fell 7.7% relative to non-adopters within six quarters. The managers who used to mentor early-career engineers are being cut or stretched across larger teams. And the tasks that once served as training ground, such as the small bug fixes and incremental features, are increasingly being handed to AI tools instead.

For leadership purely concerned with cost, the assumption is compelling: AI will keep improving, so we’ll need fewer humans, so why invest in growing them? A LeadDev survey found that 54% of engineering leaders plan to hire fewer juniors, reasoning that AI enables seniors to handle more.

On a balance sheet, the short-term economics make sense. But there’s an incredibly important question that needs to be addressed: what happens to the skills that juniors used to develop along the way, if AI is taking them and there are fewer juniors to do them in the first place?

The answer matters because much of the judgment of an experienced craftsperson comes through being in the details, making mistakes, and learning from them.

Consider judgment under ambiguity, organisational navigation, the instinct for when a shortcut will come back to bite you and when it’s the right call; these aren’t skills you acquire by reading documentation or even prompting AI for answers, but through years of making mistakes in environments where the stakes were low enough to fail safely.

There’s a term that comes to mind for how one progresses from junior to senior: scar tissue. The scars come from shipping something that broke in production and staying up to fix it, from proposing an architecture that didn’t scale and having to rebuild it, from navigating a difficult stakeholder relationship and learning, the hard way, what actually works.

AI can answer questions in the same way that revising for an exam can help you memorise an answer, but it can’t give you the scars that you can then apply to new problems in the future.

So what happens if we continue down this path? There are a number of possibilities that could all prove true to some degree. Analysing them, and where they could lead, is one of the ways we can steer towards a future that makes sense for the industry.

Three possible futures

The talent crunch. We’ve seen a version of this before. During the pandemic hiring boom of 2021-2022, tech job postings more than doubled and salaries hit record highs. Top candidates fielded multiple offers; poaching was rampant. Companies that weren’t seen as desirable places to work found themselves outbid by those that were.

Now imagine that dynamic, but worse. Senior engineers don’t appear from nowhere: they’re the juniors you hired five or ten years ago who learned, failed, recovered, and grew.

Cut the pipeline today, and the shortage doesn’t show up immediately. Instead it shows up in 2035, when the industry finds itself desperate for engineers with the scar tissue that comes from years of real-world experience. When the critical system goes down at 3am, there’s no one left who knows how it works. The parallels to other industries that neglected their pipelines, such as nursing and skilled trades, become impossible to ignore.

The bifurcation. Instead of a shortage, a split emerges. On one side: vibe coders who move fast, shipping features by orchestrating AI tools, comfortable with velocity but shallow on fundamentals. On the other: engineers who understand how things actually work, but who are increasingly rare and expensive.

The middle disappears. A HackerRank advisory board described this as a “hollowed-out career ladder”: seniors at the top, AI handling the grunt work, and very few people learning in between. The traditional path from junior to mid-level to senior breaks down because the rungs in the middle are gone.

This pattern shows up elsewhere. Economists have documented job polarization for decades: automation eliminates middle-skill routine work while high-skill and low-skill jobs grow. The same dynamic appears in wealth distribution, where the middle class has steadily shrunk across developed economies. In retail, analysts call it the barbell economy: luxury and discount thrive while the mid-market hollows out. Software engineering may be next.

The tinkerer’s precedent. There’s a more optimistic reading, grounded in computing history. Formal computer science education was still in its infancy: Cambridge offered a diploma-level course from 1953, but the first dedicated department wasn’t established until 1962 when Purdue established theirs. The first undergraduate degree followed in 1967. Yet computing advanced for decades before that, driven by aforementioned autodidacts who taught themselves from manuals, blueprints, and tinkering: messing around for curiosity’s sake.

Each new abstraction layer was supposed to be the end of entry-level programming. Before software existed at all, “computers” were humans doing calculations by hand. Then came machine code, then assembly, then BASIC: created at Dartmouth for liberal arts students, it came pre-installed on home computers and enabled a generation of bedroom coders.

The browser brought JavaScript, which democratised web development. Cloud computing abstracted away infrastructure. Each time, instead of eliminating entry points, the new layer created different ones. And with each step up, we wouldn’t wish to go back: would you want to write everything in assembly today? I thought not.

If AI follows the same pattern, we could see a world where everyone becomes part product manager, part engineer, part designer. Building software gets faster, and the bottleneck shifts elsewhere: to sales, to go-to-market, to the hard work of finding customers and convincing them to pay. The constraint moves, but it doesn’t disappear.

There’s an alternative version of this future: the number of software engineers a company needs seriously dwindles, teams of fifty become teams of five, and average company size shrinks. The engineers who thrive are the entrepreneurial ones, those who can ship whole products rather than just features. Everyone else competes for fewer and fewer seats.

What makes this scenario different from the first two is that it still offers a path. Each earlier abstraction layer required you to understand programming logic; you were just expressing it at a higher level. AI potentially abstracts away programming itself: describe what you want and let the model figure out how. That could mean the ultimate democratisation, or the elimination of the ladder entirely. But if history is any guide, new entry points will emerge, even if we can’t yet see what they look like.

What this means for you

Which scenario plays out, and in what combination, depends partly on choices being made right now: not just by industry leaders, but by individuals at every level, including yourself.

We still have years ahead in which these effects will compound, and that means years in which deliberate choices can steer us toward a better future than the one we might waltz into without thinking. Here’s what you can do depending on where you sit.

If you’re a senior engineer, your expertise is becoming scarcer, not more common. This is an extremely strong position to be in, especially if you’re investing heavily in AI-first engineering skills. The scar tissue you’ve accumulated, the instinct for where the edge cases hide, the ability to debug systems you’ve never seen before: these take years to develop and can’t be downloaded. Three things you can do:

• Mentor actively. Find a junior and invest in their growth, even if nobody’s asking you to. This is actually more fun than it used to be: you’re exploring AI tooling together, learning alongside each other rather than just handing down wisdom.

• Make your knowledge visible. Use AI to generate excellent documentation and diagrams, and use it to level up the knowledge you transfer to the rest of the organisation. The tribal knowledge in your head is worth far more when it’s shared, and the barrier to doing so has never been lower.

• Invest in engineering-led initiatives. The increased velocity you get through AI has to go somewhere. Instead of just shipping more features, use that time to work on the problems that often get deprioritised: performance, latency, resilience, and the kind of deep technical work that builds lasting competitive advantage.

If you’re a manager, the juniors you develop aren’t a cost centre; they’re a strategic bet. Every engineer you grow into a capable mid-level or senior is one you won’t have to poach from a competitor when the talent crunch bites. Remember the 2021-2022 hiring war? It could look mild by comparison. Three things you can do:

• Make the case for junior hiring. Frame it as risk mitigation, not charity. Show leadership the cost of senior attrition, the salary inflation in the market, and what happens when institutional knowledge walks out the door. Juniors are cheaper to hire and, with good mentorship, can become your most loyal senior engineers.

• Rethink what training looks like. The tasks that used to be training ground are being absorbed by AI. So create new ones: pair juniors with seniors on complex problems, give them ownership of small but real projects, let them lead incident retrospectives. OpenAI is experimenting with a “super senior + super junior” model for exactly this reason. The goal is scar tissue, not busywork.

• Invest in your own internal tooling. AI has made building custom tools almost as easy as building a spreadsheet. Instead of waiting for engineering to prioritise your visibility needs or settling for off-the-shelf software that doesn’t quite fit, build the tools yourself. Whether it’s a planning dashboard, a bragdoc generator, or a way to track knowledge distribution across the team, the friction between “I wish I had a tool for this” and actually having it has never been lower. I covered this in detail in Just build the tools yourself.

If you’re early in your career, the path is harder than it used to be, but it’s not closed. The key is to seek out the experiences that build judgment, even when the system isn’t handing them to you. Three things you can do:

• Seek scar tissue deliberately. Volunteer for on-call rotations. Take the messy migration project nobody else wants. When something breaks, be the one who stays to understand why. None of this is new: the tooling changes and the level of abstraction shifts, but the engineers who learn the most have always been the ones actively seeking scar tissue.

• Don’t outsource your understanding. AI tools are incredible accelerators, but they can also become a crutch. When the model gives you an answer, take the time to understand why it works. Read the documentation. Trace the code path. The goal isn’t to reject AI; it’s to use it without losing the ability to think for yourself. I wrote about this in Use it or lose it.

• Connect your work to the business. The engineers who get trusted with bigger problems are the ones who understand why those problems matter. Learn what your company’s metrics are, how your team contributes to them, and what keeps your leadership up at night. Then be proactive about getting closer to that work. Ask to be included in architecture discussions, request to shadow incident response, and when you get feedback, ask “why does this matter?” not just “what should I change?” Technical skill gets you in the door; business context gets you to the table.

If you’re a senior leader planning to spend more on AI than on people, you’re making a bet, whether you’ve articulated it or not. The bet is that AI will improve faster than your talent base depreciates: that you can cut junior hiring today and still have the senior engineers you need when it matters. That may be true. But if it isn’t, you won’t know until it’s too late to fix. Three things you can do:

• Stress-test your assumptions. What happens if AI progress plateaus for a few years? What happens if your most experienced engineers leave? What does your team look like in 2035 if you hire no juniors between now and then? Run the scenarios. The answers might surprise you. Why not use AI to do the modelling?

• Treat junior hiring as R&D, not overhead. The return on investment isn’t immediate, but it’s real. Every junior you develop into a senior is institutional knowledge you don’t lose when someone resigns. And some of the best junior talent right now, especially those who are AI-first, are incredible at their jobs, hungry to learn, and waiting for the right opportunity to come along. Frame junior hiring as investment, not cost, in your planning.

• Measure your knowledge concentration. How many people on your team can debug your most critical systems? What’s your bus factor on key services? If the answer is “one or two,” you have a fragile organisation, regardless of how productive AI makes those individuals. Track knowledge distribution the way you track uptime.

Wrapping up

Who will be the senior engineers of 2035? We don’t know yet. We’re running an experiment on the industry’s talent pipeline, and the results won’t be in for years.

But here’s what we do know: the outcome isn’t predetermined. The senior engineers of 2035 are being made right now, in the decisions about who gets hired, who gets mentored, and who gets the chance to fail safely.

Until next time.

We’ve got a mailbag question this month, and it’s one whose situation I suspect will resonate with many of you. Once I received it, I knew it would be a great idea for an article, because it’s something I’ve only recently come out the back of in my new CTO role.

Here’s the question, edited for brevity:

I’ve been at my current company for 12 years, where I grew from a backend engineer through to Staff and then pivoted to the leadership track, becoming an EM four years ago and more recently a Senior EM. It’s time to finally leave and I’ve accepted an EM role at a really great company. I’m looking for ways to hit the ground running and get effective as quickly as I can, all the while concerned that all the things I do know won’t translate to the new place (though I know that’s illogical). Clearly The First 90 Days is going to be a general recommendation, but I’m looking for something more specific to tech leadership.

I suspect many of you, including myself, have felt this tension before. As you’re leaving your old role, you’ve built up years of experience, developed strong instincts about how teams should work, and earned the credibility that comes from a track record of getting things done.

And then you step into a new company and... none of that is visible. You’re effectively a stranger; a new transplant in a foreign body, if you will. You don’t know where anything is, who to talk to, or why things are the way they are. It’s a paradox: you’re simultaneously an expert and a complete beginner.

As mentioned above, I went through this recently when I joined Nordhealth as CTO in early 2025. I’d spent years at Shopify, a company known for operating without traditional KPIs and thinking in hundred-year timeframes, and suddenly I was starting over. What follows is what I learned through trial and error: a framework for those first 90 days that’s specific to engineering leadership, grounded in my own experience and supplemented by research on what actually works.

My intention with this article is to wrap my recent experience into a playbook that you can take away and follow, adapting it to your own situation as you see fit.

Here’s what we’ll cover in this article:

• The expert beginner problem. Why your years of experience are simultaneously your greatest asset and your biggest liability when you walk through the door.

• Days 1-30: See things clearly. Running a listening tour that actually works, and the simple two-question survey that reveals what really matters to your new team.

• Days 30-60: Pick your battles. Picking your battles wisely, learning to steer without doing, and understanding the cross-functional work that is a key part of leadership and critical to your “transplant” working out long term.

• Days 60-90: Land the results. Landing visible results, celebrating wins in a way that reinforces the right behaviours, and setting the tone for what comes next.

• What transfers and what doesn’t. The crucial difference between principles you can bring with you and prescriptions you need to leave behind.

• When this doesn’t apply. The situations where you should throw out everything I just said and act immediately instead.

If you’re interested in the backstory of how I ended up in a CTO role in the first place, I wrote about that journey in two parts last year: Part I covers the random walk of my early career, and Part II covers how executive roles actually get filled and the decision to make the move.

So without further ado, let’s get into it.

The expert beginner problem

So let’s start with the gigantic paradox. When you join a new company as an experienced leader, you’re in a strange position: you know how to do the job, but you don’t know where anything is, who to talk to, or why things are the way they are.

In a slightly gross phrase, Michael Watkins, author of The First 90 Days, calls this an organ transplant: you’re the new organ (kind of weird, right?), and if you’re not careful, the organisational immune system will reject you. There are so many ways for this to happen, from conflicts in how you work, to how you communicate, and generally how you fit in both up and down the management chain.

The problem is compounded by something researchers call “earned dogmatism“: the more expertise you accumulate, the more likely you are to close your mind to new information. For example: you’ve seen this pattern before, you know what works, so why question the same solution that’s served you well in the past? It’s System 1 thinking, as we covered in a previous article, at its most seductive. But what worked at your last company may not work here, and the confidence that comes from your experience can blind you to that fact.

The antidote is something Zen Buddhists call shoshin, or beginner’s mind: approaching a situation with openness and curiosity, even when you have experience. The goal isn’t to pretend you don’t know anything; it’s to hold your expertise lightly, staying curious about what might be different in the here and the now. It’s easy to understand in principle, but very hard to continually implement in practice, since you have to fight your own brain’s default mode.

So keep this approach close as we go through the plan in this article. Remember: beginner’s mind. So, let’s start with your first 30 days.

Days 1-30: See things clearly

Some executives assume they were hired to fix things, and therefore feel pressure to prove their worth quickly. Then they start making changes from day one.

When I joined Nordhealth, I didn’t want to go so quickly. I used my first 30 days as a pure assessment period: listening more than acting, and resisting the temptation to propose solutions to problems I didn’t yet fully understand. I wanted to see things clearly.

Read more

Hang on, slow down? Yes, bear with me here.

Let’s bring the debate that’s probably been going on in your team for some time to a head. Some of your colleagues say that with AI we should be building and shipping even faster, prototyping in hours, and that perhaps we don’t even need to write code at all any more: we should just let the models go full auto. They’re just that good now.

Others worry that this speed is creating quality problems, that we’re accumulating technical debt faster than we can pay it down, and that codebases are becoming patchworks of AI slop that nobody fully understands.

So, who is actually right?

To an extent, both are right, but I believe they’re talking past each other. The question isn’t whether to use AI for speed. It’s when.

We’ll start by looking at this debate through the lens of Daniel Kahneman’s System 1 and System 2 thinking, and why AI has made the slow phases of work more important, not less. Then we’ll examine the illusion of speed: the thought process around rework costs, and why going fast in the wrong phase means going slow overall.

We’ll explore when deliberate slowness pays off, including using AI itself for the slow work, and how fast prototyping is actually a form of slowing down. And finally, we’ll grapple with a question that’s getting harder to answer: why are you taking so long?

This article builds on themes from recent months. If you’d like to dig deeper, here are some related reads from the archive:

• One bottleneck at a time introduces the idea of subordination: telling the fast parts of a system to slow down so the constraint can catch up.

• Use it or lose it covers the thinking first protocol, a practical approach to slowing down before offloading work to AI, ensuring that critical skills aren’t lost.

• Invert, always invert explores pre-mortems and backward thinking, both examples of deliberate slowness in action.

Let’s get going.

Two speeds of thought

There’s a useful way to frame the debate that we opened with. In his oft-cited Thinking, Fast and Slow, Daniel Kahneman describes two modes of thinking: one that’s fast, automatic, and pattern-matching, and another that’s slow, deliberate, and analytical.

Transpose this thinking onto LLMs: in his conversation with Dwarkesh Patel, Andrej Karpathy describes them as ghosts or spirits, a kind of statistical distillation of human text, ethereal entities that are fully digital and mimicking humans. Words go in, patterns get matched, and words come out, which is, if you think about it, essentially, System 1 thinking.

AI is extraordinarily good at this kind of work: fast pattern-matching at scale. But the second kind of thinking, the work of deciding what to build, why it matters, and whether we’re solving the right problem, still requires human judgment.

And here’s the counterintuitive and highly interesting part: AI didn’t make the slow phases less important, it made them more important. When execution is cheap and fast, the leverage shifts to the decisions that precede it.

A wrong requirement, a misunderstood problem, a flawed design assumption: these propagate through everything AI helps you build, only now they propagate faster. The cost of getting System 2 wrong goes up precisely because System 1 has become so powerful.

If we want to go fast, we need to slow down first.

The illusion of speed

Back when I was doing my PhD, there was a common saying in academic circles: something like a few weeks in the lab will save you hours in the library. Software development has its own version: weeks of coding can save you hours of planning.

The reason it’s a joke, of course, is that both are backwards: the rush to start, the mounting realisation that something fundamental is wrong, and the painful rework that follows. I’ve certainly done many software projects where I wish I’d stopped and thought a little more before I rushed in. I can feel the cold flush coming back to me that you get when you stare at weeks of work that are completely wrong.

We have a clear intuition in software engineering that we should catch mistakes early, ideally in requirements or design, because the further a project moves on, the more expensive it is to fix them. Common sense can derive this without any research to back it up: a box diagram is easy to change, a misunderstood requirement less so, and a fundamentally flawed deployed architecture is a rewrite.

Therefore, here’s the problem: AI can help you create technical debt faster than ever! Oh no!

If the decisions that precede execution are flawed, AI will faithfully implement those flaws in a way that looks like fully featured code. Looks can often be deceiving, especially with powerful and confident models. It will generate thousands of lines of code based on a misunderstood requirement. It will happily build an elegant solution to the wrong problem.

The illusion of speed is that you’re making progress when you’re actually digging yourself into a deeper hole.

The answer isn’t to abandon speed, but to deploy it deliberately. We should only unleash AI’s pace when we’re confident it’s pointed in the right direction. Which raises the question: how do we know when that is?

When slowness pays off

The places where deliberate slowness pays off haven’t changed much, even as everything around them has accelerated. Requirements are still cheap to change when they’re just words on a page, and expensive when they’re deployed code serving real users. Design decisions are still easier to revise in a diagram than in a production system. AI didn’t alter this fundamental physics; it just increased the leverage of getting it right.

In a previous article, I called this the thinking first protocol: before offloading work to AI, spend time clarifying what you actually want. This isn’t unnecessary process; it’s the cheapest possible place to catch mistakes.

Here is the interesting paradox which shows the incredible usefulness of AI: the same tool that accelerates execution can also accelerate deliberation. Here are some practical ways to do this:

• Clarify requirements before coding. Spend 10 minutes writing down the problem you’re solving, your success criteria, and your constraints before asking AI to generate anything. What does “done” look like? What’s out of scope? Then get AI to interrogate everything that you’ve written before generating.

• Run a pre-mortem. Ask AI “What could go wrong with this approach?” before committing to a design. It will surface risks you hadn’t considered.

• Invert the problem. Ask AI “What would make this project fail?” to expose hidden assumptions. I’ve written more about this technique in Invert, always invert.

• Build a throwaway prototype. Use AI to create something in hours, show it to stakeholders, and validate your understanding before investing weeks. This is speed in service of slowness: you’re investing time upfront to learn.

• Build scrappy internal tools. Before you spend money on real products, use AI to build your own rough versions first. You’ll learn what you actually need and what you don’t. If you’re a paid subscriber, last month’s article goes deeper into some of the tools I’ve built myself.

• Surface edge cases early. Ask AI to generate edge cases and failure modes for your design before implementation begins. It’s far cheaper to handle them in a diagram than in production.

Of course, slowing down is easier said than done. Even if you’re convinced it’s the right approach, you’ll likely face resistance from those who see AI as a reason to speed up, not slow down.

The new cultural headwind

Given that AI is speeding things up so much, if you haven’t already been challenged on why something’s taking so long, you certainly will be soon.

“Can’t you just use AI?” is a new form of velocity pressure, and it’s particularly insidious because it conflates the appearance of productivity with actual throughput. Yes, AI can generate code in seconds. But generating code and solving the right problem are not the same thing.

So, what do you do?

• Be explicit about which phase you’re in. If you’re in the slow phase, say so: explain that you’re clarifying requirements, thinking through edge cases, and making sure you’re solving the right problem.

• Invite stakeholders to contribute. Their input is cheap to incorporate now and expensive later. Once you’re confident you’re pointed in the right direction, you can move fast.

• Show your working. Share artefacts from the slow phase: requirements docs, design sketches, pre-mortem outputs. This makes the invisible work visible and builds confidence that you’re progressing, not stalling.

• Timebox the slow phase. Give the slow phase a clear boundary: “We’ll spend two days clarifying requirements before we write any code.” This makes deliberate slowness feel intentional rather than open-ended.

• Share what you’re learning. Send brief updates as you discover things: edge cases you hadn’t considered, assumptions that turned out to be wrong. This turns the slow phase into a visible stream of value.

• Demonstrate quick wins. Build a throwaway prototype or mockup early to show stakeholders you can move fast when needed, buying you credibility for the slower, more deliberate work.

Interestingly, this maps nicely to the hill chart concept from Basecamp’s Shape Up methodology: the uphill climb is the slow phase of figuring things out, where uncertainty is high and you’re discovering what the work actually is; the downhill is the fast phase of execution, where the path is clear and you’re just getting it done.

This isn’t an excuse for delays; it’s a description of how good work actually gets done. The teams that ship fastest over the long term are often the ones that slow down at the right moments.

Your turn

This doesn’t have to wait for your next big project. You can apply this to every AI-assisted task you do. Before your next one, try this:

• Spend 10 minutes writing down what problem you’re actually solving. What does success look like? What’s out of scope?

• Before you start building, ask AI to run a pre-mortem on your approach. You might be surprised what it surfaces.

• If the task is significant, consider building a throwaway prototype first, one you’re willing to delete, just to validate that you’re headed in the right direction.

Wrapping up

Speed and slowness aren’t opposites; they’re tools for different phases. AI is effective for both: fast execution when the direction is clear, and accelerated deliberation when it isn’t. The skill is knowing which phase you’re in and applying the right tempo.

As always, until next time.

Subscribe now

Here’s why: AI has made building simple tools almost as easy as building a spreadsheet, and I’m going to walk you through some I’ve built over recent months to solve common problems without needing to buy specialist software.

By the end, I hope that you’ll feel motivated to get your hands dirty and close to the details and solve real problems (and it’s fun!).

Think about how internal tooling used to work. You had two options: convince engineering to build it for you, which meant competing for roadmap space against customer-facing features, or settle for off-the-shelf SaaS that didn’t quite fit your workflow and required convincing the company to pay for it.

Good internal tooling was a luxury reserved for the biggest tech companies; the ones who could afford dedicated teams to build custom software for management tasks. For everyone else, they made do with spreadsheets and workarounds.

Here’s what we’ll cover:

• Why the landscape has shifted and what that means for managers who used to code.

• Four tools I’ve built recently, from a bragdoc generator to a planning tool that embodies the single prioritised list philosophy from this month’s free article.

• Some ideas for cool tools you could build.

• The practicalities: what this requires, where it breaks down, and when a tool has served its purpose.

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

• Being in the details explores why staying close to what your teams are building matters more than ever.

• Use it or lose it covers the “minimum effective dose” of coding for managers who want to keep their skills sharp.

• Should managers still code? tackles the fundamental question that this article builds upon.

  The Engineering Manager is a reader-supported publication. To receive new posts and support my work, consider becoming a free or paid subscriber.

The new economics of tooling

The good news is that internal tooling is no longer a luxury reserved for large companies.

AI has democratised the ability to build custom tools, especially if you are time poor and a little rusty. The economics have fundamentally changed: if you have some technical background, and even if it’s been years since you wrote code professionally, you can now build a working tool in an afternoon.

The capabilities of coding assistants at the time of writing are good enough to solve countless common problems, even if what you need is something you’d have considered paying for just a few years ago.

This isn’t about you as a leader pivoting back to individual contributor again, or putting yourself on the critical path for shipping features. It’s about removing the friction between “I wish I had a tool that did X” and actually having it. The problems worth solving this way are the ones too niche for anyone else to build for you: your specific workflow, your team’s specific needs, the visibility gap that only matters in your context.

So, let me show you what I mean. Recently, I’ve built a handful of tools that have become part of how I work. Few of them took more than an afternoon. All of them solve problems that would have sat unsolved before.

And the liberating thing, other than having useful tools that solve real problems, is that knowing they don’t need to be production-grade makes the process creative, fun, and something that just feels really good.

Cool things I’ve built

Bragdoc generator

I mentioned this one briefly in Use it or lose it, but it’s worth expanding on here. Here’s the context: performance review season is tedious: you sit down to write your self-assessment and realise you’ve forgotten half of what you actually did. The evidence is scattered across Linear tickets, GitHub PRs, Slack threads, and your increasingly unreliable memory.

The concept of a “brag document” comes from Julia Evans: a running record of your accomplishments that you update throughout the year so you’re not scrambling to remember everything at review time. It’s a brilliant idea, but I never managed to keep one up to date. So I built a tool to generate one for me instead.

My workplace uses Linear for everything, and I also track my personal work todos in it, which makes it a comprehensive record of my work. Given that it’s a system of truth, it follows that the actions I take in Linear represent my main achievements for the week.

The bragdoc generator pulls issue descriptions and comments from Linear for the past week, then uses a local LLM via Ollama to summarise what I’ve been working on. I run it weekly to generate a document that tells me what I’ve been up to, which I can then reflect on, use to plan the next week, and revisit at performance review time. It took about an hour to build with Claude Code.

It’s not perfect, but it solves my problem well enough, and that’s the point. Perfect is the enemy of done. If you’re interested in giving it a go, you can fork it yourself, or repoint it to other tools if you don’t use Linear.

The planning tool

This month’s free article introduced the single prioritised list: one ordered list of what matters most, rather than the usual mess of backlogs, roadmaps, and priority tiers scattered across different tools and documents. We wanted to use it to facilitate planning discussions at a high level for 2026, so I built something.

The requirements were more ambitious than the bragdoc:

• A list of projects with their estimates and resourcing needs as submitted by the teams, along with metadata like home team and required skills: backend, frontend, QA.

• A list of all staff with their skill sets and home teams.

• The ability to drag projects into priority order to create the single prioritised list.

• Manual allocation by dragging people onto projects.

• Auto-allocation that considers priority, available skills, and a preference for keeping engineers in their home teams.

• A roadmap view showing what gets fully staffed, what’s partially resourced, and what gets nothing at all.

• Import and export from CSV so we could pull data from existing spreadsheets.

Here’s the first screenshot of what it looks like. All staff and projects are fictional.

Read more

It’s probably the most simple idea you could think of: that your team, department, or company should have one list of priorities, stack ranked from top to bottom, but it’s surprisingly rare to see in practice because it’s so hard to do.

Most organizations instead operate with multiple competing roadmaps, parallel backlogs, and a collection of P0 initiatives that all demand equal attention. The result is predictable: silos, politics, and a workforce that’s perpetually busy but rarely finishing anything.

We’re picking up a theme that has threaded through recent months. If you’d like to dig deeper, here are the previous articles from the archive:

• One bottleneck at a time explores the Theory of Constraints and how systems always have a single constraint that limits throughput.

• The beauty of constraints reframes constraints as tools that unlock unconventional thinking and force ruthless prioritization.

• Being in the details covers how leaders can stay close to what their teams are building.

All of these articles revolve around a common idea: the discipline of focus and how saying no, and doing less, is one of the most important skills that you should learn as a leader. This month, we expand upon that by exploring what happens when leaders sidestep the hard work of deciding what truly comes first.

Priority, not priorities

Last year, a friend recommended a book to me called Essentialism: The Disciplined Pursuit of Less by Greg McKeown. Within it was an anecdote about priorities which I found compelling.

The word “priority” came into the English language in the 1400s, and it was singular, meaning the very first thing, the thing that came before all others. It stayed singular for the next five hundred years.

Only in the 1900s did we pluralise the term and start talking about “priorities.” The Oxford English Dictionary charts this shift in usage over time. As society moved into the industrial era, the singular priority gave way to multiple priorities, and the organisational behaviours that followed may have mirrored the overloading of the word itself.

Think about your own organisation for a moment.

• How many parallel roadmaps and subroadmaps exist, with engineers smeared fractionally across all of them? For example, does your security roadmap fight with your product roadmap and your performance roadmap?

• How many teams have their own backlog of P0 items, with each saying they need more people to work on them?

• How many initiatives are all happening at once, each with their own sponsor claiming that theirs is the most important, leading to silos and politics?

Here’s the rub: the plural form of the word has given us permission to avoid the hard work of truly deciding what comes first.

Why do we do this to ourselves? Because a single ordered list forces you to tell someone that their work isn’t as important as they thought. It means having uncomfortable conversations about why one team’s initiative sits below another, and it risks making enemies, or at least uncomfortable allies.

But it’s not just about other people: multiple priorities also let us avoid making hard choices ourselves, because as long as everything is important, we never have to confront what we’re willing to sacrifice. Hell, we even do it within our own personal to-do lists. So instead, we create parallel tracks, we give each team their own roadmap, we let every team maintain their own P0 list, and we avoid the conflict by pretending that everything can be first.

A single prioritised list is a forcing function, and it’s equally powerful at the individual, team, department, and organisational level. In fact, it gets more important the broader the impact. It forces the hard conversations to happen, because you cannot place two items in the same position, and someone has to decide which one comes first.

It requires trade-offs to be explicit, because moving something up means moving something else down, and everyone can see the consequences. It also drives alignment, because once the list exists, there is no ambiguity about what the organisation considers most important. And it externalises the debate: the argument becomes about the list, not about individuals and their opinions, which makes prioritisation a rational exercise rather than an emotional one.

So does it actually work? Let’s look at some examples.

Making the hard choice

There are plenty of high profile examples of the single list method working in practice. Let’s look at three of them.

At PayPal, Peter Thiel insisted that every single person could only do exactly one thing. According to Keith Rabois, Thiel would refuse to discuss virtually anything else with you except what was currently assigned as your number one initiative. Annual reviews reinforced this: employees could only identify their single most valuable contribution to the company.

Thiel understood that most people will solve problems that they understand how to solve, which means, in his words, that they will solve B+ problems instead of A+ problems. A+ problems are high impact, but they’re difficult, and you cannot immediately derive a solution, so you tend to procrastinate. The discipline of only being allowed to do one thing led to significant breakthroughs.

Amazon embodies this principle through what they call single-threaded leadership. David Limp, a former SVP, said: “The best way to ensure that you failed to invent something is by making it somebody’s part-time job.” A single-threaded leader is entirely dedicated to one initiative, with no competing responsibilities: they solely work on the number one item on their list.

When Jeff Bezos wanted to build the Kindle, he appointed Steve Kessel to lead it. As described in Working Backwards by Colin Bryar and Bill Carr, Kessel was running the physical books, music, and video business at the time, which was 77% of Amazon’s revenue. The crucial decision was that Kessel left his previous role entirely: he didn’t try to run both. The same pattern repeated with AWS, where Andy Jassy was the single-threaded owner from inception. Both, as you well know, became successful businesses.

And then, in the most famous example, when Steve Jobs returned to Apple in 1997, the company had dozens of mediocre products and was on the verge of bankruptcy. Jobs eliminated 70% of them and focused on just four computers: a consumer desktop (iMac), a consumer laptop (iBook), a professional desktop (Power Macintosh G3), and a professional laptop (PowerBook G3). “People think focus means saying yes to the thing you’ve got to focus on,” he said. “But that’s not what it means at all. It means saying no to the hundred other good ideas that there are.”

Years later, Jobs gave advice to Nike CEO Mark Parker that captures the same philosophy: “Nike makes some of the best products in the world. But you also make a lot of crap. Just get rid of the crappy stuff and focus on the good stuff.”

These examples share a common thread: leaders who were willing to make the hard choice and live with the consequences. But what happens when they don’t?

Death by a thousand priorities

What happens when organisations don’t make the hard choice? The symptoms are predictable, and you’ve probably seen them before.

• Silos form. When teams don’t share a single list, they stop sharing ownership. Each team optimises for their own backlog, guards their own resources, and operates from a mindset of scarcity. An American Management Association survey found that 83% of executives said silos existed in their companies, and 97% said they have a negative effect, yet it still continues to happen.

• Engineers get peanut buttered. Without clear priorities, engineering managers spread people thinly across too many projects. Everyone is partially allocated to everything, and nothing gets the focused attention it needs. A common failure mode is when everything becomes a P0, and any project owner who honestly labels something as P1 learns quickly that there’s no time for P1 work.

• Decision fatigue sets in. When there’s no single list to reference, every resource allocation becomes a negotiation. Leaders burn cognitive energy on debates that a clear ranking would have settled automatically.

Think back over the last week. How many of these effects have you seen, individually or perhaps all of them? How often does this happen at your organisation?

Your turn

Creating a single prioritised list is simple in theory and difficult in practice. But the difficulty is the point: the discomfort you feel when forcing a ranking is the same discomfort you’ve been avoiding by letting everything be equally important.

Take ten minutes and try this exercise:

• List everything. Write down every project and initiative currently in flight for your team or department. Don’t filter or categorise yet, just get them all down.

• Force a ranking. Put them in order from one to n. Not tiers, not categories: a single ordered list. No ties allowed.

• Notice the hesitation. Where do you want to create exceptions? Where does it feel impossible to choose? That hesitation is where the real prioritisation work lives.

• Identify who decides. Can you make these choices on your own, or do you need input from your team and peers? If it’s the latter, that conversation is the one you’ve been avoiding.

If you lead a department, see if you can identify the most important priority for each team, then rank that list. Don’t worry about the detail within each team for now. Are any teams under or overstaffed, and is that because the hard decision hasn’t been made? Would it be easier to have that rebalancing conversation with the list as proof?

Then share your list with your peers, your team, or your manager for input. Talk about the content of this article and see whether the single list approach could unblock some of the gnarliest decision bottlenecks you’re facing right now.

Wrapping up

Remember, it’s priority, not priorities: you should just have one single list. The principle is simple, but the execution requires courage: the courage to tell someone their project is seventh, the courage to admit you’ve been avoiding the hard choice yourself, and the courage to make trade-offs visible rather than hiding them behind parallel tracks and consensus theatre.

The companies that move fastest aren’t the ones with the most resources: they’re the ones that know what comes first.

Until next time.

Thanks again for your ongoing support. It gives me the resources needed to keep writing. As always, the subscriber chat is open if you want to send me your thoughts and feedback. I’m always listening and I would love to hear from you.

This month, we’re revisiting something I wrote several years ago before COVID-19 was even a thing: the final chapter of my first book, Become an Effective Software Engineering Manager. That chapter was called The Crystal Ball, and it presented an exercise for defining your career vision and then building a plan to get there. I still stand by this approach, and I think it’s able to unlock new ways of thinking about the future.

However, we can’t help but observe that the world, our careers, and even our industry are more uncertain than they’ve ever been. Projecting into the future is a difficult exercise, and maybe, depending on how you are feeling, even a futile one. So what should we do? Perhaps we should plan differently.

So, here’s a rework of that chapter. Instead of asking you to plan a destination, this article offers a different exercise: one that helps you define your north star: who you are, what you value, and what kind of work you want to be doing. Not titles, companies, or rungs on a ladder that may no longer exist. This is an exercise I’d highly encourage you to do for yourself, but also to do with your teams. It’s a great way to start the year together.

Here’s what we’re going to cover: we’ll start by looking backwards at how much has changed (and my, hasn’t it just?), then sit with the uncertainty that makes traditional career planning so difficult. After that, we’ll work through the exercise itself. Finally, we’ll look at how to use what you’ve created as a tool for making decisions.

I know that it’s easy to read exercises like this and think “I’ll come back to that later”; I’ve done it myself often, with many important things. But I highly recommend finding a little time to yourself at some point during your day or evening to go through this with a pen and paper. I think that it’s always valuable to introspect about what matters most.

So, if you’re ready, let’s go along for this ride together.

The backward look

Before we think about the future, let’s look at the past. Not to dwell on it, but to notice something important: a lot can happen in ten years, much, much more than you might ever have imagined. We tend to look backward and mentally compress timeframes, forgetting just how much actually happened. Think about it: ten years is longer than secondary school, and it’s the length of three university degrees, or about two and a half PhDs, and this is exciting thinking about what might change in the years to come.

So here’s the first part of the exercise. Draw a line on a piece of paper, or open a blank document if you want to do it digitally. Mark the left end as ten years ago and the right end as today. Now plot the significant changes in your life along that line. Not just your professional life; everything. I’m talking about jobs, promotions, skills you learned, companies you joined or left, cities you moved to. But also relationships, children, losses, moves, health, adventures. Good and bad, get it all down.

Now, if you’re earlier in your career and ten years takes you back to before you started working, that’s fine. Focus on the years you’ve been in the industry, and include significant changes from your education or early life that shaped where you are now. The point isn’t the specific timeframe, it’s recognising how much can change, and how little of it you could have predicted.

Take a step back and look at what you’ve drawn. Ask yourself:

• How much of this could you have predicted looking forward ten years ago?

• What happened that you never saw coming?

• Which events changed your trajectory the most?

• What’s on the line that you’d forgotten in day-to-day life until now?

Now, let’s zoom in on the last five years, because this part of your timeline probably looks different and denser than the rest. I mean, think about everything that’s happened since 2020: a global pandemic, lockdowns, the sudden shift to remote work, followed by the hiring boom of 2021 and 2022 fuelled by zero interest rates, and then the sharp correction that brought layoffs, hiring freezes, and the flattening of organisations. And then AI: ChatGPT arriving in late 2022, and within months, tools that genuinely changed how many of us work. All of that in just five years. Wild, isn’t it?

Go back to your timeline and think about how these events mapped to your own experience. What’s changed in how you work, where you work, who you work with, and what your role actually involves day to day? Is there anything you missed? Add it now. What happened to you versus what did you make happen?

Try putting yourself back ten years in the past. What were you thinking about at the time? What did you think your future would look like? Maybe you had a plan, maybe you had ambitions, worries, expectations. Now contrast that with what you’ve just written out. How much of it matched?

Now think about this: if you couldn’t have predicted where you are now from ten years ago, or even five years ago, what does that tell you about predicting the next ten? The next five? The world you are in when you plan is never the world you’re in when you get there.

Sitting with uncertainty

So here’s the uncomfortable part: if that much changed in the last ten years, and especially the last five, what certainty can we have about what we’ll be doing in the next ten? Or the next five? As you saw in the exercise, it was hard enough to predict back then, and arguably it’s even harder now. The honest answer is: not much.

Traditional career planning assumed a relatively stable world. You could look at people five or ten years ahead of you in their careers and see a path that might be available to you. The rungs of the ladder were visible, and I’ve written about them before: the two tracks of growth, the journey from IC to manager to director to VP.

Although the titles varied, the shape of progression was familiar. You knew where you were going, even if you weren’t sure exactly how long, and at which company, but you’d get there.

That assumption is now sitting on weaker ground. There are at least three sources of uncertainty that make the old mental models harder to rely on.

AI is changing knowledge work like ours. Assuming you haven’t been hiding under a data centre for the last three years, you’ll have seen and experienced this first hand. We don’t know exactly how this will play out, but it’s reasonable to expect that some of the work you do today will be done differently, or not at all, in future. The specific skills that got you here, such as knowing a particular programming language or domain, may not be the skills that matter most going forward. This isn’t meant to be downbeat or negative; it’s just honest uncertainty.

Flattening organisations mean fewer management positions. The Great Flattening has seen companies cut management layers across the board. If you’re an individual contributor who was planning to move into management, that path is narrower than it was, and it might not even be as appealing as it once seemed. If you’re a manager who was planning to move up, there are fewer rungs above you. The old mental models may not apply.

The nature of “senior” may be changing. Here’s a hypothesis: if AI can handle more of the routine, mechanical work, then what does it mean to be senior? Perhaps increasing seniority will mean less deep programming and more managing a team of agents. Maybe the senior engineers of the future will spend their time orchestrating, reviewing, and directing AI rather than writing code themselves. We don’t know yet, but it’s worth considering given the rapid pace of change and capabilities. This may or may not make particular paths attractive.

This isn’t meant to be a pessimistic or optimistic view; in fact, only your own reaction to the direction things are taking can determine that. But what is for certain is that the path is less clear and predictable than it used to be. The destination you’re aiming for might not exist by the time you get there. So what do we do instead?

Forming a north star

Read more

This might sound obvious, but it’s surprisingly rare in practice. Most leaders spread their effort across many initiatives simultaneously, making partial progress on everything and completing nothing. The insight we’ll explore is that systems don’t work that way: there’s always one constraint that matters most, and focusing elsewhere is, at best, wasted effort.

Here’s what we’re going to cover:

• We’ll start by looking at a pattern I call the scattered leader, which is the well-intentioned but ineffective approach of fighting on multiple fronts at once.

• Then we’ll dig into the core insight from Eliyahu Goldratt’s The Goal and the Theory of Constraints: every system has a single primary bottleneck, and improving anything else doesn’t improve the system.

• We’ll look at a practical example of what happens when you put your best people on unglamorous but critical work.

• And we’ll talk about the courage required to subordinate everything else to fixing the bottleneck.

If you find this topic interesting, here are some complementary articles from the archive:

• The beauty of constraints reframes constraints as tools rather than obstacles.

• The contribution curve explains why hiring doesn’t instantly help, since new people are net-negative contributors initially.

• Delegation covers how spreading knowledge reduces single points of failure.

But for now, let’s focus on bottlenecks. Let’s get going.

The scattered leader

Imagine a leader who’s looking at their organisation and seeing a lot of problems. Deployments are slow and painful, so the team avoids them. The hiring pipeline has stalled, with candidates stuck waiting for interviews. Code reviews are backing up, with PRs sitting for days before anyone looks at them. And there’s that auth system refactor that’s been on the roadmap for six months.

So they do what feels like the responsible thing: they start working on all of it. Some time spent researching CI improvements, a meeting with talent about hiring, a push to get reviews moving, leading a technical spike on the auth system. Progress is being made on everything, but nothing is getting finished.

Sound familiar?

This approach feels diligent, and it certainly looks proactive to those around you, because people and organisations tend to feel that being at capacity is the metric for success. But in an era of flattened organisations where managers are under high scrutiny, we need to focus deeply on our impact rather than our busyness.

The Great Flattening has seen companies like Microsoft, Amazon, and Meta cut management layers en masse, with middle managers making up 29% of all layoffs in 2024. In this environment, even though partial progress means saturation of your time, optimising for busyness rather than impact is going to lead to failure.

So what’s the alternative? It’s actually quite radical, because it requires you to do one thing at a time in a world that rewards the appearance of doing many things at once. It starts with thinking about your team, department, or organisation as a system with inputs and outputs, and systems have a particular property: at any given time, there is only one bottleneck that is limiting the throughput of the whole thing.

You can work on improving other parts of the system concurrently, but it won’t make any difference to the overall output. In fact, it often makes things worse by creating pile-ups of work waiting at the bottleneck. The discipline here is sequential focus: find the single biggest constraint, put all of your effort into removing it, then find the next one. It sounds simple, but it goes against every instinct we have as leaders to be seen as busy and responsive to all problems.

Finding the bottleneck

Like all good ideas, this idea isn’t new, and we can learn a lot from studying history. As mentioned in the introduction, it comes from Eliyahu Goldratt’s The Goal, a business novel from 1984 that introduced the Theory of Constraints.

The core insight is simple: every system, whether it’s a factory or a software team, has exactly one constraint that limits its overall throughput at any given time. Improving anything other than that constraint doesn’t improve the system. It just creates inventory, and inventory is bad because it creates blockages.

Goldratt outlines five focusing steps:

1. Identify the constraint.

2. Make sure it’s not being wasted on unnecessary work.

3. Subordinate everything else to it.

4. Elevate it if needed (invest to increase its capacity).

5. Repeat.

The key insight is that this is a cycle, not a one-time fix.

Goldratt illustrates this with a factory analogy. Imagine three stations on a production line: Station A builds components at 100 units per hour, Station B assembles them at 10 units per hour, and Station C packages them at 100 units per hour. If you invest in making Station A faster, pushing it to 150 units per hour, you don’t get more output. You get a pile of components waiting at Station B. You can already see what needs to be done to improve this system.

In software teams, this pattern shows up everywhere: pull requests pile up waiting for review, features sit in staging for weeks waiting for QA, decisions stall because they’re waiting for leadership sign-off, and engineers are blocked because specs aren’t ready. Where you find things waiting is where you also find the bottleneck, and the question you need to ask yourself and your team is simple: what are we waiting on right now?

The deployment bottleneck

Let’s work through an example. Imagine that in your organisation, deployments are slow, painful, and risky. Because of past incidents, you’ve increased the number of manual checks and gates for every deploy, and now you’re only deploying once every two weeks. Engineers see it as a platform problem, while the platform team sees it as an engineering problem, since they need to up their quality and stop breaking things. Therefore, it sits unfixed: it’s not glamorous work, it’s not anyone’s specific responsibility, and the company is afraid of change in case things break even more.

Now imagine that you have oriented your department towards fixing bottlenecks as the most important priority, and you now recognise deployment as THE constraint. Everything else in the system is waiting on it, so you make a decision: you take some of your best engineers, the ones who would normally be working on the most exciting product features, and you put them on fixing the deployment pipeline.

This feels counterintuitive, and you’ll face resistance, because we naturally want to point our highest performers at the sexiest problems, not the ugliest ones. But constraints are often the ugliest problems, and changing this cultural instinct is part of the work of leadership, because high performers turn ugly work into beautiful work.

What happens next?

Assuming that you are offering the right empowerment and environment, your high performers bring their standards to the work. They automate the manual checks. They improve test coverage so that failures are caught earlier. They measure the length of time that it takes for pipelines to run and shave off minutes by parallelising automated tests. They make it so that anyone can deploy by just pressing a button.

Within weeks, the team is deploying multiple times a day instead of once a fortnight. Deploys become fast, reliable, and fundamentally boring. Now an interesting phenomenon occurs: the bottleneck moves elsewhere, perhaps to product specs or code review, and that’s the signal that it worked.

Now you find the next constraint and do it again.

The courage to subordinate

We mentioned subordination earlier in the five focusing steps. It means that once you’ve identified the constraint, everything else in the system must be reallocated to it. This is the justification for what we described above: taking your best engineers off feature work and pointing them at the bottleneck. Subordination gives you the framework to create that environment and defend that decision.

In practice, it means telling the fast parts of the system to slow down, or redirecting their effort towards helping the bottleneck. If your developers are producing more code than your reviewers can handle, the answer isn’t to hire more engineers immediately. It’s to have some developers stop writing new code and start helping with reviews, or building tooling that makes reviews faster.

This takes courage because it looks wrong to some company leadership. You’ll face questions: “Why isn’t our best engineer shipping features?” “Why is the team’s velocity down this sprint?” “The team looks less productive on paper.” I’ve had exactly these conversations, and the discomfort is real. You’ll need to defend the decision upward, explaining that short-term optics matter less than long-term throughput. I’ve written before about the tragedy of the common leader and the importance of long-termism in leadership. This is one of those cases.

The alternative, which is busy hands creating more inventory that piles up at the bottleneck, feels productive but achieves nothing. We’re not trying to make everyone busy. We’re trying to optimise the flow of value through the system.

Your turn

Now it’s your turn. I’d encourage you to spend five minutes thinking about your team, your department, and your company. At each level, write down what you think the biggest bottleneck is to going faster right now. Then write down what you could do actionably to fix it.

At the team level, perhaps your test suite is slow and flaky, and all of the onus is being put on the QA engineer to fix it while the other engineers don’t think it’s their problem. The action here is to have all of the engineers pivot their time to speeding up the test suite together, rather than leaving it to one person.

At the department level, perhaps your hiring pipeline has stalled, with roles open for months and not enough candidates coming through. The action here is to get everyone to step outside of their usual role. For example, all engineers could spend a morning together every week sourcing people online, both from their networks and through reach-outs on LinkedIn.

At the company level, perhaps leadership sign-off on major decisions is slow, sometimes taking weeks for people to get back. The action here is to focus all effort on speeding up decisions by building a process to make sure that the most important things are shown to leadership every single day, and putting in place a 24-hour turnaround time for them to say yes, no, or to request more information.

So, what’s your bottleneck at each level? And what could you do about it? Could you start making progress on it tomorrow?

Wrapping up

The scattered leader fights every battle and wins none. The focused leader finds the single constraint and removes it, then does it again. It’s a simple discipline, but a hard one to maintain in a world that rewards busyness over impact. One bottleneck at a time: that’s all it takes.

Until next time.

Thanks again for being a subscriber; I really appreciate it. As always, the subscriber chat is open if you want to send me your thoughts and feedback in order to shape the future of this newsletter. Message me any time. I’m always listening.

As we close out 2025, I’ve been reflecting on a question that I’ve been asked more than any other this year: “How do I get my team to actually use AI to its full potential?” It’s a question that comes up at conferences, online, and in one-to-ones with other leaders. And I get it: driving AI adoption has been a core part of my role this year.

When I started my current CTO role, I came off the back of intense accelerated AI adoption at Shopify and had been extensively experimenting with LLMs for my own work, using them as thinking partners, research assistants, and coding companions.

As part of my interview and onboarding process, there was a clear feeling that AI wasn’t being used enough in the engineering organization, and that they wanted me to come in and drive adoption to increase throughput. But the question was: how?

This initial mismatch (which is now dramatically different) became one of the most interesting leadership challenges I’ve faced. How do you drive adoption of something when you can’t force people to see its value? How do you create the conditions for playful and healthy discovery rather than mandating compliance?

Throughout 2025, we’ve seen the media report on companies taking a strong-arm approach; effectively declaring it an immediate performance issue if engineers aren’t utilizing AI tools. While that is one way to go about it, I prefer a more organic approach that I think works better for most organizations that aren’t the top 0.1% big technology companies.

If you’ve been following along with my previous articles on AI, you’ll know that I’ve written extensively about using LLMs as a leader: as a thinking tool, a co-processor for the brain, and a way to accelerate decision-making. Articles like Leadership co-processing with LLMs and Councils of agents explored these ideas in depth. If you haven’t had a chance to read these, do check them out. I think they might give you a number of ideas on how to use AI more creatively in your thinking processes.

But this article turns the attention to a different challenge: getting your engineers to use AI both at all and then efficiently and effectively. Because while I’ve been a heavy LLM user for years now, the reality is that adoption across teams is uneven, and that unevenness is costing organizations real value.

I spoke about this subject at LeadDev Berlin earlier this year. The talk went down well, provoking a number of incredibly insightful conversations with others, and I thought it deserved a long-form write-up where we could really dig into the material. If you are going into 2026 wondering how to drive AI usage in your organization, this exploration is for you.

It might be worth getting a cup of tea for this one.

The J-curve

So, how do you get anybody to adopt anything? Before diving into tactics, I think it’s helpful to understand the shape of adoption itself. This brings me to a model that often bubbles up in my mind: the Productivity J-curve.

Humans have been through numerous productivity revolutions: the printing press, the Industrial Revolution, personal computing, the internet, and smartphones. For each of these technologies, adoption follows a J-curve.

But how do you read the J-curve? Let’s read it from left to right.

First, a new capability piques everyone’s interest. There is an initial burst of adoption and productivity as people lean hard into the phenomenon to see what it can do.

Then, reality sets in. The delta between the hype and the practical application sends the user experience into a trough of disappointment. Suddenly, it feels like using the new technology makes everything slower, worse, or more difficult. Resistance builds, and people wonder whether it was all just hype.

This trough is normal. But as time passes, as people learn the tooling and the capabilities improve, productivity begins to grow beyond the baseline, and then productivity outpaces the status quo before that technology came about.

We can pull from a number of examples from over the past decades to see how this occurs.

In 1987, Nobel laureate Robert Solow made an observation: “You can see the computer age everywhere but in the productivity statistics.” This became known as the Solow Paradox.

Despite massive investment in information technology throughout the 1970s and 1980s (computing capacity in the United States increased a hundredfold during this period) labor productivity growth actually declined, dropping from over 3% annually in the 1960s to roughly 1% in the 1980s. Businesses were buying computers, installing networks, training staff, and watching their productivity numbers go backwards.

The paradox persisted for nearly a decade. Economists debated whether computers were fundamentally unproductive, whether measurement was flawed, or whether something else was happening entirely.

Then, in the mid-1990s, everything changed. US productivity growth surged from 1.5% to 2.5% annually between 1991 and 2007. Research from the Federal Reserve later attributed roughly two-thirds of this acceleration to information technology: both the production of computers and their use across the economy.

The lag wasn’t a failure of the technology; it was the time required for organizations to fundamentally rethink their processes. Companies had to stop using computers to do old things faster and start using them to do entirely new and better things. After all, nobody needs a faster horse.

The same pattern was observed with smartphones. Whilst the iPhone launched in 2007, only 35% of US adults owned a smartphone by 2011. Early enterprise adoption was marked by fierce debate about whether these devices were productivity tools or productivity killers.

Research from the period documented a “latency effect” of approximately three years before mobile phone investments showed up in productivity statistics. Businesses had to figure out Bring Your Own Device policies, mobile-first workflows, and entirely new categories of work that simply weren’t possible before. By 2023, smartphone penetration reached 91% of US adults, and the debate about whether they were useful for work, or even useful at all, seems like ancient history.

As we have seen, the pattern is consistent: initial hype, a frustrating trough where the technology feels like more trouble than it’s worth, and then a new level of productivity and also a status quo which people couldn’t imagine not existing.

We are seeing the pattern reoccur with AI right now. At a macro level, the industry is navigating this curve. But critically, every individual in your team has their own local curve. As a leader, you must set expectations upfront: the beginning of the adoption process may feel slower, not faster. That is the investment period, and we must be mindful of this before it pays dividends. The Solow Paradox lasted nearly a decade for personal computing, and roughly three years for mobile phones.

With AI, the curve may compress: the tools are improving faster than any previous technology, but the trough is still real, and your engineers are no doubt hitting it at all points along the curve. Some may be struggling to get started, some may be finding it goes against some of their principles for what engineering is, and some may find it unwieldy and hard to keep under control.

So, with the J-curve in mind, the question becomes: how do you help people through it? It’s worth noting that some companies have decided to take a very direct approach.

The forced adoption spectrum

Not every company is willing to let the J-curve play out naturally. In 2025, we saw high-profile examples of leaders trying to accelerate adoption through extreme measures.

In April, my old CEO Tobi Lütke posted an internal memo on X after learning it was leaked. The memo declared that “reflexive AI usage is now a baseline expectation at Shopify. Teams must demonstrate why they cannot accomplish their goals using AI before requesting additional headcount.” AI usage immediately became part of performance reviews. Prototyping, Lütke wrote, should be “dominated” by AI exploration. “Stagnation is slow-motion failure,” he warned.

A few months later, Coinbase CEO Brian Armstrong took an even more direct approach. After purchasing enterprise licenses for GitHub Copilot and Cursor, he posted a mandate in the main engineering Slack channel: onboard to AI tools by the end of the week, or attend a Saturday meeting to explain why. Those who showed up without a good reason were fired. “I went rogue,” Armstrong admitted. “Some people really didn’t like it..., but, as you know, I think it did set some clarity.”

So, if you’re Shopify or Coinbase, i.e. companies with global fame where engineers line up to work regardless of culture, you can make these moves, if that is how you wish to run your company. The talent cost of an extreme mandate is lower when you can backfill quickly with people who want to be there. Your brand kind of absorbs the reputational hit.

But, as you know, that’s perhaps 1%, maybe less, of companies out there. For everyone else, forcing adoption risks resentment, shadow non-compliance, and losing good people who feel micromanaged rather than empowered. The engineers who leave first are often the ones with options, who are also your best performers.

So where should you position yourself?

Let’s look at how to tackle culture and also crunch some numbers so you can convince Finance.

Read more

Last month’s article covered one of these models: “invert, always invert”, which is a method for thinking about problems by flipping them on their head and considering the worst that could happen, and then ensuring that you don’t ever make that the case. It turns out that doesn’t just work for investing but it also works well for the kinds of problems that we face in software engineering: designing resilient systems, planning rollouts, and ensuring that you have a backup plan in case something goes wrong.

This month, we’re going to look at another one of these mental models: “use it or lose it.” This mental model is becoming increasingly relevant as AI becomes more ubiquitous in our lives.

Here’s what we’re going to cover in the article:

• We’ll start with an introduction to the use-it-or-lose-it model, looking at real examples ranging from playing an instrument to doing exercise.

• Then we’ll cover how “use it or lose it” has affected managers for a long time, and how AI may be potentially compounding that effect.

• We’ll then consider whether there are ways we can use AI more intentionally to potentially preserve our critical thinking skills.

• And then, to finish, we’ll see how AI may actually be able to pave the way to us becoming broader generalists as managers, in a manner that supports our desire to be in the details and thrive in today’s flatter organizations.

So, as we begin to approach the end of 2025, let’s think about ways in which we can stay sharp in 2026 and beyond.

Practice maintains perfection

The tenet of use it or lose it is best summarized by the quote from the Polish pianist Ignacy Jan Paderewski: “If I miss one day’s practice, I notice it. If I miss two days, the critics notice it. If I miss three days, the audience notices it.”

In his 11th essay, Munger reflects, in his 80s, on what he remembers since school: effectively only that which he has used daily since then. In the world of investing, Charlie frequently used the basics of mathematics to real balance sheets, but all of the advanced calculus that he was once proficient in had long been forgotten.

A lack of daily practice leading to skill decay is a recurring theme for managers. One of the most common worries when moving into a managerial role is losing the hands-on coding skills that got them into the role in the first place.

As such, diligent managers invent ways to stay close to the details, such as pair programming, continuing code review, or carving out time to fix bugs or contribute to smaller features. However, as many of you know, this can be a challenge to maintain long term. Daily busywork work can become like gas: it expands to fill the size of the tank. As such, managers who interview for new roles often have to go into an intense period of studying to prepare for coding challenges.

However, although programming skills may diminish through underuse, managers do gain more opportunity to practice the other elements of their craft on a day to day basis, such as planning and strategy, coaching, and leading.

Accountability for one or more teams requires a continual sharpening of these skills, so the pre-AI manager could more comfortably let go of coding as it was replaced by the honing of others.

But, as more of us offload our strategic thinking and planning to AI (and I too have written plenty of material on methods to do this), there is a risk of these core cognitive managerial skills diminishing too, and as such, we need to be careful. We mustn’t become passengers in our own orgs.

The science of skill decay

We see use it or lose it in action after finishing formal education, and we also see it in exercise: cardiovascular fitness drops off rapidly if we don’t workout regularly, and muscles require regular training to maintain strength.

The same is true for our cognitive skills. A 2011 study published in Science on “The Google Effect” on memory showed that our brains optimise for where to find information, rather than the information itself. Similarly, a 2021 study found that increasing offloading behavior correlates with decreasing memory accuracy. Correlatively, a 2020 study in Nature contrasted how heavy GPS users show decline in spatial memory use, whilst London taxi drivers, i.e. those expected to have “the knowledge”, instead, show growth in that region.

Although it is too early for longterm studies on AI usage, a 2025 MIT Media Lab study showed that despite increased efficiency in students using ChatGPT compared to those that didn’t, that same group of students showed weaker neural connectivity and cognitive depth.

Interestingly, on the Dwarkesh Podcast, Andrej Karpathy explained that he programmed nanochat almost all by hand, with only some minimal tab-autocomplete as assistance. Although much of what he was building was “off the distribution curve” of what LLMs are trained on (since LLMs can be seen as a compression of the internet, and nanochat is novel work), he also stated that programming manually was the only way to truly learn, and that others wanting to learn from what he wrote should also follow the same hand-coding process.

Collating the themes above, we should be mindful of how we lean into AI as a thinking partner as managers and leaders. Although we may be hardwired to offload work and strive for efficiency, we need to be careful at not diminishing the core cognitive critical thinking skills that are at the heart of our craft. Losing our coding chops was bad enough; we don’t want to lose these skills too.

Inversion: designing an increasingly ineffective leader

Since we looked at the “invert always invert” maxim in the last article, perhaps we could call upon it here to design how we could become ineffective leaders in the current times.

So, considering what could be the worst that could happen, let’s think about how you could guarantee that you could become obsolete as a leader in 12 months:

• Rule number one: Stop being close to the details of what you’re building; specifically, the code and the architecture that is being designed within your team. Fully delegate all of the decisions to your team, so that you rely on what people say to you in order to understand what’s going on. You pay them to do the work, so let them get on with it.

• Rule number two: Do not use any of your time to stay on top of the latest AI developments. Instead, let your team tell you what the latest and greatest is, and don’t spend any time yourself trying out new models or tools. Why would you need to if you’re a manager?

• Rule number three: Become a “reviewer” rather than a participant to all of the activity in your team. Let your team get on with things entirely autonomously, and simply review what is happening at meetings and also in performance reviews.

• Rule number four: Do not regularly engage in any first principles or critical thinking, either with humans or AI. Either let your team tell you what needs to be done or fully offload decisions to AI that you have to make. After all, you have others to do the work for you.

The insight here, by looking at this through the lens of inversion, is that if you are doing all of these things, you are actively choosing obsolescence of your own impact. You are becoming a passenger, and we know that in the time of increased efficiency and flattened orgs, managers that are passengers aren’t going to last long.

Additionally, the other important insight, other than your immediate performance in your role, is that you are not engaging in any cognitively difficult activities. When you subtract practice of cognition through critical thinking and coding, then what actually is left? What is the purpose of your role, and perhaps more crucially, how do you think your skills are going to fare in the next three, five, and ten years if this is your default mode?

We need to think about how to avoid this path at all costs. And hopefully, by doing so, it will mean that not only will you be an effective manager, it will mean that there is nothing for you to lose, as per the central mental model of this article.

An antidote

Building on our inverted case, we need to offer an antidote that solves each of those four rules. This antidote should be such that it means that you can have opportunities to keep your coding skills sharp, which means you are close to the details and get to practise contributing to what your team is building in more depth, but it also gives you ample opportunity to sharpen your cognitive abilities, offloading the right work to AI.

Rule number one: a minimum effective dose of coding

We know that as managers we (mostly, there are some exceptions) cannot be on the critical path for shipping features. It typically ends up slowing the team down. However, that doesn’t mean we have to stop coding entirely. We just need to find the minimum effective dose to keep our skills alive.

There are a number of ways to do this. One is building internal tools, scripts, or prototypes that help the team but aren’t blocking production. For example, I built a brag doc generator that I could use to find the descriptions and comments from issues that I’d been contributing to on Linear, and then use a local LLM via Ollama to summarise it for me. This was a fun activity that only took me around an hour with Claude Code.

Another is pair programming with your team. This is a high-leverage activity that gets you close to the workflow (the friction of the tools, the build times, the environment quirks) without the pressure of delivering a feature solo. It keeps the “finger feel” of the craft real. It works even better remotely than it does in real life, and it helps you really see what your team is building.

And of course for those of you that love programming, there’s always the evenings and weekends for hobby projects.

Rule number two: get your hands dirty with AI

Do not outsource your understanding of frontier tools to others. Take an active and passionate interest in the tools that are reshaping our industry. As hopefully I’ve shown in previous articles that show how to improve your strategic thinking and decision-making with LLMs, AI is not just for engineers, it’s for everybody. I couldn’t work without it now. You too should become well-versed in the latest and greatest through personal hands-on experience.

Instead of just reading articles and opinions about what is best, find out for yourself. Schedule weekly “lab time” (even just one hour) to test new AI tools personally. Understand the different modes that they offer from prompting to agentic interfaces to the capabilities of the different models, and which ones work best for writing and coding and which IDE you prefer. Keep that preference up to date through constant trial and iteration. For example, what exactly is different between Antigravity and Cursor other than the fact that Antigravity has less available models? How different is Antigravity’s agent mode compared to Codex’s? Try them out and see.

Reclaim the joy of creation without the pressure of production. This is how you stay ahead of the curve, rather than having it explained to you. Additionally, when your team sees that you’re getting as stuck as they are, it only builds respect, and additionally, they’ll only be more likely to trust your judgement when it comes to deciding which tools the team should use and how.

Rule number three: become an active participant

Fight hard against the trope of the manager as the approver of all things. Move from being a “reviewer” to a “participant” in your team. Force yourself to ask at least one question on a PR or design doc that requires you to open the IDE, diagramming tool, or query the logs to answer.

I call this “diving down the stack.” The idea is that you try as a manager to go one or two levels deeper than your team would typically expect. It should surprise them. Again, this helps you build your confidence in what is coming out with your team (you see and care about the details) but also builds trust and respect with those that are building for you (”wow, they see and care about the details!”).

If you can’t quite find the time and space to dive down the stack technically regularly, then at least dive down the stack with logic and reasoning. There are many mental models that you can apply here to engage in productive conversations with your engineers that will improve the work that your team is doing and fundamentally ensure that you’re utilising your cognitive ability.

For example, in a previous article, the beauty of constraints, we outlined a number of techniques that you can actively wield to encourage your team to do less unnecessary work, whilst also ensuring that you are completely across the constraints, requirements and trade-offs of the work that you’re leading.

Becoming an active participant in your team sometimes means doing the things that don’t scale. However, doing the things that don’t scale is the way to be successful as a manager today. You need to understand the code that’s being shipped, the architectural decisions, the metrics, requirements, and the constraints. But the good news is, in terms of use it or lose it, if you are doing the things that don’t scale, you’re keeping yourself incredibly sharp at the same time.

Rule number four: the “thinking first” protocol

Finally, and importantly, we need to think about how we don’t offload all of our cognitive ability to AI. Whilst it’s true that there are no long-term studies about the effect of AI on our cognition, as seen by the orthogonal studies that are referenced at the top of the article, it would be wise to keep practising our cognition in the spirit of using it and not losing it.

To me, practising our cognition is about understanding what to offload and what not to offload. The way that I’ve been navigating this choice is as follows:

• Is the task that I’m doing completely menial? Will executing and completing that task teach me nothing new? For example, tasks like cleaning data, summarising a document, or doing some research on the web where I would have had to click 40+ links on Google, and so on. If that is the case, then I can happily delegate that completely to AI and then just review the output.

• If the task is not menial, then I always make sure that I take a first pass myself using my own cognition. This helps me arrive at an initial solution, and then I can use that as a base case to start interacting with AI as a way of critiquing and expanding my work. For example, if we needed to make some improvements to our career matrix, I wouldn’t simply dump them into a prompt and then ask it what I should do. Instead, I would take the time to read and review them myself first, come up with my own suggestions for improvement, and then use that as the starting point for prompting.

A great analogy here is working like a surgeon. Here, Geoffery Litt (referencing a theme covered in The Mythical Man-Month) argues that we should be the surgeon, making the key decisions and actions, and the AI should be the team of assistants, allowing us to delegate the grunt work.

Think about what it means to use AI like a surgeon in your own role, whether that be in coding, strategic thinking, or researching and understanding information in order to make decisions. This way you fight cognitive offloading, and instead only delegate the things that you would ideally want to automate in the first place.

Wrapping up (the presents)

We began this article by exploring the biological reality of “use it or lose it,” a principle that applies as much to our cognitive abilities as it does to our muscles. We’ve seen that there is a possibility that the “competence pacifier” of AI, if left unchecked, may accelerate the decay of the very skills that make us effective leaders: our critical thinking, our technical context, and our ability to reason from first principles.

However, the path forward isn’t to reject AI, but to use it with intent. By doing an inversion pass on what it means to be an ineffective leader, we can follow the antidotes we’ve outlined: finding your minimum effective dose of coding, getting your hands dirty with the tools, becoming an overly active participant in your team’s work, and adopting a “thinking first” protocol. By doing so, you can ensure that you are sharpening your mind rather than dulling it.

The action for you in 2026 is clear: be the surgeon, not the passenger. Engage your critical thinking explicitly before you prompt. Dive into the details. Do things as a manager that don’t scale. By doing so, you won’t just preserve your skills; you’ll evolve them, becoming a broader, deeper, and more effective leader.

We are at yet another turning point for managers. More is expected of us, and in the same way that the nature of programming is changing with AI, I also strongly believe that the nature of management is as well. However, the tools are there for you to use, but it’s up to you to make sure that you use them effectively and in a way that builds your skills, rather than dulling them.

For paid subscribers, there’ll be one more December article coming up shortly. For free subscribers, I’ll be back in January with a brand new article. I hope you have a fantastic holiday period.

Here’s part two of November’s paid newsletter.

We pick up where we left off in part one, which is where Brandwatch had been acquired and it was time to move up and move on.

In this second part, we’ll cover:

• The executive recruitment process, which I had to learn and navigate for the first time. How exactly do unadvertised roles get filled?

• My move to Shopify, which was driven not only by a desire to learn and grow at somewhere famous, but most importantly supported the kind of life that I wanted.

• How economic change led to cultural change, and why becoming a parent forces the hard choices. We cover my current CTO role and how I got it, by picking up the connections that I’d made some 3.5 years previous.

We begin the story during 2021, in Cumbria, during lockdown. We’d been acquired and it was clear that the company would never be the same. It was going to be difficult saying goodbye mentally to something that had been part of my life for nearly ten years, but when you feel that it’s time, it’s time.

Getting to grips with executive recruitment

The question was, therefore, what to do next. I was in two minds. Part of me thought that now was the time to step up and be CTO for the first time; however, I didn’t really know how to do this. On the other hand, part of me was observing so many great companies starting to fully embrace remote work, and also hiring like crazy, and I saw this as an opportunity to get in at a good time with some of these proverbial rocket ships.

I decided to take a two-pronged approach. I needed to work out how CTO roles were recruited, and I also needed to look at what companies out there were hiring remotely in the UK.

Read more

Welcome to the paid newsletter for November 2025. This is the first ever paid article that I’ve written, so I’d like to thank you for being an early adopter of the paid subscription model. I hope you’ll find the content enlightening and engaging. I like to see it as the beginning of a conversation between us.

As I write more paid articles, I’d love to hear your feedback. I’ve opened the Subscriber Chat functionality on Substack so you can contact me directly. This way, you get the chance to shape the future of the newsletter.

We are going to start this month by diving into my story of how I ended up in a CTO role at a public company.

I think this might be interesting because it wasn’t always my intention. Rather, it was a random walk, to use a computer science term, following my interests, that got me here.

Additionally, CTO roles are very rarely advertised externally, so I’d like to give you some insight into how the world of executive headhunting works. If you’re interested in going down this path yourself, then I hope you’ll learn more about how to get involved.

It’s worth mentioning that everyone’s journey will be different. There is no one way to do this. So, consider this not a blueprint, but rather a map of the terrain that I’ve traversed. The easiest way to become CTO, after all, is to “just” start your own company.

What’s coming up

Since I wanted to use this opportunity to go deeper than usual in my writing, this newsletter is going to be split into two parts.

In part one, we’re going to cover the following:

• My original interest and desire to get a permanent position in academia, but how the economy, jobs market, and my desired life situation prevented me from going any further.

• How it was almost random that I got involved in a startup at the seed stage, but how curiosity, familiar faces, and a willingness to try anything in order to stay close to where I was living made it happen.

• How my managerial experience flourished when I realized that I had many interests and passions that were different from the engineers that I worked with, and how that set me apart and subsequently opened doors.

• How getting acquired showed me what I didn’t want my life to be like at work, and why trusting your gut is always underrated.

With that outlined, let’s get going. It might be worth getting a cup of tea for this one.

From academia to seed stage

I’ll briefly gloss over my early life, which is that I’ve always been incredibly interested in computers. I was a small kid playing with my sister’s ZX Spectrum and Amstrad CPC 464 as I grew up. When the initial internet wave came along in the 90s, and as I went from small child to teenager, I had a lot of fun messing around with HTML and PHP building websites, and of course, playing an unhealthy amount of online video games.

I felt at home when I was tinkering with technology, and I have fond memories of building computers, upgrading RAM and graphics cards, trying to hack games with a hex editor, and seeing the initial incarnation of the Web come to life via Yahoo!, AOL, Geocities, and later, Google.

Read more

For those unfamiliar to Charlie, he is worth getting to know. While his notoriety stemmed from being one of the greatest investors of his generation, he was also a prolific speaker and writer, and was an advocate of cross-disciplinary thinking and application of mental models. He excelled in taking ideas from mathematics, philosophy, and psychology in order to think about the world in a new way.

In this month’s article, we’re going to be looking at one of the mental models I learned from Charlie and how it can help us as engineering leaders think, plan, and execute better by avoiding failure.

But first, some changes

However, before we go any further, I wanted to take this opportunity to say that there are going to be some changes coming up to how this newsletter is run.

Currently I publish one article a month for free, which is also available on my website, The Engineering Manager. Don’t worry: this is going to continue indefinitely.

I have been slowly growing my optional paid subscriber base, of which membership is purely voluntary, and I wanted to start giving something more to them, and also see whether I can continue to grow it.

As a result, I’m now going to be writing twice a month. There will be one free article, which will continue as it always has, with the addition of one paid article, which will not be published anywhere else: it will only be available here on Substack for paid subscribers.

The price for subscriptions will remain exactly the same, which is:

1. US $10 monthly, if you prefer the flexibility to cancel any time.

2. US $100 for the whole year, which is effectively gives you 2 months of paid articles for free.

This means that paid subscribers will get 24 articles a year: 12 free, and 12 paid.

This is new territory for me, and I feel slightly nervous about doing this as it increases the expectations for me and my writing, but I’m considering this an experiment and the chance to stretch myself in something that’s already starting to work, so let’s see how it goes.

If you’re interested in subscribing, then I’ve been working on a schedule for the coming three months of paid articles, which will start this month:

• November 2025: A deep dive into my journey into the CTO role, giving you some career growth hints and tips, and also an insight into why CTO roles are never advertised and how you actually get them. If this is the ultimate destination in your career, then I hope that what I have learned can be useful to you.

• December 2025: Doing more AI: strategies and tactics for increasing adoption and skill in your team organization. Given that AI is hitting the mainstream in terms of adoption, how can we think about getting our teams to use it, increasing their skill, managing cost, and proving value?

• January 2026: Getting what you want: designing a strategic and long-term view of your career, covering how you can visualise what you want to achieve and how you might be able to get there. I found that what you do for your career is only part of the puzzle. Often career planning exercises miss out on the other things that are important in your life as well. I’ll talk about some of the choices that I’ve made over the last ten years and how they were guided by life as well as work.

If you like how that sounds, then I’d love for you to come along for the ride and become a paid subscriber.

Paid subscribers also get direct access to talk to me by chat, where you can share your feedback about what you’re reading and what you’d like to see in the future. It gives you a chance to shape upcoming articles for the newsletter.

And with that announcement done, let’s get on with the article.

Death by optimism

Software engineering is tough. No matter how hard we try and how hard we plan, we always end up missing simple things which cause a whole bunch of problems down the line.

This can range from missing features and functionality (“how did we not think of that?”), to edge cases that we haven’t thought about (“how did we not see that coming?”), to poorly conceived rollouts and launches (“why didn’t we check this didn’t work in Italy?”).

There seems to be an ability to repeatedly stumble on the same simple mistakes that suggests this is just part of human nature. We spend so much time thinking about the big picture, focusing only on the happy path that we’re traveling down, that we tend to overlook stupid mistakes that then shoot us in the foot.

The question, therefore, is why?

Why is it that we make the same mistakes over and over again? After reading Poor Charlie’s Almanack, I’ve come to think that it’s because we apply mental models that are far too optimistic to our planning. As a result, because we typically rely on an optimistic outlook, we fail to consider what could go wrong.

Countless software projects in the last twenty years have significantly underestimated time and complexity, have not done enough QA, have not considered their rollouts carefully enough, and haven’t scrutinized their scope to ensure that key features were missing.

There’s clearly a core bug in our thinking, because humans would have solved these planning problems a very long time ago if it didn’t exist.

What is inversion?

If it is the case that thinking too optimistically is one of the reasons that we keep getting things wrong in software engineering, can we instead use a pessimistic mental model? The answer, I believe, is yes, and the solution lies in one of Charlie Munger’s models called inversion.

Inversion is one of the cross-disciplinary mental models that I mentioned above that Charlie mentioned often. He would use the inversion mental model in order to scrutinize investments before he made them. When it comes to planning projects, estimating scope, and especially rolling out changes, inverting the problem can expose the blind spots optimism leaves behind. The principle of inversion is highly applicable to us as engineers.

As Charlie says: “Invert, always invert.” This is the way that you can save yourself from disaster.

The origin of inversion comes from the 19th-century German mathematician Carl Gustav Jacob Jacobi, who advocated for solving problems by approaching them backwards. Rather than trying to work something out directly, you assume the opposite and work toward a contradiction.

Munger adapts this into practical situations: to succeed at an outcome, you should invert it by thinking about what would have to happen for you to fail, and then completely avoid all of those things in order to succeed.

For example, if your goal is to keep your home clean, instead of thinking about what it means for it to be spotless, you can invert the problem by thinking about what it would mean for it to be disgusting, and then make sure you do everything possible to make it not disgusting.

It follows that for your home not to be disgusting, you would need to:

• Clean your dishes within 24 hours.

• Take out the bin when it’s full.

• Vacuum the floor once a week.

• Dust surfaces regularly.

• Do your laundry when the laundry bin is full.

• ...and so on.

And it just turns out that by inverting the problem and then doing all the items above to avoid it being disgusting you arrive at the same outcome: you have a really clean house.

This is the beauty of inversion. Instead of asking yourself, “How do I succeed?” you ask, “How do I fail?” and then systematically avoid those failure modes.

Inversion for engineering teams

Engineering teams can greatly benefit from using the inversion approach when thinking about larger initiatives such as estimation, planning, and rollouts.

As we saw above, whenever we do these activities with default optimism—thinking about what would be nice to have and what we must try to achieve—we often forget the things we must avoid as part of that process, which is where the mistakes creep in.

For example, if we are thinking of rolling out a new feature gradually to our clients, instead of leading our thinking with cohorting and the desire to launch to everyone as quickly as possible (i.e. goal oriented), we should think about what it would mean for the rollout to be a complete disaster, identify those factors, and completely avoid them. Doing so will ensure that we avoid edge cases in our thinking that we may have missed previously.

This is best explained by example.

Let’s imagine that you’ve just made a significant upgrade to part of your application and you’re thinking about how to roll it out. Instead of asking yourself how the rollout could be a success, you could invert the problem and ask yourself how the rollout could disastrously fail.

You identify that it would fail if:

• Bugs are present.

• Customers are unable to opt out if they don’t like the experience.

• Enterprise customers are caught off guard by the change and are not given adequate advance notice.

• Workflows take more clicks or scrolls or text inputs than the previous workflow that was upgraded.

• It looks worse, or is less intuitive, than the previous functionality that it replaced.

• It is slower than the previous workflow to render.

I’m sure there’s other examples that you can think of here too.

If you can take that list of reasons that the rollout could fail, and then systematically work to put protections in place so you avoid them, then it would follow that you would have a successful rollout.

Doing an inversion pass

I’d like to propose that the next time you do a significant piece of work, you do an inversion pass. It will help you systematically identify failure modes and build your defences before you embark on whatever you’re about to do.

Below is a template that you can copy and edit for your own needs.

Setup

Before we get going, we need to work out who’s doing what.

• Begin by assigning roles. One person should be the facilitator who keeps time and the discussion flowing. There should also be somebody acting as a scribe that is able to capture the conversation.

• Then define the scope. Decide what it is that we’re trying to invert, which could be a feature rollout, an infrastructure change, or an architectural decision, etc.

• Make it clear that no idea is too pessimistic, and that today we are being paid to be cynics.

Inversion questions

With roles defined, work through these questions as a group.

The facilitator keeps the group moving and on time, and the scribe ensures that everything is captured. Questions that are in quotes are intended for the facilitator to ask the group.

1. Catastrophic failure. “What would make this an absolute disaster?” If this was to cause a P1 incident, what could some of the likely root causes be? What kind of scenario would have happened in order for that to trigger? Which single component failure would cascade most dramatically?

2. Silent degradation. “How could this fail without us knowing?” What metrics are we not monitoring that we should be? Which failure modes wouldn’t trigger our existing alerts? Where might we have blind spots in our observability and logging? What could degrade slowly enough that we wouldn’t notice until customers complained?

3. Rollback. “What if we need to roll this back at 3am?” Can this change be reversed? How long would rollback take? Is there anything that’s irreversible? At what point does rolling back become more dangerous than rolling forward? What happens if none of this works?

4. Load and scale. “What happens when real load exceeds our assumptions?” If you’ve currently estimated a certain load, what would break at 10x that load? Are there any resources that you have assumed will work properly that could go wrong? What kind of behavior exists in high traffic scenarios with extreme contention or queuing?

5. Dependency failures. “What if everything that we depend on breaks?” List out all of the external services that you rely on, such as databases and APIs. For each of them, think about what could go wrong if they became slow or unavailable. Think about whether you should have retries or circuit breakers.

6. Human error. “How could we break this ourselves?” Are there any operational steps that could be prone to human error? Do we have everything written down in playbooks in case whoever is on call doesn’t understand what to do, or are we missing documentation?

7. Data integrity and security. “Is it possible for us to corrupt or lose data?” Have we thought about race conditions that could happen? Or have we assumed transactionality that doesn’t actually exist? What happens if we process the same event twice, or if we skip one event? How do we know if data becomes inconsistent? Are there any attack vectors that we need to think about? Which data are we exposing and to whom?

You may want to add or remove inversion questions depending on the kind of project that you’re doing.

Once you’ve captured your list, go through and mark each item as to whether it’s:

• A showstopper (which must be addressed before launch)

• A mitigation (which will need monitoring, fallbacks, or workarounds)

• An accepted situation of which we are understanding the risk and moving forward regardless.

When you’ve got to this point, you should have list of actions captured by your scribe that you go and work on, plus a documented inversion pass outcome that proves you have done this exercise. You can use this to generate a risk register, update your design docs, and expand your documentation.

Try it yourself

Sometimes being pessimistic is good.

Using the principle of inversion, you can identify gaps in your planning and thinking, which can make your projects better, safer, and more resilient.

In your next project, try out an inversion pass. Run the exercise on your own or do it with your team and see whether it helps you feel more confident about what you’re going to be doing next.

Additionally, think about inversion in your own life. If you were to apply the inversion principle to how you manage your finances or what you want to achieve next year, could it potentially help you to think about these goals in a new light? Perhaps it could increase your confidence in getting them done to a high standard.

Remember: invert, always invert. If it worked for Charlie, it works for me.

Subscribe now

This is a conversation space exclusively for subscribers—kind of like a group chat or live hangout. I’ll post questions and updates that come my way, and you can jump into the discussion.

Join chat

Read more

It’s been two months since I finished a sequence of LLM-based posts which were intended to think of unique ways that you could improve your leadership skills by leaning into AI as a coach, a contrarian thinker, and a way in which to expand and accelerate your decision-making.

If you’re interested in reviewing those posts, then you can find them here, in reverse chronological order:

• Leadership co-processing with LLMs, which introduces a number of prompting and usage ideas that could help you develop your thinking.

• A bag of worries: tackling overwhelm with LLMs, which is a technique I’ve been using to help me manage my own never-ending to-do list by offloading some of the cognitive load of prioritization to an LLM.

• A weekly mind meld, which uses some LLM assistance to communicate weekly with my department.

• LLMs: an operator’s view, the original post in this series, which covers some of the cultural change addressed in the first post in this list, and how code review and hiring are also changing.

Building on the leadership co-processing article, we’re going to go further this week and think about how we can expand our usage of a thinking partner into multiple thinking partners by using LLM agents to create your own councils that you can use to accelerate and supercharge your thinking and also simulate situations where many actors may not have default consensus on issues.

Inspiration

At work, I’ve mostly been using Claude Code as my go-to interface. Generally speaking, I like the Claude models, which have become particularly good since Sonnet 4.5 and Haiku 4.5 were released. However, I also enjoy the terminal interface, which I always keep open at the side of the screen as it is space efficient. I can mix regular prompting along with the generation of code, and it looks cool as well.

One neat feature of Claude Code, which is the backbone of this article, is that it makes it extremely easy to build agents that you can delegate to. For example, you just type /agents like below:

From here, you can create a new agent.

In order to create an agent, all you have to do is give a rough sketch of what the role of the agent is. For example, here is my initial prompt for a QA Engineer agent.

Claude Code is able to expand that into something far more detailed which you can edit and tweak however you wish.

If you’d like to see more examples of how a number of agents could be defined, then there’s a great public GitHub repository where people have been collecting together their examples. Each of the folders has a different type of agent (or agents) combined with a collection of commands that you can use in order to work with them.

This is especially useful when you’re programming since you can delegate specific types of work to these agents, such as refactoring, security testing, initial code reviews, and so on. Now, none of these are meant to be substitutions for the real thing, however, they become great partners when you’re coding because you can call upon specific functionality when you need it, which is especially useful when you know that you have blind spots. For example, a security engineer agent can continually make sure that you’re aware of these kinds of issues as you code.

One particularly interesting observation, highlighted in Simon Willison’s recent post, is that Claude Code could be considered a general purpose agent, rather than just a coding tool.

Following my own usage, I agree with this viewpoint. Claude Code is not just a tool for coding, but is also a tool to think. And agents let you get really creative with your thinking.

In previous posts, we looked at how we could use simple prompts to “pair think” with LLMs, from organising our time, to cross-checking decisions, to enabling mob sessions where architecture or code is designed together, and so on.

The more senior you get as a leader, the more nuanced and complex some of your decisions can be: not necessarily only because of the impact of those decisions, but also because of the challenge of finding consensus within large groups with differing opinions, biases, and experiences.

Sometimes the act of maintaining fast, synchronous connections with groups of people in order to debate, discuss, and forward your thinking can be blocked by others’ busyness or timezone. That’s where agents come in.

Council of agents

In the same way that there were examples above of how to use agents in Claude Code for specific technical functions (such as refactoring and testing), you can use agents to form specific thinking councils that you can use to accelerate your thinking faster than you could by working either on your own or by requiring synchronous time with others.

This is most easily shown by example, so we’ll go through two of them in this section. The first will be a technical council, and the second will be an executive council.

Creating a technical council

Now that we’ve seen how to build one agent, we can now think about building multiple agents that can make up a council that you can work with and think with. For this first example, let’s consider a technical council that can help you.

Firstly, you’ll need to think about which kind of roles you’d like to have in your technical council of agents. For example, you might want to have the following:

• Principal Engineer, covering broad technical vision, architectural patterns, and cross-cutting concerns.

• Platform Engineer, covering infrastructure, deployment pipelines, developer experience, and tooling.

• Security Engineer, with an interest in threat modeling, secure architecture, compliance, and vulnerability management.

• QA Lead, covering testing strategies, quality metrics, automation, and release confidence.

• AI/ML Engineer, responsible for machine learning systems, model deployment, and intelligent feature design.

Your own mileage may vary on the above depending on what kind of role and company you’re in.

With a decision made about what kind of roles you want to have in your council of agents, you then create them using the same methodology as we did in the example above.

For each of those roles, you create an agent in Claude Code, and you use your initial prompt to outline what they’re responsible for. Then, Claude Code will expand those into more detailed role definitions for the agents, which you can edit if you wish. And then, you continue doing this until you’ve defined your whole council.

Once this is done, it means that you can then ask questions to your whole council of agents. Here’s an example of what that could look like.

Here’s the output that was achieved from that particular query.

For this example, I specified in the query that I wanted just one paragraph of output per agent. However, if you wanted it to generate a detailed report and use one of the more expensive thinking models to do so, and then output that to a file, then the choice is yours.

And that’s it: with a small upfront effort, you now have a model of a technical council at your fingertips that can help you quickly interrogate ideas and decisions taking into account the diverse strengths and biases of each of those particular roles. It’s an incredibly useful tool to have.

Creating an executive council

Here’s one that helps me a lot.

As a CTO, my team is probably the most multi-disciplinary of them all, given that everybody in my executive team runs one of the other functions of the business. I am the only engineer!

Therefore, in order to help with my own thinking, especially about company-wide issues, having an executive agent council is highly valuable, and improves the kinds of proposals and decisions that I can bring to the group. Essentially, I almost get one or two meetings of iteration on my ideas completely for free (token costs aside) by doing it locally with my agent council.

In order to create this executive council, I go through the exact same steps but change the role definitions. For example:

• CEO, owning the overall company vision, board relations, strategic direction, and having final decision authority.

• Chief Product Officer, covering product strategy, roadmap prioritization, user experience, and feature decisions.

• Chief Operating Officer, responsible for operational execution, cross-functional coordination, process efficiency, and delivery.

• Chief Revenue Officer, owning sales strategy, pipeline, revenue targets, and go-to-market execution.

• Chief Marketing Officer, covering brand, demand generation, market positioning, and customer acquisition

• Chief Customer Officer, responsible for customer success, retention, NPS, implementation, and the voice of customer.

Again, depending on what kind of company you work for and who you’d like to have in your executive council, you may want to switch these roles out for whatever is relevant for you.

Here’s an example of the kind of query that you could ask. Let’s assume that the chat functionality that we were previously thinking about with the technical council is now ready to launch: how do we bring it to market?

You can see in the query that I accidentally wrote “rollout” twice, which I guess proves to you that these articles are still written by a human.

What’s fascinating about our query this time is that Claude Code even asked for input from the user to model the company that we’re working at. I did not explicitly ask to be given these choices in the setup.

After thinking for a while, I received output that looks like this. There was far more output than could fit in the screenshot, but for each of the executive council members, there are at least three to five interesting points that I know that we need to think through when we discuss it as a real human team.

Try it yourself

I’ve been finding this council of agents approach really useful for thinking through larger, more strategic plans and also in helping me develop my ideas before I bring them to the human version of the groups they represent. They allow me to do much more asynchronously. And then, when I do connect with my team synchronously, I find that the discussion and ideas that I am bring are more nuanced, considered, and researched.

So why not try it yourself?

Experiment with creating your own councils of agents using Claude Code or other tools and frameworks that support them. Get creative and think about ways in which you could improve your programming, your thinking, and your strategic decision-making.

It’s also a whole lot of fun as well. What councils of agents will you create?

Now, this isn’t the first time that we’ve written about constraints, so if you’re interested:

• We looked at Parkinson’s Law back in 2024, which is the classic anti-pattern that occurs when people are given too much time (or no deadline at all) when asked to do something. The result is that work — like gas — expands to fill the time available, and yes, we’ve all been there with our school assignments.

• We covered the iron triangle of project management in 2017, which is the classic model of the three constraints that projects typically have: scope, resources, and time. The idea is that you can only ever optimize two of the three.

• We more recently explored how scope could be reframed as thoroughness in 2024, since scope alone rarely tells the whole story about what is being delivered.

But this time we’re talking about constraints as tools. Tools that you wield and can use.

Discovering places where you can add constraints to your projects is a superpower: it unlocks unconventional thinking, forces people to prioritize ruthlessly, and leads to unexpected and surprising results.

Let’s go on a journey together to explore the beauty of constraints. We’ll start by examining their paradoxical nature.

The constraint paradox

The word “constraint” often has a negative connotation. If you asked an average person, being “constrained” in general would not be seen as a desirable state. One does not wish to wear a pair of trousers that make them feel constrained.

However, paradoxically, constraints in engineering can often lead to our best work. The longstanding meme of IT projects being over budget and late is often due to a lack of constraints.

This is because projects often begin with a forward-facing process of thinking about all of the requirements that a product should have, and then estimating how long it will take to deliver them.

But the problem is that estimation of large projects (and even small ones) is essentially guesswork. If no constraints are imposed, the result is a project that stumbles along with ambiguous, bloated requirements and timelines. Walking along a path purely defined by what we want, without any constraints, is where it all goes wrong.

That is because this manner of thinking about projects — where we think about what we want and then work out how long it will take to get there, then go — very rarely makes us challenge ourselves to work in unconventional ways. There’s a difference between traveling a road to explore it and experience it versus trying to deliver a package as quickly as possible.

And talking of packages, a classic Bezos quote comes to mind here. “Frugality drives innovation, just like other constraints do. One of the only ways to get out of a tight box is to invent your way out.”

Putting oneself in a tight box, paradoxically, will make one execute better. Constraints tend to bring out the best in people.

Innovation through constraints

This isn’t just hyperbole, either. There are many great examples of products that achieved innovation through constraints. Here’s some of my favorites.

The original Sony Walkman emerged from a focused set of constraints: power, cost and size for portable travel. It’s worth remembering that at the time, cassette players and home stereos were bulky, imposing hunks of machinery and plastic.

The engineers were tasked with creating a device that could play music whilst walking and on long flights, which meant innovation in miniaturization, motor efficiency and stability, and headphone design.

Additionally, the compact form factor constraints dramatically led to stripping back requirements that were standard on home stereos, such as recording capabilities.

Another example is Twitter, which began with a strict 140-character limit, similar to SMS. This constraint forced users to be concise and creative in their communication. Interestingly, when Twitter expanded the character limit to 280, only 5% of users utilized the additional space, demonstrating how constraints can shape behavior and innovation. Looking at X today, many messages are still short and to the point, showing how the original constraint has had a lasting impact.

My favourite constraint-driven design story is that of the Dyson dual cyclone vacuum cleaner. The constraint of a bagless vacuum led to the invention of cyclonic separation on a small scale. It took 5,127 prototypes in James Dyson’s garden outbuilding to achieve this over many years of toil and no income. However, these constraints brought the first real innovation to vacuum cleaners in decades. Now Dyson is a household name and billion-dollar company.

Types of constraints

Constraints typically fall into three categories, broadly categorized by the iron triangle of project management: scope, resources, and time. I wrote about this way back in the early days of this blog in 2017, although my thinking has evolved since then.

But how?

Whereas earlier in my career I would consider those three trade-offs typically whilst wearing a project manager hat, I now consider them as categories of constraints that can be purposefully applied to projects in order to encourage teams to deliver more with less.

So, looking at each corner of the iron triangle, let’s see along which vectors constraints can be applied:

• Scope is the set of features and requirements that a project is trying to deliver. However, instead of just accepting scope for what it is, great leaders try to ruthlessly cut down scope to shrink a project to the bare essentials. We’ll look at an algorithm for doing this shortly.

• Resources typically means the number of people working on a project, which you can deliberately limit in order to force tough prioritization choices. However, resources can also mean money or other technical constraints, such as cost of infrastructure, or choice of technology. Great leaders will ensure that resources are deliberately limited in order to drive innovation. For example, instead of standing up new search infrastructure, what could you do with a simple database query?

• Time is straightforward: Parkinson’s Law tells us that work expands to fill the time available. Therefore, great leaders will encourage teams to set challenging deadlines and use them as forcing functions to keep scope and resources in check.

So the way that I encourage you to look at the iron triangle is not as an accepted set of trade-offs, but instead as a toolkit of constraints that are available to engineering leaders to help their teams deliver more with less.

At all stages of a project, from the beginning to the end, never accept the status quo. Always ask yourself: “Can we do this with less scope, less resources, or less time?”

So how can you start looking at your projects and seeing whether constraints can be applied?

Let’s look at a practical algorithm for doing that which is one of the most repeated themes in Walter Isaacson’s Elon Musk autobiography.

The 5-step algorithm

I watch this video at least once a month as a reminder to question everything that we’re doing. It’s a short (1 minute and 29 second) clip of Elon Musk explaining his 5-step algorithm for finding ways to strip projects back to their bare essentials.

This isn’t just useful at the beginning of projects. As we mentioned before, estimation is guesswork, and so as projects evolve, it’s important to continually re-evaluate whether the original constraints are still valid, and if not, change or delete them. Repeated and continual application of this algorithm will help you do that.

The algorithm touches on all three corners of the iron triangle, inviting you to insert constraints in scope, resources and time.

Here’s the algorithm:

1. Question the requirements. Musk says that the most common error of a smart engineer is to optimize things that shouldn’t exist in the first place. He stipulates that smart folk are trained to answer questions, but not to challenge the questions in the first place. So, the first step of the algorithm is to accept that some or all of the requirements are dumb, and they should especially be questioned if they come from a smart person! For each requirement, ensure that it is attributable to a specific person or user need. If not, challenge it ruthlessly. If you can’t justify a requirement, then it gets deleted with no remorse.

2. Remove unnecessary steps. Once the requirements have been stripped back to the essentials, look at all of the steps of the project or process to achieve them. Try very hard to delete every step or feature that isn’t absolutely necessary. In fact, a good rule of thumb is to remove steps until you are forced to put some back in. That’s when you know that you’ve found the bare minimum.

3. Optimize. Now you know that you’ve stripped the project back to its bare essentials, you can optimize each step. This is where you can apply your engineering skills to make each step as efficient as possible. That could be code optimization, process improvement, or tooling. But remember: the only things that get optimized are the bare essentials that remain.

4. Accelerate time-to-learning. Next, look at ways in which you can accelerate cycle time, specifically the amount of time that it takes to get something done that you can learn from so you can start your next iteration. What’s the fastest way to prototype, build, ship, measure and learn? The maxim is that if the timeline is long, it’s wrong.

5. Automate. Finally, look at ways of using automation to speed things up. Note that this is the last step. No time should be spent on automating things that shouldn’t exist in the first place. Musk tells the story of how he automated too early in his factories, resulting in expensive robots needing to be removed because the steps were unnecessary or could be done more efficiently by hand.

Try going through this algorithm with your team on your current project. You’ll often surprise yourself at how much you can simplify what you’re doing.

Your constraint toolkit

Constraints are tools, and as such, you should have a toolkit of constraints that you can use at any time. Below is a non-exhaustive list of tools categorized by scope, resources, and time.

Scope constraints

• Use the 5-step algorithm above multiple times during a project to continually re-evaluate scope. Perhaps schedule it weekly or monthly to ensure that your project remains as lean as possible.

• Use techniques such as the MoSCoW method (must have, should have, could have, won’t have) to further strip back requirements ruthlessly.

• Explicitly specify a single-sentence “success condition” for a project or feature and work backwards from there to ensure that everything is aligned to that goal. Delete any requirements that don’t align. This increases your cycle time to learn.

• Tightly constrain the number of features to cover the absolute minimum happy path for the first version. Defer all nice-to-haves and edge cases to future iterations: learning about the happy path is more important than building out the full feature set.

• Remove configuration options. Lean heavily into sensible defaults that work for the majority of users and only add configuration options later if absolutely necessary. Configurability and optionality causes complexity.

• Build and ship for one platform first. Don’t try to launch everywhere for everyone in the first version. Pick a single platform (web, iOS, Android, etc.) and ship that only to learn faster. Once you’ve learned that what you’ve built is valuable, you can expand to other platforms.

Resource constraints

• Limit the size of teams deliberately. It’s an easy escape hatch for teams to always feel like they need more people. Instead, set the challenge of being resourceful with less. It’ll force scope constraints, prioritization, and new ways of thinking. Ironically needing to hire more people often makes projects take longer; not only because of the Mythical Man-Month effect, but it takes a long time to ramp up new people (see: the contribution curve).

• Limit costs. If the scope of a project is going to incur high infrastructure costs, challenge the team to find ways of doing it with lower-cost alternatives. This will often lead to new and interesting ways of thinking about the problem than buying more RAM, CPU or instance hours.

• Limit technology choices. Instead of always reaching for another new technology or service, challenge the team to use what they already have. A huge amount can be done with simple databases, queues, and caches if you think about the problem in the right way, and your existing technology stack already exists and doesn’t need provisioned or learned.

Time constraints

• Set challenging deadlines. Instead of asking “How long will this take?” ask “What’s the fastest we can do this?” and then work backwards from there. This will often lead to new ways of thinking about the problem.

• Continually ask “What would it take to do this in half the time?” You will be surprised at how many timelines can be dramatically shaved down just by asking this question.

• Use sub-milestones as forcing functions. For example, having an expected cadence of shipping daily or demoing weekly will force teams to prioritize and shape their work in a different way.

• Use time-boxed iterations. Instead of open-ended projects, use fixed-length sprints or iterations that yield shipped software or demos to create a sense of urgency and focus.

Now you try!

It’s over to you: you now have the tools, so give some of these techniques a go.

At the very least, do the following:

1. Apply the 5-step algorithm to one of your current projects. Do it as a team exercise and see what you can shave from the requirements.

2. Challenge one timeline by asking “What would it take to do this in half the time?” and see what happens.

There are so few leaders that do the above that you’ll not only be surprised at how much time you can save, but also how much your team will appreciate the challenge.

Trust me: constraints are your friend.

This month, we're building upon the cultural shift that management has experienced recently: smaller, leaner and tighter orgs. We'll build upon concepts from our previous articles: new advice for aspiring managers, should managers still code?, and being in the details.

This article, plus those listed above, reflect a new and expected management style for the current era: more hands-on, detail-oriented, and direct. This shift is driven by tighter economic conditions and the push for AI-driven efficiency.

Let's examine the concept of "going direct."

What is going direct?

Going direct means empowering everyone on your team to communicate openly and directly, without unnecessary intermediaries. This communication can be lateral (peer-to-peer) or diagonal (across different departments and levels), bypassing formal reporting chains.

Org charts are essential for defining roles, ownership, and facilitating performance management. However, people often mistakenly believe these charts also dictate communication paths, feeling obligated to follow the hierarchy. At best, this requires irritating message-passing. At worst, it dramatically slows down work and fosters bureaucracy.

An example best illustrates why this is an anti-pattern. Imagine person X in Team A needs to talk to person Y in Team B. These teams are in different departments, led by peer managers M and N, respectively.

When communication follows the org chart, X must tell their manager, who tells their manager M. M then talks to N (or perhaps even their shared manager) to pass the message down N's reporting line to Y.

Wow, that was a mouthful.

As you can see, this is incredibly inefficient. When you read it back, it’s borderline ridiculous. X should be able to talk to Y directly. Not only should there be no barriers to this, but it should also be actively encouraged.

The benefits of going direct

The consequences of not going direct extend far beyond annoying message-passing. It implicitly sets a cultural precedent that approval is required for every action. This creates a bureaucratic culture and undermines your team's sense of autonomy and efficacy.

Furthermore, forcing every decision up the chain can lead to counterproductive behaviors, like hiding or distorting information to secure a sign-off. Over time, staff spend more energy navigating internal politics than on what matters most: building great software (or hardware or toys or cars).

Going direct has a ton of benefits:

• Faster communication and decision-making. When the people closest to a problem can talk directly, they can make the right decisions quickly amongst themselves.

• Increased collaboration and knowledge sharing. It encourages direct collaboration across the organization, building connections, trust, empathy, and shared knowledge.

• Reduced bottlenecks. By removing intermediaries, fewer people are needed to make a decision, reducing bottlenecks from communication delays or availability issues.

• Increased trust. Allowing staff at all levels to talk to anyone they need signals a high degree of trust and autonomy. Conversely, requiring hierarchical approval implies superiors must ratify every decision.

• Increased initiative and accountability. When people are empowered to make decisions directly, they are more likely to take ownership of their work and be accountable for the outcomes.

Managers save time too. As we discussed in the opening of the article, the management landscape has changed. When teams go direct, managers reclaim time to be more hands-on and in the details, which is a win-win for everyone.

Putting guardrails in place

So far, so good. We want our staff to go direct whenever they need to. The reasons are clear.

However, if you're going to implement a culture of going direct (and you certainly should) you must put appropriate guardrails in place. These clarify how to go direct and when to revert to hierarchical communication.

When you announce this cultural shift to your team, it's crucial to establish these guardrails upfront. You should:

• Clarify decision-making authority. Define who has the authority to make certain decisions. The goal should be to maximize the number of decisions that don't require management approval. Spell these out with examples related to your organization, such as prioritizing tasks, defining feature specifications, or architecting code.

• Clarify when to seek approval. Conversely, define situations where approval is necessary. It also helps to provide examples. Frame these as "one-way door" decisions: choices that are difficult to reverse or that carry significant risk, such as potential downtime or exposure to security vulnerabilities. These types of decisions should be escalated up the management chain, or to the right group of domain experts.

• Establish a process for sharing decisions. As more decisions are made locally, you need a system for documenting and sharing them with the wider organization. This could be done through regular written broadcasts or dedicated decision logs.

With these guardrails in place, you must also lead by example. Practice going direct yourself to show the organization what it looks like and why it’s beneficial.

You can do this by having skip-level meetings, talking to your engineers directly about their work (because you are in the details), and encouraging people to come direct to you with anything on their mind at any time (see: Jensen Huang's "top 5 things" practice).

Additionally, always provide positive reinforcement when people go direct. This can be one-on-one praise or public recognition for a team that resolves blockers quickly or delivers at a fast pace. Call it out, give praise, and ensure that everyone knows that this is the right way to operate.

Some examples

With the reasoning and guardrails in place, let's look at some examples.

Imagine a direct report asks if someone from another team can help with a task. This is a great opportunity to encourage them to go direct. You could say:

"I'd recommend you ask them directly. If you don't make progress, or if it turns out the decision is a one-way door, then loop me in."

Similarly, if you detect an issue that could be solved by direct communication, reinforce the principle. For example, if you were asked:

"Can you help me unblock this ticket? We're waiting on a code review from the widget team."

You could respond with:

"Have you asked them directly to prioritize it? Let me know if you don't get a response."

As you shift the company culture, you'll find yourself repeating these responses. This is a good thing; you're reinforcing the right behavior. Over time, people will message you less and resolve more issues themselves.

Coaching everyone on how to go direct

Simply telling direct reports to "go direct" isn't enough. As a manager, your role is to equip your whole department with the tools to do it effectively so they build bridges, not friction. When people feel confident in their ability to communicate, they are far more likely to take the initiative and sort problems out themselves.

So coach them to make their requests easy to answer. A poorly phrased request creates more work for the recipient and is likely to be ignored. Encourage them to follow a simple structure: context, problem, and a clear ask.

Compare these two ways, the latter using that approach:

• The ineffective way: "Hey, can you look at the widget API? It’s not working." This message is vague, lacks context, and forces the recipient to start a fact-finding mission.

• The effective way: "Hi Alex, hope you're having a good week. I'm on the new reporting dashboard, and I'm seeing a 502 error when I call the /widgets/summary endpoint. This is blocking me from finishing my ticket. Could you point me to the right person on your team who knows about this endpoint? Thanks!" This is perfect. It provides context, defines the problem, and has a specific, low-effort ask.

Next, establish the etiquette. Encourage a "public by default" mindset. If a question isn't sensitive, asking it in a shared channel like #team-widgets instead of a DM means others can learn from the answer, and it doesn't get lost if one person is unavailable. Remind your team that "direct" doesn't mean "instant." Everyone is busy, so they should send their message and move on to another task.

Finally, give staff a simple escalation path. I often tell my team to follow up once, politely, later in the day if they haven't heard anything (and assuming the person is not on vacation). If they’re still blocked after that, it’s no longer a communication issue; it’s down to priorities. That is the perfect time to offer your own assistance, perhaps by looping in their manager too.

Things to look out for

Be mindful of a few potential issues as you encourage direct communication.

First, some managers may feel uncomfortable. They might feel out of the loop, especially if they're used to bureaucratic environments where they are involved in every step of every decision.

The solution isn't to reinstate that communication chain. Instead, encourage those managers to be so in the details that they already know what's happening. If a manager is sufficiently in the details, no decision should catch them off guard. If it does, work with them on improving their awareness and involvement.

Second, watch for people currying favour. A common example is a team member who constantly goes to a specific senior manager because they know that leader is biased towards their opinions. In this scenario, the senior manager must ensure that no special treatment is given.

Coach leaders that their decisions must align with the company's mission and values, not individual favoritism. This prevents back channels that subvert company priorities (e.g., prioritizing work due to a favorable relationship), which you will need to course-correct immediately.

And remember, you'll need to follow exactly the same advice if particular individuals always come to you.

So, go direct

Going direct is an essential tool in an age of flatter hierarchies and hands-on, detail-oriented managers. Autonomous organizations always go direct, knowing when to escalate important or "one-way door" decisions.

By fostering the right culture, you create an environment where going direct is the norm. Your staff will feel empowered to communicate openly, enabling you to move faster than your competitors. As a leader, your job is to set the guardrails and cultural tone that empower everyone while ensuring they know when to escalate.

When done right, you'll not only move faster but also free up significant time to focus on more impactful, strategic work, or even get your hands dirty in the code. You don't have to be just a message queue.

So, go direct. The org chart does not control the flow of communication. In fact, you're faster if you ignore it entirely.

• New advice for aspiring managers, which covers how the cultural shift in our industry is changing the way we think about management and how aspiring managers should adapt to that change.

• A bag of worries: tackling overwhelm with LLMs, which is a technique I've been using to help me manage my own never-ending to-do list by offloading some of the cognitive load of prioritization to an LLM.

• A weekly mind meld, which uses some LLM assistance to communicate weekly with my department.

• LLMs: an operator's view, the original post in this series, which covers some of the cultural change addressed in the first post in this list, and how code review and hiring are also changing.

I'm always trying to find new ways to use LLMs because it's both useful and a lot of fun. One of the unsurprising elements of being a CTO is that the buck stops with me when it comes to decisions about my engineering department, so I've been leaning more on LLMs to help me evolve my thinking, challenge my assumptions, and make better decisions.

I thought I'd write up some of the ways that I've been doing that in the hope that it might help other engineering leaders to do the same.

Effectively, I now think of LLMs as a co-processor for my brain. It isn't always correct or even trustworthy, but in practice it always puts momentum behind my thinking, and often helps me to see things from a different perspective.

Here's what we'll cover in this post:

1. Prompting: using LLMs to help me think through problems.

2. Pair prompting: using LLMs to help me work on solutions with a human partner.

3. Deep research: challenging myself to look deeper into a problem than I might otherwise do.

4. Contrarian thinking: using LLMs to help me explore alternative perspectives and challenge my assumptions.

5. The executive assistant: breaking through organizational stalemate by having the LLM tell me what to do.

6. The coach and sounding board: using LLMs to help me think through my own feelings and reactions to situations.

Prompting

Although it may seem beyond obvious in 2025, I still believe that many leaders are not using just simple prompting to help them think through problems.

I believe that some of this comes from habit; that is that they've spent potentially decades thinking through problems on their own or in front of a blank page, so the new habit of injecting momentum into their thinking with an LLM is not yet second nature.

I also think that some of it comes from a lack of understanding of how to use LLMs effectively. If you are reading this and you think that applies to you, then Andrej Karpathy's How to use LLMs video is a great overview with plenty of examples, including how the "zip file of the internet" works.

The way I trained my own habit of using simple prompting more was to have my LLM open in a thin browser window (about one-sixth width) on the left-hand side of my screen so that it was always visible. That forced me to use it. I've seen others do similar things, like even having a post-it note that says "what would AI do?" to remind them to use it.

Now that at the time of writing most LLMs can search the internet for real-time information, there's a ton of value from simple prompting, as LLMs are getting good enough to be an infinitely patient partner, from searching the web and summarizing information.

I won't enumerate over every single way that you might use simple prompting to help your thinking, but I will highlight the learning that I've taken away from it. This is an observation about myself rather than something grounded in proven neuroscience; however, I notice that I have a bias to the following behaviors:

• My brain tends to be fast, solution-oriented, and optimizes for speed of thought. This means that I often jump to conclusions, and I can miss important details. When using LLMs, I find that I can both slow down my thinking by writing and also open myself to other options since LLMs will often suggest alternatives that I might not have thought of, even if I don't agree with them.

• The act of writing reveals more layers of depth than making a snap judgement. When I take the time to articulate my thoughts, I often uncover nuances and complexities that I hadn't considered before. These can come both from myself and from the LLM, especially when asking it to be contrarian, as we'll see later.

• Because LLMs greatly reduce the friction of research, I find myself going deeper into topics than I would have otherwise. This is a great way to avoid the Dunning-Kruger effect where I might otherwise have thought I knew enough about a topic to make a decision, but in reality I didn't. A simple additional prompt to the LLM to "tell me more", "what else should I know?" or "what do other people say online about this?" can help me to avoid that trap.

Just remember that you get out what you put in, so the more effort you put into your prompts, the more you'll get out of the LLM. If you ask a simple question, you'll get a simple answer. If you ask a complex question, you'll get a complex answer.

If you're struggling with getting good answers from your LLM, then check out the one of my previous posts which shows you how to use existing detailed prompting guides into reusable Gems/GPTs/equivalents to help you get better results.

In short, get your LLM open on your screen at all times and every time you need to think through a problem, or answer a non-trivial question, ask it for help. I found that within a couple of days, this became second nature and improved my thinking and decision-making significantly.

For example:

You are an AI assistant acting as a highly experienced Technical Advisor to a Chief Technology Officer (CTO). Your primary goal is to efficiently process and synthesize technical communications from engineering teams.

Your task is to analyze raw Slack message threads from engineers, identify key technical discussions, problems, and proposed solutions.

For each provided Slack message thread, perform the following steps:

1.  **Summarize the Core Technical Issue:** Provide a concise summary (1-2 sentences) of the central technical problem or discussion point being addressed in the thread. Focus on the 'what' and 'why' from an engineering perspective.
2.  **Identify Root Causes/Key Factors (if discernible):** Based on the discussion, extract any explicitly mentioned or clearly implied root causes, contributing factors, or critical dependencies. List these as bullet points.
3.  **Extract Proposed Solutions/Action Items:** Identify all suggested solutions, workarounds, or next steps discussed by the engineers. List these clearly. If multiple solutions are debated, briefly note the pros and cons discussed for each.
4.  **Recommend a Strategic Solution (as a CTO's Advisor):** Based on the technical context and common industry best practices, recommend the most viable or impactful solution from the proposed options, or suggest a new, high-level strategic direction if the existing ones are insufficient. Justify your recommendation briefly, considering factors like technical feasibility, potential impact on system stability, resource allocation, and alignment with business objectives. If immediate action is required, highlight it.

Ensure your output is structured clearly, prioritizing actionable insights and high-level summaries for quick review by a CTO. Maintain a professional, analytical, and solution-oriented tone.

[INSERT SLACK MESSAGE THREAD HERE]

Pair prompting

The next step in prompting is involving another human. This is a technique that I call "pair prompting", and it can be done both synchronously and asynchronously. The asynchronous approach I specifically learned about on a podcast episode of Stratechery, as Ben Thompson uses that technique with his research assistant.

Pair prompting is just like pair programming, but with an LLM as the third member of the team. The idea is that you and your partner can use the LLM to help you both think through a problem together, and it can help you to see things from a different perspective.

If you're doing this synchronously then you can do it over a video call or in person. However, the utility of the LLM really shines in asynchronous pair prompting, and Ben Thompson's approach is a great example of that. He mentioned that prior to using LLMs, he would ask his research assistant to explore a topic and then write up a summary of their findings. The input and output of that process would be documented (the instruction and the document).

Now, with LLMs, since the link can be shared to a prompting session to allow for collaboration, not only is the input and output documented, but the entire thinking process is documented as well.

What this means is that if you've tasked one of your teams to go and explore how a feature should be built, by using pair prompting, or even just sharing the link to the LLM session, you can see the entire thought process that they went through, add your own thoughts to it, or see whether any of the assumptions that they made were incorrect.

This is a highly underused technique that exploits how LLMs need their context window (since every call to an LLM is the whole context of the conversation), and it allows you to see the entire thought process that your team went through, rather than just the final output.

Next time you need to think through a solution with a colleague, try using an LLM as a conduit for your discussion. You get the input, the output, and importantly, all of the thinking in between.

Here's a prompt that could form a template to start a pair prompting session:

You, as the AI assistant, will facilitate a pair prompting session between a Chief Technology Officer (CTO) and a Senior Engineer. The primary objective of this session is to collaboratively research and outline architectural considerations, technology stacks, and key features essential for building a scalable and robust chat application.

Throughout our discussion, after each significant point or decision, please provide a concise "Session Summary" that captures the essence of our findings, decisions, and the reasoning behind them. This will serve as a living document of our thought process for others to review.

Each "Session Summary" should include the following sections:

Key Discussion Points: Main topics covered.

Decisions Made: Conclusions or choices reached (if any).

Rationale: The reasoning or justification for these decisions.

Next Steps/Open Questions: What needs to be explored next or what questions remain.

Let's begin by exploring the fundamental architectural patterns suitable for chat applications. Please outline common patterns like client-server, peer-to-peer, and hybrid models, and highlight their respective pros and cons in the context of real-time communication.

Remember, this is a collaborative research session. Your role is to guide our discussion, provide comprehensive information, and facilitate a clear, documented thought process.

Deep research

From talking to people in my network, the deep research functionality of LLMs is still underused. I think that this is partially because it takes a long time for deep research reports to be generated, which means that you need a good prompt to start with, and the output can be highly verbose, but this is definitely improving with time.

My own predominant usage of deep research as a CTO has been to help me explore what's going on in the wider world and industry so I can synthesize that information into a coherent application for my own organization.

All of these deep research usages replace situations where I would have spent a ton of time searching the internet and reading articles. In a way, it does for my thinking what trusted review sites do for product research: something like What Car? for my brain.

I looked through my own LLM history and looked at the things that I've used deep research for, and they include:

• Seeking opinions on the best way to organize out-of-hours support, including what the legal implications could be in different countries for employment contracts and additional hours worked.

• Getting a deep dive into what competitors may be doing in particular areas, and seeing whether a product idea that we have is already being done by someone else.

• Getting ideas on how to improve our incident response process, including what other companies do and how they handle incidents, and software recommendations.

• Exploring potential new markets or customer segments for our products, including what the competitive landscape looks like and what the key trends are.

All of these are things that would have taken me hours to do thoroughly, and deep research allows me to fire off a request, go and do something else, and then read it when it's ready.

Similar to needing to push oneself into the habit of using simple prompting regularly, using deep research will also take some time and effort to fit into your own routine. We've never had research assistants before, so we need to train ourselves to remember to use them often and to use them effectively.

Contrarian thinking

We all have biases, and we all have blind spots. LLMs are great at helping us actively explore them and to challenge our assumptions.

I like to employ an LLM as a contrarian thinker whenever I need to make a controversial decision or ensure that what I am thinking is not just a confirmation of my own biases.

This works for pretty much anything, and it helps me feel more confident in my decisions, especially when I know that I have considered the alternatives.

Here's a prompt that might help you to get started with contrarian thinking:

As a Chief Technology Officer, I need a rigorous evaluation of my proposed strategies. Act as a highly critical and contrarian advisor, whose primary objective is to identify flaws, challenge assumptions, and present alternative viewpoints to any argument I present. Your responses should be structured as follows:

Re-state my argument concisely: Confirm your understanding of the core point I am making.

Identify underlying assumptions: Pinpoint any unstated assumptions that my argument rests upon.

Present the contrarian view: Offer a directly opposing or alternative perspective, supported by logical reasoning or potential counter-evidence.

Highlight potential risks or weaknesses: Detail any vulnerabilities, oversights, or negative consequences that my argument might entail.

Propose alternative solutions or considerations: Suggest different approaches or factors I might not have considered.

Maintain a professional yet assertive tone. Do not agree with my statements unless you have exhausted all possible contrarian angles. Focus on constructive criticism to foster robust decision-making. My argument is: [INSERT YOUR ARGUMENT HERE]"

Give it a go whenever you have to decide something big or controversial. It really helps.

The executive assistant

In the same way I've never had a research assistant, I've never had an executive assistant — the sort of person who can help me to manage my time, my priorities, and my tasks.

I am definitely guilty of not taking the time to critically look at everything I need to do in my day, and using an LLM as an executive assistant can help me to break through that organizational stalemate.

There's also some odd cognitive trick with being told how to structure your day rather than structuring it yourself that makes you take it more seriously. I think that this is because it feels like an external authority is telling you what to do, rather than you just making it up yourself.

If you're going through particularly busy periods, then taking a few minutes to write to the LLM about what's on your plate and asking it to help you prioritize can be a great way to get some clarity and focus.

For example:

I am an Engineering Manager. Here's a raw list of my tasks for today, along with my calendar:

Meetings: 9 AM - Standup, 10 AM - 1:1 with Alex, 11:30 AM - Product Sync, 3 PM - Architecture Review.

Tasks: Review PR for new payment gateway, Draft Q3 OKRs for my team, Prepare feedback for Alex's performance review, Respond to urgent security vulnerability email, Research distributed tracing tools, Update project status for stakeholders, Block out focus time for coding (if possible).

Context: The security vulnerability is critical and needs a response by end of day. Alex's 1:1 is important for career development.

Given this, help me structure my morning (8 AM - 12 PM) to maximize productivity. Prioritize tasks, suggest blocks for focused work, and identify any conflicts or areas where I might need to delegate or defer. Also, recommend a single most important task for me to tackle first thing.

Yes, there are tools that can do this for you, but you can go a long way with just a simple prompt.

Similarly, even though tools like Granola exist, you can use a plain prompt to help digest what you should do after meetings given your notes or a recorded transcript.

Here are my raw notes from a 90-minute architecture brainstorming session. Please read through them and extract:

Key decisions made (e.g., 'We will use Kafka for async messaging').

Clear action items, including who is responsible and a rough due date if mentioned (e.g., 'Sarah to research Kafka cluster sizing by Friday').

Open questions or topics that need further discussion.

Any technical risks identified.

Notes:

scribbled details about API Gateway options

discussion on database sharding strategy - leaning towards range sharding but some concerns about hot spots

Sarah mentioned looking into Kafka for event bus, seems promising, maybe by end of week?

need to decide on observability stack - Prometheus + Grafana or DataDog?

John brought up data consistency issues with eventual consistency model

agreed to use GraphQL for public API

next meeting for deep dive on database sharding next Tuesday

urgent: security review of data encryption at rest - assigned to platform team

This will help you to get the most out of your meetings and ensure that you don't forget anything important.

The coach and sounding board

Finally, sometimes we all need some support. LLMs can be a great sounding board for your own thoughts, feelings, and reactions to situations.

For example:

I've just been informed that a significant re-organization is coming to our department in the next 4-6 weeks, and some of my team members will be transitioning to new teams or roles. I want to ensure I lead my team through this change as effectively and empathetically as possible, minimizing disruption and maintaining morale.

Act as my personal executive coach. Ask me probing questions that help me anticipate potential challenges and formulate a proactive strategy for communication and support before the reorg is officially announced. Focus on:

- My initial communication strategy to the team (pre-announcement and post-announcement).

- How I can best prepare to address team members' anxieties, uncertainties, and potential resistance.

- Specific actions I can take to support those transitioning and those remaining.

- My own emotional preparedness for leading through this period of change.

Start by asking me the first question, and I will respond.

The key here is in specifying up front how the LLM can coach you, and how to structure the conversation as a two-way dialogue. Feel free to adapt the prompt to your own needs at a given time.

Summary

I still believe that we are underusing LLMs in our day-to-day work as managers and leaders. Partially this is because they require some upfront effort and creativity to get the best out of them.

I've been trying hard to overcome these creativity blocks to find ways to improve my thinking, reasoning and effectiveness as a leader, and I hope that some of the techniques I've shared here will help you to do the same.

If you've got any of your own cool ideas and prompts, I'd love to see them.