The Engineering Manager

This month, we’re going to explore what might be the most counterintuitive practice in the age of AI: knowing when to slow down.

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.

This month, we’re going to explore one of the most powerful forcing functions available to leaders: the single prioritized list.

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.