Vom Startup zum Unicorn 5 🦄: Technologie skalieren

Joel Kaczmarek: Hallo Leute, mein Name ist Joel Kaczmarek, ich bin der Geschäftsführer von digital kompakt und du hast wieder eingeschaltet zu einer Folge, wo wir darüber sprechen, wie man eigentlich vom Startup zum Unicorn wird. Und zwar heute im fünften Abschnitt dieser Reihe sprechen wir darüber, wie man den Technologiebereich skaliert. Kleiner Disclaimer, wir sprechen über den Technologiebereich eher aus Business- und Investorensicht. Wenn du jetzt wirklich Deep Tech möchtest, gibt es vielleicht andere Inhalte, wie zum Beispiel den Alphalist-Podcast, der ist ein bisschen technischer, wir sind eher so ein bisschen business-technisch heute. Wir deklinieren wieder die Top 6 Skalierungsfehler durch und wie man sie vermeidet. Wenn ich sage wir, dann ist an meiner Seite zum einen wieder der liebe und geschätzte Florian Heinemann. Den kennt ihr als Marketing- und Venture-Koryphäe schlechthin. Und auch Martin Schilling darf nicht fehlen, der gerade veröffentlicht. Lieber Martin, herzlichen Glückwunsch, ein großartiges Buch geschrieben hat, nämlich genau über dieses Thema, wie man vom Startup zum Unicorn wird. Mit dem schönen Namen The Tech Builder's Guide to the Galaxy. Und er ist jetzt Partner bei Techstars. Glückwunsch zu deinem Buchrelease. Jetzt können die Leute auch endlich mal live bestellen. Also, Freunde der guten Unterhaltung, geht auf Amazon oder Thalia oder wo immer ihr Bücher bestellt und beschert dem Kollegen mal ein bisschen Umsatz. Das hat er sich redlich verdient, weil er sehr viel Energie und tolle Inhalte in dieses Buch gesteckt hat. Und heute reden wir, wie gesagt, über Technologie. Florian, ist eigentlich Tech so dein Part auch bei Project A, wenn du mit Gründern zu tun hast? Oder wer ist da der Verantwortliche bei euch?

Florian Heinemann: Du meinst jetzt von der Betreuungsseite? Ja, wir haben ja ein technisches Team, also ein wirklich super CTO, der das macht. Und bei den technischeren Themen von der Partnerseite ist eigentlich eher Uwe Horstmann, weil der deutlich näher am Gerät ist als ich. Ich bin eher so für die Marketing, für die weicheren Themen.

Joel Kaczmarek: Und ich fand einen ganz schönen Impuls. Martin hatte angeregt, ob wir nicht mit so einer kleinen Case-Study starten wollen, nämlich mit der Knight Capital Group. Wer sich ein bisschen mit Börse beschäftigt, sehr visibles Thema. Martin, nimm uns doch mal mit unter die Haube, weil da kann man, glaube ich, so das Thema Tech-Skalierung sehr schön am offenen Herzen quasi nochmal nachsitzieren.

Martin Schilling: So ist es, Joel. Ja, also es war 2012 in einer verregneten Nacht, als ein junger Programmierer von Knight Capital die sogenannten Smart Servers geupdatet hat. Die Smart Servers waren damals zuständig für den automatisierten Kauf von Aktien an der New Yorker Börse. Dieser junge Kollege hat den Code in diesen acht Servern bei sieben richtig kopiert, aber hat einen vergessen. Knight Capital hat am Morgen darauf unbeabsichtigterweise 150 Aktien im Wert von 7 Milliarden US-Dollar gekauft, innerhalb von 45 Minuten, bevor der Fehler bemerkt wurde. Die Firma hat es dann noch versucht zu stornieren über die Trade Commission, die hat das abgelehnt und im Endeffekt wurde die Firma zu einem Bruchteil des Wertes wenige Monate nachverkauft. Die Firma hatte kein Vier-Augen-Prinzip im Technologiebereich, hatte keine automatisierten Tests, sie hatte Fehlermeldungen nicht sauber klassifiziert. Also ein typisches Beispiel, wo ein Technologiebereich über Jahre super funktionieren kann, ein Fehler und die Firma ist bankrott.

Joel Kaczmarek: Das muss man können. Also Florian kauft sieben Milliarden in Aktien eigentlich jede Woche, aber der nimmt sich halt ein bisschen mehr Zeit als 45 Minuten.

Florian Heinemann: Da ich das hier über eine traditionelle Bank mache, gibt es immer noch ein Vier-Augen-Prinzip. Nicht mit diesen modernen Neobrokern. Da ist das natürlich, ging das einfach so.

Joel Kaczmarek: Aber ich glaube, ich habe das hier auch schon mal im Podcast erzählt. Ich war ja früher mal für eine Firma tätig. Serene heißt die in Potsdam und das war ganz cool, weil der Johannes Bonet, der Geschäftsführer dort, der war auch schon mal im Podcast und der hat mir das damals echt so von der Pike auf beigebracht. mal Software auch so ein Stück weit als Gebilde zu sehen und in so eine Bildlichkeit zu verschieben. Die haben so Städtemodelle, ganz lustig, damals mal in den frühen Phasen gebaut. Da konntest du deinen Softwarecode ansehen wie so eine 3D-Karte und dann konntest du sehen, welches Gebäude war hoch, aber schmal. Das heißt, wenn die Grundfläche irgendwie nicht gut war und das Gebäude zu hoch droht, ist umzustürzen. Und so konntest du sozusagen so Predictive Maintenance machen. Und das Bild, was mir total im Kopf geblieben ist, war, der hatte, glaube ich, das Beispiel von einer Versicherung, wo er meinte, wenn du den Source-Code von so einer Versicherung ausdrucken würdest auf Papier, der Papierstapel wäre so hoch wie ein 30-stöckiges Hochhaus. Da muss man sich mal diesen Komplexitätsgrad, also von dem Produkt, von dem wir hier reden, vorstellen. Du ja gar nicht mehr durchblicken kannst als Mensch und du ja auch das Problem hast, dass dann 50 unterschiedliche Teams vielleicht an so einem Hochhaus arbeiten, aber sie gar nicht wissen, was machen gerade die anderen. Das heißt, du musst es ja auch irgendwie immer zusammengeführt kriegen. So, that being said, ich glaube, ein echt ganz schönes, bildliches Beispiel von dir, Martin, mit Knight Capital. Und dann gehen wir doch mal direkt rein in diese Top-Skalierungsfehler. Also, der erste Fehler, und man darf dazu sagen, das ist auch zu großem Teil immer aus deinem Buch abgeleitet, haben wir genannt, die Schlüsselergebnisse des Technologiebereichs nicht transparent genug messen. Heinemann ist ja auch Fan vom Messen, aber fang mal an, kurz den Fehler zu beschreiben, Martin.

