Work the problem: how to solve, lead, and know when to ask for help

On 14 April 1970, two days out from Earth, an oxygen tank on Apollo 13 ruptured. The spacecraft was venting, the crew was three days from home, and the room full of engineers responsible for getting them back had no procedure for the situation on the board. Flight director Gene Kranz stopped the noise with one instruction: "Let's work the problem, people. Let's not make things worse by guessing."

That line is not a poster. It is an operating rule, and it has two halves that only work together. Work the problem — actively, with method. And do not guess, because guessing in a crisis does not just fail, it adds new failures to the ones you already have. NASA's own Apollo 13 record↗ (opens in a new tab) is worth reading for how boring the recovery actually was: known values, checklists, one owner per decision, hours of verification.

You are not flying a spacecraft. You are also not exempt. Your livelihood runs on a series of decisions you make with incomplete information — when to release, what to spend, who to work with, when to stop mixing. So the question is worth asking plainly: are you working the problem, or are you guessing and calling it instinct?

What guessing actually looks like

Guessing is not stupidity. It is deciding without pulling the known values first, and it feels almost identical to momentum. In practice it looks like this:

• Picking a release date because it "feels right", with no idea how much lead time your distributor, pre-save links and playlist pitches actually need.
• Setting a budget from hope rather than from what the last three projects cost you.
• Announcing a deadline with no chain of smaller deadlines behind it, so the whole thing collapses onto the last week.
• Re-mixing a track for the fourth time because you are uncertain, not because you have identified a specific problem.
• Assuming a collaborator knows the scope, the date, and the deliverable because you mentioned it once.

Each of those feels like action. Each of them is a decision made on unstated assumptions, which means when it fails you cannot tell which part failed. That is the real cost of guessing: not the wrong answer, but the loss of any way to learn from it.

The method

Working the problem is a sequence, and the sequence is unglamorous on purpose.

1. State the problem in one sentence. If you cannot, you do not have a problem, you have a mood. "My rollout is a mess" is a mood. "I need a release date that gives me four weeks of pitching and lands before the label's Q4 blackout" is a problem.

2. Separate what you know from what you assume. Two columns, written down. Known: your distributor's delivery window, your mastering turnaround, the money in the account. Assumed: that the artwork will be done in a week, that the feature will clear, that the playlist editor will answer. Everything in the assumed column is a risk with a date attached.

3. Convert your biggest assumptions into known values. One email, one phone call, one look at last year's numbers usually does it. This step is where most people skip straight to a decision, and it is the step that pays.

4. List real options against real constraints. Not "release in October or November" but what each date actually costs you in pitching time, budget and attention.

5. Pick, and write down why. The reason matters more than the choice, because the reason is what you check later.

6. Verify against the result, not your intent. Did the thing you predicted happen? Not "was it a good idea?" — did the number move?

Run that on one decision this week and you will notice how much of what you normally call strategy was actually column two.

Leading yourself

Before you lead anyone else, you are the flight director of your own operation, and that role has specific duties.

Own the call. Someone has to decide. Deferring a decision is a decision, usually a worse one, made later with less time.

Work from status, not mood. Mission control ran on status reports: what is the actual state of this system right now? You need the same on yourself — what is finished, what is blocked, what has a date. Your feelings about the project are data about you, not about the project.

Report your real numbers, including to yourself. The streams you actually got. The money you actually have. The number of tracks that are actually finished versus nearly finished. "Nearly finished" is the most expensive phrase in creative work.

Separate the crisis from the schedule. Kranz's room worked because it triaged: what will kill us in the next hour, what can wait. Most of what feels urgent to a creator is a schedule item wearing a costume.

Leading others

The moment a second person is involved — engineer, manager, collaborator, designer, the artist you are featuring — your job changes from doing to specifying.

One owner per decision. Two people who both think they might be handling the artwork is the same as nobody handling it. Say the name out loud.

Give scope, date, and deliverable together. "Can you mix this?" is not a request. "Can you mix these four tracks, stems delivered Friday, back to me by the 14th, reference track attached" is.

Do not guess on someone else's behalf. If you do not know whether your distributor needs 21 or 28 days, ask them. Assuming for another party is how you end up missing a date you never actually confirmed.

Say what "done" means. Done is a definition, not a feeling. Write it into the message.

Close the loop out loud. Confirm receipt, confirm the date, confirm the change. Mission control repeated everything back for a reason.

Knowing when to follow, and when to ask

The part of Kranz's room people miss: it was full of people who led their own station and deferred instantly outside of it. The guidance officer did not have opinions about the electrical system. That is not weakness, it is how the room stayed fast.

You are outside your station when:

• You are guessing repeatedly on the same question. One guess is a gap. Three guesses on the same topic is a skill you do not have.
• The decision has been stalled for more than a few days. Stalling is almost always missing information, not missing willpower.
• The cost of being wrong is higher than the cost of asking. A wrong master costs you a re-run. A wrong split sheet costs you years.
• Money, contracts, or rights are involved. This is the category where guessing does permanent damage. If it involves publishing, ownership, or a signature, go find the person who does that for a living — and learn the vocabulary first so the conversation is short.

Asking early is a technique, not a concession. The people who look effortless are usually just the people who ask at hour one instead of week six.

Following well is its own skill, too. When you have handed a decision to someone better qualified, let them make it. Hiring an expert and then overruling them on instinct is the most expensive kind of guessing, because you paid for the known values and then ignored them.

Self-awareness, not self-loathing

There is a version of self-knowledge that is just quiet contempt, and it is useless. It produces no decisions. The useful version is an inventory — flat, specific, unemotional, written down.

Make three lists:

• What I am genuinely slow at. Not bad at — slow at. Slow is a scheduling fact, and scheduling facts can be planned around.
• What I avoid. Whatever you keep not doing is where your projects will die. Admin, follow-up emails, metadata, asking for money. Avoidance is a reliable signal, and it is usually about discomfort rather than difficulty.
• What I have never actually learned. Not "should know" — never learned. There is no shame in the list; there is only cost in pretending it is empty.

Then convert each line into a mechanism, because a weakness you have named and left alone is still a weakness:

The honest line	What it converts into
I am slow at mixing	Twice the time in the schedule, or an engineer
I avoid admin	A weekly 30-minute block with a checklist, not willpower
I forget metadata	A template you fill on delivery day, every time
I never learned contracts	A named person you call before signing anything
I lose track of assets	One folder structure and one file that lists where everything is

That is the whole trick. Self-awareness turns into strength only at the moment it becomes a system — a longer timeline, a delegation, a checklist, a template. Until then it is just accurate commentary on your own failures, and accurate commentary has never shipped a record.

The people who scale are not the ones with fewer weaknesses. They are the ones whose weaknesses are known, documented, and covered by something that does not depend on how they feel on a given Tuesday.

The goal is not to be right

Here is the part that separates working the problem from arguing about it.

In a room working a real problem, nobody gets credit for having been right early. The scoreboard is the outcome — the crew comes home, the record ships, the business survives. If your first call was wrong and someone else's call was correct, the correct call wins and you move on inside the same minute. Ego is a variable to remove from the equation, not a position to defend.

That has practical consequences for how you operate:

• Argue about the problem, not the person. "That date doesn't leave pitching time" is a problem. "You always rush this" is a fight.
• Reverse yourself when the data changes. Changing your mind with new information is the skill. Refusing to is just a slower way of being wrong in public.
• Kill your own idea first. If you can articulate the strongest case against your plan, you either fix it or you drop it early, and both outcomes are cheap.
• Ask "what result do we need?" before "what do I think?" Almost every stuck creative decision is two people optimising for different unstated goals.
• Separate the decision from the identity. You are not your release date. You are not your mix. Those are attempts, and attempts are supposed to be revised.

The mission is the point. Your record, your business, your name on something that works. Being personally correct along the way is a nice side effect and nothing more.

Tools that remove the guessing

None of this survives contact with a busy month unless it lives somewhere outside your head. Three things do most of the work:

Backward-planned dates in a calendar. Start at the release date and walk backwards: distribution delivery, mastering, artwork, pitching window, announcement. If you have never done this, you will find out immediately that your usual timeline was a guess. We wrote the long version of this in how to build a music release calendar that actually works.

A written release checklist. The same list every time, so the fifth release does not lose the lessons of the fourth. Metadata, splits, ISRCs, credits, assets, links.

One source of truth for files and information. One place where the current master, the current artwork, and the current metadata live. Two places means neither is correct.

You can run all of that in a calendar and a text file, and plenty of people do. If you would rather use something built for the job, Sampledex makes two free macOS tools that came out of exactly this problem:

• Sampledex Release OS↗ (opens in a new tab) — a release planner for rollouts, deadlines and delivery dates. It exists because backward-planning a rollout on paper works right up until you have three of them overlapping.
• Sampledex Producer Notes↗ (opens in a new tab) — notes built around sessions, references and takes, so the decisions you made in a session are still legible three weeks later.

Both are free on the Mac App Store, and both started as internal tools before anyone else asked for them.

Your next twenty minutes

Not a plan. Three actions, today:

1. Write your current biggest problem in one sentence. If it takes more than one, it is more than one problem — split it.
2. Make the two columns. What you know, what you are assuming. Then send the one message that converts your largest assumption into a fact.
3. Put one real date on a calendar and work backwards from it until every step has a day.

That is working the problem. It is not inspiring and it does not need to be. It just means that when something breaks — and it will — you will be looking at known values instead of guessing with your livelihood on the table.

---

Disclosure: the owner of Sampledex runs this blog. The tools mentioned above are our own, they are free, and the method in this piece works with or without them.