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
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.