Vom Startup zum Unicorn 5 🦄: Technologie skalieren | #Gründen 🛠

00:00:00:

00:00:18: Hallo Leute, mein Name ist Joel Katschmarek.

00:00:20: Ich bin der Geschäftsführer von Digital Compact und du hast wieder eingeschaltet zu einer Folge wo wir darüber sprechen wie man eigentlich vom Startup zum Unicorn wird Und zwar heute.

00:00:28: im fünften Abschnitt dieser Reihe sprechen wir darüber wie man den Technologiebereich skaliert.

00:00:32: Kleiner Disclaimer, wir sprechen über den Technologiebereich eher aus Business und Investoren Sicht.

00:00:37: Wenn du jetzt wirklich Deep Tech möchtest gibt es vielleicht andere Inhalte wie zum Beispiel den Alphalist Podcast.

00:00:42: der ist einher technischer.

00:00:43: Wir sind eher so bisschen businesstechnisch heute!

00:00:47: Skalierungsfehler durch und die man sie vermeidet.

00:00:50: Wenn ich sage wir, dann ist an meiner Seite zum ein wieder der liebe und geschätzte Florian Heinemann.

00:00:55: den kennt ihr als Marketing- und Venture Corrifere schlechthin Und auch Martin Schilling darf nicht fehlen der gerade veröffentlicht.

00:01:01: lieber Martin herzlichen Glückwunsch.

00:01:02: ein großartiges Buch geschrieben hat nämlich genau über dieses Thema Die man vom Startup zum Unicorn wird mit dem schönen Namen Detect Builders Guide to the Galaxy und er ist jetzt Partner bei Techstars.

00:01:13: Glückwünsche zu deinem Buchrelease.

00:01:14: Jetzt könnt Ihr doch endlich mal live bestellen.

00:01:16: also Freunde der guten Unterhaltung geht auf Amazon oder Talia, wo man ihr Bücher bestellt und beschert dem Kollegen mal ein bisschen Umsatz.

00:01:21: Das hat er sich redlich verdient weil er sehr viel Energie und tolle Inhalte in dieses Buch gesteckt hat.

00:01:25: Und heute reden wir wie gesagt über Technologie.

00:01:27: Florian ist eigentlich Tech so dein Part auch bei Project A?

00:01:30: Wenn du mit Gründern zu tun hast oder wärst da der verantwortliche bei euch?

00:01:33: Du meinst jetzt von der Betreuungsseite?

00:01:35: Ja!

00:01:35: Wir haben ja technisches Team also wirklich super CTO der das macht und bei den technischeren Themen von der Partner-Seite ist es eigentlich eher Uwe Hausmann, weil der deutlich näher am Gerät ist als ich.

00:01:45: Ich bin eher so für die Marketing, aber für die weicheren Themen.

00:01:48: Und ich fand einen ganz schönen Impuls.

00:01:50: Martin hat da angeregt ob wir nicht mit so einer kleinen Case study starten wollen?

00:01:53: Nämlich mit der Night Capital Group.

00:01:56: sehr wer sich ein bisschen mit Börse beschäftigt, sehr visibles Thema.

00:01:59: Martin nimm uns doch mal mit unter die Haube weil da kann man glaube ich das Thema Textkalierung am offenen Herzen quasi nochmal nachsezieren.

00:02:06: So ist es schön.

00:02:07: Also, es war in einem verregneten Nacht als ein junger Programmierer von Night Capital die sogenannten SMARS-Servers geupdatet hat.

00:02:17: Die SMARS Servers waren damals zuständig für den automatisierten Kauf der Aktien an der New Yorker Börse.

00:02:23: Diese junge Kollege hatte den Code bei sieben Richtig kopiert und einen vergessen.

00:02:29: Night Capital hat am Morgen darauf unbeabsichtigterweise Hundertfünfzig Aktien im Wert Milliarden US-Dollar gekauft innerhalb von fünfundvierzig Minuten, bevor der Fehler bemerkt wurde.

00:02:40: Die Firma hat es dann auf Versuch zu stonieren über die Trade Commission, die hat das abgelehnt und im Endeffekt wurde die Firma zu einem Bruchteil des Wertes wenige Monate nachverkauft.

00:02:47: Die firma hatte kein Vier-Augenprinzip im Technologiebereich, hatte keine automatisierten Tests sie hatte Fehlermeldung nicht sauber klassifiziert.

00:02:54: also typisches Beispiel wo ein Technologie Bereich über Jahre super funktionieren kann einen Fehler und die Firma ist Bankrott.

00:03:02: Das muss man können.

00:03:02: Also Florian kauft sieben Milliarden in Aktien eigentlich jede Woche, aber der nimmt sich halt ein bisschen mehr Zeit als forty-fünf Minuten.

00:03:08: Aber da

00:03:08: ich das hier über eine traditionelle Bank mache gibt es immer noch einen Vier-Augenprinzip nicht mit diesen modernen Neobrokern!

00:03:13: Da ist das natürlich gegen das einfach so...

00:03:16: Aber ich glaube, ich hab das hier auch schon mal im Podcast erzählt.

00:03:18: Ich war ja früher mal für eine Firma tätig.

00:03:19: Serene heißt die in Potsdam und es war ganz cool weil der Johannes Bonett, der Geschäftsführer dort, er war auch schon ein Podcast ... Und der hat mir das damals echt so von der Pieke auf beigebracht, mal Software auch so'n Stück weit als gebildet zu sehen und in so ne Bildlichkeit zu verschieben.

00:03:32: Die haben so Städte-Modelle ganz lustig Damals mal in den frühen Phasen gebaut.

00:03:35: Da konntest du dein Software-Code ansehen wie so'ne drei D-Karte und dann kannst du sehen welches Gebäude war hoch aber schmal.

00:03:40: Das heisst wenn die Grundfläche irgendwie nicht gut war und das Gebäudetzuch droht ist umzustürzen du sozusagen so Predictive Maintenance machen.

00:03:47: 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 kurz vor so einer Versicherung ausdrucken würdest auf Papier Der Papierstapel wäre so hoch wie ein dreißigstöckiges Hochhaus.

00:03:59: 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 fünfzig unterschiedliche Teams vielleicht an so einem Hochhaus arbeiten aber sie gar nicht wissen was machen gerade die anderen.

00:04:11: Das heißt du musst es ja auch irgendwie immer zusammengeführt kriegen.

00:04:13: So, that being said, ich glaube ein echt ganz schönes bittiges Beispiel von dir Martin mit Night Capital.

00:04:17: Und dann gehen wir doch mal direkt rein in diese Top-Skalierungsfehler.

00:04:20: also der erste Fehler und man darf dazu sagen es ist auch zu großem Teil immer aus deinem Buch abgeleitet haben wir genannt die Schlüsselergebnisse des Technologiebereichs nicht transparent genug messen.

00:04:29: Heinemann ist ja auch Fan vom Messen.

00:04:30: aber fangen wir an kurz den Fehler zu beschreiben Martin.

00:04:32: Gerne!

00:04:32: Also eines der Themen die man oft sieht gerade eine Schölle von Start Up to Scale up ist dass das Technologiebereich manchmal mit der Messung seine eigenen Leistungen hinterherhängt.

00:04:42: Da ist es wichtig als Gründer, als Führungsteam zu achten.

00:04:45: Natürlich auch als CTO und Technologieorganisation klarzusehen.

00:04:48: Es gibt vier Bereiche in denen eine Technologie-Organisation ihre Leistungen messen kann.