Martin Schilling: Gerne. Also, eines der Themen, die man oft sieht, gerade an der Schölle von Startup zu Scale-Up, ist, dass der Technologiebereich manchmal mit der Messung seiner eigenen Leistung hinterherhängt. Da ist es wichtig, als Gründer, als Führungsteam darauf zu achten, natürlich auch als CTO, als Technologieorganisation, da klar zu sein. Es gibt vier Bereiche, in denen eine Technologieorganisation ihre Leistung messen kann. Also erstens Produktivität, typisches Schlüsselergebnis, die sogenannte Deployment-Frequenz pro Entwickler pro Woche erhöht. Also, dass du irgendein Maß an Produktivität hast. Leistung und Zuverlässigkeit der Plattform. Das sind so typische Themen. API-Reaktionszeit oder Prozentverfügbarkeit. Diese berühmten vielen Neuner-KPIs. Also 99,99% Verfügbarkeit eines Start-Scale-Ups heißt in etwa eine Stunde offline pro Jahr. 99,999% heißt bis 5 Minuten offline. Dazwischen bewegen sich die meisten Startup-Scale-Ups. Dann natürlich Code-Qualität. Das hatten wir jetzt gerade bei Knight Capital. Anteil des Codes, der automatisiert getestet wird oder Anteil von automatischen Pull-Requests, die getestet werden. Das sind typische Themen dort. Und dann viertens natürlich Sicherheit. Also so Schlüsselergebnisse wie Verhältnis erfolgreiche Cyberangriffe zu allen Cyberangriffen oder durchschnittliche Zeit zur Erkennung einer Sicherheitslücke. Das sind so typische vier Themen, wie man im Technologiebereich Schlüsselergebnisse messen kann.

Joel Kaczmarek: Und ich meine da auch schon mal wieder den Faktor Skalierung. Also ich erinnere mich noch, bei meiner letzten Gründung war auch mal das Thema, da hatten wir irgendwelche Server und dann hieß es 99% Verfügbarkeit und dann rechnest du durch 1% Non-Verfügbarkeit auf ein Jahr, sind schon fast vier Tage. Also vier Tage offline, das ist halt schon relativ hoch. Florian, du bist ja auch immer datengetrieben, messgetrieben vor allem. Was ist denn so dein Blick auf das, was Martin auch gerade geschrieben hat? Also einerseits Produktivität auf der einen Seite, dann irgendwie Plattformverfügbarkeit und Qualität. Wie geht ihr so mit dem Thema Messen von Technologie, Qualität und Produktivität um?

Florian Heinemann: Also vielleicht ein ganz konkretes Beispiel. Also wir haben Leute bei uns, wo wir investieren, dabei helfen, systematische Qualitätssicherung zu implementieren und die dann eben auch zu automatisieren. Das ist jetzt so eines der Kernthemen, wo wir versuchen zu helfen, Best Practices eben zu etablieren, weil wir häufig gerade in den jüngeren Startups wo wir investieren, wo dann vielleicht einen technischen Mitgründer hast, der aber häufig ja noch nie eine IT-Abteilung mit 30, 40, 50 Leuten geführt hat. Und das ist schon ein ganz wesentlicher Teil des professionellen Managements von so einem Tech-Bereich. Und das ist auch häufig etwas, warum wir da stark auch propagieren, erfahrene Mitarbeiter reinzuholen. Du hast ja immer so ein bisschen den Trade-off zwischen, setzt du auf Potenzial und hirest eher nach Potenzial und gibst diesen Leuten Raum oder du holst halt erfahrene Mitarbeiter. Und du musst von Bereich zu Bereich eigentlich schauen, wo schlägt Erfahrung, Potenzial und wo ist es eigentlich umgekehrt. Und ich glaube, gerade in diesem technischen Bereich, da Best Practices zu implementieren, hilft es, Leute reinzuholen, die einen gewissen Senioritätsgrad haben und sowas schon mal in einer exzellenten Form gesehen haben. Das ist zum Beispiel auch etwas, wo wir dann sehr stark darauf achten. Also sprich, da implementieren wir das dann nicht selbst oder schreiben den Menschen das vor.

Wir legen halt nah und helfen dabei zu rekrutieren eine Person, die das dann schon mal gemacht hat. Also das ist dann eher sozusagen unser Ansatz dort. Und ich glaube, du brauchst halt eine gute Mischung zwischen auch jüngeren Entwicklern, die dann da wieder innovative Ansätze reinbringen in dieses Framework. Und das ist, glaube ich, sozusagen die Killer-Kombination im Tech-Bereich, also innovative Personen. Das eben zu kombinieren mit erfahrenen Leuten, die eben genau sowas da reinbringen, weil das das Schwierige im Tech-Bereich ist ja, anders jetzt als im Marketing-Bereich, wo du letztendlich an zwei KPIs oder drei sehen kannst, bin ich jetzt auf einem guten Weg oder nicht. Und hier hast du ja im Marketing-Bereich, würdest du sagen, Zwischen-Conversions. Also eine gute Uptime sorgt ja noch nicht dafür, dass jetzt die Applikation auch kundenfreundlich ist. Und je weiter weg du letztendlich von dem endgültigen Ziel bist, desto eher musst du ja sozusagen mit diesen Zwischen-KPIs arbeiten, die halt gewisse Elemente einer erfolgreichen IT-Applikation oder Infrastruktur oder Organisation abbilden. Aber du brauchst eben, je mehr du wegrückst vom Endziel, brauchst du halt mehrere Sachen. Und das ist ja auch genau das, was Martin beschrieben hat. dass du halt eine Reihe von Indikatoren brauchst, die dir dann hoffentlich ein gutes Gesamtbild geben. Natürlich, je mehr KPIs du hast, desto schwerer ist dann natürlich, das Gesamtbild zu interpretieren. Und ich glaube, da ist eben auch nochmal, wo Erfahrung halt hilft. Was von diesen Elementen ist jetzt eigentlich wie wichtig und wie spielt das auch zusammen?

Martin Schilling: Vielleicht nochmal einmal anschließend an das, was Florian gerade gesagt hat, zum Thema automatisierten Tests. Da haben wir ein ganz spannendes Beispiel gehört. Also es gibt Scale-Ups, die kaufen sich im Prinzip ein iPhone und ein Android-Gerät und programmieren dann einen Systemtest, der folgendes macht. Der lädt auf beiden Geräten 24-7 die verschiedenen Versionen der App aus verschiedenen Ländern runter. Jetzt in einem Fintech-Beispiel macht eine Transaktion pro Gerät, löscht die Applikation und lädt sie wieder neu. So ein Systemtest, wo du im Prinzip dass jede deiner Länderversionen, Sprachversionen der App immer funktioniert. Und wenn dann irgendwie die Applikation bricht, hast du sofort einen Alarm, der dir sagt, oh, da stimmt was nicht.

Joel Kaczmarek: Apropos Tooling. Also ich mache jetzt mal frecherweise nochmal für die Kollegen aus Potsdam Werbung, weil ich fühle mich denen ja auch noch ein bisschen verbunden, wenn ich früher da gearbeitet habe. Bei Serene fand ich das mal ganz interessant. Die haben gesagt, die bauen so ein Digital Boardroom. Die haben Software-Analytics und Process-Mining-Technologien benutzt, um Software irgendwie zu visualisieren, dass du halt auch als technischer Entscheider oder sag mal als Budgetgeber, der vielleicht nicht technisch basiert ist, versteht, was da passiert. Martin, was ist denn so? dein Tipp, wenn wir jetzt darüber reden? Der Fehler ist eigentlich, die Schlüsselergebnisse im Technologiebereich nicht transparent genug zu messen. Womit tue ich das? Also sind das so die Syrenes dieser Welt. oder was habt ihr so für Software-Tools zum Beispiel auch bei N26 eingesetzt?

