Survivorship Bias in Tech

Hi,

Do you know what Survivorship Bias is?

[…] According to Survivorship Bias, the probabilities of success are systematically overestimated because successful individuals or states are more visible than unsuccessful ones. ~ Wikipedia

This cognitive bias is interesting because it affects us in development as well. For 15 years, I have been working mainly in small and medium-sized enterprises (SMEs), which are companies with up to 250 employees. Clearly, these are not large corporations.

And last week, I wrote about how the size of development teams in SMEs is very similar.

Whether the company has 20 or 250 employees, you will rarely find development teams with more than 20 developers. Compared to large corporations, these teams are small. For context, Netflix employs over 2,500 developers.

What does this have to do with Survivorship Bias?

We are just as influenced by successful stories in the tech sector.

At conferences, success stories are almost exclusively reported. And these conferences are sponsored by companies that can:

• Afford it
• And need to recruit so much that the promotion is worthwhile

So, large corporations.

And those who sponsor a conference also give talks and keynotes.

And if I, as a company, am putting thousands of euros into sponsoring a conference, then I want it to be worth it. So, I talk about my successes and how great everything I do is. I want everyone to apply to my company.

It’s logical, right? I would do the same. That’s the game.

But here, we are experiencing Survivorship Bias.

And I was guilty of being led by it.

Large corporations face completely different challenges than SMEs.

It would also be absurd to think that I could manage the same architecture with 20 developers as Netflix does with 2,500 developers. The developers in SMEs are certainly not 125 times better and faster than those at Netflix.

“But Marcus, that’s nonsense. I have a much smaller scope and therefore less effort. The architecture is secondary!”

Yes… and no.

Thought experiment: You’re building an ERP system specialized for the logistics industry. What do we need? First, the standard features: employees must be recorded, with personnel files, pictures, organizational charts, and whatever else is needed. Okay. Add some basics: finance, report generation, dashboards, etc.

Now, specifically for the logistics industry: I need to be tenant-capable. Deliveries should be monitored. So, I have to integrate the APIs of logistics companies, including international ones, given that we are export champions. Ah, most small logistics companies don’t have an API. So, an Excel import. And it must be dynamic. Now these deliveries need to be mapped to my orders. And I want to be informed about unexpected bottlenecks. Oh, and an order can be mapped to multiple deliveries….

I could go on like this for longer.

Now consider: We want to build a video-on-demand platform. Let’s call it Jetflix. What do we need? The ability to stream videos and series. A personalized catalog with recommendations. And a rating system. We also need an admin interface for adding new streams. Then a billing system. I can think of more things here too. But it doesn’t feel more demanding than the description above.

The difference: The first scenario is one of my clients, with 10 employees. The second was Netflix (Surprise!) with 2,500 developers. That’s a difference. But it’s not about the scope of the features. It’s about the non-functional requirements.

Survivorship Bias in SMEs leads us to adopt solutions not meant for us.

This has all sorts of negative consequences. This is what I mainly correct with my clients. Be aware of this bias! Choose the solutions that fit you!

Rule the Backend,

~ Marcus