00:04:53: Also erstes Produktivität, typisches Schlüsselergebnis die sogenannte Deployment Frequenz pro Entwickler pro Woche also dass du irgendein Maß an Produktivitäten hast.

00:05:02: Leistung und Zuverlässigkeit der Plattform.

00:05:05: Das sind so typische Themen, API-Reaktionszeit oder Prozentverfügbarkeit.

00:05:08: Diese berühmten vielen neuner KPIs.

00:05:11: Also, ninety-neinzig, neun, neuen Prozent Verfügwahrheit eines Start-Stack-Scalabs heißt in etwa eine Stunde Offline pro Jahr.

00:05:18: Neunneinzig, neunein, neuin Prozent heißt bis fünf Minuten Offline.

00:05:21: Dazwischen bewegen sich die meisten Startup Scalabs.

00:05:24: Da natürlich Code.

00:05:25: Qualität hat man jetzt gerade bei Night Capital.

00:05:26: Anteil des Codes, der automatisiert getestet wird oder Anteil von automatischem Pull & Request.

00:05:31: getestet werden diese typische Themen dort.

00:05:33: Und dann vierten es natürlich Sicherheit, also so Schlüsseergebnisse wie Verhältnis erfolgreiche Cyberangriffe zu allen Cyberangriffen oder durchschnittliche Zeit zur Erkennung einer Sicherheitslücke.

00:05:43: So und das sind so typische vier Themen, die man im Technologiebereich Schlüssergebnisse messen

00:05:46: kann Und ich meine da auch schon mal wieder den Faktos Skalierung.

00:05:49: Also, ich erinnere mich noch bei meiner letzten Gründung war auch mal das Thema Da hatten wir irgendwelche Server und dann hieß es neunundneinzig Prozent Verfügbarkeit und rechnest du durch ein Prozent Non-Verfügbarkeit auf einen Jahr sind schon fast vier Tage, ne?

00:05:58: Also die vier Tage offline!

00:06:00: Das hat schon relativ hoch.

00:06:01: Florian Du bist ja auch immer Daten getrieben Messgetrieben vor allem.

00:06:04: Was ist denn so dein Blick auf was Martin auch gerade geschrieben also einerseits Produktivität Auf der einen Seite Dann irgendwie Plattformverfügigkeit und Qualität?

00:06:11: Wie geht ihr mit dem Thema messen von Technologiequalität und Produktivitet um?

00:06:14: Ja vielleicht ganz konkretes Beispiel bei uns, wo wir investieren dabei helfen, systematische Qualitätssicherung zu implementieren und die dann eben auch so automatisieren.

00:06:22: Das ist jetzt so eines der kernten Themen, wo Wir versuchen zu helfen, Best Practices eben zu etablieren weil Ihr häufig gerade in den Neuronstardubs probiert investieren, wo dann vielleicht einen technischen Mitgründer hast, der aber häufig ja noch nie eine IT-Abteilung mit dreißigvierzig Leute geführt hat und das ist schon ein ganz wesentlicher Teil des professionellen Managements von so einem Techbereich und dass es auch häufig etwas warum wir da stark auch propagieren erfahrene Mitarbeiter reinzuholen.

00:06:45: Du hast ja immer so ein bisschen den Trade-off zwischen, setzt du auf Potenzial und heirast eher nach Potenzials.

00:06:51: gibt es diesen Leuten Raum oder du holst halt erfahrene Mitarbeiter.

00:06:54: Und du musst von Bereich zu Bereich eigentlich schauen, wo schlägt Erfahrung Potenzial und wo ist das eigentlich umgekehrt?

00:06:59: Und ich glaube gerade in diesem technischen Bereich da Best Practices zu implementieren hilft es Leute reinzuholen die einen gewissen Seniorettätsgrad haben und sowas schon mal in einer exzellenten Form gesehen haben.

00:07:10: Das ist zum Beispiel auch etwas wo wir dann sehr stark drauf achten.

00:07:12: also sprich implementier mir das nicht selbst oder schreiben den Menschen das vor Wir legen halt nahe und helfen dabei zu rekrutieren eine Person macht hat.

00:07:20: 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.

00:07:30: Und das ist glaube ich sozusagen die Killer-Kombinationen im Techbereich, also innovative Personen.

00:07:35: Das eben zu kombinieren mit erfahrene Leuten, die genau so was da reinbringen, weil das schwierig im Tech Bereich ist ja... Anders jetzt als im Marketingbereich wo du letztendlich an zwei KPIs oder drei sehen kannst bist einem guten Weg oder nicht.

00:07:45: und hier hast du ja im Marketing Bereich würdest du sagen zwischen Conversions Also eine gute Abteil besorgt dir doch nicht dafür dass jetzt die Applikation auch kundenfreundlich ist du letztendlich von dem endgültigen Ziel bist.

00:07:56: desto eher musst du ja sozusagen mit diesen Zwischen KPI's arbeiten, die halt gewisse Elemente einer erfolgreichen IT-Applikation oder der Infrastruktur oder Organisation abbilden.

00:08:05: Aber du brauchst eben je mehr Du wegrückst vom Endziel, brauchst Du halt mehrere Sachen und das ist auch genau das was Martin beschrieben hat Dass Du halt eine Reihe von Indikatoren brauchst, die Dir dann hoffentlich ein gutes Gesamtbild geben.

00:08:15: Natürlich je mehr KPIs Du hast, desto schwerer ist dann natürlich das Gesamtbild zu interpretieren.

00:08:20: Und ich glaube da ist eben auch nochmal wo Erfahrung hilft.

00:08:23: Was von diesen Elementen ist jetzt eigentlich?

00:08:25: wie wichtig spielt das auch zusammen.

00:08:27: Vielleicht einmal anschließend an das, was Florian hat gesagt zum Thema automatisierten Tests.

00:08:31: Da haben wir ein ganz spannendes Beispiel gehört.

00:08:33: also es gibt Scale-Ups die kaufen sich im Prinzip ein iPhone und ein Android Gerät und programmieren dann einen Systemtest der Erfolgung des Machtes.

00:08:41: Der lädt auf beiden Geräten vierundzwanzig sieben die verschiedenen Versionen in der App aus verschiedenen Ländern runter.

00:08:48: jetzt in dem Fintech Beispiel macht eine Transaktion pro Gerät löscht die Applikation und lädt sie wieder neu.

00:08:54: so ein Systemtest wurde im Prinzip sicherstellt, 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 oder stimmt was nicht.

00:09:04: Apropos Tooling, also ich mache jetzt mal frecherweise nochmal für die Kollegen aus Potsdam Werbung weil ich fühle mich den ja auch noch ein bisschen verbunden wenn ich früher da gearbeitet habe.

00:09:11: Bei Serene fand ich das mal ganz interessant.

00:09:12: die haben gesagt sie bauen so einen Digital Boardroom Die haben Software Analytics und Process Mining Technologien benutzt um Software irgendwie zu visualisieren.

00:09:19: dass du halt auch als technischer Entscheider oder sagen wir als Budgetgeber der vielleicht nicht technisch basiert ist versteht was da passiert.

00:09:24: Martin was ist denn so dein Tipp?

00:09:26: Wenn wir jetzt drüber reden Der Fehler ist eigentlich die Schlüsselergebnisse im Technologiebereich nicht transparent genug zu messen.

00:09:30: Wohin tue ich das?

00:09:31: Also sind es so die Serenes dieser Welt.

00:09:34: Wer Tools zum Beispiel auch bei N-Twenty-Six eingesetzt?