Martin Schilling: Wir waren und ich bin da ein Fan von großer Einfachheit. Die ganz genauen technischen Monitoring-Tools kenne ich nicht. Da gibt es eine ganze Reihe von, also Prometheus etc. Aber wir haben immer versucht, es so einfach wie irgendwie möglich zu halten. Also bevor wir irgendwelche großen Tools einführen, haben wir einfach erstmal Google Sheets verwendet. Und wenn wir Tools eingesetzt haben, dann eben natürlich Dashboards. Da bin ich großer Fan von Pragmatismus.

Joel Kaczmarek: Gehen wir mal weiter zum zweiten Fehler. Kennt jeder, Technical Debt hat mir ja auch schon mal im Podcast mehrfach, glaube ich, technische Schulden aufzubauen, ohne es zu bemerken, wenn man quasi zu pragmatisch unterwegs ist. Martin, erzähl mal von der Front.

Martin Schilling: Erstmal, was sind denn technische Schulden? Also technische Schuld nimmt man dann auf, wenn man eine Lösung programmiert, die schnell ist, aber die man nacharbeiten muss. Also typisches Beispiel, du erlaubst deinen Nutzern, sich erstmal mit Passwort und Username einzuloggen und programmierst halt nicht gleich einen Single Sign-On mit deinem Google- oder Facebook-Account. Jedes Startup nimmt technische Schuld auf. Das ist normal und auch okay. Jetzt gibt es aber ein paar Prinzipien, die wichtig sind, um diese technische Schuld in Anführungszeichen zu managen. Also erstens, einen Monolithen am Anfang aufzubauen, ist oft die Empfehlung. Beispiel Amazon, da heißt der Monolith, der bis heute läuft, soweit ich weiß, Obidos oder LinkedIn, da heißt der Leo. Im Prinzip heißt es am Anfang, Monolith, du programmierst eine Softwarearchitektur, bei der alle Komponenten, also Datenbank, Kundenanwendung, Serveranwendung, auf einer Einrichtung, einzigen langen Code-Basis laufen. Ja, eben ein Monolith. Das hat den großen Vorteil, das kannst du schnell programmieren. Das hat den großen Nachteil, wenn du irgendwas änderst an irgendeiner Stelle, musst du den Code immer wieder neu bereitstellen. Und warum ist das wichtig am Anfang? Weil du, wenn du eine modulare Architektur am Anfang baust, also du hast zum Beispiel einen Doktor-Patienten-Marktplatz, baust dafür eine modulare, elaborierte IT-Architektur. Dann pivotierst du hin zu einer App, nur für Patienten musst du sehr viel neu machen. Deswegen wird am Anfang oft gesagt, mach pragmatisch einen Monolithen, weil du schnell abheben kannst. Und jetzt gibt es noch zwei, drei andere Punkte, können wir gleich diskutieren, wie man dann auf der Basis dieses Monolithen dann schnell die technische Schuld nicht zu groß werden lässt.

Joel Kaczmarek: Ja, vertief doch gerne mal, was du da noch an Input hast, wäre ich mal neugierig. Ich staune ja auch, weil ich immer dachte, Monolithen seien schlecht, aber jetzt lerne ich das Gegenteil.

Martin Schilling: Also natürlich ist eine monolithische Struktur, die du am Anfang entwickelt hast und nicht richtig weiterentwickelst, schlecht und problematisch, wenn du skalierst. Das ist gar keine Frage. Aber aus der Erfahrung heraus, wenn du Startups hochfährst, kommt man oft an Monolithen nicht vorbei. So, jetzt ist es aber sehr wichtig, genau wie du sagst, jetzt muss man eine ganze Reihe von Themen anpacken, damit der Monolith nicht zum Problem wird. Also erstens. jede IT-Architekturentscheidung, die die technische Schuld weiter aufbaut, sollte dokumentiert werden. Also das heißt, du setzt früh einen Standard, wo du sagst, jeder Entwickler, der IT-Architekturentscheidungen trifft, muss dokumentieren. Also sowas wie Problemen, technischer Ansatz, ein paar Komplementierungsbeispiele, so drei bis vier Seiten Dokumentation. Dann denken Entwickler einfach viel präziser darüber nach, bevor sie was tun und werden sich dieser technischen Schuld mehr bewusst. Und dann eben wichtig, je größer du wirst, nimmst du mehr und mehr aus dem Monolithen raus. Also du gehst hin zu einer sogenannten modularen Infrastruktur. Das heißt einfach, du hast dann zum Beispiel so eine Infrastruktur, Paymentservice, Verifikationsservice. Und der große Vorteil ist dann, du kannst dann Teams parallel und unabhängig an den verschiedenen Modulen arbeiten lassen. Das ist der entscheidende Punkt. Also das heißt, dann kann ein Team die Verifikation aufs nächste Level bringen und parallel kann ein Team am Paymentservice arbeiten.

Joel Kaczmarek: Florian, wie viel beschäftigst du dich so mit Technical Debt oder ihr euch als Investor? Ist das sehr fern von euch?

Florian Heinemann: Überhaupt nicht. Das macht eben auch eher unser technisches Team und das hast du ja nicht nur im Hardcore-technischen Bereich, sondern das hast du auch im Bereich BI häufig, was ja auch nah dran ist an dem Kern-IT-Thema, weil auch dort wählen Leute irgendwelche Lösungen, um Kundendaten, Transaktionsdaten, Produktdaten abzulegen, wo du dann im Nachhinein eben merkst, das schränkt dich in deiner weiteren Entwicklung ein. Also die Awareness für Technical Debt zu schaffen, das tue sogar ich, obwohl ich jetzt ja nicht ein großer IT-Experte bin, weil wir eben sehr, sehr, sehr, sehr regelmäßig sehen, dass eine der Hauptgründe ist, warum eine Skalierung dann im späteren Verlauf dann doch eben nicht so einfach funktioniert, wie das hoffentlich sein soll. Und du hast ja genügend Wachstumsschmerzen, wenn die Firma gut läuft und Und idealerweise sollte sich die IT-Infrastruktur und auch die Dateninfrastruktur dann nicht daran hemmen und die Awareness dafür zu schaffen, dass das ein Thema ist und auch bei sehr, sehr vielen Firmen ein Thema ist und dass man rechtzeitig darauf achten sollte, eben vor der wirklichen Skalierung diesen Schritt raus aus der monolithischen Struktur geschafft zu haben.

Den Schritt raus jetzt im Datenbereich aus einer Silo denke, dass das total wichtig ist, weil das wird häufig so ein bisschen vor sich her geschoben. Wenn du solche Themen vor der Skalierung nicht löst, das wird halt immer schlimmer. Das ist ja letztendlich die Situation, gerade im Corporate-Kontext sprichst du ja immer von Legacy-IT. Also wenn du so ein größeres Unternehmen hast, jetzt immer so im Datenbereich, wo ich einfach ein bisschen näher dran bin, ist es völlig üblich, dass ein größeres Unternehmen Kundendaten in sechs verschiedenen Systemen hat, die alle nicht miteinander korrespondieren. Und das ist ja sozusagen genau das, was passiert, wenn du als Startup Technical Debt nicht versuchst von Anfang an zu verhindern oder sozusagen rechtzeitig das eben gut zu managen und dann bist du eigentlich nicht mehr handlungsfähig. Und dann ziehst du natürlich die komplette Energie aus so einer Organisation. Und das ist eigentlich auch das, wo jemand, selbst wenn er keinen technischen Sachverstand hat, wo die Konsequenz dessen eigentlich sehr, sehr transparent wirkt. Das erlebst du sehr, sehr regelmäßig in Corporates. Du hast da ja Menschen, die sind sehr emotioniert, die wollen viel umsetzen und so weiter. Die scheitern aber letztendlich daran, dass die technische Entwicklungsstruktur oder die technische Infrastruktur die Ideen, die diese Menschen haben, dann eigentlich nicht mehr umsetzbar macht. Und das sorgt im Prinzip dazu, dass die Leute, wenn das ein paar Mal passiert, das Energielevel verlieren, was für mich eine der größten Probleme ist an dem, was aus Technical Debt dann irgendwann wird. Und wie gesagt, du musst es halt von Anfang an verhindern. Und das ist etwas, was wir sehr stark versuchen, gerade natürlich bei den nicht technischeren Gründern, die Awareness zu schaffen, warum das so wichtig ist.

