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.

What hasn't changed

Before getting into everything that has changed, I wanted to point out something that is still important and true: the world needs more great leaders.

It is something that I believed when I thought I'd give the job a shot myself many years ago, and it is the reason that my books and this newsletter exist (especially when I write it right up to the deadline...)

Managing teams is hard but can be incredibly rewarding. It gives you the opportunity to help people grow, succeed, and be happy. It lets you build great products that you couldn't build alone. And, over time, as you look back at all of the people that you mentored and see how they've all gone on to do great things, it can be one of the most fulfilling things you can do in your career.

So, there is a place for you in management if all of that sounds appealing to you. But the manner in which you will do it, and the environment that you will be doing it in, is very different.

Companies reflect the world around them

Managers exist within a new world. A lot has changed. We've been though a pandemic, a recession, and for the first time in a long time, interest rates are high and there is far less cheap capital for companies to use in the form of investment or credit.

For anyone that got into management in the last 15 years, fiscally, it couldn't be more distinct. Over the ZIRP period, cheap capital meant plenty of investment into technology companies, and that meant a lot budget and a lot of hiring.

Lots of hiring needs lots of managers, and that meant that there were plenty of opportunities for people to make the switch, and it was a safe environment to do so: all these new people needed to report to someone, after all.

Fast forward to today, after years of post-pandemic layoffs, you can see a number of key differences:

• Managers have been specifically targeted in reporting on major tech layoffs. The term "flattening" has entered the vernacular, meaning that companies are looking to reduce the number of managers and layers in the organization.

• Related to the above, there is a lot more scrutiny on the value that managers provide. Despite hiring flurries creating management roles in the first place, managers are now being asked to justify their existence.

• And, following that, the wave of new AI tooling that can make engineers more productive is making companies optimize for either having fewer people do more work, or for more individual contributors than managers to increase raw output.

Now, back to the premise of this article: yes, it is still possible to get into management. But the environment is more challenging and you really need to be invested in it to succeed.

Growth is expanding impact, not headcount

Whereas the previous focus of managers was to rapidly hire and scale their teams, today's focus is on expanding impact. This is because in today's macroeconomic environment, output is key.

In the eyes of a 2025 company, the more that you can do with fewer people, the better. There are very few additional people to go around, so the focus is on how you can help your team do more with less.

This may have some consequences for the new manager:

• They may not be able to hire as many people as they would like, or at all. This means that they will need to focus on how to get the most out of their existing team.

• They will likely need to remain more hands-on with their smaller team, rather than fully delegating work to others. I wrote about this before in an article titled Being In The Details. You don't become a manager to become hands-off in 2025: that's a surefire way to be seen as underperforming.

• As a result of the above, the pure (fully delegated) manager may not even be a thing any more in front-line teams. Thus, managers are often more of a hybrid role, where they are still doing some of the work themselves, while also managing others.

• If new managers are expecting to grow to a Director or VP role, they may need to adjust their expectations. The path to those roles is still there, but it is going to be a lot harder and take longer than it did in the past. In the same way that there are only 20 Premier League managers, there are only so many senior roles to go around, and they are being created far less frequently than they were before.

So, to the new manager: do it if you are happy to be hands-on and focused on running one team for some time. If you are going to be disappointed that you can't make VP in two years, then maybe now isn't the right time for you to make the switch.

Efficiency is the new growth

In a capital-constrained environment, the focus is on efficiency. Whereas a growth-mode manager may have had a primary focus on hiring and coaching, now engineering managers are expected to be all-in on efficiency.

This means optimizing processes, eliminating bottlenecks, shipping quickly, and maximizing the productivity of their developers.

Efficiency is proven though measurement, so new managers should expect that they will need to be able to measure the output of their team in ways that they may not have had to before.

This can span operational measurements such as DORA metrics through to strategic measurements via OKRs or KPIs.

The more that you can measure, the more that you can optimize, and the more that a manager be sure that they are providing value to the company. This is a good thing to be able to do.

Quantitative measurements are essential: new managers should have the conversation straight away about how they will be measured, and therefore what the expectations are for them and their team.

Headcount is a liability until proven otherwise

Whereas new hires flowed liberally in the past, meaning that future roadmaps were built on the assumption that more people would be available to do the work, today, headcount is heavily scrutinized.

This means that every single new hire needs to be justified, and the manager needs to be able to show that they can get the most out of their existing team before they can even think about hiring more people. Some companies have even stated that managers will have to justify that AI can't do the work before they can hire a new person.

Headcount scrutiny equally affects existing team members. Given the financial constraints, managers are expected to be proactively raising the bar on their team, and that those that are not performing at the expected level will need to be let go to make room for new hires. I wrote about this in a previous article: Performance Management: The Rising Tide.

The skeptical reader may be thinking "surely this is no different than before?", but the reality is that it is: performance management expectations now are far higher than they have been in the past. During ZIRP, the member of staff who's performance was on the fence of acceptable was often tolerated, and now they certainly are not.