00:09:36: Wir waren und ich bin da ein Fan von großer Einfachheit.

00:09:39: Die ganz genauen technischen Monitoringtools kenn'n nicht, da gibt's ne ganze Reihe von Prometheus

00:09:44: etc.,

00:09:45: aber wir haben immer versucht es so einfach wie irgendwie möglich zu halten.

00:09:48: Also bevor wir großen Tools einführen, haben wir das mal Google Sheets verwendet.

00:09:51: Und wenn wir Tools angesetzt haben dann eben natürlich der Sports.

00:09:54: Bin ich ein großer Fan von Pragmatismus!

00:09:56: Gehen wir mal weiter zum zweiten Fehler.

00:09:58: Kennt jeder Technical Debt hat mir ja schonmal einen Podcast mehrfach glaube ich Technische Schulden aufzubauen ohne es zu bemerken wenn man quasi zu pragmatisch unterwegs ist.

00:10:06: Martin, erzähl mal von der Front!

00:10:07: Erstmal was sind denn technische Schulden?

00:10:09: Also technische Schuld nimmt man dann auf, wenn man eine Lösung programmiert die schnell ist aber die man nacharbeiten muss.

00:10:16: 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.

00:10:24: ja so das musst du in der Regel nochmal irgendwann nochmal anpacken.

00:10:26: Jedes Start-up nimmt technische Schuld auf.

00:10:29: Das ist normal und auch okay, so.

00:10:31: jetzt gibt es aber ein paar Prinzipien die wichtig sind um diese technischen Schuld in Anführungszeichen zu managen.

00:10:35: also erstens einen Monolithen am Anfang aufzubauen ist oft die Empfehlung.

00:10:40: Beispiel Amazon heißt der monolith bis heute läuft soweit ich weiß obidors oder LinkedIn heißt er leo.

00:10:45: im prinzip heißt es Am Anfang Monolith.

00:10:47: du programmierst eine software architektur bei der alle Komponenten Also Datenbank Kundenanwendung Server anwenden auf einer einzigen langen Code Basis Eben ein Monolith.

00:10:57: Zu dem großen Vorteil, das kannst du schnell programmieren.

00:10:59: zu den großen Nachteilen wenn du irgendwas änderst an irgendeine Stelle musst du den Code immer wieder neu bereitstellen.

00:11:04: Warum ist es wichtig am Anfang?

00:11:06: Wenn du eine modulare Architektur im Anfang baust, also du hast zum Beispiel einen Doktor-Patientenmarktplatz.

00:11:11: Du baust dafür eine modulaere, elaborierte Artierarchitur und dann pivotierst du hin zu einer App nur für Patienten, musst du sehr viel neu machen.

00:11:18: Deswegen wird am Anfang oft gesagt mach pragmatisch ein Monolithen weil du schnell abheben kannst.

00:11:21: Und jetzt gibt's noch zwei oder andere Punkte.

00:11:23: können wir gleich diskutieren wie man auf der Basis dieses Monolithens dann schnell die technische Schuld nicht so groß werden lässt?

00:11:28: Ja vertieft doch gerne mal, was du da noch an Input hast.

00:11:29: Ich steuere ja auch weil ich immer dachte Monolithen seien schlecht aber jetzt lerne ich das Gegenteil!

00:11:33: Also natürlich ist eine monolitische Struktur die du am Anfang entwickelt hast und nicht richtig weiterentwickelst schlechte problematisch wenn du hoch skalierst.

00:11:40: Das ist gar keine Frage.

00:11:41: Aber aus der Erfahrung raus, wenn du Startups hoch fährst kommt man auf den Monolithn nicht vorbei.

00:11:45: so jetzt ist aber sehr wichtig.

00:11:46: genau wie du sagst Jetzt muss man eine ganze Reihe von Themen anpacken damit der Monolith nicht zum Problem wird.

00:11:50: also erstens jede IT Architektur Entscheidung die die technische Schuld weiteraufbaut sollte dokumentiert werden.

00:11:56: Also das heißt, du setzt früh einen Standard.

00:11:58: Wo du sagst jeder Entwickler der hithilische Entscheidung betrifft muss dokumentieren also sowas wie Problemen, technische Ansatz, Panpräventierungsbeispiele so drei bis vier Seiten Dokumentation.

00:12:08: dann denken Entwickler einfach viel präziser drüber nach vor sie was tun und werden sich dieser technische Schuld mehr bewusst.

00:12:16: Und dann eben wichtig, die größte Wurst nimmst du mehr und mehr aus dem monolithen Raus.

00:12:20: Also gehst hin zu einer sogenannten Modulareninfrastruktur.

00:12:22: das heißt einfach Du hast zum Beispiel so einen Payment Service Verifikations-Service.

00:12:27: Der große Vorteil ist dann kannst du Teams parallel und unabhängig an den verschiedenen Modulen arbeiten lassen.

00:12:33: Das ist der entscheidende Punkt.

00:12:34: also das heißt da kann ein Team die Verifikation aufs nächste Level bringen.

00:12:37: Parallel kann ein team Payment service arbeiten.

00:12:39: Florian, wie viel beschäftigst du dich so mit Technical Debt?

00:12:42: oder ihr euch als Investor?

00:12:43: ist es sehr fern von euch?

00:12:44: Überhaupt

00:12:45: nicht.

00:12:45: 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 also 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 dass schränke ich in deiner weiteren Entwicklung ein.

00:13:05: Also die Awareness für technical debt zu schaffen sogar ich, also obwohl ich jetzt ja nicht große IT-Experte bin.

00:13:12: Weil wir eben sehr regelmäßig sehen dass eine der Hauptgründe ist warum die Skalierung dann im späteren Verlauf 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 idealerweise sollte sich die IT Infrastruktur noch 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.

00:13:34: Dass man rechtzeitig darauf achten sollte eben vor der wirklichen Skalierung diesen Schritt raus aus der monolithischen Struktur geschaffen zu haben den Schritt raus jetzt im Datenbereich aus einer Silo.

00:13:43: denke, dass das total wichtig ist.

00:13:45: Aber das wird häufig so bisschen vor sich hergeschoben wenn du solche Themen vor der Skalierungen nicht löst.

00:13:50: es wird halt immer schlimmer.

00:13:51: Das ist ja letztendlich die Situation.

00:13:53: gerade im Corporate Kontext sprichst du ja immer von Legacy IT also wo du wenn du so größeres Unternehmen hast jetzt immer so im Daten Bereich wo ich einfach ein bisschen mehr dran bin völlig üblich, dass ein größeres Unternehmen Kundendaten in sechs verschiedenen Systemen hat die alle nicht miteinander korrespondieren.

00:14:07: Ja, und das ist ja sozusagen genau das was passiert.

00:14:09: Wenn du als Start-up technical debt nicht versuchst von Anfang an zu verhindern oder sozusagen rechtzeitig das in Ruhe zu managen und dann bist du eigentlich nicht mehr handlungsfähig Und dann ziehst du natürlich die komplette Energie aus so einer Organisation.

00:14:21: und dass es auch das wo jemand selbst wenn er keine technischen Sachverstand hat Wo die Konsequenz dessen eigentlich sehr sehr transparent wirkt Das erlebst du sehr sehr regelmäßig in corporates.

00:14:30: Du hast da ja Menschen die sind sehr emotioniert diese wollen viel umsetzen und weiter Die scheitern aber letztendlich daran dass die technische Entwicklung Struktur oder die technische Infrastruktur.