Martin Schilling: Nochmal kurz Brücke zurück zum Fehler 1, zu dem, was Roland gerade gesagt hat. Du siehst das an Produktivitätsverlusten. Deployment pro Person, pro Entwickler pro Woche, die geht runter, wenn die technische Schuld hoch ist.

Florian Heinemann: Und was du natürlich auch siehst, ist der Anteil, den du brauchst, um allein die technische Infrastruktur im Leben zu erhalten. Selbst wenn die Leute dann viel machen, verbringen die Leute bei einer schlecht aufgesetzten technischen Infrastruktur sehr viel Zeit damit, den Status Quo irgendwie zu maintainen und wenig damit in Richtung Feature-Fortschritt zu arbeiten. Hat nochmal so einen ticken anderen Angle, weil man könnte ja sagen, ja, die Leute sind weiter produktiv, die deployen wahnsinnig viel, aber sie deployen im Prinzip halt in die Bestandsinfrastruktur, ohne dass es eigentlich zu einer kundenseitigen Weiterentwicklung der Plattform kommt. Und das ist eigentlich auch nochmal ganz spannend, ein weiterer Aspekt, den man da reinbringen könnte.

Joel Kaczmarek: Fehler 3. Wenn wir gerade bei Fehler 2 zu pragmatisch waren, dann sind wir vielleicht bei Fehler 3 zu wenig pragmatisch und zwar mit der Alleskönner-Plattform in Schönheit zu sterben. Als dritter Fehler erinnert mich ein bisschen an den Mark Zuckerberg-Satz, dann ist better than perfect. Nimm uns mal mit unter die Haube, Martin. Was sind da so deine Befunde?

Martin Schilling: Du hast oft, gerade wenn du unerfahrene technische Führungskräfte hast, die da manchmal versuchen, eine Alleskönner-Plattform am Anfang zu bauen. Und das heißt, das ist jetzt genau, was wir gerade hatten, mal nicht zu sagen, pragmatisch, komm, jetzt bauen wir mal einen Monolithen und gehen mal raus, damit wir schnell in die Lernzyklen kommen, sodass wir Kundenfeedback holen können, sondern die dann sagen, nee, stopp, wir machen jetzt erstmal ein Jahr ganz präzise eine modulare Tech-Infrastruktur, damit wir dann auch wiederkommen. wirklich auf 10 Millionen Kunden skalieren können. Das ist oft ein Fehler. Du wirst in der frühen Phase oft pivotieren und du weißt noch gar nicht, wie genau deine Plattform aussehen muss. Und es kann eben schon sein, dass du einfach mal ein Jahr lernst und dann zu einem Punkt kommst, wo du komplett nochmal von vorne anfängst und auch technologisch nochmal wirklich bei Null anfängst. Deswegen ist es wirklich super wichtig, da pragmatisch zu sein, so schnell wie es geht mit Kunden zu lernen. Du musst 15 Rechnungen pro Monat verschicken. Da brauchst du jetzt kein ausgeklügeltes Abrechnungssystem oder eine Data Science Plattform muss man nicht einführen, wenn du erstmal MVP-Status Nutzerfeedback einholst. Also das ist so die große Gefahr hier.

Joel Kaczmarek: Florian, da bist du ja glaube ich Profi. Wie viel Pragmatismus kann man sich denn auf der technischen Ebene am Anfang von so einem Startup erlauben? Wie mischt ihr das ab? Hast du da so Best Practices?

Florian Heinemann: frühzeitig an das gewöhnen, wie es denn mal sein wird. Also du brauchst halt schon so eine gewisse, ich nenne das immer Frontloadedness, also sozusagen für das Wachstum, was dann mal kommen wird, schon die richtigen Voraussetzungen schaffst. Diesen Trade-Off bewusst zu managen und da bewusste Abwägungsentscheidungen zu treffen und die auch innerhalb des Managements zu teilen, weil es ist, glaube ich, ganz wichtig, dass du dass allen Leuten, die in der Firma irgendwie was zu sagen haben, das ist immer auch ein Stück weit, müssen das halt die Top-Führungskräfte mittragen. Und ich glaube, unser Job kann ja eigentlich nur sein, zu sagen, identifiziert für euch die Trade-offs und legt für euch gemeinsam als Management fest, wie ihr euch da positionieren wollt. Und ich sage halt immer, je mehr Geld du hast, je mehr Ressourcen du hast, desto stärkere Frontloadedness kannst du dir halt leisten. Desto stärkere Frontloadedness macht auch Sinn. Die Wahrscheinlichkeit, dass du tatsächlich in diese Skalierung kommst, steigt natürlich.

Und das ist genau sozusagen natürlich auch der Unterschied zwischen einer Venture-Capital-finanzierten Firma und einer Bootstrapped-Firma. Bei einer Bootstrapped-Firma gibt es diesen Trade-Off nicht, sondern da kannst du im Prinzip halt nur entlang der Wachstumsentwicklung so ein bisschen mithoppeln und hoffen, dass dann irgendwie funktioniert. Und der Witz bei Venture-Capital ist ja gerade, dass du dir halt eine gewisse Frontloadedness halt leisten kannst. Das Bewusstsein dafür zu schaffen, dass man diese Trade-Off-Entscheidung hat und dass es halt nicht unbedingt immer cool ist, den Bootstrapping-Modus zu fahren, wenn du eigentlich sieben Millionen Euro auf deinem Konto hast, sondern dass es die schlauere Entscheidung sein kann, an gewissen Stellen diese Frontloadedness an den Tag zu legen. Das ist ja eigentlich mein Job als Coach zu sagen, ich weiß auch nicht, was das Richtige ist, aber ich kann euch sagen, ihr habt diesen Trade-Off und da müsst ihr euch halt überlegen, wie es ist. Das ist sozusagen mein Job.

Joel Kaczmarek: Fehler 4, der dockt da sehr schön an und ich glaube, den kennt jeder Unternehmer, die typische Make-or-Buy-Frage. Und der vierte Fehler wäre, durch zu spezielle Anforderungen zu oft Software selbst entwickeln. Und ich fühle mich wärmstens erinnert, als wir damals bei Gründerszene uns überlegt hatten, eine Datenbank zu bauen und wir vor der Frage standen, gibt es irgendwie coole Services, mit denen man Datenbanken darstellen kann? Also heute gäbe es sowas, sowas wie Airtable zum Beispiel, damals gab es das nicht so. und dann haben wir selber losgelegt und mit allen Schmerzen, die man dabei so kennt. Also ich glaube, das kennt jeder Unternehmer, wenn du immer so in dieser Frage stehst, nehme ich Sachen von der Stange, passe ich mir an oder baue ich komplett selber. oder gibt es vielleicht noch irgendwas dazwischen. Martin, berichte mal aus deiner Recherche.

