One Problem a Week

Marc Andreessen was asked on a podcast how one person runs five companies at once. His answer had nothing to do with hours or genius. It was a loop. Every week, at each company, Musk finds the single biggest problem that company has that week, fixes it, and then does that for 52 weeks in a row. Andreessen's follow-up was the sharper part: he thinks the single biggest question in business right now is why more CEOs don't operate that way, and his answer is that most of them spend months in meetings, presentations, and reviews before they get anywhere near the problem.

You can argue about the man. Plenty of people do, and some of the arguments are good. I want to set him aside and keep the loop, because the loop is the only leadership practice I know of that gets stronger, not weaker, as AI takes over the rest of the job.

The short version

Every organization has one constraint at a time, and only work on that constraint moves the system. Goldratt wrote that down forty years ago, and AI made it brutal, because improving everything other than the constraint is now nearly free. So the one decision that still moves a business is which problem gets this week, and most leaders don't make it. They inherit a roadmap that made it a year ago, run a status meeting that reports forty problems and picks none, and delegate the hard one into a layer of the org where nobody is senior enough to kill it. The loop is four moves: name the constraint in one sentence as a problem rather than a theme, put one owner on it, decide what Friday has to prove, and repeat, because the constraint moves the moment you fix it. It isn't a CEO practice. It runs at every level, and it's the half of leadership agents can't do: they're good at surfacing problems and no good at choosing one. SpaceX's version is to blow up rockets on purpose and learn from what breaks, and that only works because the failure was designed to be survivable, which is why downside exposure gets ranked before speed.

The constraint moves, and that is the method

Goldratt's rule is simple and almost nobody runs an org by it. A system has one bottleneck. Speed up anything that isn't the bottleneck and throughput doesn't change; you just stack inventory in front of the step that is still slow. Fix the bottleneck and a new one appears somewhere else, because the system has rebalanced around the improvement.

Most leaders treat that second sentence as bad news. It's the whole point. A constraint that moves is a system that got better, and the job is to go find where it moved to. A leader who fixed the onboarding funnel in March and is still talking about onboarding in September has stopped running the loop and started running a project.

I wrote two weeks ago about an org where nobody was reading anything, where management had correctly noticed that pushing code was no longer the bottleneck and then never asked where the bottleneck went. That's what a stalled loop looks like from the inside. They found the constraint once, in 2024, and they're still optimizing it.

Why AI makes this the only decision left

Here's what changed. Under the old cost structure, improving the non-constraint was expensive, so an org couldn't afford to do much of it. Scarcity did the prioritizing. Now generation is close to free. Your teams can produce specs, code, tests, dashboards, plans, and reports at a rate nobody can read, and every one of those artifacts feels like progress.

So the system can now pile inventory in front of the constraint at a speed Goldratt never imagined. That's the modern failure: not an org that does too little, an org that does an enormous amount of everything except the one thing.

Which leaves exactly one decision that still moves the business. Which problem gets this week. Everything downstream of that decision is getting cheaper by the quarter. The decision itself is not, because it requires knowing what the business is, what it can survive, and which of the forty flagged problems is load-bearing. That's judgment. Outcome accountability at agent velocity comes down to the same thing: you can't steer by lagging outcomes when you ship ten times a week, so you steer by picking the constraint well and measuring direction.

How orgs hide from the problem

The pathology has a consistent shape, and I've run orgs that had it.

They rename it. The problem becomes a "challenge," then an "opportunity area," then a "theme." Each rename moves it further from a sentence anyone could be accountable for. "Onboarding" is a theme. "Customers who import more than ten thousand records hit a timeout, and most of them never come back" is a problem, and the difference is that the second one has a Friday.

They abstract it. The problem gets a workstream, a steering committee, a quarterly OKR, and a slide. The status meeting is where this happens weekly: forty things reported, zero things chosen, everyone leaves informed and nothing moves.

They delegate it into oblivion. The hardest problem gets pushed down to the level where someone has the time to work on it, which is also the level where nobody has the authority to make the call it requires. Andreessen's description of Musk going straight to the engineer is the inverse of this: the leader goes to where the problem is instead of waiting for the problem to climb the org chart in a deck.

And underneath all three: the roadmap. I've argued the roadmap should die, and this is the deepest reason. A roadmap is a way of making the "which problem" decision once, a year ahead, so nobody has to make it this week. It's a pre-commitment to not noticing that the constraint moved.

The loop, in four moves