00:14:38: Die Ideen, die diese Menschen haben dann eigentlich nicht mehr umsetzt war macht und das sorgt im Prinzip dazu dass die Leute wenn das 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.

00:14:51: 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-technischen Gründern die awareness zu schaffen warum das so wichtig ist.

00:15:00: nochmal kurz Brücke zurück zum fehler.

00:15:01: eins zu des was vorhin gesagt hat ne Du siehst das an Produktivitätsverlust Deployment pro Person, pro Woche, Entwickler pro Woche.

00:15:08: Die geht runter wenn die technische Schulter hoch

00:15:11: sind.".

00:15:11: Und was du natürlich auch siehst ist der Anteil den du brauchst um allein die technischen Infrastruktur am Leben zu erhalten.

00:15:16: Selbst wenn die Leute dann viel machen verbringen die Leute bei einer schlecht aufgesetzten technischem Infrastruktur sehr viel Zeit damit den Status quo irgendwie zu maintainen und wenig damit in Richtung Feature-Fortschritt zu arbeiten.

00:15:28: Da hat noch mal so einen ticken anderen Engel weil man könnte ja sagen Ja die Leute sind weiter produktiv, die deployen waren sich viel aber sie deployen im Prinzip halt in die Bestandsinfrastruktur, ohne dass es eigentlich zu einer kundenseitigen Weiterentwicklung der Plattform kommt.

00:15:40: Und das ist auch noch mal ganz spannend.

00:15:41: ein weiterer Aspekt den man da reinbringen könnte.

00:15:43: Fehler drei!

00:15:44: Wenn wir gerade bei Fehler zwei zu pragmatisch waren dann sind wir vielleicht bei Fehler drei zu wenig pragmatig und zwar mit der Alleskönnerplattform in Schönheit zu sterben.

00:15:52: als dritter Fehler erinnert mich ein bisschen an den Max Zuckerberg Satz Dann is Better Than Perfect.

00:15:56: Nimm uns mal mit unter die Haube Martin.

00:15:57: was sind also deine Befunde?

00:15:59: Du hast oft, gerade wenn du unerfahrene technische Führungskräfte hast, die da manchmal versuchen eine Alles-Könner-Platform an zu bauen.

00:16:07: Das heißt das ist jetzt genau was wir gerade hatten.

00:16:09: und mal nicht zu sagen pragmatisch kommen, jetzt bauen wir meinen Monolithen und gehen mal raus damit wir schnell in die Lernzyklen kommen also dass wir Kunden Feedback holen können sondern die dann sagen ne Stopp!

00:16:17: Wir machen jetzt erstmal ein Jahr ganz präzise eine modulare Tech Infrastruktur damit wir auch wirklich auf zehn Millionen Kunden skalieren können.

00:16:26: Das ist oft ein Fehler.

00:16:28: oft pivotieren und du weißt noch gar nicht, wie genau deine Plattform aussehen muss.

00:16:33: Es kann eben schon sein dass du einfach mal ein Jahr lernst und dann so einen Punkt kommst wo du komplett nochmal von vorne anfängst oder auch technologisch nochmal wirklich bei null anfängest.

00:16:41: Deswegen ist es wirklich super wichtig da pragmatisch zu sein so schnell wie's geht mit Kunden zu lernen!

00:16:47: Du musst fünfzehn Rechnungen pro Monat verschicken.

00:16:49: Da brauchst jetzt kein ausgeglügeltes Abrechnungssystem.

00:16:52: oder eine Dataseinsplattform muss man nicht einführen wenn du erstmal MVP-Status Nutzerfeedback einholst.

00:16:57: Das ist so die große Gefahr hier.

00:17:09: Du brauchst kein Data Warehouse, um eine eine Million Euro Umsatzfirma zu führen.

00:17:14: Das geht auch mit Excel wunderbar muss halt bewusst sein dass wenn die Skalierung dann kommt dann bräuchte man es irgendwann.

00:17:20: du willst natürlich idealerweise die Prozesse wie die Leute auch arbeiten frühzeitig an das gewöhnen wie's denn mal sein wird.

00:17:27: also du brauchst halt schon so eine gewisse ich nenne das immer front loadedness also sozusagen für das Wachstum was dann mal kommen wird schon die richtigen Voraussetzungen schaffst diesen tradeoff bewusst zu managen und da bewusste abwägungsentscheidung und die auch innerhalb des Managements zu teilen, weil es ist glaube ich ganz wichtig dass das allen Leuten die in der Firma irgendwie was zu sagen haben.

00:17:47: Das ist immer auch ein Stück weit müssen das halt die Top-Führungskräfte mittragen.

00:17:50: Und ich glaube unser Job kann ja eigentlich nur sein sozusagen identifiziert für euch die Trade Offs und legt für euch gemeinsam als Management Fest wie ihr euch da positionieren wollt.

00:17:58: und ich sage halt immer je mehr Geld du hast, je mehr Ressourcen du hast desto stärkere Frontloadedness kannst du dir halt leisten.

00:18:05: Desto stärker.

00:18:05: frontloadednes macht auch Sinn.

00:18:07: die Wahrscheinlichkeit die Skalierung kommst, steigt natürlich.

00:18:11: Das ist genau der Unterschied zwischen Adventure Capital finanzierten Firma und einer Bootstrapped-Firma.

00:18:17: Bei der Bootstraptfirma gibt es diesen Tradeoff nicht, sondern da kannst du im Prinzip nur entlang der Wachstumsentwicklung ein bisschen mithoppeln und hoffen das dann irgendwie funktioniert.

00:18:25: Und der Witz bei Adventure Capital ist ja gerade dass du dir eine gewisse Frontloadedness leisten kannst.

00:18:30: Das Bewusstsein dafür zu schaffen, dass man diese Tradeoffentscheidung hat und dass es halt nicht unbedingt immer cool ist den Bootstrapping Modus zu fahren wenn du eigentlich sieh Millionen Euro... auf deinem Konto hast, sondern dass es die schlaure Entscheidung sein kann an gewissen Stellen diese Frontloadedness an den Tag zu legen.

00:18:44: Das ist ja eigentlich mein Job als Coach zu sagen ich weiß auch nicht was das richtig ist aber ich kann euch sagen ihr habt diesen Trade-off und da müsst ihr euch halt überlegen wie's ist.

00:18:51: Das is sozusagen my job!

00:18:53: Fehler vier der Doktor sehr schön an und ich glaub den kennt jeder Unternehmer die typische Make or Buy Frage.

00:18:59: und der vierte Fehler wäre durch zu spezielle Anforderungen zu oft Software selbst entwickeln.

00:19:03: Und ich fühle mich wärmstens erinnert, als wir damals bei Gründerstehen uns überlegt hatten eine Datenbank zu bauen und wir vor der Frage standen gibt es irgendwie coole Services mit denen man Datenbanken darstellen kann.

00:19:12: Also heute gäbst du was so wie Airtable zum Beispiel?

00:19:14: Damals gab's das nicht so.

00:19:15: dann haben wir selber losgelegt und mit allen Schmerzen die man dabei so kennt.

00:19:18: also ich glaube das kennt jeder Unternehmer wenn du immer in dieser Frage schießt nämlich Sachen von der Stange pass sie mir an oder baue ich komplett selber Oder gibts vielleicht noch irgendwas dazwischen?

00:19:25: Martin berichte mal aus deiner Recherche.

00:19:28: Das ist ein ganz wichtiges Thema, vor allem für nicht technische Start-up-Führungskräfte.