If you are aiming to be a new manager, realize that the unsexy part of the job isn't something you need to deal with once a year: it's something that you will feel the pressure to do all of the time, else you'll be the underperformer.

Scrappy is back in fashion

Being entrepreneurial and scrappy is now essential. It goes hand in hand with the efficiency focus, but it is also a mindset that is increasingly expected of those leading teams.

Your company will want you and your team to be able to show progress and value as quickly as possible, likely every single week.

This means:

• Building prototypes and MVPs to show value quickly, rather than waiting for a fully polished product. The urge for executives to see something as proof of progress has never been higher, especially when you can vibe code a prototype in a few hours.

• Cutting scope aggressively to ship as soon as possible. We're back in a zero-waste environment, so continually ask yourself "what is the minimum that I can ship to deliver value?" and then do that.

• Debates about the "right" way to do things hold little value: instead, show progress. Show a prototype, some code, or a demo. Create rather than debate.

• Acting as an operator, not just a manager. Think of your team has a small business unit, and you are the CEO. You need to be able to make decisions quickly, pivot when necessary, and show results. Pointing at others in the company as a reason why you can't do something doesn't cut it: do it yourself, or find a way to get it done.

This can be either good or bad for a new manager: I know many people who love operating in this manner, and they'd certainly enjoy getting into management now. However, I equally know many people who have a different style, and they may find today's environment a lot more challenging.

AI is now table stakes

The final key piece of advice that I would give to new managers is that use of AI is now required.

Of course, this isn't particularly surprising given where we are in 2025, but importantly, as a manager you will be expected to increase and optimize the use of AI in your team.

What this means is that you will need to:

• Ensure that all of your engineers are using AI in their workflows, both from use of prompting to improve research, thinking and decision making, to using AI to accelerate the production and testing of code.

• Be able to measure the impact of AI on your team's productivity, and be able to show how it is improving output. This may mean that you need to track metrics such as time saved, code quality improvements, or reduced cycle times; this was covered in the efficiency section above.

• Be able to coach your team on how to use AI effectively, which means that you need to be able to use it effectively yourself.

• Be creative in how you use AI in your own work. I wrote a few previous articles on this, such as LLMs: An Operator's View, A weekly mind meld, and A bag of worries: tackling overwhelm with LLMs. Get creative and inspire your team.

• Likely treat AI skeptics as underperformers. Although it makes me feel somewhat uncomfortable writing this, there really is no place for people who refuse to use AI in today's software engineering roles: it is evident that productivity is significantly higher when it is used, and so it is a key part of your job to ensure that your team is using it effectively.

So, do you still want to be a manager?

Remember, and I said it at the start: the world needs more great leaders, and if you want to do it, I'm sure that you can. The issue is that the world has changed outside of our control, so we have to adapt and operate differently.

If you're excited by the prospect of being scrappy, hard on performance, resourceful and able to do more with less, and want to help teams level up in their use of AI, then maybe now is a good time for you to make the switch. After all, if an opportunity presents itself, remember that these opportunities are far rarer than before.

Best of luck.

Brought to you by:

• Volv delivers the most breaking and interesting news in 9-second reads. No fluff—just sharp, credible facts. You might even find some of my writing on there. Download Volv—free, fast, no clutter.

If you've had periods in your leadership journey where you feel like you're generating more to-do items than you can handle, then you're not alone.

Every day, you might add five or ten items to your list, each representing an entire project that could take weeks or even months to complete.

For example, after a busy Monday your list might have the following items added to it:

• Review increasing infrastructure costs and propose optimizations.

• Plan team offsite for next quarter including budget and agenda.

• Look into security audit findings and create action plan.

• Prepare for upcoming performance reviews and set criteria.

Sigh.

And that's on top of the existing huge items that you already have on your list from last week which you haven't had the time to deal with yet.

This can lead to a feeling of being overwhelmed, like you're carrying around a heavy mental load. Each item on your list feels like a weight, and the more you add, the heavier it gets.

Although the pragmatist may say that the solution is simply to put time aside to properly triage, prioritize, and delegate or action these items, this is easier said than done. At the end of a busy day I'm usually pretty tired, and the creative juice that I need to properly think through these items is often in short supply.

My own mental resistance to dealing with these items is often the biggest barrier to getting them done, rather than the actual complexity of the items themselves. Long days with lots of context switching can seriously deplete my mental capacity. I wrote about managing this capacity in a previous article, noting how it can expand and contract based on the demands of the day.

In order to better manage my capacity and energy, and also leaning on creative ways to use LLMs, like in my mind meld technique from the last article I've been trying a new approach to deal with this problem, which I call "the bag of worries".

Separating to-dos from worries

The first problem I have is that the big, gnarly, and unprioritized items on my to-do list are not really to-dos, but larger, unsorted worries. Like in the example list at the beginning of the article: a discussion in a meeting making me worried about projected infrastructure costs, or some known bottlenecks in the system that require deeper investigation.

These tasks are not five minute jobs.