Name it. One sentence, as a problem, with a number in it if you can. If it takes a paragraph, you have a theme, and you're not done. The sentence is the hardest part and the part most leaders skip, which is why it's first.

Own it. One person, for one week. Not a committee that owns the quarter. The owner is whoever is closest to the problem and senior enough to make the call, and sometimes that's you, which is the uncomfortable half of Andreessen's story.

Decide what Friday proves. Not "progress." A number that moved, an experiment that returned an answer, a customer whose behavior changed. If you can't say what Friday proves, you don't know what you're fixing. The eval-is-the-spec discipline is this move applied to AI features: define done before you start.

Repeat. Monday, the constraint has moved. Go find it. Keep the record in a decision log, one line per week, so that in a year you can read the fifty-two sentences and see the shape of the company.

This is not a CEO practice

The reason I'm writing this for every leader and not for founders is that the loop is level-independent, and the org that benefits most is the one where it runs everywhere.

A product manager has a weekly constraint, and it's usually not on the roadmap. A forward deployed engineer sitting at a customer has one, and the whole FDE argument is about whether the product lets them fix it the same day. An engineering manager has a flaky pipeline that is quietly taxing every release. A designer has one flow that nobody finishes. A sales leader has one stage where every deal stalls. A customer success lead has one account that will decide the quarter's churn number.

When every one of those people names their constraint on Monday, two things happen. Each team moves, because it's working on the thing that matters instead of the thing that's scheduled. And the constraints become visible up the org, because a leader reading six one-sentence problems from six teams can see which one is the company's. A leader reading six status decks cannot.

That's the real reason the loop beats the status meeting. It isn't faster. It's legible.

What AI changes, both directions

Two things, and they pull against each other.

First, finding candidate problems is now nearly free. A KPI watchdog flags the metric drop before anyone opens a dashboard. A direction dashboard shows which leading indicator bent this week. Feedback summarizers surface the complaint that showed up eleven times. The surfacing half of the loop, which used to be a leader's Monday morning, is a thing agents do overnight.

Second, and this is the trap: agents are no good at the choosing half. A system that flags forty anomalies and ranks them by statistical surprise has not told you which one is load-bearing. It has reproduced the status meeting with better graphics. The selection requires knowing what the business can survive, which customers matter, which numbers are vanity, and which failure would be irreversible. Nothing in the model knows that. Someone has to.

That's the shape of leadership that's left after AI takes the rest: not generating the options, choosing among them, and owning what Friday proves.

Blow up the rocket, but design the explosion

The SpaceX half of the Musk story matters here, and it's the part people get wrong.

After the April 2023 Starship test ended in what the company calls a rapid unscheduled disassembly, SpaceX's statement was that with a test like this, success comes from what we learn. That is the loop at maximum aggression: run it, let it fail, extract the constraint, repeat. It is also only sane because the failure was designed to be survivable. The rocket was unmanned, the range was cleared, the budget assumed a loss, and the test existed to find out what breaks. The explosion was an experiment with a known downside.

Most orgs that quote this philosophy skip that part. They move fast on the wrong class of problem. The loop needs a filter in front of it, and the filter is downside exposure: before you give a problem the week, ask what happens if the fix is wrong. A reversible bet can be run like a rocket test. An irreversible one, a pricing change, a data migration, a message to every customer under the company's name, gets the same loop with a different Friday: not "did it work" but "did we prove it won't hurt."

Fast is cheap on reversible bets and ruinous on the other kind, and the leader who can't tell them apart will eventually blow up something that wasn't a test.

Start this week

Write the sentence. Your single biggest constraint, one line, phrased as a problem with a number in it, with a name next to it and what Friday has to show.

If you can write it, give it the week and tell your team that's what the week is for. If you can't write it, that is the problem this week, and it's a bigger one than anything on the roadmap.

Sources: Theron Mohamed, "Elon Musk solves Tesla's and SpaceX's biggest problems in a week and repeats that 52 times a year, Marc Andreessen says," Business Insider (December 2024), reporting Andreessen's remarks on the Modern Wisdom podcast with Chris Williamson · Brendan Byrne, "SpaceX rocket explodes shortly after test flight takeoff in Texas," NPR (April 20, 2023), for the "success comes from what we learn" statement · Eliyahu Goldratt, The Goal (1984), for the theory of constraints.

Part of the running argument on Product Leadership: the operating model is the product decision most leaders never make on purpose, and the weekly constraint is the smallest version of it.

Related answer: What is the one-problem-a-week leadership loop?