00:19:33: Um die Hintergründe zu verstehen.

00:19:34: Also Entwickler entwickeln gern!

00:19:36: Ja das muss man sich immer vor Augen halten.

00:19:38: also wenn man intern fragt hey sollen wir das kaufen oder sollen wir es entwickeln haben viele Entwickler die Tendenz zu sagen und klein entwickeln wird es Wir sind ja Entwickler.

00:19:47: Ich mache mal zwei Beispiele als Entwürdigstix wo wir uns glaube ich richtig entschieden haben bei einem falsch.

00:19:50: Also das falsche Beispiel wo uns falsch entschieden haben war wir haben einen Tool nachprogrammiert zum Routing von Anfragen im Kopf Kontaktcenter, ja?

00:19:58: Also ein englischer Kunde Onboarding muss zu einem englisch sprechenden Spezialisten-Onboarding weiterentwickelt werden.

00:20:03: Da gibt es auf Tools auf dem Markt und da hat unser Tech Team gesagt, das müssen wir unbedingt entwickeln!

00:20:06: Das haben wir gemacht, dann ist das Tech Team gegangen und wir hätten es vom Marker von zwei Fehlern.

00:20:09: Weil eine Routingmaschine in einem Kontaktcenter kaum zur zusätzlichen Kundenbegeisterung beiträgt – das merkt der Kunde kaum.

00:20:17: Wir haben uns auf der anderen Seite gut entschieden einen Chatboard selbst zu entwickeln obwohl es ja viele Chatbots von der Stange gibt weil wir glauben dass der Chatbot irgendwann einen Kunden begeistern wird.

00:20:26: Wie kann ich mir den BMW leisten?

00:20:28: Ja, also der Chatbot wird dann vergleichen.

00:20:30: Was bekomme ich?

00:20:31: Was nehme ich ein und was kostet der BMW?

00:20:33: so?

00:20:33: Also wird direkt eine Kundenbegeisterung auslösen.

00:20:36: Weitere Beispielen.

00:20:37: Salando hat an irgendeinem Punkt die internen Warenmanagement-Systeme nachprogrammiert weil sie damit die Pakete schneller und zuverlässiger den Kunden aussiefern können.

00:20:45: Deswegen wenn mein Appell an jeden der da wo diese Entscheidung steht sich ganz klar zu überlegen kreiert dieses möglicherweise zu entwickelnde Tool dieser Service Kunden Begeisterungen.

00:20:54: Wenn ja... Kann das ein Grund sein, selbst zu entwickeln?

00:20:57: Florian,

00:20:57: da interessiert mich ja mal deine Meinung.

00:20:59: Weil vor der Frage steht man so oft als Unternehmerin, finde ich, dass man sich fragt wann mache ich was selber?

00:21:04: Wann kaufe ich was von der Stange?

00:21:06: Findest du die Formel von Martin zu sagen wenn es die Kundenzufriedenheit verbessert und nicht mir da irgendwie so ein Anpferd wahntisch zieht?

00:21:12: ist das so der Wahrheit?

00:21:13: letzter Schluss?

00:21:14: Ist das worum es anfängt?

00:21:14: Ja

00:21:15: ich würde vielleicht einen Ticken bereiterfast alles wo du dich gegenüber der Konkurrenz differenzieren kannst Das kann Kunde sein aber das kann natürlich auch für ein Salando das interne Buying Support Tool sein dass in irgendeiner Weise eine Differenzierung gegenüber der Konkurrenz verspricht.

00:21:30: Ich glaube das ist ja sozusagen der Benchmark, ich fand zum Beispiel Zalando hat zum Beispiel überlegt 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 Fünfzig Entwickler reinstecken die dann kontinuierlich an so einem Ding arbeiten.

00:21:46: welcher Google Analytics hat es zu dem Zeitpunkt?

00:21:48: achthundert Entwickler oder tausende Entwickler.

00:21:49: So dann sagt natürlich ok da bitte das replizieren kannst was kannst du da eigentlich gewinnen?

00:21:53: wenn du jetzt besser Web Tracking betreibst und das fand ich jetzt total no-brainer dass man das nicht selbst baut weil das Argument dagegen gewesen ist oh dann trägt ja Google mit was wir so machen wo du denkst so ja OK aber dass sie das jetzt mit inhaltlicher Logik interpretieren können.

00:22:08: I don't know, du übergibst ja selbst die Sachen was du dir so.

00:22:10: Ich würde es ein bisschen breiter fassen überall wo du dich differenzieren kannst das ist sehr häufig gegenüber dem Kunden.

00:22:15: das kann aber tierisch auch etwas anders sein und vielleicht auch wo es dir erlaubt ein weiteres Geschäftsmodell drauf aufzubauen.

00:22:20: Was meine ich?

00:22:21: Also du hast da sozusagen diese Plattform-Charakteristika dass Amazon irgendwann angefangen hat wir brauchten einen cloud basierten Service dann haben sie das für sich selbst entwickelt weil sie es für sich selber braucht und dann haben Sie es direkt so gemacht weil es ja angeblich das Amazon Jeff Bezos Entwicklerprinzip ist der auch kein Entwickler ist übrigens sondern harmloser Investmentbacker bei Training.

00:22:37: Der hat ja in Gepicht, im Jahr two-thausend zwei schon gesagt wir entwickeln alles was wir machen so dass wir Stiritsch auch für dritte Kunden verkaufen können.

00:22:42: Das geht so ein bisschen mit diesem Differenzierungsaspekt einher, weil ich kann ja nur etwas an Dritte verkaufen.

00:22:47: Wenn ich es auch besser mache.

00:22:48: das kann noch ein weiteres Argument sein gerade für ein sehr hohes Ambitionsniveau an Unternehmen.

00:22:53: aber das bedingt natürlich muss man auch fairerweise sagen dass machst du jetzt nicht als kleines Unternehmen sondern das machst du nur wenn 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 sie ist zum Beispiel über einem About You die jetzt ihre Fashion fokussierte e-commerce Plattform dritte anbieten, dass jetzt genauso ein Beispiel dann musst du natürlich auch deine Logistik selbst machen.

00:23:16: Also das sind für dich so Beispiele.

00:23:18: aber wie gesagt ich wollte es eigentlich genau sehen vielleicht noch ein bisschen erweitert.

00:23:22: 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.

00:23:29: So und der fünfte Fehler wäre die Datensicherheit zu lange zu vernachlässigen.

00:23:33: man kennt ja glaube ich mittlerweile sogar aus Film- und Serien immer gerne so diese Team Red Team Blue Geschichten wie man zum Beispiel Sicherheit prüfen kann.

00:23:40: Ich bin mir sicher der liebe Martin hat noch ein paar andere griffigere Beispiele oder Stories dazu rund um das Thema Datensichalt.

00:23:45: für uns.

00:23:46: Die Relevanz von Datensicherheit hängt natürlich auch stark vom Geschäftsmodell ab.

00:23:49: 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.

00:23:56: Also deswegen ein Thema wo man sich oft zu spät damit beschäftigt.

00:24:00: Es gibt so drei Standards, die man als Startup im Griff haben muss.

00:24:03: Erstens, wie Gilles gesagt hat gesagt, du brauchst das mal einen ganz pragmatischen interne Sicherheitsteam überhaupt also sogenanntes Bluteam, 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.

00:24:19: Dann ist es sehr klug einen Externis sogenanntes Penetration Testing, Pentesting-Team zu beauftragen.

