The End of Priority.

I want to retire a word.

The word is priority, and it has cost me more than any line item on any budget I have ever signed. It has cost me SevenRooms — a project we have been “prioritizing” for over a year. It has cost me Inventory. It has cost me Costume. It has cost me every system I have ever asked a good developer to build for me, because every time I asked what was next, the answer came back the same way: “we have to finish the priority first.”

And so nothing finishes. The priority moves. A new fire arrives. The old work is shelved with the best of intentions and the worst of outcomes, which is that it is never shelved back onto the same shelf. It drifts. A year later I am still writing the same email about the same feature that was supposed to ship last quarter, and everyone in the room can feel it, and no one knows how to say it, so we agree on a new priority and go home.

I am done doing that.

I — The team that lost had the best player

Argentina got the ball to Messi. They managed two shots.

Before I explain myself, I want to describe a football match, because it says the thing I have been failing to say for years.

On the nineteenth of July, Argentina played Spain in the World Cup final at MetLife Stadium. Argentina had Messi — eight goals in that tournament already, the best player of his generation. Their plan was the sensible plan, the one any competent manager would write down: identify the most important thing on the field, and get it the ball.

Argentina finished the match with two shots. Neither on target. Spain had twenty, twelve on target, sixty-five per cent of the ball, and no cards at all against Argentina’s seven yellows and a red. Spain won 1–0 in extra time.

Then look at who the tournament actually rewarded. Best player: Rodri, a holding midfielder — a man whose job is to win the ball back and give it to somebody else. Best goalkeeper: Spain’s. Best young player: a nineteen-year-old centre-back, chosen ahead of his own teammate Lamine Yamal, the winger the world had bought tickets to watch.

And the detail I cannot get out of my head: Rodri was substituted off at ninety-nine minutes. The best player at the World Cup was not on the pitch when the goal went in. It arrived at a hundred and six minutes from Ferran Torres, a substitute who had come on at sixty-two.

Argentina had a plan for ninety minutes. Spain had a squad for a hundred and twenty. Nobody in a white shirt was waiting to be told who the priority was.

And here is the part I have to own before I ask you for anything. I have never wanted one thing at a time — but every time somebody asked me “what is the priority?”, I answered. I thought I was being reasonable. I was being weak, and I was asking you to be Argentina.

I am not going to answer that question again. I would rather find you the help than rank the work.

I did not know that is what I was doing. I thought asking for one thing at a time was discipline, and that a man who asks for everything is a dreamer who does not understand constraints. I had it backwards, and I am the one who should have caught it, not you.

II — Why the word fails

The word is a lie in 2026.

Priority is a word that made sense when a company had one architect, one line of production, one shipment leaving on Friday. In that world, prioritization was the entire job of management, because resources were physically scarce and sequence was destiny.

We do not live in that world anymore. I can open ten Perplexity Computer sessions right now, on this laptop, and each one will run in parallel, and each one will produce work while I sleep. I can spin up a droplet in ninety seconds. I can generate a specification, write test cases, ship code to staging, and get feedback from an AI reviewer in the time it used to take to schedule a meeting about whether we should schedule a meeting. The cost of a line of code is approaching zero. The cost of a decision is approaching zero. The cost of a rendering, a mockup, a database migration, a landing page — approaching zero.

What has not changed is the cost of management attention. That is still finite. That is still the whole game. And every time we hide behind the word “priority,” we are pretending that management attention is scarcer than it actually is, so that we do not have to admit the real bottleneck: we have not yet learned how to run more than one thing at a time.

Elon Musk is not building rockets and data centers and cars and satellites and neural implants in sequence. He is not saying to his teams, “let’s finish SpaceX first, then we’ll do Tesla.” That would be absurd. He built the operating system that lets ten teams execute in parallel, with clear deliverables, clear lead times, and a plan for every blocker before the blocker arrives. That is not priority management. That is throughput management. That is what modern leadership actually looks like.

If he ran his companies the way we have been running ours, he would still be assembling the first Falcon 1 rocket, and no one would have heard of him.

III — What replaces it

The three questions that replace it.

Starting now, in every conversation I have with a developer, a vendor, a manager, or a partner, I will ask three questions, and only three questions.

1. What is the deliverable?

Not the vision. Not the “phase one.” The actual thing that will exist in the world when this is done. A working screen. A tested endpoint. A trained staff member using it in production.

2. What is the lead time?

Not “as soon as possible.” Not “next sprint.” A date. If you cannot give me a date, the first deliverable is the discovery work required to give me a date.

3. What are the blockers, and what is the plan?

Every real project has blockers. Data we do not have. Decisions I have not made. A vendor who has not replied. That is fine. That is expected. What is not fine is treating a blocker as a stop sign instead of a puzzle. I want to hear: “Here is the blocker. Here are three ways to remove it. Here is the one we recommend. Here is the decision we need from you to proceed.”

And before you ask: no, this does not mean everything gets built

There is a fair objection to all of this, and I would rather answer it here than have you sit on it. If nothing is a priority, does every idea anybody has now become a project? No. But the answer is not a ranking — it is a direction.

We do not rank the work; we filter it, and then we run everything that survives. The difference is not cosmetic. A ranking is a queue, a queue always has a bottom, and the bottom never ships — which is the entire history of SevenRooms. A filter has no bottom. Everything inside it is live.

