Love to lose

I've been recently reading Chaos Kings: How Wall Street Traders Make Billions in the New Age of Crisis by Scott Patterson. The book tells the story of the mightiest Black Swans catchers, Nassim Taleb and Mark Spitznagel, and the hedge fund Universa, and previous Empirica.

Of course, as most people who know me know, I'm well acquainted with Nassim Taleb's Spitznagel's ideas. I've read their books multiple times but also listened to their interviews and speeches again and again during my (long) walks.

But reading Chaos Kings, something that crossed my mind was the old trader adage, "Take your losses and let your profits ride".

Mark talks about how he learned from Everett Klipp, the philosophy of loving to lose and hating to win. If a position starts to lose money, sell immediately. Panic early and cut your losses immediately, because if your position keeps falling, you can be wiped out.

In other words, don't try to be a hero.

This resonated a lot with me because, somehow, this is how I, as a developer, as a product manager, handle and take risks with projects, and it's a philosophy I try to share all the time with my team.

I, as a software developer, write code for information systems and software products. I don't write complex algorithms, I don't like to wrestle with hard things. What I love is to build something that works, even though it isn't perfect, and ship it.

When I am writing software (or designing a feature) and I encounter a blocking problem, which happens a lot when you are adding new features to an existing product, you usually have two choices:

Solving the blocking problem, which means still going for the solution that was previously thought for the previously defined problem.

Or working around the blocking problems, which means accepting that this is too hard, this is something that we didn't think about, let's redefine the solution previously thought, and even more, can we redefine the problem.

One path, solving the hard problem, is going for the win.

The other, working around it, not trying to solve hard things, is taking your losses.

The problem in software development (and probably managing projects) is that the block, the uncertain event, might put the whole project at risk. Projects are wagged by the tail; they are from what Nassim named Extremistan, an uncertainty that wasn't thought before might have a huge impact and incur a lot of overrun.

Yes, sometimes a hero, a mythical 10x developer, can go forward and save the project with all-nighters. But keeping this mentality, is about time, in the long run, a project will definitely blow up and might put the whole organization at risk.

Taking your losses, on the other side, will ensure that at least you won't be overrun by the project cost or take more time than was bet.

Yes, there is a chance that the project won't be shipped as expected, as the solution had to be redefined, but most of the time the customer doesn't care as long as the new solution is better than the alternative they currently have.

As a coder, panic early can take multiple forms, asking for help from more senior people, looking for other solutions, presenting the trade-offs to the product manager and negotiating if the point in the specification or pitch that is causing the trouble is really needed.

Or, as a last option, accept that a very big unknown wasn't discovered before, and work on something else until the next cycle.

And above all, accept that loving to lose in the long run will help ship more projects without taking too much risk.

Remember: don't be a hero, love to lose. Panic early and take your losses; accept that the problem is too hard and work around it. Don't go for the win, hate to win.