00:24:25: Das kann man gut vom Markt kaufen.

00:24:27: Es ist im Prinzip sowie der Besuch beim Zahnarzt.

00:24:29: regelmäßige Untersuchungen sichern langfristig einen schmerzfreien Gesundheitszustand.

00:24:34: also typischerweise machen sie dann sowas wie eine vierteljährliche Schwachstellenprüfung offene Ports

00:24:38: etc.,

00:24:39: die machen Belastungs-Tests als wenn du auf einmal sehr viel mehr Traffic bekommst, die setzen eventuell auch mit ihren externen Bounty-Hunting-Programme auf, wo also freundliche Hacker versuchen Fehler zu finden und du zahlst ihnen für Geld wenn sie Fehler oder Sicherheitslücken finden.

00:24:51: Ganz konkret gibt es so ein zwei kleinere Anbieter, also Kobalt habe ich gehört uns Sys-Sensor Typische, Pentest as a Serviceanbietter und dann die auch die Großen, die Leut, Kabirmini, McAfee

00:24:59: etc.,

00:25:00: die kann man da für sowas fragen.

00:25:01: Florian hilft mir auch immer zu verstehen, wieso das Thema Sicherheit bei Startups und Scale-Ups irgendwie gebaut ist.

00:25:07: Weil mir fallen so zwei bekannte Beispiele ein, fairerweise sind wir beim ersten der Name entglitten.

00:25:11: es gab ja mal diese ich glaube kanadische Dating-Plattformen wo auch viele Homosexuelle gedatet haben, wo dann auch die ganzen Nutzerdaten eröffneten gegangen sind.

00:25:19: Ich weiß nicht, ob es nicht Ashley Madison oder so war.

00:25:23: Das

00:25:23: ist Ashley Madison eine Enabling-Plattform fürs Fremdgehen?

00:25:27: Ashley Madison weiß ich wurde gehackt und gab's teilweise Selbstmode von Nutzern weil ihr Fehlverhalt ... Sowohl

00:25:33: Ashley Madison hatte einen Datenskandal als auch Grindr.

00:25:36: Grindr musste deswegen auch seine IPO Pläne absagen.

00:25:39: Ashley Madison hat glaub ich nie IPO Plänen aber dem Wert wird sicher auch nicht geholfen.

00:25:43: Weil gerade bei dem Thema Fremde gehen will das natürlich jetzt nichts was du gerne möchtest dass das zu breit getreten wird.

00:25:48: Da merkt man aber wie empfindlich so was auf einmal sein kann.

00:25:52: 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.

00:25:59: Oder andere Geschichte und ich meine es ja eigentlich frappierend Amazon mit Twitch wo er glaube ich sogar der gesamte Source Code offengelegt wurde.

00:26:05: Man konnte wie alle Verdienste der größten Twitch Nutzer sehen man staunt ja so ein bisschen.

00:26:08: also du bist nicht vor Gefight wahrscheinlich gehackt zu werden.

00:26:10: Und trotzdem freu ich mich auf der anderen Seite ab wann ist ein guter Zeitpunkt sich über Datensicherheit Gedanken zu machen?

00:26:16: Wie viel davon gehört eigentlich dringend auch auf Vorstandsebene sozusagen betrachtet.

00:26:21: Das

00:26:21: Problem ist eben, das ist ja hier so ein Null- oder Einsthema bei dem was wir bisher beschrieben haben.

00:26:25: da treten ja sozusagen die negativen Folgen wenn du da Fehler machst in unterschiedlichen Dosen schon sozusagen entlang des Weges auf.

00:26:32: Hier tritt ja gar nichts auf bis es dann eben auftritt.

00:26:35: Das ist ja häufig bei so Themen, wo du halt sagst.

00:26:38: So richtig wert generiert das halt erst mal jetzt nicht also in Sinne von aktiven Wert.

00:26:42: Generiert halt nur dann Wert wenn dir halt irgendwas passiert wäre was du dann eben verhindern kannst.

00:26:46: und da merkst du dass fällt Menschen und dementsprechend auch Gründer viel viel schwerer diese Themen zu adressieren weil es eben so null oder eins Charakter hat und eben kein aktive Wirtschaft sondern eben nur eine Wertminderung verhindert.

00:26:58: und deswegen ist es auch ehrlicherweise überhaupt nicht so leicht dafür Awareness zu kreieren.

00:27:03: interessiert sich hier für ein kleines bevor die Mich-Hecke, der Hecken, die doch zerlande oder in den sechsundzwanzig oder irgendwas so.

00:27:08: Und das kann natürlich so sein und häufig ist es ja auch so.

00:27:11: Es geht aus wie mit so GDPR Verstößten, da denk ich's auch Ja, weil mich findet doch die Behörde nicht, wenn sich erst mal die Autos oder wir noch immer kümmern.

00:27:18: Das kann so sein!

00:27:19: Und viele kommen damit natürlich auch durch.

00:27:21: aber für uns als Venture Capitalist oder 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.

00:27:27: Die Schwierigkeit dabei ist natürlich auch klaren n-sexton zwanziger Zerlanden oder so können dann auch wirklich permanent Mitarbeiter dieses Thema abstellen, Server-Sicherheit und so weiter.

00:27:36: Für die meisten kleineren Startups 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 an eigene Strukturen ab einer gewissen Größenordnung aufzubauen.

00:27:52: Es ist in der Tat nicht leicht die Awareness dafür zu schaffen weil es dir aber natürlich konkret bei den nächsten Finanzierungsrunden nicht hilft.

00:27:58: Man sieht aber – und das ist schon ganz spannend – dass gerade wenn du so wachstumsinvestoren hast due diligence machen.

00:28:03: Also jetzt nicht unbedingt die Tiger Globels dieser Welt, ich glaube nicht dass sie das prüfen aber sozusagen Leute die in spätere Phasen reingehen, die prüften so was zum Beispiel mit.

00:28:11: auch da ist es wieder 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.

00:28:22: Es ist wieder aufwendig und nervig Und deswegen versuchen wir auch da frühende gewisse Geiden zu geben und auch Dienstleister an die Hand zu geben Auch wieder in einem Phasemodell also für alles, was wir so machen.

00:28:32: So Phasenmodelle zwar, also wenn du ganz klein bist dann ist das der richtige Ansatz, wenn du ein bisschen größer bist, dann ist da der richtige ansatz.

00:28:38: Und Phasemodellen auch für diese Cyber Security die für das jeweilige Startup relevant sind, da so eine Art Zielbild im Kopf zu haben für die jeweiligen Entwicklungsphase sehen wir schon auch mit als unsere Aufgabe

00:28:48: an.

00:28:49: Also aus meiner Sicht spätestens bei Series A muss man das substanziell investieren, also einfach auch ein kleines Internist-Team.

00:28:55: Spätestens dann auch haben.

00:28:56: es gibt ganze Branchen und Organisationen von Cyberkriminellen die versuchen dort Startups natürlich auch größere Firmen abzuziehen ja beispielsweise in der Finanzindustrie.

00:29:05: Es gibt quasi die Sicherheitsteam beispielsweise der Fintechs Und es gibt eine Antigruppe da draußen Die alles versucht um gerade Finteks oder Startups wo man halt schnell Geld irgendwie abziehen kann denen auch Geld weg zu nehmen oder die Kundengeld wegzunehmen.

00:29:18: Das ist ein schlummern Risiko.

00:29:20: Wenn dich nicht darum kümmert, kannst du in einem Morgen aufwachen und auf einmal deine Kundendaten im Internet finden!