Martin Schilling: Das ist ein ganz wichtiges Thema, vor allen Dingen für nicht technische Startup-Führungskräfte, um die Hintergründe zu verstehen. Also Entwickler entwickeln gern. Das muss man sich immer vor Augen halten. Also wenn man intern fragt, hey, sollen wir das kaufen oder sollen wir es entwickeln, haben viele Entwickler die Tendenz zu sagen, na klar entwickeln wir das, wir sind ja Entwickler. Ich mache mal zwei Beispiele aus N26, wo wir uns, glaube ich, richtig entschieden haben, bei einem falsch. Also das falsche Beispiel, wo wir uns falsch entschieden haben, war, wir haben ein Tool nachprogrammiert zum Routing von Anfragen im Kontaktcenter. Also ein englischer Kunde, Onboarding muss zu einem englisch sprechenden Spezialisten-Onboarding weiterentwickelt werden. Da gibt es auch Tools auf dem Markt. Da hat unser Tech-Team gesagt, das müssen wir unbedingt entwickeln. Das haben wir gemacht. Dann ist das Tech-Team gegangen und wir hätten es vom Markt auf uns. Das war ein Fehler, weil eine Routing-Maschine im Kontaktcenter kaum zu zusätzlicher Kundenbegeisterung beiträgt. Das merkt der Kunde kaum.

Wir haben uns auf der anderen Seite gut entschieden, einen Chatbot selbst zu entwickeln, obwohl es ja viele Chatbot von der Stange gibt, weil wir glauben, dass der Chatbot irgendwann einen Kunden begeistern wird und Fragen beantworten kann, wie kann ich mir den BMW leisten? Also der Chatbot wird dann vergleichen, was bekomme ich, was nehme ich ein, was kostet der BMW so? Also wird direkt eine Kundenbegeisterung auslösen. Weiteres Beispiel, Zalando hat an irgendeinem Punkt die internen Warenmanagementsysteme nachprogrammiert, weil sie damit die Pakete schneller und zuverlässiger den Kunden ausliefern können. Deswegen wäre mein Appell an jeden, der vor dieser Entscheidung steht, sich ganz klar zu überlegen, kreiert dieses möglicherweise zu entwickelnde Tool, dieser Service Kundenbegeisterung? Wenn ja, kann das ein Grund sein, selbst zu entwickeln?

Joel Kaczmarek: Florian, da interessiert mich ja mal deine Meinung, weil vor der Frage steht man so oft als Unternehmerin, finde ich, dass man sich fragt, wann mache ich was selber, wann kaufe ich was von der Stange? Findest du die Formel von Martin zu sagen, wenn es die Kundenzufriedenheit verbessert und ich mir da irgendwie so einen Anfährt-Warntisch ziehe, ist das so der Wahrheit? letzter Schluss? Ist das, worum es ankommt?

Florian Heinemann: Vielleicht ein Ticken breiter fast. Alles, wo du dich gegenüber der Konkurrenz differenzieren kannst, das kann ein Kunde sein, aber das kann natürlich auch für ein Zalando das interne Buying-Support-Tool sein, wenn das in irgendeiner Weise eine Differenzierung gegenüber der Konkurrenz verspricht. Ich glaube, das ist ja sozusagen der Benchmark. Ich fand zum Beispiel, Zalando hat zum Beispiel überlegt, ich weiß gar nicht, ob sie es dann irgendwann gemacht haben, aber ein eigenes Web-Tracking-Tool zu entwickeln, wo du halt so sagst, okay, also um jetzt besser zu sein als Google Analytics, musst du wahrscheinlich 50 Entwickler da reinstecken, die dann kontinuierlich an so einem Ding arbeiten. Weil ich glaube, Google Analytics hat zu dem Zeitpunkt 800 Entwickler oder 1000 Entwickler. Dann sagst du natürlich, okay, damit du das replizieren kannst, was kannst du da eigentlich gewinnen, wenn du jetzt besser Web-Tracking betreibst? Das fand ich jetzt total no-brainer, dass man das jetzt nicht selbst baut. Weil das Argument dagegen wäre gewesen, oh, dann trackt ja Google mit, was wir so machen. Wo du denkst so, ja, okay. Aber dass die das jetzt mit inhaltlicher Logik interpretieren können, I don't know. Du übergibst denen ja selbst die Sache. Ich würde es ein bisschen breiter fassen, überall, wo du dich differenzieren kannst. Das ist sehr, sehr häufig gegenüber dem Kunden. Das kann aber theoretisch auch was anderes sein. Und vielleicht auch, wo es dir erlaubt, ein weiteres Geschäftsmodell drauf aufzubauen. Was meine ich? Also du hast ja sozusagen diese Plattform-Charakteristika, dass Amazon irgendwann angefangen hat, wir brauchen einen Cloud-basierten Service und dann haben die das für sich selbst entwickelt, weil sie es für sich selbst brauchten und dann haben sie es aber direkt so gemacht, weil das ja angeblich das Amazon-Jeff Bezos-Entwickler-Prinzip ist, der auch kein Entwickler ist übrigens, sondern ein harmloser Investmentbanker bei Training.

Der hat ja angeblich 2002 schon gesagt, wir entwickeln alles, was wir machen, so, dass wir es theoretisch auch für dritte Kunden verkaufen können. Das geht so ein bisschen mit diesem Differenzierungsaspekt einher, weil ich kann ja nur etwas an Dritte verkaufen, wenn ich es auch besser mache. Das kann auch ein weiteres Argument sein. gerade für ein sehr hohes Ambitionsniveau an Unternehmen. Aber das bedingt natürlich, muss man auch fairerweise sagen, das machst du jetzt nicht als kleines Unternehmen, sondern das machst du nur, wenn du natürlich ein relevantes, industry-changing Unternehmen werden zu wollen und auch die Ressourcen hast, um das zu tun. Weil nur die werden ja theoretisch dann auch in der Lage sein, siehst du ja zum Beispiel bei einem About You, die jetzt ihre fashion-fokussierte E-Commerce-Plattform für Dritte anbieten. Das ist jetzt genau so ein Beispiel. Dann musst du natürlich auch deine Logistik selbst machen. Also das sind für dich so Beispiele, aber wie gesagt, ich würde es eigentlich exakt genauso sehen, vielleicht noch ein bisschen erweitert.

Joel Kaczmarek: Da sind wir ja nicht fern von unserem fünften Fehler, weil wenn ich Dinge selber baue, muss ich mir auch Gedanken dazu machen, dass sie doch auch sicher gebaut sind. Und der fünfte Fehler wäre, die Datensicherheit zu lange zu vernachlässigen. Man kennt ja, glaube ich, mittlerweile sogar auch aus Filmen und Serien immer gerne so diese Team Red, Team Blue Geschichten, wie man zum Beispiel Sicherheit prüfen kann. Aber ich bin mir sicher, der liebe Martin hat noch ein paar andere griffigere Beispiele oder Storys dazu, rund um das Thema Datensicherheit für uns.

