Financial (counsellors|advisors|gurus) suggest everyone keep an emergency fund of (3|6|12) months of (living expenses|income) in cash.

The objections then flood in, “That’s a lot of cash! If I leave keep that as cash, I’m not earning much of a return!” This response, while accurate, misses the point of an emergency fund. You don’t have one to earn massive returns.

It gives you flexibility.

Tires blow out? You have cash to deal with it rather than turning to debt. Did you get laid off? You now have patience to find another role rather than jumping at the first thing that comes along. Family member suddenly hit with expensive medical bills? You can contribute.

Reserving capacity in your teams and optimizing for Flow do the same thing in your software development efforts that an emergency fund does in your financial planning.

If you’re looking at outdated unit economics, you would, of course, have your developers cranking out code every single moment of every day. And you’ll get lots of code doing that.

But what happens when a critical bug is found in production? Who is available to respond? How disruptive is the response?

When you have pull requests piling up and your developers forget all the context that went into those pull requests by the time someone finally reviews it, what happens to quality and frustration levels among your team?

When you discover a new market opportunity, but your teams are all tapped out to the max, how do you make use of your new knowledge without coming through like a bull in a china shop?

Almost everything I write here will seem absurd if you’re looking at it through a lens of unit economics. I had a coworker a year ago or so literally call me “insane” (and not in a joking way) because he could only see through that lens.

A focus on unit economics will absolutely keep your people fully utilized.

But it won’t deliver value to your customers, which is where your revenue comes from.