00:29:25: Okay, also ich lerne jetzt, Florian.

00:29:27: Dass man sicher leider eher als Kostcenter denn als Profizenter sieht ist deswegen vernachlässigt weil nicht direkt Umsatzwachstum.

00:29:32: Jetzt gibt's ja noch den anderen Faktor Mensch bei Software.

00:29:35: Ich muss gerade an diese Geschichte denken hier Karbanack damals Diese russische Hackergruppe die dann von Banken hunderte Millionen geklaut hat indem sie die Mitarbeiter über so Fishingmails Also dieses Social Engineering Geschichten quasi geknackt haben.

00:29:47: das heißt die haben den E-Mails mit irgendwie Kästchenvideos oder sowas geschickt.

00:29:50: Die haben die geöffnet.

00:29:51: zack waren sie drin und haben sich die Kameras von da aus gehackt.

00:29:53: Haben die kurz einbetrachtet Ist in der Start-up-Branche, wenn du mit Unternehmen zu tun hast, so was irgendwie ein Thema?

00:29:59: Dass Mitarbeiter mittlerweile auch drauf trainiert werden sich gegen solche Geschichten zu wappen und es auf dem Schirm zu haben.

00:30:03: Ich

00:30:03: glaube ich ist eher die Ausnahme

00:30:05: Hätte ich jetzt irgendwie

00:30:05: ausprobiert.

00:30:06: Also ich bin jetzt an diesem Thema nicht so nah dran aber das will mir jetzt neu beziehungsweise würde mich überraschen.

00:30:12: Aber wie oft hast Du denn schon erlebt?

00:30:13: Jetzt kommt ja auch nicht immer alles raus Ja dass Startups auf solchen Wegen gehackt wurden!

00:30:17: Ist es denn ein realistisches Problem trotzdem?

00:30:20: Auf jeden Fall Es ist halt kein Problem, bis es dann eben ein Problem ist und dann ist das eben ein großes Problem.

00:30:24: Das kommt deutlich häufiger vor als man denkt.

00:30:27: 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 nix ist was du jetzt auch in Richtung deiner Investoren teilst unbedingt.

00:30:39: Was ja auch zum Teil im haste ist in dem Bereich so Erpressungsversuche wo du weissrussischen Heckerring hast der sagt wie machen wir die Nile of Service Attacke es sei denn überweist in Bitcoin hunderttausend irgendwas?

00:30:50: weil das dann auch hier entschieden wird.

00:30:51: Überweisen wir jetzt, aber so kleinere Dinge tauchen ja gar nicht richtig auf ist auf jeden Fall etwas auch wenn es erstmal jetzt vermeintlich langweilig ist wo man auf jeden fall Prozesse verhaben sollte und dokumentierte Vorgehensweisen.

00:31:03: Gut, kommen wir zu unserem letzten Fehler.

00:31:05: Bis dato haben wir gesprochen über Daten.

00:31:07: sicher der ging es ja quasi um die Handhabung von Daten nach außen.

00:31:10: jetzt gibt's hier 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.

00:31:18: Martin erzähl mal was ist damit gemeint?

00:31:20: Früher war es ja so, dass die Arbeit mit Daten in der Hand von wenigen Experten lagen.

00:31:25: Da hast du dann ein Data Science Team gehabt, vielleicht ein zentrales Datenteam.

00:31:28: Heutzutage gibt es immer mehr Start-ups und Scale-Ups, in denen zwei Drittel aller Mitarbeiter regelmäßig mit SQL-Datenanfragen starten.

00:31:35: Also du hast die Tendenz sowieso schon, dass viele Rollenfiele Teams eben mit Daten arbeiten müssen.

00:31:40: 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, SQL, Curies baut und dann verschiedene Arten von KPI's berechnet.

00:31:52: Andererseits möchtest du auch nicht Flaschenhälse kreieren beim zentralen Datenteams.

00:31:56: Und das ist so ein bisschen die Herausforderung.

00:31:57: Da gibt es ein paar Punkte, die wichtig sind.

00:31:59: also erstens mal zu standardisieren wird einfach in der Scalepphase wichtiger.

00:32:03: Wir hatten es auf EntrySix zum Beispiel gesehen an einem Punkt wo wir zum Beispiel die monatlich aktiven Nutzer verschieden kalkuliert hatten und da ist natürlich doof wenn du da auf dieselbe KPI guckst die wieder unterschiedlich berechnet.

00:32:12: Also dass da ein zentrales Datenteam Standard sitzt ist der erste wichtige Punkt.

00:32:15: und selbst Bedienungsdatantools.

00:32:17: Dann gibts eine ganze Reihe Mode Analytics, Lockers, Snowflake und weiter.

00:32:21: 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 Datanalysen zu starten.

00:32:28: Und ein weiterer Punkt auf sogenannte Minimal Viable Data Products zu achten das heißt einfach mal wirklich kritisch nachzufragen auch dann oft von der Daten-Tech Kollegen Seite wenn ein Business Team jetzt sagt ich brauche einen Echtzeit dashboard ist es wirklich notwendig reicht nicht vielleicht ein Dashboard was alle zehn Minuten aktualisierte Daten anzeigt?

00:32:47: ja dass technischer Unterschied, ein Echtzeit-Dashboard zu bauen versus ein Dashboard was sich alle zimmelten updated.

00:32:53: Florian

00:32:53: du wirst ja auch oft im Marketing dieses Thema haben.

00:32:56: wer kann welche Daten einsehen?

00:32:57: Wir reden dann um die Data Warehouses über Rohdaten über schon vordefinierte Daten etc.

00:33:01: etc.

00:33:02: Was ist denn dein Blick auf Datenzugang innerhalb von Unternehmen?

00:33:05: Was ja eigentlich so die Traumvision ist und diese Marketing eigentlich sogar gar nicht so schlecht umsetzbar.

00:33:10: jeder Mitarbeiter oder ihre Mitarbeiterin sich die Frage war ich jetzt gestern gut oder schlecht?

00:33:14: selbst beantworten kann Und ich bin mittlerweile ein relativ starker Fan davon, dass die Person sich das nicht unbedingt holen muss.

00:33:20: Sondern dass das zu ihr gebracht wird.

00:33:22: Dass du das per E-Mail, per Push-Notification in der App oder wie auch immer.

00:33:26: Ein Customer ist Dashboard bekommen, was genau auf dich zugeschnitten ist und sehr klar darlegt an welchen Stellen sollst du eigentlich etwas tun?

00:33:33: noch nicht?

00:33:33: Also ich weiß nicht ob dir schon mal in so einem Tradingfloor wart, bevor es da bankt... Das hat sich so bisschen geändert.

00:33:38: aber wenn du da vor ein paar Jahren reinkamst, da waren wahnsinnig viele Menschen, die saßen von irgendwelchen Bildschirmen haben eigentlich ständig Entscheidungen getroffen also eine wahnsinnige hohe Entscheidungsregion.

00:33:45: Und am Abend wussten die, war das eigentlich heute ein guter Tag oder war das ein schlechter Tag?

00:33:49: Das konnten sie für sich selbst beantworten.

00:33:51: Klar gibt es da noch mal irgendjemand der drüber guckte ob jetzt da der eine vierhundvierzig-biohen Euro in die falsche Richtung überwiesen hat.

00:33:56: Das fällt natürlich dann schon auf aber vom Grundsatz her konnten ihr das selbst tun und jeder Mitarbeiter sollte eigentlich gemessen an seinen OKAs einen seien täglichen zielen oder was auch immer klare startenbasiertes Feedback bekommen und zwar nicht von den Menschen.