Martin Schilling: Die Relevanz von Datensicherheit hängt natürlich auch stark vom Geschäftsmodell ab. Ein Fintech oder ein Kryptoanbieter muss sich da mehr Gedanken machen als jetzt eine E-Commerce-Plattform. Aber natürlich auch die E-Commerce-Kollegen müssen da stark sein. Also deswegen ein Thema, wo man sich oft zu spät damit beschäftigt. Es gibt so drei Standards, die man als Startup im Griff haben muss. Du brauchst jetzt mal einen ganz pragmatischen internen Sicherheitsteam überhaupt. Also ein sogenanntes Blue Team. Die definieren Sicherheitsstandards, also Programmierrichtlinien, Anzahl und Umfang von Belastungstests. Die konfigurieren Hardware, spielen Patches ein. Diese ganzen Themen, die einfach das interne Team macht. Dann ist es sehr klug, ein externes sogenanntes Penetration Testing, Penetration Testing Team zu beauftragen. Das kann man gut vom Markt kaufen. Das ist im Prinzip so wie der Besuch beim Zahnarzt. Regelmäßige Untersuchungen sichern langfristig einen schmerzfreien Gesundheitszustand. Also typischerweise machen die dann sowas wie eine vierteljährliche Schwachstellenprüfung, offene Ports etc. Die machen Belastungstests, also wenn du auf einmal sehr viel mehr Traffic bekommst. Die setzen eventuell auch mit dir ein externes Bounty-Hunting-Programm auf, wo also freundliche Hacker versuchen, Fehler zu finden und du zahlst ihnen dafür Geld, wenn sie Fehler oder Sicherheitslücken finden. Ganz konkret, es gibt also ein, zwei kleinere Anbieter, also Cobalt habe ich gehört und Sys sind so typische Pentest-as-a-Service-Anbieter und dann natürlich auch die großen, die Lloyd, KB, Mini, McAfee etc., die kann man da für sowas fragen.

Joel Kaczmarek: Ich meine, Florian, hilf mir doch immer zu verstehen, wie so das Thema Sicherheit bei Startups und Scale-Ups irgendwie gebaut ist. Weil mir fallen so zwei bekannte Beispiele ein. Fairerweise ist mir beim ersten der Name entglitten. Es gab ja mal diese, ich glaube, kanadische Dating-Plattform, wo auch viele Homosexuelle gedatet haben, wo dann auch die ganzen Nutzerdaten Grindr. Grindr. Ich glaube, es war Grindr. Ich weiß nicht, ob es nicht Ashley Madison oder sowas war.

Florian Heinemann: Ja, aber Ashley Madison ist ja sozusagen eine Enabling-Plattform fürs Fremdgehen.

Joel Kaczmarek: Also Ashley Madison weiß nicht, wurde auf jeden Fall mal gehackt und da gab es ja teilweise wirklich Selbstmorde von Nutzern, weil irgendwie ihr Fehlverhalten zu breit getreten wird. Da merkt man aber, wie, wie soll man sagen, empfindlich sowas auf einmal sein kann. Also eigentlich eine simple Dating-Plattform, auf einmal nehmen sich Menschen das Leben, weil da halt ihre Seitensprünge oder schwulen Aktivitäten oder sowas dokumentiert sind. Oder andere Geschichte, ich meine, das ist ja eigentlich frappierend, Amazon mit Twitch, wo ja glaube ich sogar der gesamte Source-Code offengelegt wurde. Man konnte irgendwie alle Verdienste der größten Twitch-Nutzer sehen. Man staunt ja so ein bisschen. Also du bist nicht vor gefeit, wahrscheinlich gehackt zu werden. Und trotzdem frage ich mich auf der anderen Seite, ab wann ist ein guter Zeitpunkt, sich über Daten-Sicherheit Gedanken zu machen und wie viel davon gehört eigentlich dringend, dringend, dringend auch auf Vorstandsebene sozusagen betrachtet?

Florian Heinemann: Das Problem ist eben, das ist ja hier so ein Null-oder-Eins-Thema. Bei dem, was wir bisher beschrieben haben, da treten ja sozusagen die negativen Folgen, wenn du da Fehler machst, in unterschiedlichen Dosen schon sozusagen entlang des Weges auf. Hier tritt ja gar nichts auf, bis es dann eben auftritt. Das ist ja häufig bei so Themen, wo du halt sagst, So richtig Wert generiert das halt erstmal jetzt nicht, also im Sinne von aktivem Wert. Generiert halt nur dann Wert, wenn dir halt irgendwas passiert wäre, was du dann eben verhindern kannst. Und da merkst du, das fällt Menschen und dementsprechend auch Gründern viel, viel schwerer, diese Themen zu adressieren, weil es eben so einen Nullen-oder-Eins-Charakter hat und eben keinen aktiven Wert schafft, sondern eben nur eine Wertminderung verhindert. Und deswegen ist es auch ehrlicherweise überhaupt nicht so leicht, dafür Awareness zu kreieren. Wer interessiert sich denn jetzt hier für so ein kleines Ding? Bevor die mich hacken, da hacken die doch Zalando oder N26 oder irgendwas so. Und das kann natürlich so sein. Und häufig ist es ja auch so. Es ist genauso wie mit so GDPR-Verstößen.

Und dann denkst du auch, ja, mich findet doch die Behörde nicht. Wir werden uns ja auch erstmal um die Ottos oder wen auch immer kümmern. Das kann so sein und viele kommen damit natürlich auch durch. Aber für uns als Venture Capitalist oder auch. Auch für die Gründer ist es natürlich schon massiv wertzerstörend und das sind natürlich Themen, die wir adressieren müssen. Die Schwierigkeit dabei ist natürlich auch, klar, ein N26 oder Zalando oder so, die können dann auch wirklich permanent Mitarbeiter für dieses Thema abstellen, Serversicherheit und so weiter. Für die meisten kleineren Startups, die müssen natürlich eher dann mit externen oder Freelancern arbeiten, die ihnen dabei helfen. weil es ja eben kein dauerhaftes Thema ist, sondern das muss man einmal vernünftig aufsetzen und dann wird es in irgendeiner Weise gemonitort und irgendwann fängt man dann an, eigene Strukturen ab einer gewissen Größenordnung aufzubauen. Es ist in der Tat nicht leicht, die Awareness dafür zu schaffen, weil es dir natürlich konkret bei der nächsten Finanzierungsrunde nicht hilft. Man sieht aber, und das ist schon ganz spannend, dass gerade wenn du so Wachstumsinvestoren hast, die professionellere Due Diligence machen, also jetzt nicht unbedingt die Tiger Globals dieser Welt, ich glaube nicht, dass die das prüfen, aber sozusagen Leute, die in viel späteren Phasen reingehen, die prüfen sowas zum Beispiel mit.

Auch da ist das wieder so ein Thema, wenn du früh damit beginnst und früh dich darauf ausrichtest, dann ist es relativ schmerzlos, wenn du das versuchst im Nachhinein dann noch irgendwie nachzuziehen und das nie so richtig im Blick hattest, ist es wieder aufwendig und nervig und deswegen versuchen wir auch da, früh eine gewisse Guidance zu geben und auch Dienstleister an die Hand zu geben, auch wieder in so einem Phasenmodell, also wir versuchen eigentlich für alles, was wir so machen, so Phasenmodelle zu haben, also wenn du ganz klein bist, dann ist das der richtige Ansatz? Wenn du ein bisschen größer bist, dann ist das der richtige Ansatz. Ein Phasenmodell auch für diese Cyber Security, die für das jeweilige Startup relevant ist, da so eine Art Zielbild im Kopf zu haben für die jeweilige Entwicklungsphase, sehen wir schon auch mit als unsere Aufgabe an.

