Survivorship Bias in Tech
Find the English version below
Hi ,
Kennst du das Survivorship Bias?
[...] Nach dem Survivorship Bias werden Wahrscheinlichkeiten eines Erfolgs systematisch überschätzt, da erfolgreiche Personen oder Zustände stärker sichtbar sind als nicht erfolgreiche. ~ Wikipedia
Diese kognitive Verzerrung ist interessant, weil sie uns auch in der Entwicklung betreffen. Seit 15 Jahren arbeite ich hauptsächlich im Mittelstand. Das sind Unternehmen bis 250 Mitarbeiter. Also ganz klar keine Großunternehmen.
Und letzte Woche habe ich darüber geschrieben, dass die Größe der Entwicklungsteams im Mittelstand sehr ähnlich ist.
Egal, ob das Unternehmen 20 oder 250 Mitarbeiter groß ist, du wirst sehr selten Entwicklungsteams mit mehr als 20 Entwicklern finden. Im Vergleich zu Großunternehmen sind sie klein. Zum Vergleich: Netflix beschäftigt über 2.500 Entwickler.
Was hat das jetzt mit dem Survivorship Bias zu tun?
Wir lassen uns von den erfolgreichen Geschichten im Tech-Bereich genauso beeinflussen.
Auf Konferenzen wird fast ausschließlich von Erfolgen berichtet. Und diese Konferenzen werden durch Unternehmen gesponsert, die es sich:
- Leisten können
- Und so viel rekrutieren müssen, dass sich die Promotion lohnt
Also, Großunternehmen.
Und wer eine Konferenz sponsort, der hält auch Vorträge. Und Keynotes.
Und wenn ich als Unternehmen schon tausende Euro ins Sponsoring einer Konferenz stecke, dann soll sich das auch lohnen. Ich berichte also von meinen Erfolgen und wie toll ich alles mache. Alle sollen sich bei mir bewerben.
Ist doch logisch, oder? Ich würde es nicht anders machen. That's the game.
Aber wir erleben hier das Survivorship Bias.
Und ich war selbst schuldig, mich davon leiten zu lassen.
Die Großunternehmen haben nämlich vollkommen andere Herausforderungen als der Mittelstand.
Es wäre doch auch absurd, wenn ich die gleiche Architektur mit 20 Entwicklern stemmen könnte, wie Netflix mit 2.500 Entwicklern. Die Entwickler bei mir im Mittelstand sind mit Sicherheit nicht 125x besser und schneller als die Entwickler bei Netflix.
"Aber Marcus, so ein Quatsch. Ich habe doch einen viel geringeren Umfang und daher weniger Aufwand. Die Architektur ist da doch zweitrangig!"
Ja... und nein.
Gedankenexperiment: Du baust ein ERP-System. Es soll spezialisiert für die Logistikbranche sein. Was brauchen wir so? Erstmal den Standard einbauen: Meine Mitarbeiter müssen erfasst werden. Mit Personalakte. Und Bildern. Und Organigramm. Und was man da noch so haben will. Okay. Noch ein paar Basics dazu: Finanzen, Reportgenerierung, Dashboards etc.
Gut. Jetzt speziell auf die Logistikbranche: Ich muss tenantfähig sein. Lieferungen sollen überwacht werden. Also muss ich die API der Logistikunternehmen anbinden. Aber auch der internationalen. Schließlich sind wir Exportweltmeister. Ah, die meisten kleinen Logistikunternehmen haben keine API. Also ein Excelimport. Und der muss dynamisch sein. Jetzt müssen diese Lieferungen noch auf meine Aufträge gemappt werden. Und ich will natürlich bei unerwarteten Engpässen informiert werden. Ach, und ein Auftrag kann auf mehrere Lieferungen gemappt werden....
Ich könnte noch länger so weitermachen.
Und jetzt überlegen wir: Wir wollen eine Video-on-Demand-Plattform bauen. Nennen wir sie Jetflix. Was brauchen wir? Die Möglichkeit Videos und Serien zu streamen. Ein personalisierter Katalog mit Empfehlungen. Und ein Bewertungssystem. Wir brauchen auch eine Adminoberfläche, zum Einpflegen neuer Streams. Dann noch ein Abbuchungssystem. Mir fallen auch hier noch weitere Dinge ein. Aber es fühlt sich nicht aufwendiger an als die Beschreibung von oben.
Der Unterschied: Das erste Szenario ist einer meiner Kunden. Mit 10 Mitarbeitern. Das zweite war Netflix (Surprise!) mit 2.500 Entwicklern. Das ist ein Unterschied. Aber es liegt nicht am Umfang der Features. Es sind die nicht-funktionalen Anforderungen.
Das Survivorship Bias verführt uns im Mittelstand, Lösungen zu verwenden, die nicht für uns gedacht sind.
Das hat alle möglichen negativen Folgen. Das ist, was ich hauptsächlich bei meinen Kunden korrigiere. Sei dir dieser Verzerrung bewusst! Nimm die Lösungen, die zu dir passen!
Rule the Backend,
~ Marcus
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