00:34:09: Das kann dann auch auf den Top kommen, gerade wenn es darum geht was mache ich denn jetzt besser oder Ideen zu haben?

00:34:14: Was könnte ich jetzt tun?

00:34:16: Ich glaube sehr stark daran dass das die Produktivität vom Unternehmen dramatisch viel besser macht.

00:34:20: D.h.,

00:34:20: die Demokratisierung des Datenzugangs ist total wichtig.

00:34:23: Es kombiniert mit Analysten die fachspezifische Expertise für den jeweiligen Fachbereich haben um Leuten das zu erklären weil das ist auch nur Beobachtung!

00:34:31: Es gibt halt Menschen zu denen sprechen Daten und sie wissen auch was sie tun sollen.

00:34:36: Es gibt aber auch einen relevanten Teil.

00:34:38: Da muss man die richtige Aufbereitung finden.

00:34:39: Und ich glaube, das ist gerade sozusagen die Leistung von guten Analysten, dass sie halt diese Übersetzungsleistungen schaffen.

00:34:44: Das heißt, ich glaube eine Demokratisierung von Daten muss immer auch einhergehen mit sozusagen einer adäquaten Übersetzungleistung entweder aus dem Tool was ich einsetze oder menschlichen Analystiken, die diese Über- setzungsleistung übernehmen.

00:34:56: Du solltest idealerweise anhand von möglichst wenig KPIs sehen ob es jetzt drei sind fünf oder sieben.

00:35:01: da fragst du wahrscheinlich eher welche Leuten die sich mit kognitiven Fähigkeiten besser auskennen als ich?

00:35:05: Das ist glaube ich auch individuell sehr unterschiedlich.

00:35:07: aber dass sozusagen die wesentlichsten Themen, die dem Individuum das zeigen ist es jetzt gut oder schlecht.

00:35:11: Ich halte das für extrem produktivitätssteigerend wenn ich das tue und ich glaube das übersteigt die Gefahren von der dezentralen Datenzugang bei Weitem.

00:35:19: Aber ne?

00:35:19: Ich glaube das nochmal ganz wichtiger Punkt.

00:35:21: was du sagtest Martin, das darf nicht dazu führen dass du so eine sehr starke Randomness in den ganzen hast sondern das quasi die KPI-Basis die dem zugrunde liegt.

00:35:28: Dass sie halt sehr stark standardisiert ist und von einem Team zentral gepflegt wird.

00:35:31: deswegen bin ich mittlerweile auch im kein Fan mehr davon.

00:35:33: Das Marketingteam macht seine eigene Reportings ein Produkt, die macht seine eigene Reportings.

00:35:38: Jeder macht das so.

00:35:39: Du kannst schon spezifische Analysten haben aber du brauchst auf jeden Fall ein zentrales Team was zentrall eben standardisiert festlegt was sich hinter welchen Zahlen verbirgt dafür gerade steht dass die Qualität der Datenerfassung konsistent ist und so weiter.

00:35:52: dass du da nicht so einen Zoo von KPIs hast und unterschiedliche Interpretationen und man isst ja schon erstaunt.

00:35:57: also denkst ihr so ja Monthly Active User?

00:35:59: Was kann da... Aber was Monthly active user ist?

00:36:02: Zähl ich den jetzt schon nach zehn Sekunden in der App nach dreißig Sekunden Da gibt es ja keine Richte falsch.

00:36:06: und da die einheitliche Definition zu haben, ist wichtiger als man so denkt.

00:36:10: Schön, also wir haben sechs Fehler durchdekliniert.

00:36:13: Wir können ja nochmal ganz kurz zusammenfassen.

00:36:15: Fehler eins war die Schlüsselergebnisse des Technologiebereichs sich transparent genug messen.

00:36:19: Fehler zwei war technische Schulden aufzubauen ohne es zu merken.

00:36:22: Fehler drei mit der Alleskönnerplattform in Schönheit sterben.

00:36:25: Fehler vier durch zuspezielle Anforderungen zu auf Software selbst entwickeln.

00:36:28: Fehler fünf daten sich halt zu lange vernachlässigen und als letztes eben gerade den Datenzugang nicht früh genug in haptes Unternehmen zu demokratisieren.

00:36:36: Man kann euch noch kleine Hinweise nach hinten rausmachen.

00:36:38: Vielleicht, wenn ihr das spannend findet, euch das beschäftigt.

00:36:41: 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 ist da auch nochmal auf den Bilderskyte hingewiesen weil da gibt es auch noch einen spannendes Kapitel rund um die Einführung von Development Operations.

00:36:56: So that being said haben wir alle sollte gut gepasst haben oder ihr beiden?

00:37:00: Absolut

00:37:02: Absolut.

00:37:03: Nur diese Podcast vollgehören und schon hast du einen Best-Perform mit den Technologien bereit.

00:37:07: Absolut, sehr gut!

00:37:08: Ich kann aber auch schon sehen Florian Schabtschen mit den Füßen der will hier an seinen Red Bullschrank, will wieder ein bisschen was hacken, will auch mal hier wieder seine Entwicklungsskills...

00:37:15: Auch das ist leider für mein nächstes Leben vorbehalten wenn es denn das gibt.

00:37:19: Genau, ich glaube das ist leider ein bisschen spät.

00:37:20: Aber dass es in der Tat wenn nicht eine Entscheidung anders treffen könnte dann wäre das sicherlich mehr technischen Sachverstand in einem jüngeren Alter aufzubauen.

00:37:27: Ja darf ich da nochmal ganz kurz einhaken?

00:37:29: Ich komme gerade aus so einer Art Zabetical.

00:37:30: Das ist mittlerweile auch wenn man's davor nicht gemacht hat teilweise eben doch nicht zu spät.

00:37:35: Judacity zum Beispiel hat da sehr gute Kurse.

00:37:38: also ich habe jetzt beispielsweise in den letzten Monaten mal gelernt wie man ein neuronales Netzwerk programmiert oder Python programmiert.

00:37:43: das geht mittlerweile innerhalb von ein paar Wochen Monaten.

00:37:46: du wirst natürlich damit nicht einen Entwickler klar und versteht die Prinzipien.

00:37:50: Also deswegen mein Rad, wer im Tech-Startup-Bereich arbeitet und nicht technisch in der Grunde hat hier und da mal vielleicht in einer Pause über ein Urlaub da mal rein zu gucken das ist schon

00:37:58: toll.

00:37:59: Das kann ich auf jeden Fall unterschreiben und das idealerweise bevor ihr Kinder habt.

00:38:03: Die Zeit nutzt uns danach sonst wird es erst bei der Rente irgendwas.

00:38:07: Sehr gut.

00:38:08: Vielen Dank!

00:38:09: Macht's gut.

00:38:10: Danke euch.

00:38:10: Ciao Danke fürs Zuhören

00:38:15: beim Digital-Kompakt-Podcast.

00:38:17: Du merkst,

00:38:18: jetzt siehst du massig Wissen für dich und dein Unternehmen heraus!

00:38:21: Wenn du mit uns noch erfolgreicher werden möchtest, abonniere uns auf den gängigen Podcast-Plattformen – und hey, je größer wir werden, desto

00:38:29: mehr Menschen

00:38:30: können wir helfen.

00:38:32: Also erzähl doch auch deinen Kolleginnen von uns.

00:38:35: Bis zum nächsten Mal.