Martin Schilling: Also aus meiner Sicht spät Spätestens bei Series A muss man das substanzieller investieren, also einfach auch ein kleines internes Team, also spätestens dann auch haben. Es gibt ganze Branchen und Organisationen von Cyberkriminellen, die versuchen dort Startups und natürlich auch größere Firmen abzuziehen. Also beispielsweise in der Finanzindustrie, es gibt quasi die Sicherheitsteam, beispielsweise der Fintechs und es gibt dann eine Antigruppe da draußen, die alles versucht, um gerade Fintechs oder Startups, wo man halt schnell Geld auch irgendwie abziehen kann, denen auch Geld wegzunehmen oder die Kunden Geld wegzunehmen. Also das ist ein schlummerndes Risiko. Wenn du dich nicht darum kümmerst, kannst du in einem Morgen aufwachen und auf einmal deine Kundendaten im Internet finden.

Joel Kaczmarek: Okay, also ich lerne jetzt, Florian, dass man Sicherheit leider eher als Cost-Center, denn als Profit-Center sieht, ist deswegen vernachlässigt, weil nicht direkt Umsatzwachstum. Jetzt gibt es ja noch den anderen Faktor Mensch bei Software. Ich muss gerade an diese Geschichte denken, hier Kabanak damals, diese russische Hacker-Gruppe, die dann von Banken hunderte Millionen geklaut hat, indem sie die Mitarbeiter über so Phishing-Mails, also diese Social-Engineering-Geschichten quasi geknackt haben. Das heißt, die haben den E-Mails mit irgendwie Kästchen-Videos oder sowas geschickt, die haben die geöffnet, zack, waren sie drin und haben sich die Kameras von da aus gehackt, haben die Codes einbetrachtet und, und, und. Ist in der Startup-Branche, wenn du mit Unternehmen zu tun hast, sowas irgendwie ein Thema, dass Mitarbeiter mittlerweile auch darauf trainiert werden, sich gegen solche Geschichten zu wappnen und es auf dem Schirm zu haben?

Florian Heinemann: Glaube ich, das ist eher die Ausnahme. Hätte ich jetzt irgendwie auch vermutet. Also ich bin jetzt an dem Thema auch nicht so nah dran, aber das wäre mir jetzt neu, beziehungsweise würde mich überraschen.

Joel Kaczmarek: Aber wie oft hast du denn schon erlebt, es kommt ja auch nicht immer alles raus, dass Startups auf solchen Wegen gehackt wurden. Ist es denn ein realistisches Problem trotzdem?

Florian Heinemann: Ja, auf jeden Fall. Es ist halt kein Problem, bis es dann eben ein Problem ist und dann ist es eben ein großes Problem. Es kommt deutlich häufiger vor, als man denkt. Ich bin auch fest davon überzeugt, dass auch wir als Investor nur einen kleinen Teil von den tatsächlich aufkommenden Problemen dann wirklich mitbekommen, weil das natürlich auch nichts ist, was du jetzt auch in Richtung deiner Investoren teilst. Unbedingt. Was du ja auch zum Teil eben hast, ist in dem Bereich so Erpressungsversuche, wo wo du einen weißrussischen Hackerring hast, der sagt, wir machen eine Denial-of-Service-Attacke, es sei denn überweist in Bitcoin 100.000 irgendwas. Das kriegst du natürlich mit, weil das dann auch ja entschieden wird, überweisen wir das jetzt. Aber so kleinere Dinge tauchen ja gar nicht so richtig auf. Ist auf jeden Fall etwas, auch wenn es erstmal jetzt vermeintlich langweilig ist, wo man auf jeden Fall Prozesse für haben sollte und dokumentierte Vorgehensweisen.

Joel Kaczmarek: Gut, kommen wir zu unserem letzten Fehler. Bis dato haben wir gesprochen über Datensicherheit, da ging es ja quasi um die Handhabung von Daten nach außen. Jetzt gibt es ja aber auch noch das Thema Daten nach innen. Und der sechste Fehler wäre demnach, den Datenzugang nicht früh genug innerhalb des Unternehmens zu demokratisieren. Martin, erzähl mal, was ist damit gemeint?

Martin Schilling: Früher war es ja so, dass die Arbeit mit Daten in der Hand von wenigen Experten lagen. Da hast du dann ein Data Science Team gehabt, vielleicht ein zentrales Datenteam. Heutzutage gibt es immer mehr Startups, Scale-Ups, in denen zwei Drittel aller Mitarbeiter regelmäßig mit SQL-Datenanfragen starten. Also du hast die Tendenz sowieso schon, dass viele Rollen, viele Teams eben mit Daten arbeiten müssen. Und jetzt hast du die Herausforderung, dass du im Prinzip einerseits natürlich deine Daten sichern musst und jetzt nicht im Sinne von verschiedenen Standards möchtest, dass jeder da eigene SQL-Queries baut und dann verschiedene Arten von KPIs berechnet. Andererseits möchtest du auch nicht Flaschenhälse kreieren beim zentralen Datenteam. Und das ist so ein bisschen die Herausforderung. Jetzt ein paar Punkte, die wichtig sind. Also erstens mal zu standardisieren wird einfach in der Scale-Up-Phase wichtiger. Wir haben das auch bei Android 6 zum Beispiel gesehen an einem Punkt, wo wir zum Beispiel die monatlich aktiven Nutzer verschieden kalkuliert hatten.

Und dann ist das natürlich doof, wenn du da auf dieselbe KPI guckst, die wird aber unterschiedlich berechnet. Also, dass da ein zentrales Datenteam Standards ist, ist der erste wichtige Punkt. Und dann Selbstbedienungsdatentools. Da gibt es dann eine ganze Reihe. Mode Analytics, Locker, Snowflake und so weiter. Da gibt es eine Reihe von Tools, die man einführen kann, die dann die Teams selbst in die Lage versetzen, so Dashboards zu bauen und selbst Datenanalysen zu starten. Ein weiterer Punkt, auf sogenannte Minimal Viable Data Products zu achten. Das heißt einfach mal wirklich kritisch nachzufragen, auch dann von der Datentech-Kollegenseite. Wenn ein Business-Team jetzt sagt, ich brauche ein Echtzeit-Dashboard, ist das wirklich notwendig? Reicht nicht vielleicht ein Dashboard, was alle 10 Minuten aktualisierte Daten anzeigt? Das ist ein riesiger technischer Unterschied, ein Echtzeit-Dashboard zu bauen versus ein Dashboard, was sich alle 10 Minuten updatet.

Joel Kaczmarek: Florian, du wirst ja auch oft im Marketing dieses Thema haben. Wer kann welche Daten einsehen? Wir reden dann über Data Warehouses, über Rohdaten, über schon vordefinierte Daten etc. etc. Was ist denn dein Blick auf Datenzugang innerhalb von Unternehmen?

Florian Heinemann: Was ja eigentlich so die Traumvision ist und die ist im Marketing eigentlich sogar gar nicht so schlecht umsetzbar. Jeder Mitarbeiter oder jede Mitarbeiterin sich die Frage, war ich jetzt gestern gut oder schlecht, selbst beantworten kann. Und ich bin mittlerweile ein relativ starker Fan davon, dass die Person sich das nicht unbedingt holen muss, sondern dass das zu ihr gebracht wird. dass du das per E-Mail, per Push-Notification in der App oder wie auch immer, ein Customized Dashboard bekommst, was genau auf dich zugeschnitten ist und sehr klar darlegt, an welchen Stellen sollst du eigentlich was tun oder nicht. Also ich weiß nicht, ob ihr schon mal in so einem Trading-Floor wart, von so einer Bank, das hat sich so ein bisschen geändert, aber wenn du da vor ein paar Jahren reinkamst, da waren wahnsinnig viele Menschen, die saßen vor irgendwelchen Bildschirmen und haben eigentlich ständig Entscheidungen getroffen. Also eine wahnsinnig hohe Entscheidungsfrequenz und am Abend wussten die, war das eigentlich heute ein guter Tag oder war das ein schlechter Tag? Und das konnten die für sich selbst beantworten.