And notice that the test is about direction rather than importance. Musk is not drilling a hole toward the centre of the earth. He would burn up, and it would not matter how well he had planned it or how hard his team worked. Effort in the wrong direction is not a lower priority; it is not work at all. So when you bring me something, I am not going to ask how important it is. I am going to ask which way it points.

Notice what is not on that list

Cost is not on that list, because I have the budget. If I have brought a project to you, the money is decided. I do not want to hear a proposal that leads with cost. I want to hear a proposal that leads with a plan, and if that plan needs money, I will approve it.

Priority is not on that list, because I want all of it. I have twenty-four projects moving at once and I do not have the luxury of picking one. Neither do you. Neither does anyone building anything real anymore. The question is never “which one first” — the question is always “how do we structure the work so that all of them move forward at once.”

“One step at a time” is not on that list, because it is a phrase I never want to hear from anyone I work with again — not from my Thai staff, not from my sales floor, not from a developer I have paid for a decade. Steps are for stairs. We are not climbing stairs. We are running a company.

IV — Working with me

What this means for a developer working with me.

You are not being asked to pick between projects. You are being asked to figure out how to run them all.

That does not mean you personally write ten features at once. It means you tell me: “For this month, I will lead A myself, farm B out to a contractor, use AI to draft C, defer D until E ships because they share a dependency, and here is the calendar that ties them together.” That is a plan. That is what I am paying for. If you do not have contractors, tell me and I will help you find them. If you do not have AI tooling, tell me and I will pay for it. If you do not have a project manager, tell me and we will hire one this week. But do not tell me you can only do one thing at a time. In 2026, that is not a resource problem. That is an imagination problem.

Delivering the code is not the finish line either. A feature that ships to a repo and never gets adopted by the club is a feature that does not exist. Your job includes the plan to get it into staff hands — training, rollout, feedback loop, iteration. Some of that is outside your control, and that is fair, and I will help you with the parts you cannot own. But the plan is yours. The default answer is not “we finished the code, now it is someone else’s problem.” The default answer is: “Here is how it gets used, here is who owns the rollout, here is when I check in on adoption, here is what I do if adoption stalls.”

V — What you get from me

The commitment I am making back.

I am not asking for anything I am not putting on the table myself.

I will give you clear direction, and I will give it fast. If you ask me a question, you will get an answer the same day — because I use AI to help me answer, and so should you. There is no more excuse for a week of silence waiting for the boss to “think about it.” I can think about it in real time, with better tools than we have ever had, and so can you.

I will not ambush you with new priorities on Friday afternoon. Instead, we will keep a running list of everything active, and we will look at it together, and we will decide together where each project is on its lead-time clock and what its next blocker is. You will always know where you stand. There will be no surprises about what matters, because everything matters — the only question is what state each one is in.

I will approve budgets before I ask for outcomes. If a project needs a tool, a subscription, a contractor, or a piece of infrastructure, tell me at the start and I will approve it before you begin. I will not use budget refusal as a hidden way of prioritizing. If I decide a project is not worth doing, I will kill it out loud, in writing, so no one wastes another hour on it.

VI — Why I am in a hurry

I am not going to run this company forever.

I owe you the real reason, because without it this reads like a management theory I picked up somewhere, and it is not.

I am not a young man. I have a certain number of good working years left to do this in. I know roughly what that number is, and it is not large enough to do things one at a time.

A priority list is a written promise that something will still be unfinished on the day I hand this over.

That is what a list is, if you are honest about it. It ranks what gets done, which means it also ranks what does not, and the bottom of it is a quiet description of what I have decided to leave undone. I have sat in other men’s offices and listened to them explain the second half of their list. I am not going to be one of them.

What I intend to hand over is finished. Not perfect — finished. Systems that work and are documented, so the next person does not have to reverse-engineer a decade of our decisions the way we are currently reverse-engineering the payroll crons. More than one way for this company to earn. People who own their zones and do not need to ask me what matters most.

You have built with me for a long time, and a great deal of what I am describing lives in code you wrote. Which is why I am telling you this directly rather than letting you infer it from my impatience: when I push for all of it at once, that is not me being unreasonable about scope. It is me being realistic about time.

VII — Where this starts

The next six months, and the first project under the new rules.

This is not a memo about culture in the abstract. This is the operating agreement for the way I will work with the software team for the rest of 2026 and into 2027, and it starts with a specific project.

The PIMP Foundation Modernization project runs under these rules. No conversations about which thread is the priority. No conversations about what to finish first. Thirteen threads of workflow archaeology, a synthesis document, a modernization plan, and a Jira triage — all of them move in parallel, with clear deliverables per thread, clear lead times per thread, and a documented blocker plan for each. When a thread is blocked, we do not stop; we surface the blocker, propose the plan, decide together, and keep going. When a thread ships, we push it to GitHub, we update the ledger, we move on. There is no “we’ll get to that after PIMP” — because PIMP is not the priority. PIMP is one of many, and the reason it will finish is not because we sacrificed the others to it, but because we finally learned how to run all of them at once.

SevenRooms will finish, too. So will Inventory. So will Costume. Not because we finally got around to them. Because we finally admitted that the reason they never finished was not that we had bigger things to do — it was that we let the word “priority” excuse us from ever building the machine that could do all of it together.

Everything else — the deliverable, the lead time, the blocker plan, the budget, the adoption strategy, the parallel execution — is downstream of that one shift. Once you accept that framing, every conversation gets shorter. Every project moves faster. Every developer who has been waiting for permission to be ambitious gets it, in writing, from me, right now.

I am not going to work the old way anymore. I do not think you should either.

Let’s build.