Compared to the other things on my to-do list which are often small, actionable items that I can rattle through sequentially, these larger items are more like worries that I carry around with me. They require a fair bit of unpacking and thought before I can even start to think about how to tackle them.

As a result, I've separated out my to-do list into two parts: a "to-do" list for actionable items, and a "worries" list for these larger, more complex items that need more thought and planning. Because the to-do list is typically sorted by priority, and the worries list is not, I call my worries list "the bag of worries", as they're all jumbled together in a single place.

I wrote previously about my second-brain system of gather, decide, execute, in which I use Logseq to continually make notes and gather information, and then decide what to do with it. The bag of worries is a natural extension of this system (it's just a page in Logseq), and it allows me to keep track of these larger items without them cluttering up my to-do list.

As I go through my day and see things that worry me, or that need looking into further, I just throw them into the bag of worries. I don't worry (no pun intended) about whether they're important or not, or whether I should be doing them now or later. I just add them to the bag.

I'm feeling lucky

But hang on, isn't that just procrastination? Well, kind of. Based on self-observation, if I have these kinds of big worrisome items staring me in the face alongside my to-do list, I tend to begin to feel a little overwhelmed, and I find it hard to focus on the essential tasks that I need to get done. So tucking them away in the bag of worries is a way to declutter my mind and focus on the immediate tasks at hand.

However, the bag of worries is not just a dumping ground, and I've been experimenting with picking one big thing from it each day to break down and then make a plan from.

Since these items in the bag of worries often are large and require a lot of unpacking, I've been enlisting the help of LLMs to kickstart my thinking and planning process.

In the last article I wrote about how to use the Prompt Engineering whitepaper as an input to your own GPT or Gemini Gem (or other equivalent), enabling you to generate significantly better prompts than you might write unassisted.

To save clicking away from this article, I'll reproduce the Gem/GPT here, of which you attach the PDF to as additional context:

You are a tool to generate excellent prompts that will greatly improve output compared to what is given as input. You will use the attached book on Prompt Engineering to formulate these prompts and you will return the improved prompt along with your reasoning for why it is better.

You are always helping a CTO do their job, so frame the prompts as such.

I then use this to generate a prompt for the bag of worries: it helps me select one at random, unpack it, and then generate a plan of action.

Here it is:

As a CTO, I'm managing a 'bag of worries' – a list of pressing technical and strategic issues that require my attention. You are my expert executive assistant. I need your assistance to systematically tackle these.

My current bag of worries is:

[insert list of worries here, e.g. "increasing infrastructure costs", "team offsite planning", "security audit findings", "performance reviews preparation"]

Your task is to:

• Randomly Select One Worry: From the provided list, please choose a single worry at random. Clearly state the selected worry.

• Generate a Comprehensive Action Plan: For the selected worry, develop a detailed and actionable plan to help me, as the CTO, take positive and effective action.

  This plan should be structured and include the following elements:

• Objective: A clear, concise statement of what successful resolution of this worry looks like.

• Key Actionable Steps: A sequence of 3-5 primary steps to address the worry. For each step, provide a brief description of the action.

• Stakeholder Identification: List key individuals or teams (e.g., Head of Engineering, Security Lead, Product Management, specific engineering squads) that need to be involved, and their general role in the action plan.

• Potential Challenges & Mitigation Strategies: Identify 1-2 potential roadblocks or challenges that might arise and suggest a proactive mitigation strategy for each.

• Resource Considerations: Briefly mention any critical resources (e.g., budget allocation, specialized tools, external consultants, dedicated time from specific teams) that might be necessary.

• Success Metrics: Define 1-2 measurable indicators that would signify progress or successful resolution of the worry.

• Suggested Initial Timeline/Focus for the Next 2 Weeks: Outline what realistically can be initiated or achieved in the immediate short term (e.g., initial meetings, data gathering, preliminary assessments).

Output Format:

Please present the selected worry first, followed by the detailed action plan with clear headings for each of the elements listed above.

Tone and Style:

Strategic, decisive, and action-oriented, suitable for a CTO's executive advisor.

This works surprisingly well for plucking something out of the bag of worries and removing the initial mental effort to turn it into a real action plan.

The generated action plans are fairly long, so I didn't want to copy and paste them verbatim into this article. However, I do recommend trying this out for yourself, as I have found that it's been the best way of taking a big scary worry and having me able to actually do something about it in a fast and structured way.

Or, you could prioritize

Another way to tackle the bag of worries is following the classic Eisenhower Matrix prioritization exercise, except you let the LLM do it for you.

Here's a prompt for that:

Assume the role of an expert executive assistant, highly skilled in productivity and prioritization frameworks. I am your CTO, and I'm providing you with my current 'bag of worries' – an unsorted list of tasks, concerns, and observations that require my attention.

Your task is to:

1. Analyze each item from my provided list of worries.

2. Categorize each item according to the Eisenhower Matrix. For clarity, these categories are:

- Urgent and Important (Do First): Tasks that demand immediate attention and are critical for achieving significant goals.

- Important but Not Urgent (Schedule): Tasks that are vital for long-term success and strategic objectives but do not require immediate action; these should be planned and scheduled.

- Urgent but Not Important (Delegate): Tasks that require prompt handling but do not necessitate my direct involvement and can be effectively assigned to someone else.

- Neither Urgent nor Important (Eliminate/Delay): Tasks that contribute minimally to our objectives and can likely be removed from the list or significantly deferred.

3. Present the categorized list clearly. Please use distinct headings for each of the four Eisenhower Matrix quadrants.

4. Provide a brief rationale (1-2 sentences) for each item's categorization. Explain the thinking behind placing it in that specific quadrant, especially if urgency or importance might be ambiguous. (Adopt a 'think step-by-step' approach for your reasoning).

5. After categorizing all items, identify and recommend the single most critical item from the 'Urgent and Important' quadrant that I should address first.

6. Explain your reasoning for selecting this top-priority item over any others in the 'Urgent and Important' quadrant.

My 'bag of worries' is as follows:

[Insert your comma-separated or bulleted list of worries here.]

Please process this list and provide your categorized output and recommendation.

Try it out yourself

Before finishing this article and going back to whatever else you were doing with the rest of your day, try this out for yourself.

1. Take a moment to write down the top three or four big worries that you have at work right now. Perhaps these are upcoming performance reviews, a design document that needs writing, or perhaps you need to come up with a plan for analyzing the current budget and finding 5% savings.

2. Open up your favorite LLM, such as ChatGPT or Gemini, and paste in the bag of worries prompt above (you can choose between the random selection or prioritization version).

3. Copy your worries into the prompt at the place with the square brackets in either.

4. Hit send and see what comes back.

5. Look at the action plan, and see if you then have a clearer idea of what to do next.

6. If you do, then congratulations! You've just taken a step towards tackling one of your big worries. That was easy, wasn't it?

7. If you don't, then try tweaking the prompt a little bit to better suit your needs. You could do this by using the reusable prompt engineering gem above, or by just changing the wording.

Congratulations on having a new executive assistant.

You might find that it helps to have a version of this for your home life too, as it's rare that you only carry around a bag of worries for work. There's DIY to do, insurance to renew, and family events to plan.

Every day I find more neat tricks that LLMs can do in order to help me be more productive at work. I find you get out what you put in.

How are you managing your own 'bag of worries'? Have you found other creative, non-obvious applications for LLMs in your managerial work? Let me know if you have.

You need a solution that works for you and your team, and allows the most efficient use of everyone's time, and is also archival, searchable, and shareable. The good news is that this solution already exists, and it predates slideshows, videos, and, come to think of it, even the internet. It's called writing.

Since starting my new CTO role, I've been sharing a weekly update with my team. I think about it as a mind meld, which has the Wiktionary definition of:

From the Star Trek franchise, where the term was first used in 1966 for a telepathic ability possessed by the alien race of Vulcans to share thoughts and feelings with another individual.

It's how I continually open up my thoughts to the team with a long-term goal to reduce any mental alignment gap between us. I like to think that the more I share, the more they can understand what I believe is important and why, and the more that my style of working and thinking can propagate through the team.

There are a few rules and guidelines I follow when writing these mind melds. They should:

• Take no longer than 60 minutes to write.

• Be no longer than 1,500 words.

• Be sent out on a Friday afternoon as a way to close the week.

• Have a conversational tone and high ease of reading, similar to how I write this newsletter.

• Mix general updates with praise and feedback on things we can do better.

• Be sent to the entire team in a way that anyone in the company can also read it.

I will call out that because I have done a ton of writing and that English is my first language, I can write fairly quickly compared to other people who don't write as often. However, writing is a skill that can be learned and improved over time, so don't let that stop you from trying.

I'll spend the rest of the article going over my process for collecting the information I want to share, how I structure it, and then give you some hypothetical examples.

Collecting information

The first step is to continually collect information throughout the week. I wrote back in January about my daily system for how I capture notes and tasks using Logseq, but everyone uses something different.

The key is that you engage with your daily activities mindfully in a way that keeps your weekly update in mind. What I mean by this is that you are always on the lookout for:

• Direct experiences that you have had that would be valuable to share with the team. This could be anything from conversations with customers to shareable summaries of closed-door meetings such as executive reviews.

• Events that can be celebrated, such as a big project shipping, a long-standing bug being resolved, or performance improvements that have been rolled out.

• Things that could be improved, such as an incident that happened, an inefficient process that is causing friction, or data that highlights a problem that needs to be fixed (e.g. a drop in performance or an unexpected increase in infrastructure costs).

• Events that are happening in the near future that you want to remind people about.

For me, as I go about my week, I'll tag things in my notes with a weekly-update tag. This allows me to quickly search for them all later and use that as a starting point for my writing. I spend most of my week hammering out notes, so adding a tag is a super simple way to aggregate a week's worth of information on a Friday.

Structuring the mind meld

So, we get to Friday, and I've blocked out some time to write my update. I've got my tagged notes that I can use as a starting point, but we need some structure to the update.

Here's the rough structure that I hang my updates on:

• Intro: A short paragraph that sets the tone for the update. Assuming nothing big and serious has happened, I keep it light and observational. For example, the other week I was in Helsinki for our exec committee meeting, so a paragraph about the trip and the meme around the Finnish weather was a good way to start.

• General updates: I batch together any general one-line updates that I want to share. This covers anything from welcome new hires, to upcoming events, to general company and engineering news. It's important stuff that doesn't need its own section.

• The main event: I'll pick one topic that I think is the most important thing to share. For example, if we are making a major change of some kind, this is where I'll go into detail about it. Similarly, if I've had a key observation that I think is worth exploring more deeply, this is it. In the following section, I'll cover some examples of what I mean by this. Typically I'll try to hang this on any key principles or values that I want to reinforce. The main event usually takes up the most space, maybe between 300-500 words.

• The sideshows: This is where I cover the other less important topics that I want to share, maybe a few hundred words each. This could be a summary of a recent incident, a shout out to a team or individual, or discussion around a process that we are trying to improve.

• The wrap up: I finish with a short paragraph that wraps up the update. This is usually a call to action such as asking for feedback or to share thoughts via comments or on Slack. If the tone of the update is light, I might share some interesting articles or podcasts that I found interesting during the week.

As outlined before, I try to keep the entire update to around 1,500 words. This is a good length for people to read in one sitting, and I can hammer it out in one pass in around an hour.

Once I'm done and before I send it I'll also do a quick proof read to check for typos and grammar. I'll also then get an LLM to scrutinize it to see if there are ways that I can improve the content.

Here's an example of a prompt I might use:

You are an expert editor. Please analyze the following draft of my weekly update that I sent as CTO to my department.

First, conduct a thorough proofread for grammar, spelling, and clarity. Then, evaluate the content for completeness, conciseness, and strategic alignment with our company's goals.  Suggest specific revisions to improve the update's impact, including:

- Identifying any missing information that should be included.
- Rephrasing sentences for better clarity and flow.
- Ensuring the update is concise and avoids unnecessary jargon.
- Highlighting key achievements and their impact on the company's objectives.
- Suggesting ways to make the update more engaging for the intended audience (e.g., using visuals, summarizing key takeaways).
- Applying 'Chain of Thought' prompting, break down complex updates into step-by-step reasoning for clarity.
- If applicable, use 'Tree of Thoughts' to explore alternative ways to frame certain updates for maximum impact.

Here is the draft of my weekly update:

[insert draft here]

If you're looking for help with generating prompts for you that are this detailed, then a neat trick that you can use is to take the PDF whitepaper on Prompt Engineering as input to your own GPT or Gemini Gem, and then create a reusable tool that utilizes it to improve the input prompt that you give it.

For example, the prompt text for your reusable tool using the whitepaper to generate prompts could be:

You are a tool to generate excellent prompts that will greatly improve output compared to what is given as input. You will use the attached book on Prompt Engineering to formulate these prompts and you will return the improved prompt along with your reasoning for why it is better.

You are always helping a CTO do their job, so frame the prompts as such.

I find myself using this trick all the time now, and it works really well. I don't copy the output verbatim because I like to keep my own writing style and voice, but it does help me make a number of edits and improvements to the text.

An example mind meld

Instructions aside, it's probably best to just show you an example of a weekly mind meld. Here's a hypothetical one following the structure above. I've made it up, but it should give you a good idea of what I mean.

The April 2025 mind meld

Hey team,

I'm back home after spending a week visiting our London office. It was nice to spend a few days away from the screen and get to spend time with many of you who I don't get to see as often. I even managed to get out for a couple of evening walks in the unusually warm weather.

There are a few short updates that are worth sharing before we go any further:

• A huge welcome to our five (!) new starters this week: Alice, Bob, Charlie, Dave, and Eve. It's great to have you here with us, and as you get your dev environments set up, please DM me if you have any issues: we've put a lot of effort into improving cold starts recently, but I know there can still be some hiccups which we will continue to work on.

• Congratulations to the infrastructure team for completing the migration of our final legacy database. We are now 100% on our new database platform which is not only faster, but also so much cheaper and scalable.

• A reminder that we have our quarterly all hands next week. The invite is in your calendar and you can submit Q&A via the link in the invite.

Speed of decision making

There is an important topic that I wanted to cover this week: speed of decision making. We've been growing a lot recently and as we do, we need to be hyper-aware about our rate of progress.

As I talked to many of you in person, the main complaint that I heard was that we are moving too slowly. This wasn't just in one area, but across all teams and projects. I think this is a symptom of our growth, and it's something that we need to address as a team.

Here's something that I would like us all to try: if you are blocked on progress in any way, shape or form, and it has been more than 24 hours, please escalate it to me. I will then work with you to unblock it. This could be anything from a decision that needs to be made, to a resource that you need, or even just a conversation that you need to have with someone.

This might seem like an unscalable solution, but I want to make it super clear that we cannot afford to slow down at this stage of our growth. The longer we take to make decisions, the more ground that our competitors will gain on us. As such, I will be prioritizing any escalation that I receive, and I will work with you to get it resolved as quickly as possible.

Honestly, nothing is too small. Just DM me and we will fix it. Trust me.

Incident response

I wanted to bring attention to the new process that we are starting around incident response. We've been working hard to improve our incident response process, and I think we are finally getting to a place where we can start to see some real improvements.

We have implemented new rotas, new tools, and new processes to help us respond to incidents faster and more effectively. I know that this is a big change for many of you since we have dramatically expanded our on-call rota, but I think it is a necessary step to take. For far too long we have been relying on a small number of people to respond to incidents, and this has led to burnout and frustration.

I want to thank everyone who was involved in turning around the incident that happened earlier this week. I was scrolling through the Slack messages and I was impressed by the organization, communication, and speed of response from many of you who hadn't done this before. The RCA that was done the following day was also very insightful, and we're already getting to work on the action items that were raised.

Let's keep at this and build our muscles in this area.

Thoughts for the weekend

I'm aware that there is a public holiday coming up in the UK, so a number of us have an extra day off. If you get a bit of free time, here are some cool things to check out:

• Have a play with the latest Gemini model, 2.5 Flash. I've been very impressed by Google's latest models, and if you've only been using ChatGPT for a while, you might be surprised by how Gemini compares.

• I really enjoyed the latest Acquired podcast on Epic Systems. If you're outside of the US, you might not have heard of them, but they are an impressive and curious company — just search for pictures of their campus in Wisconsin.

• And lastly, if you really just want to get away from the screen and do nothing for three days, that is totally fine too.

Have a great weekend.

And that's a wrap

I've been enjoying writing weekly to my team so far. Even though writing isn't video or audio, I still think it's the most scalable way to communicate with a large team, and one that allows me to keep pushing forward on the things that I believe are important, whilst keeping the team aligned and informed.

I hope this article has given you some ideas on how to do the same. I'd love to hear how you communicate with your own teams.

You may run one or many teams, or even a whole company. And, even if you are not a manager by definition, you may wield a great deal of influence over directions and decisions.

In the midst of the current LLM explosion, we as operators find ourselves amongst:

• A blistering pace of improvement in the capabilities of LLMs. New models and products are being released at a rate that is hard to keep up with.

• Immense noise and hype online making all sorts of claims, good and bad, about what the future holds.

• An expectation from our companies to go full-on with "AI", which typically means LLMs, both in developer tooling and in customer-facing products. AI is the new data is the new cloud.

• Echoes in the industry that we are all now overstaffed as a result of productivity gains: that everyone should do more with less, and that AI is the answer to that.

Note: this article is not a technical overview of how to build products with LLMs. Instead, the intent is to touch upon what leadership should do from the perspective of the productivity of teams and organizations, and consequently how we should think about spending our budgets to make that happen. There are plenty of hot takes out there on AI. This is not intended to be one of them.

What we'll cover related to LLMs is:

• The (real) rising floor of developer productivity.

• The changing size of organizations.

• The increasing importance of code reviews.

• The changing nature of interviews and identifying talent in short spaces of time.

The intent is that this should provoke thought and discussion, and will hopefully help you think about how to allocate your budget and focus in the coming months and years.

The floor is rising

With Copilot, Cursor, Cline and other LLM-based developer tools, the floor of developer productivity is rising.

At the time of writing in 2025, I believe even the most AI-skeptical developers are now seeing the insane productivity gains that LLMs can provide. Yes, it was true that, several years ago, the promise and the hype far outweighed the consistent proof of benefits, but in a post GPT-4 world, LLMs have become an integral part of the developer's toolkit, even if it is just for fast research or rubber ducking rather than agentic pair programming.

I don't know many developers that would give them up now, myself included. I go too fast with them to go back to the old way of doing things.

If for some reason (!) you haven't fully leaned into LLM-assisted coding yet, the benefits are plentiful:

• LLMs are fantastic for getting over the cold start problem of a new idea. You can go from nothing to a throwaway prototype in no time at all, starting with a vague prompt of what you want and iterating on it. There are numerous "vibe coding" projects that are generating some serious revenue.

• You can use a prompt to sketch out whole architecture ideas with back of the envelope calculations and tradeoffs.

• Copilot-style autocompletion is now very good unlocks the next step in your thought process.

• Agent-based tools like Cursor or Copilot Chat, when kept under control, can be a great way to get a lot of boilerplate code written quickly.

• Writing tests, and therefore driving up code coverage, is now much easier. LLMs can write tests for you, and agent-based tools can execute the red-green cycle for you as you go.

If you haven't yet spent an afternoon or evening with Cursor, then please, please, please make time and see how fast you can go from a blank page to a fully functioning hobby project. It is incredible how fast you can go from nothing to something.

So in terms of the Gartner hype cycle J-curve, we are clearly on the upward slope towards enlightenment. The tools are getting better, and they are getting better fast. It is unclear as to how far the Bitter Lesson will take us, and predictions currently range from being on the cusp of hitting a plateau of productivity to full-blown AGI, but it is clear that an organization that does not embrace LLMs will be left behind by their competitors.

As an operator, up-skilling your team to use these tools is now essential. Securing the necessary budget to give everyone access to the Pro tiers of ChatGPT, Cursor, or whatever tools represent the best fit for your team is a table stakes activity. And yes, this does mean that your budget will increase, but the productivity gains from an existing team will more than make up for it. Trade the cost of hiring new people for the cost of acquiring tooling.

You should also take the adoption of this tooling seriously. It is not just a case of giving everyone subscriptions and hoping for the best. You need to invest time and effort into training your team on how to use these tools effectively.

• Run a survey to see what tools your team is already using and how they are using them. As part of the survey, identify which of your engineers are already fully ingrained in the new LLM workflows and which are not.

• Identify champions based on the previous point and have them run training sessions and also overindex on pair programming with those who are less familiar (or more skeptical) of the tools.

• Promote a culture of sharing best practices and tips for using LLMs. Get your champions to lean in and share their workflows and processes with the rest of the team. Videos work wonders here.

• Track the usage of AI tools over time as you adopt them. For example, Cursor offers team analytics, and you can see how many lines of code are being generated and accepted. Use this as part of the feedback loop to see how your team is progressing. Is usage increasing or decreasing? Why?

• Cross-reference the usage data with other metrics you are collecting. For example, how is the average number of commits to the codebase changing as tool usage increases? What about the number of incidents or reported bugs? What's happening with your DORA metrics as a result?

Focus on showing that the tools are making a real difference, and this too can be motivation to bring the most skeptical engineers on board.

Organization sizes are changing

Given that the way that we create software has changed, there is another operator's consideration: the size of your organization.

Layoffs have been rife since the end of ZIRP. Overlapping this period has been the rise of LLMs, and in some cases, the two have been conflated: organizations haven't just shrunk because of AI efficiency gains, but they also haven't just shrunk because of the macroeconomic environment either; the two are becoming somewhat intertwined, if you believe what these companies are saying.

However, it is true that from a company-operator's perspective, the hard-to-exactly-quantify, but definitely real, productivity gains from LLMs allow you the ability to do more with less.

And amongst a tricky economic environment, instead of staying same-sized and increasing output, there has been a trend in many organizations to reduce headcount and combine this with AI tooling to (sort of) maintain the same level of output.

If you think about it, many of the world's largest companies are (or were) staffed to pre-LLM productivity levels off of the back of ZIRP, and you could argue that there consequently has been an exchange of a large chunk of money that used to pay salaries for a smaller chunk of money that pays for tokens and subscriptions.

One could even argue, especially at large companies, that if all developers could go, let's say, twice as fast with the new tooling, then other bottlenecks would appear that would limit the speed of progress anyway, so less really is more.

These bottlenecks may already exist: the sometimes glacial speed of making decisions, the amount of change and new features that your users can stomach at once, the time it takes to go through cycles of shipping and learning and iterating and so on.

Many companies are already at the point where they effectively block the speed of their own progress in other ways than just the number of developers they have. Making those developers faster may not actually help them ship more features, and in fact, it may make things worse.

Maybe you work for a company like this.

Going back to the operator's perspective, if you currently work for a small or medium-sized company, a good idea would be to focus your attention on giving everyone access to the right tools and training to become more productive before you go on another hiring spree. Get everyone coding like they should be coding in 2025 first, assess and prove the productivity gains, get your tooling in place, and then look at hiring more people.

And remember that tooling goes beyond developers: we're talking about all employees. A pro subscription to ChatGPT is just as useful for a marketer's efficiency as it is for a developer. Giving each employee in a 50-person company a ChatGPT Pro subscription is still cheaper than hiring a senior developer or two. Think about macro efficiency gains across the whole organization, not just in engineering.

Reviews are more important than ever

The flip side of the productivity gains is that more code is being written, and, most importantly, not all of it has been as carefully thought through as handcrafted code.

If you've used Cursor without specifically asking the prompt to slow down, go step-by-step and ask for your input frequently, you've likely seen it go off and blast out hundreds of lines of code that is hard to keep track of.

Now, this is great for getting a prototype up and running, but it is not so great for production code: the code generation starts to go faster than you can meaningfully comprehend it as a human, and bugs can be introduced that are hard to spot. In the best case, the code can be messy or unoptimized. In the worst case, it can be full of security holes that could seriously compromise your organization.

As such, with the faster production of code, as an operator it is more important than ever to ensure you have a strong review process in place: if your most senior engineers were getting a half-arsed rubber stamp thumbs up from their peers (not advised, but it happens), now you need to ensure that all code is being scrutinized as the origins of it are less clear.

You could:

• Make it clear to your organization that even though LLMs can generate lots of code almost instantly, human reviewers can only digest so much. Keep PRs small, commits clear, and code easy to read.

• Increase the number of required reviewers on your PRs. For example, go from one reviewer to two. You could also have engineers flag their own PRs that have heavy LLM usage to call out that they need extra scrutiny.

• Give people a refresher on security best practices (shock horror!) so they can be better aware of when LLMs are generating code that is insecure.

• Make improvements in your incident postmortem process to ensure that you are learning from your mistakes. Share any production issues that stemmed from overlooked generated code widely across the organization so that everyone can learn from them.

• Investigate AI tools such as DeepCode by Snyk or Graphite's Diamond that could help detect issues in code before it is even reviewed by a human.

Am I even interviewing you? Or your LLM?

The typical tech interview process for individual contributors, which involves some combination of coding challenges, white boarding, and system design, has had another curve ball thrown at it by LLMs.

When interviewing remotely, we may have previously been concerned about candidates using a search engine to look up answers, but now we have to consider that they might be side-channeling all of the questions to an LLM.

If you are an interviewer, how can you tell that off to the side of the Google Meet window is another browser window with a prompt open? By the time you have described the system design specification, the candidate could have easily typed it into the prompt and have gotten an incredibly detailed and plausible answer back.

And hey, don't just take my word for it, try it: open Grok and type "I am doing a system design interview. Help me with it. I have to design Instagram from scratch. Give me back of the envelope calculations and follow the structure of the ByteByteGo book."

Scary, huh?

If your candidates are good at placing their windows on the screen in the right places and keeping their eye movement under control, you might not even notice that they are doing it. How are we meant to get good signal from candidates now that we can't figure out if we're talking to them or a prompt?

If you want to test a candidate completely without LLM assistance, you could ask them to share their entire screen so you can see what is going on. However, this feels invasive. Alternatively, a lighter touch version is to have the interviewer share their screen and problems are tackled together via pair programming and high bandwidth conversation where it would be hard for the candidate to be typing away into a prompt and then trying to pass off the answer as their own.

Alternatively, you could go in the complete opposite direction: accept that LLMs are now part of the job, and like the rest of the article, embrace them.

For example, if you want to hire people that can tackle large and ambiguous problems quickly with LLMs, get them to demonstrate these skills in the interview. This is similar to exams at school that are open book: you can use whatever resources you want, but you have to demonstrate that you know how to use them and that you can think critically about the answers that they give you.

The choice is yours as an interviewer: either allow LLMs or don't, but be explicit about it ahead of the interview so that the candidate knows what to expect. If you do allow LLMs, you should also be clear about the rules of conduct in the interview: are they allowed to use them for everything? Are they allowed to use them for some things? What are the boundaries? Don't make them guess.

Regardless of which way you go, you'll need to adapt your interview process to ensure that you are getting the right signal.

• Having candidates seek solutions to leetcode problems is not going to work. LLMs can easily dump code for doubly linked lists and binary trees, and annotate the answers with all of the big-O complexities attached.

• Instead, questions that you ask should be sufficiently ambiguous that part of the interview is figuring out the specific requirements of the problem and what the code or system should do. Doing this in a conversational manner is a great way to see how the candidate thinks, and if you've not allowed LLMs to be used, it should be obvious through long periods of silence if they're trying to bend the rules.

• Spot-test their knowledge: the interviewer should be able to interrogate components of the candidate's solution as they go along, asking questions about the design and implementation that highlight whether the candidate actually has knowledge here, or at least is able to think about their solution critically and from first principles. For example, if they think a cache should be implemented, ask them why, and what the tradeoffs are. Ask for some examples of caches they have used before and how they worked. Pick a point in the solution and go fully down the rabbit hole with them. Think latency, throughput, and failure modes. Answers should be fairly instantaneous if they know their stuff.

• If candidates come to a solution quickly, see if there are alternative ways in which they could have approached the problem. For experienced engineers, it should be possible to have a conversation about the tradeoffs of different approaches to the one they have taken. If they've used a batch processing system, ask about how a streaming system could look. If they've written code that is synchronous, ask them how they would make it asynchronous, and so on. Probe deeper.

• Use methods of collaboration that LLMs are not good at. For example, a shared whiteboard is a great way to think about problems together, interactively, proving that you are really working together with the candidate in the same way that you would if they were a new hire.

Design your interview process to find the kinds of candidates that you really want to work with. If you're looking for people that are great at using LLMs, then have your interview process find these people. Be open about it.

If instead you value candidates that are great at coding or design solutions unassisted despite the tools we all now have available, that's also fine, but be open about that too. Let them know way ahead of time that this is how it's going to be. You can't have it both ways, and you need to design your process accordingly to get the right signal.

And that's a wrap

If you haven't already, you need to start bringing your team(s) into the present day. Software development isn't just changing, it has changed, and if you haven't been adapting already, you're getting left behind. This isn't just important for your company, but it's also incredibly important for your employees: you owe them access to the best tools available to do their jobs.

Happy prompting.