Klar gibt es da nochmal irgendwie jemand, der drüber guckte, ob jetzt da der eine 440 Millionen Euro in die falsche Richtung überwiesen hat. Das fällt natürlich dann schon auf. Aber vom Grundsatz her konnten die das selbst tun. Und jeder Mitarbeiter sollte eigentlich gemessen an seinen OKRs, an seinen täglichen Zielen oder was auch immer, klares, datenbasiertes Feedback bekommen. Und zwar nicht von einem Menschen, das kann dann noch on top kommen, gerade wenn es darum geht, was mache ich denn jetzt besser oder Ideen zu haben, was könnte ich jetzt tun. Ich glaube sehr stark daran, dass das die Produktivität von Unternehmen dramatisch viel besser macht. Das heißt, die Demokratisierung des Datenzugangs, dass das total wichtig ist, kombiniert auch mit Analysten, die fachspezifische Expertise für den jeweiligen Fachbereich haben, um Leuten das zu erklären, weil das ist auch notwendig. Es gibt halt Menschen, zu denen sprechen Daten und die wissen auch, was sie tun sollen. Es gibt aber auch einen relevanten Teil von Menschen, da muss man die richtige Aufbereitung finden. Und ich glaube, das ist gerade sozusagen die Leistung von guten Analysten, dass die halt diese Übersetzungsleistung schaffen. Das heißt, ich glaube, eine Demokratisierung von Daten muss immer auch einhergehen mit sozusagen einer adäquaten Übersetzungsleistung, entweder aus dem Tool, was ich einsetze oder menschlichen Analysten, die diese Übersetzungsleistung übernehmen.

Du solltest idealerweise anhand von möglichst wenig KPIs sehen, ob es jetzt drei sind, fünf oder sieben, da fragst du wahrscheinlich eher irgendwelche Leuten, die sich mit kognitiven Fähigkeiten besser auskennen als ich. Das ist, glaube ich, auch individuell sehr unterschiedlich. Aber dass du sozusagen die wesentlichsten Themen, die dem Individuum das zeigen, ist das jetzt gut oder schlecht? Ich halte das für extrem produktivitätssteigernd, wenn ich das tue. Und ich glaube, das übersteigt die Gefahren von einem dezentralen Datenzugang bei weitem. Aber ich glaube, das ist nochmal ein ganz wichtiger Punkt, was du sagtest, Martin, das darf nicht dazu führen, dass du so eine sehr starke Randomness in dem Ganzen hast, sondern dass quasi die KPI-Basis, die dem zugrunde liegt, dass die halt sehr stark standardisiert ist und von einem Team zentral gepflegt wird. Deswegen bin ich mittlerweile auch eben kein Fan mehr davon. Das Marketing-Team macht seine eigenen Reportings, das Produkt-Team macht seine eigenen Reportings, also jeder macht da so ein eigener so. Du kannst schon spezifische Analysten haben, Aber du brauchst auf jeden Fall ein zentrales Team, was zentral eben standardisiert festlegt, was sich hinter welchen Zahlen verbirgt. Dafür gerade steht, dass die Qualität der Datenabfassung konsistent ist und so weiter. Dass du da nicht so ein Zoo von KPIs hast und unterschiedlichen Interpretationen. Und man ist da schon erstaunt. Also man denkt so, ja, Monthly Active User, was kann da? Aber was Monthly Active User ist, zähle ich den jetzt schon nach 10 Sekunden in der App, nach 30 Sekunden. Da gibt es ja kein richtig oder falsch. Und da die einheitliche Definition zu haben, ist wichtiger, als man so denkt.

Joel Kaczmarek: Schön, also wir haben sechs Fehler durchdekliniert. Wir können ja nochmal ganz kurz zusammenfassen. Fehler 1 war, die Schlüsselergebnisse des Technologiebereichs nicht transparent genug messen. Fehler 2 war, technische Schulden aufzubauen, ohne es zu merken. Fehler 3, mit der Alleskönner-Plattform in Schönheit sterben. Fehler 4, durch zu spezielle Anforderungen zu oft Software selbst entwickeln. Fehler 5, Datensicherheit zu lange vernachlässigen. Und als letztes eben gerade, den Datenzugang nicht früh genug innerhalb des Unternehmens zu demokratisieren. Man kann, glaube ich, noch kleine Hinweise nach hinten raus machen. Vielleicht, wenn ihr das spannend findet, euch das beschäftigt, liebe Hörerinnen und Hörer. Auch unser letzter Podcast zum Thema Skalierung von Produktmanagement, der hält ja auch noch einiges bereit zu Produkt- und Technologieorganisationen, wie man die technisch unabhängig und gut aufstellt. Und es sei auch nochmal auf den Builders Guide hingewiesen, weil da gibt es auch noch ein spannendes Kapitel rund um die Einführung von Development Operations. So, that being said, haben wir alles? Sollte gut gepasst haben, oder ihr beiden?

Florian Heinemann: Absolut.

Martin Schilling: Absolut. Nur diese Podcast-Folge hören und schon hast du einen bestperformenden Technologiebereich. Absolut.

Joel Kaczmarek: Sehr gut. Ich kann aber auch schon sehen, Florian schaut schon mit den Füßen, der will ja an seinen Red Bull-Schrank, will wieder ein bisschen was hacken, will auch mal hier wieder seine Entwicklungsskills.

Florian Heinemann: Auch das ist leider für mein nächstes Leben vorbehalten, wenn es denn das gibt. Genau, ich glaube, das ist leider ein bisschen spät, aber das ist in der Tat, wenn ich eine Entscheidung anders treffen könnte, dann wäre das sicherlich mehr technischen Sachverstand in einem jüngeren Alter aufzubauen.

Martin Schilling: Ja, darf ich da nochmal ganz kurz einhaken? Ich komme gerade aus so einer Art Sabbatical. Das ist mittlerweile, auch wenn man es davor nicht gemacht hat, teilweise eben doch nicht zu spät. Udacity zum Beispiel hat da sehr gute Kurse. Also ich habe jetzt beispielsweise in den letzten Monaten mal gelernt, wie man ein neuronales Netzwerk programmiert oder Python programmiert. Das geht mittlerweile innerhalb von ein paar Wochen, Monaten. Du wirst natürlich damit nicht ein Entwickler. Das ist auch klar. Man versteht die Prinzipien. Also deswegen mein Rat, wer im Tech-Startup-Bereich arbeitet und nicht technischen Hintergrund hat, hier und da mal vielleicht in der Pause über den Urlaub da mal reinzugucken. Das ist schon toll.

Florian Heinemann: Das kann ich auf jeden Fall unterschreiben. Und das idealerweise, bevor ihr Kinder habt.

Martin Schilling: Genau.

Florian Heinemann: Die Zeit nutzt man danach. Sonst wird es erst bei der Rente irgendwas.

Joel Kaczmarek: Sehr gut. Ihr Lieben, vielen Dank.

Florian Heinemann: Macht's gut. Danke euch. Ciao.