March 23, 2019.
Of the early Stripe lore I've encountered, my favorite is that it managed to accomplish a tremendous amount with a small team because folks moved so rapidly from one project to another project that, leaving an afterimage behind them, it appeared that they were everywhere simultaneously.
In my head, this becomes a variant of the Heisenberg uncertainty principle: as long as you don't ask what the team was working on at a given moment, they truly are doing everything. But if you do ask, then suddenly they're frozen into a single task, surrounded by a sea of unstaffed projects.
The common advice is to do things that don't scale until you find product market fit. It's good advice–your biggest early risk is that no one will care about your creation–but the aftermath is often a strong case of fire fixation.
Fire fixation is the pattern of patching urgent problems as quickly as possible, and then immediately moving on to the next. It can be a remarkably rewarding period for teams, with folks feeling like they're doing some of their best work, but is also the defining characteristic of a team that is falling further and further behind.
You rarely get to this place by failing, rather it's almost always a sign that you're succeeding faster than you can sustain. However, if you're not careful, teams in the cycle of firefighting become the bottleneck on future growth. Worse, the reward loop of fighting fires is more immediate and more powerful than the reward loop of doing durably good work, and folks rapidly come to believe it's the correct way for a team to function.
Limiting work-in-progress doesn't work well when you have more existential fires than your team can manage simultaneously. They're also too hot to ignore, too numerous to mend, and forward motion grinds to a halt.
If you see a team fascinated by their fires, take a moment to be proud of their urgent work, but then take immediate steps to dig them out. It only gets harder the longer you wait.