The Engineering Manager

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.

This month, we’re going to think about our teams, departments, and organisations as systems. Specifically, we’re going to consider how we can increase throughput and output by identifying and removing the biggest bottleneck at any given time.

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 reachouts 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.