Product Management, Software Development

Bonfire of the Best Practices

As we get stuck into 2024 I am wondering how many of the product and engineering best practices that we’ve seen develop over the past 10-15 years will turn out to be ZIRPs (“zero interest rate phenomenon”).

Probably quite a few. Two reasons I can see:

First reason is pretty obvious. When money was cheap the objective was to raise as much investment as possible and use that money to build an aggressive roadmap fast. When time is of the essence and cost isn’t a big deal, the first reaction of most managers is going to be to hire people to do more stuff. Not surprising that many companies over-hired – e.g. see https://qz.com/from-overhiring-to-optionality-what-we-can-learn-from-1850267076 and https://stripe.com/gb/newsroom/news/ceo-patrick-collisons-email-to-stripe-employees

Burning loads of VC cash to hire loads of people to build more stuff brings its own set of challenges. The processes and best practices that evolve will work well with these sorts of challenges.  When there is less investment money floating around you need to be leaner and more intentional in where you spend your time. The processes that work best in a leaner environment won’t necessarily be the same as those that worked in the sorts of VC-backed outfits we’ve seen over the last decade.

It’s a common trope that you shouldn’t just pick a process that worked in a company whose brand you admire and expect it to work in your company. What I’m saying here is a bit stronger than that. I’m saying that any product or engineering advice coming out of the VC-backed cash-burning-machine era might need to be chucked in the bin in these leaner times.

It’s not just that a bigger company’s processes might not work for where your company is right now. The sorts of processes that worked in a ZIRP era business model might just not make sense in a leaner era.

Here comes the second reason that makes it even more important for you to question ZIRP-era process advice.

As a company gets bigger, the people who have the time and inclination to write about processes get further and further removed from the reality on the ground. Even in @simfoni it’s difficult for me to know what an individual product iteration really involves for the people doing the work. If you’re reading a blog post by a tech leader of a company with 200  or 1,000 engineers, how confident should you be that the blog reflects reality? Or does it reflect what the writer thinks is happening, or how they would like things to be happening?

A great example of this is the Spotify Model. The Spotify model is (was?) an organizational structure that inspired a lot of imitators until it turned out that even Spotify didn’t use the Spotify model: https://www.agility11.com/blog/2020/6/22/spotify-doesnt-use-the-spotify-model  It was as much a leadership aspiration as it was a statement of reality.

To sum up, I see 2 things combining here:

  1. Processes developed in ZIRP-era VC-backed company might fundamentally not work in leaner times
  2. The processes as described in blog posts and analyst reports maybe never even existed in real life

So a 2024 resolution for myself, and a call to arms for anyone reading is to “question all the blog posts”. Even more than you normally would.

Except for this one, of course. This one is bang on the money 😀