How smart founders decide which fires to let burn

Executive overview

Fast-scaling companies generate more problems than any team can solve. Trying to fight every fire burns out founders and stalls growth.

The smarter approach is intelligent triage: assign probabilities to risks, fix only what can kill the business, and consciously defer the rest.

Core insight: Letting fires burn is not neglect — it is a deliberate growth strategy that keeps you focused on what actually matters.

The triage mindset

• All fires feel equal when you're inexperienced — only battle reps build perspective
• Assign a probability and a severity to each fire; multiply them to set priority
• Ask: is this correctable after it hits, or is it fatal and irreversible?
• "Fatal fires" — those that end the business completely — demand immediate action regardless of probability
• Lower-probability, correctable fires can wait; solve them in a batch when you have capacity
• Chasing every fire means all reaction, no action — you miss the growth opportunities that require proactive building

When to ignore customer service

• PayPal grew exponentially with a three-person customer service team, accumulating 10,000 unanswered emails per month
• The team turned off desk-phone ringers and switched to cell phones rather than slow down product development
• Rationale: serving future customers at scale matters more than fully serving current customers today
• Deferred service until positioned to solve it all at once — flew to Omaha and stood up a 200-person call centre
• Rule for scale companies: provide whatever service you can, as long as it does not slow you down

How to prioritise when fires stack up

• Brian Chesky's leverage approach: list everything, group by theme, find the three actions that resolve twenty problems as side effects
• The goal is fewer, bigger moves — not exhaustive task completion
• Triage leader principle: in a crisis, designate one person to own communication and keep the team calm
• Communication is the first thing to break down when something goes wrong — fix that before fixing the technical problem

The SurveyMonkey Chernobyl

• SurveyMonkey had no database backup when Selina joined as president — a server failure would have wiped the entire business
• Selina and the team treated it as a probabilistic problem: low daily probability, but catastrophic and non-correctable if it hit
• They fixed it quickly by adding a database copy, then built a long-term solution separately
• Framing worst-case scenarios as probability calculations converts paralysing fear into actionable engineering work

Letting ugliness burn deliberately

• SurveyMonkey's design was widely criticised as outdated; Selina chose not to fix it for years
• Reason: the product was easy to use and performant — beauty and usability are not the same thing
• Amazon's website is ugly by design; Bezos locked on convenience, price, and speed and refused to deviate
• A fire left burning long enough can merge with another — the design debt eventually hurt SurveyMonkey's recruiting
• Workaround: attend meetups, use personal networks, get people in the door so you can pitch them directly

Surviving viral growth without a plan

• Evite co-founders discovered their product's viral coefficient by accident — a tripped power cord and an angry caller
• iLike doubled its server count repeatedly over a single Memorial Day weekend, renting a U-Haul to physically rack machines in borrowed data centres
• Kuli Kuli said yes to a nationwide Whole Foods launch in January, starting in June, with no factory ready — gritty product, snowstorm, near-collapse
• The launch still quadrupled Kuli Kuli's store footprint; saying yes was still the right call
• Moving fast means accepting unforced errors as the price of seizing growth windows

Signalling calm while fires burn

• Teams read founders' reactions as a signal — panic spreads faster than smoke
• Selina learned patience through parenthood: snapping does not resolve the situation
• Triage leader practice from Ticketmaster: get everyone on a call, ensure full information sharing, keep tone measured
• Employees who stay focused on their work while a background blaze rages are the ones worth keeping
• Ugly, broken, or unfinished parts of a product filter for candidates who join because of the mission, not the aesthetics

Advice for faster learning

• Ship fast and get consumer feedback to a percentage of the audience — early data prevents fires rather than fighting them
• Hire for your weaknesses early; a great designer as a first hire covers a blind spot the founder cannot
• Experience compresses the panic response — veterans assign probabilities instinctively; junior founders treat all fires as equal emergencies
• Build a triage habit before you need it; under pressure, you default to whatever system you have practiced