00:00:00 Einführung in Startup-Tech-Prüfungen
00:01:42 Wie VCs Joannes zu Tech-Prüfungen führten
00:03:24 Tech-Prüfungen als Einnahmequelle
00:05:08 Software in Startups bewerten
00:06:36 Joannes’ Erfahrung im Bereich Machine Learning
00:08:50 Wesentliche Aspekte einer Tech-Prüfung
00:10:02 Abwägung zwischen Sicherheit und Korrektheit
00:11:46 Investorenberichte effektiv verfassen
00:14:57 Startups jenseits von Checklisten bewerten
00:17:04 Prüfungen an den Geschäftskontext anpassen
00:20:24 CTOs interviewen und Code live überprüfen
00:24:12 Vertrautheit und Führungsqualitäten von Entwicklern bewerten
00:28:22 Kompetenz von Entwicklern beurteilen
00:30:49 Warnsignale in der Codequalität
00:33:47 Erkenntnisse aus der Commit-Historie
00:37:03 Nachhaltigkeit der Cloud-Kosten
00:42:14 LLMs, die NLP-Startups durcheinanderbringen
00:46:29 Lukrative Software-Nischen finden
00:50:32 Risiken technischer Schulden
00:55:34 Übermäßige Investitionen in Skalierbarkeit
00:59:59 Klare Schreibweise signalisiert gute Technik
01:04:08 Warum Tech-Prüfungen bei Investitionen selten sind
01:07:12 Schlussbemerkungen
Zusammenfassung
In einer kürzlichen LokadTV-Episode interviewte Conor Doherty Joannes Vermorel, CEO von Lokad, über seine jahrzehntelange Erfahrung in der Durchführung technischer Prüfungen von Startups. Vermorels „Lightning Tech Audits“ bieten Venture Capitalists fachkundige Bewertungen von Technologie-Stacks, die sich von herkömmlichen Methoden abheben, indem sie dynamische, kontextspezifische Bewertungen in den Vordergrund stellen. Sein Prozess umfasst intensive, eintägige Bewertungen, zu denen auch Interviews mit CTOs und Engineering-Teams gehören, um die Codequalität und Funktionalität des Teams einzuschätzen. Vermorel betont die Bedeutung von Leidenschaft, klarer Dokumentation und einem klugen Ressourceneinsatz in der Technologieentwicklung. Seine Erkenntnisse offenbaren erhebliche Lücken in der Branche und heben Best Practices sowohl für Investoren als auch für Tech-Unternehmer hervor.
Erweiterte Zusammenfassung
In einer kürzlichen Episode von LokadTV setzte sich Conor Doherty, Kommunikationsdirektor bei Lokad, mit Joannes Vermorel, dem CEO und Gründer von Lokad, zusammen, um eine seiner weniger bekannten, aber äußerst wirkungsvollen Aktivitäten zu beleuchten: die Durchführung technischer Prüfungen von Startups. In den letzten zehn Jahren hat Joannes diese Prüfungen durchgeführt und Venture Capitalists fachkundige Einschätzungen zu den Technologie-Stacks potenzieller Investitionen geliefert. Diese Praxis, die er als „Lightning Tech Audits“ bezeichnet, verschaffte ihm einen einzigartigen Einblick in die besten und schlechtesten Praktiken der Tech-Branche.
Joannes’ Weg in die technischen Prüfungen begann in den frühen Jahren von Lokad, als er darüber nachdachte, Venture Capitalists ins Boot zu holen. Obwohl er sich letztlich dagegen entschied, formelle Investitionen anzunehmen, führten seine Begegnungen mit Investoren dazu, dass er seine Expertise bei der Bewertung der technologischen Aspekte anderer Startups anbot. Dieser Wandel ermöglichte es ihm, potenziell zeitraubende Meetings in wertvolle Verkaufsgelegenheiten zu verwandeln, indem er seine Dienstleistungen den Venture Capitalists anbot, die eine fachkundige Einschätzung der Technologie-Stacks der Unternehmen, die sie für eine Investition in Betracht zogen, benötigten.
Der Kern von Joannes’ Prüfungsprozess ist eine eintägige, intensive Bewertung, die sich erheblich von traditionellen Prüfmethoden unterscheidet. Im Gegensatz zum Standardansatz, der sich stark auf Checklisten stützt, ist Joannes’ Methode dynamisch und auf den spezifischen Kontext jedes Startups zugeschnitten. Er beginnt mit einem 20-minütigen Interview mit dem CTO, um sich ein Bild der technologischen Landschaft des Unternehmens zu machen, und verbringt anschließend den restlichen Tag mit Einzelgesprächen mit dem Engineering-Team. Dieser praxisnahe Ansatz ermöglicht es ihm, nicht nur die Codequalität, sondern auch die Sprachgewandtheit und Kohärenz des Teams bei der Handhabung ihrer eigenen Technologie zu beurteilen.
Joannes betont, dass es ihm nicht darum geht, ein Experte für die Technologie des Unternehmens zu werden, sondern zu bewerten, ob das Team funktional ist und ob die technologische Ausrichtung sinnvoll erscheint. Er sucht in der Codebasis, in der Commit-Historie und in der Qualität der Dokumentation nach Mustern. So kann er beispielsweise die Qualität der Codebasis rasch anhand der Konsistenz der Programmierstandards und der Klarheit der Commit-Nachrichten einschätzen. Zudem beurteilt er, ob das Team seine begrenzten Ressourcen klug einsetzt – ein kritischer Faktor für Startups.
Eines der markantesten Erkenntnisse, die Joannes teilte, ist die Häufigkeit, mit der Tech-Unternehmen mehrere Finanzierungsrunden durchlaufen können, ohne dass jemand ihre Technologie ernsthaft unter die Lupe genommen hat. Er findet es verblüffend, dass selbst in späteren Finanzierungsrunden der Technologie-Stack oft unangefochten bleibt. Dieser Mangel an Due Diligence kann zu erheblichen Versäumnissen führen, wie es berühmt bei Theranos der Fall war.
Joannes sprach auch über die Bedeutung von Leidenschaft und Sorgfalt in der Technologieentwicklung. Er ist der Überzeugung, dass ein Mangel an Sorgfalt für Tech-Unternehmen fatal sein kann. Wenn der CTO und das Engineering-Team wirklich leidenschaftlich bei der Sache sind, spiegelt sich das in der Qualität und Kohärenz ihrer Arbeit wider. Umgekehrt sind die Resultate häufig katastrophal, wenn Unternehmen ihre Entwicklung an Freelancer auslagern oder nicht tief in ihre Technologie investieren.
Hinsichtlich der Best Practices hob Joannes die Bedeutung von klarer Schreibweise und Dokumentation hervor. Ob es sich um Kommentare im Code oder die Formulierung von Problemstellungen in Tickets handelt – Klarheit und Prägnanz sind entscheidende Indikatoren für ein gut funktionierendes Team. Außerdem schätzt er den Einsatz ungewöhnlicher, aber passender Technologien, was auf ein tiefes Verständnis der technologischen Landschaft und das Bestreben hinweist, die besten Lösungen zu finden.
Joannes’ Ansatz bei technischen Prüfungen ist eine willkommene Abkehr vom Gewöhnlichen und konzentriert sich auf die praktischen Realitäten sowie die spezifischen Bedürfnisse jedes Startups. Seine Erkenntnisse bieten wertvolle Lehren für Investoren und Tech-Unternehmer, indem sie die Bedeutung von Leidenschaft, Klarheit und einem maßgeschneiderten Ansatz in der Technologieentwicklung unterstreichen. Während sich die Tech-Branche weiterentwickelt, liefert Joannes’ Methode der Lightning Tech Audits einen soliden Rahmen zur Bewertung des tatsächlichen Potenzials technologischer Innovationen.
Vollständiges Transkript
Conor Doherty: Willkommen zurück bei LokadTV. Heute treffe ich mich im Studio mit Joannes Vermorel, Lokad’s Gründer und CEO. Wir werden über eine seiner einzigartigen Nebenaktivitäten sprechen: die Durchführung technischer Prüfungen von Startups. Nur wenige wissen tatsächlich, dass Joannes seit etwa einem Jahrzehnt Softwareunternehmen bewertet, indem er alles von Code und Infrastruktur bis hin zu Personal und Führung überprüft. Er und ich werden einige Best Practices und die Erkenntnisse, die er im Laufe der Zeit gewonnen hat, besprechen. Wie immer: Falls euch gefällt, was ihr hört, und ihr schätzt, was wir tun, abonniert den YouTube-Kanal und folgt uns auf LinkedIn. Damit präsentiere ich das heutige Gespräch mit Joannes Vermorel. Joannes, willkommen zurück. Wie ich bereits in der Einleitung erwähnte, sind wir heute hier, um über etwas zu sprechen, das neben unserem üblichen Thema von großem Interesse ist. Du machst viele Tech-Prüfungen, korrekt?
Joannes Vermorel: Ja, und das mache ich nun schon seit über einem Jahrzehnt, wahrscheinlich fast 14 Jahre.
Conor Doherty: Und wie kam das genau zustande? Denn, wie gesagt, alle, die LokadTV verfolgen – das ist jetzt ungefähr im siebten oder vielleicht achten Jahr, wie Max hinter der Kamera bestätigen kann – kennen dich dafür, dass du über supply chain und all die damit verbundene Technik sprichst. Aber das ist vermutlich das erste Mal, dass jemand davon hört, und dennoch hast du gerade gesagt, dass du das seit 10 Jahren machst. Was Nebenaktivitäten angeht, war es also eine eher subtile Entwicklung. Wie kam es dazu genau?
Joannes Vermorel: In den frühen Jahren von Lokad habe ich darüber nachgedacht, Investitionen anzunehmen, sprich, Venture Capitalists hereinzuholen. Es stellte sich heraus, dass ich niemals formelle Investoren ins Unternehmen holte, doch in den Anfangsjahren von Lokad sprach ich mit einigen von ihnen. Nach einer Weile weißt du, läuft es so ab, dass entweder du eine E-Mail schickst oder sie dir eine E-Mail schicken mit dem Hinweis: “Oh, lass uns doch einen Kaffee trinken gehen oder so.” Es kostet Zeit, sich mit Investoren zu treffen, um das Unternehmen zu besprechen und ob sie an einer Investition interessiert wären. Das kostet Zeit, und irgendwann dachte ich: “Okay, ich verbringe all diese Zeit in Treffen mit potenziellen Investoren, und das ist Zeit, die ich nicht mit dem Aufbau oder Verkauf verbringe.” Da fragte ich mich: “Was, wenn ich ihnen etwas verkaufe?” Also behandelte ich diese Treffen mit Venture Capitalists als Verkaufsgespräche. Es stellte sich heraus, dass ich diesen Personen sagte, falls sie interessiert seien – ich war für sie kein heiß begehrter Lead, da ich nicht verzweifelt nach Geld suchte – aber ich erklärte, dass Lokad vielleicht nicht ihr ideales Startup sei, weil ich nicht verzweifelt Geld benötigte. Aber falls sie jemanden suchten, der eine fachkundige Meinung zu einer anderen Investition abgeben kann, könnte ich ihr Mann sein. Meine Spezialität lag nicht darin, ein anderes Startup zu begutachten und zu beurteilen, ob es profitabel wäre – das liegt außerhalb meiner Expertise, es ist sehr schwierig. Was hingegen in meinen Fähigkeiten lag, war, eine fundierte Meinung zu ihrem technologischen Stack abzugeben. Es stellte sich heraus, dass, wenn man als Venture Capitalist in Tech-Unternehmen investiert, ein großer Teil der Bewertung vieler dieser Unternehmen von der Technologie abhängt, die sie entwickeln. Ist die Technologie wirklich wertvoll? Rechtfertigt sie die Pre-Money-Bewertung, die die Gründer verlangen? Und siehe da, ich begann mit diesen Tech-Prüfungen. Ich führe etwa eine, manchmal zwei pro Monat durch – und das nun schon seit, ich glaube, 12 oder 13 Jahren. Ich habe also viele Unternehmen geprüft, und das Format dieser Prüfungen ist sehr kurz. Übrigens, du hattest gefragt, wie ich die Zeit dafür finde. Nun, ich habe diese Prüfungen immer als Lightning Tech Audits belassen; alles wird an einem Tag erledigt.
Conor Doherty: Darauf werden wir definitiv zurückkommen, denn dieser Ansatz hat weitreichende Implikationen. Wir werden darauf eingehen, wie sich dein Vorgehen von dem unterscheidet, was die meisten als den Status quo einer im Grunde beratenden Dienstleistung ansehen. Aber um das richtig einzuordnen – da du die Begriffe “expert opinion” und “expertise” verwendet hast – erzähle uns gerne von deinen zahlreichen Erfolgen.
Joannes Vermorel: Ich bin schon seit Langem leidenschaftlich an Software-Technologien interessiert. Ich begann bereits in der Grundschule mit dem Programmieren, verbrachte die meiste Zeit der Mittel- und Oberschule damit, meine Programmierfähigkeiten mit immer ausgefeilteren Projekten zu verbessern, und ich war schon immer außerordentlich fasziniert von allem, was mit Software zu tun hat. Als ich mit diesen Prüfungen begann, war ich noch nicht 30, aber fast, und zu der Zeit verfügte ich bereits über fast ein Jahrzehnt professioneller Software-Erfahrung mit eigenen Projekten sowie weiteren Projekten, die ich an der Universität und in anderen Firmen realisiert hatte.
Conor Doherty: Du hast übrigens auch eine Zeitlang in Amerika bei AT&T Labs gearbeitet. Es war eine Zeit, in der sie echte Pioniere im Bereich machine learning waren. Sie begannen bereits in den 90ern mit Machine Learning.
Joannes Vermorel: Ja, sie haben sich mit Machine Learning beschäftigt, lange bevor künstliche Intelligenz cool und gehypt wurde. Es gab schon Leute, die an diesem Thema arbeiteten, aber das war nur ein Teil meines Interesses. Wenn ich Unternehmen prüfe, ist Machine Learning sehr häufig nur ein winziger Teil der Herausforderungen. Oft spielt es gar keine Rolle. Diese Unternehmen können ganz unterschiedlich sein. Es gibt Software-Unternehmen, aber sie können alles sein – von einem Biotech-Unternehmen, das Software intensiv nutzt, über Online-Glücksspiele, bis hin zu einer B2B-Produktivitäts-App oder eingebetteter Software, die in ein Gerät integriert wird, das in einem Operationssaal eines Krankenhauses steht. Software findet in äußerst unterschiedlichen Situationen Anwendung, und die Technologien, die in diese Startups einfließen, variieren enorm von einem Unternehmen zum anderen, auch wenn das Kernprodukt stets Software ist. Genau da sehe ich den Schwerpunkt meiner Expertise.
Conor Doherty: Wenn du von der Durchführung von Tech-Prüfungen sprichst, denke ich, dass die Leute bereits eine Vorstellung davon haben, was das bedeutet. Aber was genau gehört dazu? Auf welche Bereiche konzentrierst du dich? Bewertest du ausschließlich die Software? Bewertest du auch die Menschen? Was genau umfasst das?
Joannes Vermorel: Das Ergebnis – denn wir müssen mit dem beginnen, was geliefert wird – ist ein Memo, das ich dem Investor zurückgebe. Ein Risikokapitalgeber steht kurz davor, in ein Startup zu investieren. In der Regel liegt bereits ein unterzeichneter Absichtserklärungbrief vor. Sie sind dabei, zwischen 2 und 20 Millionen, manchmal auch mehr, Dollar oder Euro in ein Unternehmen zu investieren. Ein großer Teil der Bewertung besteht in den Technologien, in die sie investieren. Sie investieren in ein Team, das angeblich bereits etwas entwickelt hat. Ich führe diese Audits nicht im Seed-Stadium durch; wir sprechen hier von Series A, manchmal Series B. Also geht es um Personen, die in diesem Stadium normalerweise schon etwas entwickelt haben, was eine höhere Bewertung rechtfertigt. Jetzt stellt sich die Frage: Ist es das wert, wofür diese Leute etwas verlangen? Der Wert bemisst sich nicht nur danach, was sie haben, sondern auch nach den technologischen Dynamiken innerhalb des Unternehmens, sodass sie – falls sie das Geld vom Investor erhalten – in der Lage sind, die Ziele ihrer Roadmap zu erreichen. Man investiert nicht nur in das, was das Unternehmen ist, sondern vor allem in das, was es morgen werden wird. Ich kann nicht beurteilen, ob ihre finanziellen Projektionen korrekt sein werden. Meine Expertise liegt nicht in der Zukunft, sagen wir, der Glücksspielmärkte. Ich weiß es nicht. Das ist für andere, um das es sich zu kümmern. Aber wenn sie mir eine App für Glücksspiel zeigen, müssen wir überprüfen, ob sie sicher sein wird, denn wenn es um Glücksspiel geht, muss sie extrem sicher sein. Das ist die Art von Frage, die ich beantworten kann. Wenn es sich um ein Gerät handelt, das während eines chirurgischen Eingriffs verwendet wird, dann ist die Korrektheit absolut lebenswichtig. Buchstäblich, wenn das Gerät versagt, kann es einen Patienten töten. Die Herausforderungen sind völlig unterschiedlich.
Conor Doherty: Nur um noch einmal darauf zurückzukommen – als du das Beispiel genannt hast, verstand ich die Sicherheitsfrage, und das passt offensichtlich zu deiner Jacke –, aber wie siehst du bei einem chirurgischen Gerät die Bewertung dieser Korrektheit? Wird es zuverlässig das tun, was es soll?
Joannes Vermorel: Es ist kein Sicherheitsproblem, denn diese Geräte werden vom Netzwerk isoliert betrieben. Sie werden in einer Umgebung eingesetzt, die aus IT-Sicht bereits sehr sicher ist – keine Netzwerkverbindung und dergleichen. Aber die Frage ist, wie man sicherstellt, dass es nicht zu Störungen, Bugs oder Ähnlichem kommt, die buchstäblich die Funktionsfähigkeit des Geräts gefährden könnten. Viele Maschinen sind heutzutage automatisiert. Wenn beispielsweise eine Pumpe betrieben wird, die irgendeine Flüssigkeit in den Patienten fördert, wie stellt man sicher, dass sie nicht ausfällt und genau das tut, was man von ihr erwartet? Letztlich besteht mein Ansatz darin, eine fundierte Meinung zu bilden. Das ist ein Memo, das ich dem Investor zurückgebe, in dem ich darlege, was ich grundsätzlich vom Wert dieses Unternehmens halte – basierend auf seinen eigenen Voraussetzungen. Und das ist wirklich das Entscheidende. Ich versuche, eine Meinung darüber zu formen, was das Unternehmen wert ist in Bezug darauf, was es zu erreichen versucht. Wenn du ein Videospiel entwickelst, stellt sich die Frage, ob du etwas entwickelst, das sehr süchtig machend, fesselnd und unterhaltsam ist. Das sind deine Engagement-Bedingungen. Wenn du in der Biotech-Branche tätig bist und eine neue Diagnosetechnologie entwickelst, die angeblich eine Pathologie früher und schneller als alternative Methoden erkennen lässt – funktioniert sie? Ist sie real? Hast du belastbare Statistiken? Verfügst du über alle Prozesse, die darauf hinweisen, dass deine empirischen Ergebnisse exakt so ausfallen, wie sie sollten? Wenn wir eine Produktivitäts-App betrachten, lautet die Frage bei einer B2B-App: Wie gehst du damit um, dass du Hunderte, eventuell Tausende von Features oder Mikro-Features hast? Gerade bei Enterprise-Apps können diese wie ein Labyrinth von Funktionen sein, weil so viele Fälle abgedeckt werden müssen. Wie managt das Unternehmen diese Komplexität? Geht es in der eigenen Komplexität unter oder wird sie gut beherrscht? Ist alles gut organisiert? Je nachdem, welches Startup ich auditieren werde, variieren die Engagement-Bedingungen – was ist das Wertversprechen, was ist das Wesentliche des Werts – erheblich. Mein Deliverable besteht darin, eine Meinung zu formen und zu reflektieren, die ich dem Investor darüber zurückgebe, was am wichtigsten ist. Wenn ich während dieses Audits etwas entdecke, das diesen Kernwert gefährden könnte, weise ich darauf hin.
Conor Doherty: Nochmals, du sagst, du machst das seit etwa 10 oder 12 Jahren. Gehen wir von ein bis zwei Audits pro Monat aus, dann sprechen wir von mindestens über 100 durchgeführten. Was ist also der Großteil? Denn du hast skizziert, dass ich mir zum Beispiel eine Glücksspiel-App oder medizinische Geräte ansehen könnte. Offensichtlich sind diese Bereiche sehr, sehr unterschiedlich. Wie ist also der typische Schwerpunkt deiner Audits?
Joannes Vermorel: Es sind in erster Linie Softwareunternehmen. Es sind Menschen, die Software entwickeln. Manchmal gibt es auch einen physischen Aspekt – es kann also auch um Leute gehen, die Software für ein Gerät entwickeln. Hin und wieder muss mehr oder weniger Fremdsoftware integriert werden. Handelt es sich um eine eigenständige App oder wird sie in zahlreiche andere Systeme eingebunden? Es gibt zahlreiche Szenarien. Offensichtlich entfallen wohl etwa zwei Drittel meiner Tätigkeiten auf den B2B- oder professionellen Bereich und ein Drittel auf den B2C-Bereich. Aber das ist nur eine Klassifikation; insgesamt ist das Spektrum äußerst vielfältig.
Conor Doherty: Nun, du hast uns einen effektiven Überblick über die Deliverables und deinen Hintergrund gegeben. Aber was die wesentlichen Schritte angeht: Wie bildest du eine Meinung und welche Schritte sind nötig, um zu diesem Memo und dieser Meinung zu gelangen?
Joannes Vermorel: Hier weicht mein Ansatz erheblich von dem ab, was man üblicherweise als Auditprozess betrachtet. Um es für das Publikum zusammenzufassen: Ein Auditor – und ich würde sagen, 99 % der Menschen, die irgendeine Art von Audit durchführen – verfügen über Checklisten. Sie haben lange Checklisten mit mehreren hundert Fragen und gehen zum Unternehmen, um zu fragen: „Machen Sie dies oder das?“ – Ja, nein, ja, nein etc. Der Auditor geht die Liste wie ein Roboter ab. Meiner Meinung nach ist dieser Prozess kompletter Unsinn, insbesondere bei technologischen Audits von Startups.
Das Problem ist, dass diese Liste, wie auch immer sie lautet, das Startup nie auf seinen eigenen Grundlagen in Frage stellen wird. Es ist völlig irrelevant, ein Unternehmen, das Spiele entwickelt, daraufhin zu prüfen, ob es überragend sicher ist. Wenn du ein Videospiel entwickelst, ist Sicherheit nur von untergeordneter Bedeutung. In einem Startup sind die Ressourcen knapp. Macht es Sinn, dass die meisten Videospiele in einen Sicherheitsbeauftragten investieren und massiv in Sicherheitsfeatures investieren, die den Alltag der Nutzer verkomplizieren? Bei Gelegenheitsspielen ist das beispielsweise völlig unsinnig. Niemand interessiert sich dafür, dass du Farmville spielst.
Letzten Endes ist die Verwendung von Checklisten ein Rezept für eine enorme Zeitverschwendung für die Gründer und eine massive Ablenkung für die Investoren selbst. Sie könnten sagen: „Oh, das Startup erfüllt Hunderte von irrelevanten Punkten“, und dann würdest du entgegnen: „Oh, aber bei diesen 100 Punkten tun sie es nicht“, was ebenfalls völlig irrelevant für den Erfolg des Unternehmens ist. Meiner Meinung nach haben sie einen Business Case; sie sagen, dass sie in eine bestimmte Richtung gehen wollen, was das Geschäft angeht. Ob damit Geld verdient werden kann, überlasse ich anderen. Ich habe zwar eine eigene Meinung darüber, ob es plausibel erscheint, aber ich stelle die Marktgröße nicht infrage. Mein Ansatz ist: Nehmen wir an, es gäbe einen Markt und wenn du es exzellent ausführst, wird es auch Kunden geben, die bereit sind, zu zahlen.
Jetzt stellt sich wirklich die Frage: Wirst du dein Versprechen einhalten? Du entwickelst eine Technologie, die etwas bewirken soll. Wirst du das liefern, was du tatsächlich versprichst?
Conor Doherty: Und du bist in der Lage, diese Erkenntnisse zu liefern. Du kannst über die Technologie spekulieren und…
Joannes Vermorel: Im Vergleich zu einem Auditor – wenn ich zur Checkliste zurückkomme – ist meine Auffassung, dass ich zu Beginn des Tages, in den ersten 20 Minuten, in der Regel den CTO interviewe. Die Idee ist, dass ich innerhalb von 20 Minuten gedanklich eine Reihe von Fragen entwerfe, um die Diskussion in Richtung der für mich interessantesten Punkte zu lenken. Nach den 20 Minuten der Präsentation, die meist in einem lockeren Gespräch erfolgt, führe ich den restlichen Tag durch eine Serie von Interviews, bei denen mir jemand vor einem Computer seine Codebasis zeigt. Ich führe mehrere Eins-zu-eins-Gespräche, bei denen wir beide auf denselben Bildschirm blicken, und ein Mitarbeiter des Unternehmens fungiert als mein Führer durch deren Codebasis.
Conor Doherty: Also, du bist Virgil.
Joannes Vermorel: Ja, sie führen mich durch ihre Codebasis. Ich verlange keine Kopie der Codebasis, da dies eine Menge Probleme verursachen und mich haftbar für geistiges Eigentum machen könnte. Die Idee ist, dass ich einen Einblick in die Codebasis gewinnen möchte – so betrachte ich die Technologie. Aber Codebasen können extrem umfangreich sein. Selbst ein kleines Unternehmen mit fünf Softwareentwicklern, das seit ein paar Jahren besteht, kann leicht 100.000 Zeilen Code oder mehr haben. Wenn ich diese Codebasis alleine durchforsten würde, wäre 90 % meiner Zeit damit verschwendet, mich zurechtzufinden. Deshalb habe ich einen Ingenieur neben mir, stelle Fragen, und er zeigt mir den Code. Wir überprüfen den Code gemeinsam – natürlich nur eine Stichprobe; die gesamte Codebasis können wir nicht durchgehen.
Conor Doherty: Angesichts des potenziellen finanziellen Risikos, warum würdest du das nicht einfach mit dem CTO gemeinsam durchgehen?
Joannes Vermorel: Erstens, der CTO kennt nicht zwangsläufig alle Bereiche der Codebasis. Wenn es sich um ein Team von fünf Personen handelt – einschließlich des CTO – ist der CTO wahrscheinlich mit der gesamten Codebasis vertraut. Bei einem Unternehmen in einem späteren Stadium mit 20 Entwicklern ist der CTO höchstwahrscheinlich nicht in allen Segmenten der Codebasis kompetent. Generell ist es für mich außerdem sehr interessant, wenn auch andere Mitarbeiter des Unternehmens neben mir sitzen, denn so kann ich sehen, wie sicher sie im Umgang mit der Codebasis sind. Sind sie in ihrer eigenen Technologie verloren? Wenn ich eine grundlegende Frage stelle wie „Wie greift ihr auf eure persistente Schicht zu?“ oder „Wie greift ihr auf die erfassten Daten zu?“ und die Leute keinerlei Ahnung haben, ist das nicht gut. Wenn ich sie frage: „Was war das Letzte, was du gemacht hast?“ und sie sagen: „Ich habe dieses Feature entwickelt“ und dann unsicher werden, als sie mir zeigen sollen, woran sie aktuell arbeiten, ist das ebenfalls nicht gut.
Das Interview mit dem CTO ist gut, aber ich muss auch beurteilen, ob das Team ebenbürtig zum CTO ist. Das kann in beide Richtungen gehen. Manchmal ist der CTO sehr gut, aber der Rest des Teams nicht so. Manchmal ist es umgekehrt. Es kann auch vorkommen, dass der CTO ziemlich schwach ist, während das restliche Team tatsächlich stark ist. Das variiert und fließt ebenso in meine Einschätzungen ein, die ich dem Investor im Rahmen dieses Memos zurückgebe. Ich habe auch eine Meinung darüber, ob die derzeit zum Unternehmen gehörenden Mitwirkenden der nächsten Phase gewachsen sind. Wenn die Investition zustande kommt, ist das Budget eines Startups oft extrem begrenzt, und sie greifen dann auf Personen zurück, die technologisch nicht überragend talentiert sind. Dies passiert häufig, wenn der Gründer kein Tech-Gründer ist. Wenn der Gründer jemand ist, der Insiderwissen hatte, der weiß, dass ein spezifisches Problem gelöst werden muss, und dieser Bedarf sowie willingness to pay besteht – was in B2B-Märkten sehr häufig vorkommt – dann holt man sich den erstbesten Softwareentwickler. Möglicherweise hat man kein großes Budget, sodass die erste Einstellung jemand ist, dessen Hauptvorteil darin besteht, sehr günstig zu sein.
Nochmals, das ist in Ordnung, in Ordnung. Ich meine, du startest von Null. Du hast, sagen wir, €20.000, die du in das Unternehmen steckst. Für dich ist das bereits eine beträchtliche Investition. Dank dieser €20.000 schaffst du es, einen Seed von etwa einer halben Million zu erhalten. Das ist gut. Du kannst dein Team, sagen wir, aus zwei Softwareentwicklern zur Produktentwicklung zusammenstellen. Dann möchtest du in die nächste Phase gehen und die erste Finanzierungsrunde von, sagen wir, €3 Millionen erreichen. Nun, in diesem Stadium, wenn wir von einer Investition im Millionenbereich sprechen, hast du das Geld, um echtes Talent im Bereich Softwareentwicklung zu engagieren. Die Frage ist also, ob die Personen, die du aktuell hast, der nächsten Herausforderung, der nächsten Stufe des Unternehmens, gewachsen sind. Das ist somit auch – es ist nicht die einzige Frage, aber eine der Fragen, die betrachtet werden.
Conor Doherty: Nur um es klarzustellen: Würdest du im Rahmen des Memorandums, also des Deliverables, potenziell Empfehlungen abgeben, wer bleiben sollte und wer nicht?
Joannes Vermorel: Ja, ja. Wieder, es ist alles, was dazu beitragen kann, den technologischen Wert des Unternehmens oder seinen technologischen Entwicklungsverlauf zu verbessern oder zu gefährden. Manchmal hat man eben die falschen Akteure. Ich meine, du hattest die Spieler, die du gebraucht hast, um eine super lokale Meisterschaft zu gewinnen, aber wenn du landesweit spielen oder sogar die Weltmeisterschaft anstreben willst, dann brauchst du womöglich andere Spieler. Mehr Geld einzubringen verändert die Dynamik. Plötzlich kannst du dir potenziell Leute leisten, die viel erfahrener und talentierter sind. Es variiert. Manchmal sind Menschen sehr talentiert, aber aus irgendeinem Grund ist die Dynamik im Unternehmen extrem schlecht. Manchmal gibt es sogar aus unerfindlichen Gründen zwei CTOs. Das ist in einigen Audits vorgekommen. Du hast also zwei technologische Leiter, die unterschiedliche Roadmaps verfolgen. Meine Botschaft ist dann: Entscheide dich für einen. Du kannst nicht völlig schizophren bleiben; du musst wählen. Das wäre eine Geschäftsentscheidung, weil du verschiedenen Märkten hinterherjagst. Letztlich ist das genau das Problem, bei dem ein Investor wissen muss, ob etwas mit der Technik nicht stimmt oder in Zukunft etwas damit nicht stimmen wird. Denn manchmal gibt es noch kein Problem, aber wenn man Geld dazugießt, ist es, als würde man Öl ins Feuer schütten. Wenn etwas leicht dysfunktional ist und du dann ein paar Millionen obendrauf packst, kann ein kleines Problem durch die Investition enorm vergrößert werden. Das kann also auch ein Problem sein. Nochmals: Für mich gibt es keine Checkliste, es gibt keine Regeln. Es ist einfach das, was ich sehe und was in Bezug auf zu behebende Probleme oder Empfehlungen für den Investor Sinn ergibt. Das gehört zu meinem Aufgabenbereich. Die Idee ist, dass ich das als eine Tagesmission behandle, weil ich nicht die Zeit habe für viel mehr. Aber auch, weil die Gründer selbst sehr beschäftigt sind. Ich denke, ein Teil des Problems bei klassischen Audits ist, dass solche Dinge eine totale Zeitverschwendung sind. Es dauert Wochen, lähmt das Unternehmen komplett, und es kommt nichts Gutes dabei heraus.
Conor Doherty: Nun, dazu: Du sagst also, dass du keine Checkliste benutzt und es darauf anlegst, in weniger als einem Tag rein und raus zu sein. Wenn du von einem Tag sprichst, ist das ein Arbeitstag. Du sprichst also davon, statt eines mehrwöchigen Prozesses – also statt mehrerer Wochen mit 8-Stunden-Tagen – von vielleicht 8 bis 10 Stunden, abzüglich Taxis und Flügen, ohne Checkliste, und dann sehr folgerichtige Empfehlungen zu geben, was mit dem Unternehmen getan werden sollte, Dinge, die andere Menschen betreffen. Ich muss fragen: Angesichts all dieser Einschränkungen, bist du einfach so brillant oder wie genau triffst du diese Entscheidungen an einem einzigen Tag ohne Checkliste?
Joannes Vermorel: Ja, ich meine, zuerst einmal – die Codebasis. Wenn du schon daran gewöhnt bist, viele Codebasen zu lesen, werden solche Dinge extrem offensichtlich. Innerhalb weniger Minuten, in denen du die Codebasis durchsiehst, erkennst du, ob der Code gut geschrieben ist oder einfach nur schlecht. Gewöhnlich habe ich schon innerhalb von 5 Minuten beim Durchstöbern der Codebasis eine Meinung. Wenn du wirklich daran gewöhnt bist, viele Programmiersprachen zu lesen und hast unzählige Codebasen gesehen, brauchst du keine Stunden, um dir eine Meinung zu bilden, ob das eine schöne, präzise Ingenieurskunst ist, gut organisiert und sinnvoll, oder ob es schlichtweg absolutes Chaos und inkonsistent ist. Zum Beispiel, wenn ich eine Codebasis durchgehe und radikal unterschiedliche Kodierungsstile sehe, sage ich: “Oh, okay, wir haben verschiedene Mitwirkende, die überhaupt keine gemeinsame Übereinkunft darüber haben, wie der Code aussehen sollte.” Das ist wirklich schlecht. Schaue ich mir die Commit-Historie an? Das verrät mir vieles. Zum Beispiel, wenn ich in der Commit-Historie sehe, dass es einen Commit für ein Feature gibt und dann zwei Dutzend Commits, um Fehler zu beheben, die durch die Einführung dieses Features entstanden sind, ist das super schlimm. Das bedeutet, dass immer, wenn etwas eingeführt wird, viel Zeit damit verbracht wird, die Dinge zu reparieren, die man gerade kaputt gemacht hat. So siehst du schon allein durch einen flüchtigen Blick auf die letzten vielleicht 200 Commits, ob sich ein Muster abzeichnet. Man kann viele Muster erkennen. Manchmal, beispielsweise, hast du die Historie der Commit-Messages. Das ist die Entwicklung für das Publikum. Commits sind die Art und Weise, wie du die Codebasis schrittweise änderst. Du nimmst Anpassungen vor, und heutzutage benutzt du typischerweise Git. Wir nutzen das für das Web, und bei Lokad verwenden wir es wie alle anderen auch für unseren Tech-Stack. Die Frage ist zum Beispiel: Wenn du Änderungen in der Codebasis siehst, machen diese Änderungen Sinn? Beispielsweise, wenn du Commits siehst, bei denen der Titel des Commits “more stuff” lautet – buchstäblich, was soll das sein, dieses Stück Mist? Nein, hier wurde nichts Substanzielles geändert. Dann, wenn beispielsweise ein Fehler behoben wird, wird neben der Fehlerbehebung auch etwas getan, um sicherzustellen, dass der Fehler beim nächsten Mal nicht wieder auftritt, wenn du die Codebasis änderst? Es gibt zahlreiche Möglichkeiten, das zu verhindern. Kümmerst du dich darum? Wenn du dir die Beiträge, die Commits, ansiehst – haben die Leute Code-Reviews? Besprechen sie, wie Dinge entwickelt werden sollten? Wiederum wird die Codebasis eine gewaltige Geschichte erzählen, sowohl über die zugrunde liegende Technologie als auch über ihre Historie. Du kannst die Entwicklung sehen, wie sie sich entfaltet hat. Dann kannst du in die Kernbereiche hineingehen. Zum Beispiel, wenn du ein KI- oder Machine Learning-Startup bist, sollte dein Kernwert irgendein intelligentes numerisches Rezept sein, das etwas sehr Schwieriges leistet oder Ähnliches. Wie machst du das? Ist es einfach ein Trick, oder verfügst du über wirklich tiefgehende Expertise? Wie breit ist dein Burggraben? Hast du einen echten Burggraben, sodass es schwierig ist, das, was du gerade geschaffen hast, zu replizieren, oder ist es nur ein illusionistischer Trick, bei dem du irgendeine Open-Source-Bibliothek benutzt und zack – in der Produktion läuft im Grunde gar nichts? Du hast einfach etwas recycelt, das bereits in der Community existiert. Wiederum ist das eine sehr kritische Frage für den Investor, denn wenn Leute sagen: “Oh, wir haben eine einzigartige Machine Learning-Technologie entwickelt”, und das, was du machst, im Wesentlichen darin besteht, ein Open-Source-Produkt zu verwenden, kann es jeder machen. Also ja, es ist cool, es funktioniert, aber sollte der Investor dein Unternehmen hoch bewerten, nur weil du etwas hast, das funktioniert? Nun, eigentlich nicht, denn wenn es Open-Source ist, bedeutet das, dass es im Grunde jeder machen kann. Also kein Burggraben. Nochmals: Die Dinge, auf die ich achte, hängen wirklich von den spezifischen Gegebenheiten des Unternehmens ab.
Conor Doherty: Du kannst auch, wenn du das Beispiel nimmst und es mit einer Anekdote kombinierst, beispielsweise beim Blick in das Commit-Log in Git oder Bitbucket – wir nutzen Bitbucket – ziemlich viel herauslesen. Zum Beispiel, selbst bei uns im Marketing-Team, wenn wir irgendetwas auf die Website pushen, bestehst du auf ein sehr sauberes, ordentliches Commit-Log. Man sieht genau, was passiert ist, wer es genehmigt hat.
Joannes Vermorel: Genau. Und auch, manchmal allein die Art und Weise, wie Menschen mit mir interagieren. Ich spreche mit jemandem, stelle eine zufällige Frage – ist diese Person blitzschnell dabei, mir direkt die relevante Stelle im Code zu zeigen? So in der Art: “Oh, es gibt dieses Feature, das ziemlich interessant ist – kannst du mir den entsprechenden Code zeigen?” Und dann sagt der Typ: “Oh ja, kein Problem”, zack, direkt zur Implementierung. Das ist sehr gut. Diese vollständige Beherrschung der Codebasis, also wie alles umgesetzt wird, ist sehr, sehr positiv. Manchmal verrät allein die Leichtigkeit, mit der sich die Leute in der Codebasis zurechtfinden, mir unglaublich viel. Ebenso, wenn sie Features einführen: Haben sie gut geschriebene Tickets, um dies zu rechtfertigen? Sind die Softwareingenieure einfach wild am Code herumfummeln, oder haben sie einen strukturierten Ansatz, so dass zum Beispiel gesagt wird: “Okay, ich will das tun, hier ist mein Ticket, das klar beschreibt, warum ich das tun möchte”, und dann diskutiere ich die verschiedenen Ansätze, es umzusetzen, usw. Es kommt darauf an, aber typischerweise ist die Qualität der Tickets enorm wichtig. Das wäre besonders kritisch bei B2B-Apps oder Produktivitätsanwendungen, weil du eine endlose Liste von Features hast, die alle extrem domänenspezifisch sind. Wenn du eine Enterprise-App entwickelst, solltest du dich wirklich nicht in der unendlichen Menge von Features verlieren, die du deiner App hinzufügen könntest. Das wäre für verschiedene Unternehmenstypen sehr wichtig. Das wäre ein völlig anderer Prozess. Aber was ich sagen möchte, ist: Wie kann ich mir in nur wenigen Stunden eine Meinung bilden? Wenn du direkt neben jemandem sitzt, der mit der Codebasis arbeitet, siehst du unglaublich viel. Wenn du einfach auf die Muster achtest, darauf, was die Menschen tun – und ja, es ist Mustererkennung – gibt es eine endliche Anzahl von Dingen, in denen Menschen in einem bestimmten Beruf gut oder schlecht sein können.
Es gibt eine endliche Anzahl von Dingen, in denen Menschen in einem bestimmten Beruf gut oder schlecht sein können.
Conor Doherty: Ja, und du prüfst auch die Konsistenz, weißt du. Erzählen die Leute überhaupt dieselbe Geschichte in Bezug auf die Technologie? Ich frage: “Was denkst du, was diese Komponente macht?” Und wenn ich mehrere Personen bekomme, die mir völlig unterschiedliche Erklärungen liefern, sage ich: “Okay, es ist offensichtlich, dass in diesem Team niemand wirklich versteht, was vor sich geht.”
Joannes Vermorel: Ich brauche nicht die Wahrheit, um zu erkennen, dass Dinge inkonsistent sind. Nochmals, mein Ziel ist es nicht, ein Experte in dem zu werden, was sie tun. Mein Ziel ist es lediglich zu beurteilen, ob das Team funktionstüchtig ist und die technologische Entwicklung in einem vernünftigen Rahmen verläuft. Manchmal geht es auch darum zu überprüfen, ob beispielsweise die Cloud-Computing-Ressourcen tatsächlich unter Kontrolle sind. Manchmal gibt es Unternehmen, die ihre Cloud-Ressourcen falsch managen. Die Cloud ist fantastisch, pay as you go, was bedeutet, dass der Himmel die Grenze ist. Du kannst Tonnen von virtuellen Maschinen, Tonnen Speicher, Tonnen von allem aufdrehen. Und manchmal, weißt du, drehen manche Unternehmen ein bisschen durch und am Ende haben sie eine Entwicklung, bei der sie viel zu viel für Cloud-Computing-Ressourcen ausgeben, als sie sollten.
Conor Doherty: Das hängt wiederum davon ab, was sie tun. Wie viel sollte man für Cloud-Computing-Ressourcen ausgeben? Nun, es kommt wirklich darauf an, was du zu erreichen versuchst. Es gibt also keine klare Regel, aber ein Teil der Erfahrung besteht darin, zu beurteilen, was die Arbeitslast ist, die du in der Cloud bewältigen möchtest, und ob es Sinn macht, dass du so viel zahlst. Ist es eine Leistung – gut gemacht, deine Software ist hoch leistungsfähig – oder ist es super schlecht und du verschwendest einfach Geld? Wahrscheinlich ist es nicht der richtige Zug, dir Tonnen von extra Geld zum Verbrennen zu verschaffen. Du solltest diese Probleme wahrscheinlich beheben, bevor dir ein paar extra Millionen zur Verfügung gestellt werden.
Joannes Vermorel: Wenn du zu wenig Geld hast, kannst du dich nicht disziplinieren, um nicht unklug Geld durch überhöhte Ausgaben für Rechenressourcen zu verschwenden. Die Chancen, dass du weise wirst, sobald du viel mehr Geld hast, sind extrem gering.
Conor Doherty: In diesem Zusammenhang haben wir tatsächlich ein weiteres Video zum Thema Rechenressourcen, also schau dir die Playlist dazu an. Aber zum Thema Geld: Wenn du über Finanzen sprichst, weiß ich, dass du, wenn wir über supply chain sprechen, über die finanzielle Wirkung deiner Entscheidungen sprichst. Gehst du bei der Bewertung eines Tech-Unternehmens genauso vor? Betrachtest du, was die finanziell vorteilhafteste Orchestrierung des Technologieunternehmens ist oder was einfach die beste Technik ist, unabhängig vom Preis?
Joannes Vermorel: Nein, nein, nein. Jedes Startup hat begrenzte Ressourcen. Die Idee – und das ist wieder das Problem mit Checklisten – ist, dass Checklisten eine absolute Perspektive haben. Sie sagen, du musst dies, dies, dieses und jenes tun. Meine Perspektive ist immer völlig relativ zur Reife des Unternehmens.
Conor Doherty: Ja, genau, zu ihren eigenen Bedingungen.
Joannes Vermorel: Du willst zum Beispiel nicht, dass es pure Verrücktheit wäre, wenn ein winziges Unternehmen eine ISO-Zertifizierung anstrebt. Es ist eine komplette Ressourcenverschwendung, es sei denn, du befindest dich in einem hyperregulierten Markt, in dem du ohne diese Zertifizierung nicht überleben kannst. Was ich beurteile, ist, wie gut du deine begrenzten Ressourcen einsetzt, um den maximalen Nutzen herauszuholen. Ich gehe einfach davon aus, dass deine Ausrichtung gut ist, dass du, wenn du erfolgreich bist, Geld verdienen wirst. Aber trotzdem, wenn ich deine Geschäftsausrichtung als gegeben annehme, sage ich: “Okay, geben wir zu, wenn dieses Vorhaben gelingt, wirst du in diesem Markt wettbewerbsfähig sein und es wird Geld zu verdienen geben.” Das nehme ich als gegeben hin. Nun, jeder Dollar oder Euro, der dafür ausgegeben wird, diesen Markt zum nummer-eins Spieler zu machen – wird er klug ausgegeben?
Conor Doherty: Absolut. Das kann zum Beispiel bedeuten: Hast du das richtige Talent? Manchmal geben sie zu wenig aus. Es kommt vor, dass ein Unternehmen eine gewisse Erfolgsphase erreicht, und sie lassen Leute nicht gehen, die ursprünglich eingestellt wurden, weil sie super günstig waren. Das passiert auch ziemlich häufig bei Tech-Startups.
Joannes Vermorel: Besonders wenn der Gründer kein Tech-Gründer ist, sondern ein Vertriebsgründer, und dann hast du den CTO, der ursprünglich der erste Softwareentwickler war, der je im Unternehmen eingestellt wurde. Das passiert häufig, und diese Person entspricht nicht dem erforderlichen Niveau. Wiederum, Ausnahmen variieren – deine Erfahrungen können variieren.
Conor Doherty: Genau. Meine Frage ist also: Gab es Situationen, in denen du ein Unternehmen bewertet hast, in dem du all das beurteilt hast, worüber du gesprochen hast – den Code, die Arbeitsweise des Teams, ob sie mit den vorhandenen Ressourcen das Ziel erreichen könnten – und bei denen sich herausstellte, dass ihr eigentliches Ziel völlig unsinnig war? Zum Beispiel: Es ist 2008 und dieses Unternehmen hat sich fest vorgenommen, die VHS-Kassette wiederzubeleben – etwas absolut Verrücktes, von dem du fest überzeugt bist, dass es eine riesige Verschwendung von Geld, Zeit und Ressourcen darstellt.
Joannes Vermorel: Oh ja, das kommt vor. Fühl dich frei, aber nenne keine Namen.
Conor Doherty: Nein, das Ding ist: Manche Softwaretechnologien entwickeln sich ziemlich schnell. Zum Beispiel habe ich in den letzten zwei Jahren einige Unternehmen auditiert, die sich mit NLP beschäftigt haben. Diese Unternehmen wurden 2018 oder 2019 gegründet, und sie sprangen auf die KI-Welle auf und entwickelten NLP-, also Natural Language Processing-Technologien, aber pre-LLM, vor großen Sprachmodellen. Es gab eine enorme Literatur zu NLP-Modellen und Machine Learning, deep learning, die keine LLMs sind. LLMs waren ein Auslöschungsereignis für all diese NLP-Technologien.
Joannes Vermorel: Ja, es gab viele Unternehmen, bei denen ich zu dem Schluss kam, dass dieses Unternehmen 20 ziemlich ausgefeilte NLP-Modelle entwickelt hat, die alle völlig veraltet sind. LLMs übertreffen all das einheitlich. Man kann einfach den gesamten Tech-Stack über Bord werfen und von Grund auf mit einem LLM im Mittelpunkt neu starten – so wird es besser. Es gibt nichts zu retten. Es passiert ziemlich häufig, vielleicht eins von zehn, eins von zwanzig, dass die Technologie aus irgendeinem Grund einfach veraltet ist. Manchmal haben die Leute nicht genau gesehen, was der Ersatz sein wird, aber ja, wenn ich merke, dass diese Sache einfach so weiterläuft, löst man ein Problem, das bereits gelöst ist.
Conor Doherty: Normalerweise ist es so, dass es nicht Unsinn im Sinne davon ist, dass diese Leute Dummköpfe sind. Es gibt ein Problem, das gelöst werden muss, und sie haben etwas Schönes entwickelt – aber es gibt etwas viel Besseres, das bereits gefunden wurde und möglicherweise sogar kostenlos ist. Diese Sache ist noch nicht populär, noch nicht super bekannt. Ich denke, LLM ist wirklich der extreme Fall, in dem diese Unternehmen irgendwie verzweifelt waren, weil sie wussten, dass LLMs kommen würden und dass es ein Aussterbeereignis darstellt. Aber du bist der Gründer eines Unternehmens, du hast bereits das in Seed-Runden aufgebrachte Geld investiert, um das zu tun, und jetzt stehst du vor der Aussicht, dass deine Technologie irgendwie wertlos ist. Du versuchst vielleicht, eine Investition zu bekommen, die dir erlauben würde, die Technologie neu zu entwickeln. Schwierig.
Joannes Vermorel: Meine Meinung in solch einer Situation ist nicht, den Investoren zu sagen: “Investiert nicht.” Meine Botschaft lautet, dass der Technologie-Stack, den sie besitzen, einfach nichts wert ist. Falls die Leute gut sind, könnte es trotzdem sinnvoll sein, in sie zu investieren – allerdings zu einer viel niedrigeren Bewertung, denn das, was sie haben, ist einfach: dieses technologische Asset ist völlig veraltet. Es ist kein Asset mehr, es ist eine Verbindlichkeit.
Das Team funktioniert, und die Entwicklungstrajektorie der Technologie ist verrückt. Manchmal geht es auch darum, beispielsweise zu überprüfen, dass die Cloud-Computing-Ressourcen wirklich unter Kontrolle sind. Manchmal gibt es Unternehmen, die ihre Cloud-Ressourcen falsch verwalten. Die Cloud ist fantastisch; pay-as-you-go bedeutet, dass der Himmel die Grenze ist. Man kann Unmengen von virtuellen Maschinen, massig Speicher und alles Mögliche hochfahren. Manchmal drehen Unternehmen ein wenig durch und landen in einer Situation, in der sie viel zu viel für Cloud-Computing-Ressourcen ausgeben, als sie sollten. Es kommt darauf an, was sie tun. Wie viel solltest du für Cloud-Computing-Ressourcen bezahlen? Nun, es hängt wirklich davon ab, was du erreichen möchtest. Es gibt keine eindeutige Regel, aber ein Teil der Erfahrung besteht darin, abzuschätzen, welche Arbeitslast du in der Cloud bewältigen möchtest und ob es Sinn macht, so viel zu bezahlen. Ist es eine gut erbrachte Leistung, deine Software ist hochperformant, oder ist sie super schlecht und du verbrennst einfach Geld? Wahrscheinlich ist es einfach nicht klug, dir Unmengen von extra Geld zu geben, das du verbrennen kannst. Du solltest diese Probleme wohl lieber beheben, bevor dir ein paar extra Millionen zur Verfügung gestellt werden. Wenn dir das Geld fehlt, kannst du dich nicht disziplinieren, um nicht durch unkluge Ausgaben bei Rechenressourcen Geld zu verbrennen. Die Chancen, dass du weise wirst, sobald du viel mehr Geld hast, sind äußerst gering.
Conor Doherty: Mir kommt in den Sinn – und dazu haben wir tatsächlich ein weiteres Video zum Thema Rechenressourcen, schau dir dazu die Playlist an – aber zum Thema Geld: Wenn du über Finanzen sprichst, weiß ich, dass wenn wir über supply chain reden, du über die finanzielle Auswirkung deiner jeweiligen Entscheidung sprichst. Gehst du beim Bewerten eines Technologieunternehmens genauso vor? Siehst du eher, was die finanziell vorteilhafteste Orchestrierung ist, oder was einfach die beste Technologie ist – unabhängig vom Preis?
Joannes Vermorel: Nein, nein, nein. Jedes Startup hat begrenzte Ressourcen. Das Problem mit Checklisten ist, dass sie eine absolute Perspektive einnehmen und vorschreiben, dass man dies, das und jenes tun muss. Meine Sichtweise ist immer völlig relativ zur Reife des Unternehmens.
Conor Doherty: Ja, genau – zu ihren eigenen Bedingungen.
Joannes Vermorel: Man will zum Beispiel nicht, dass es reine Verrücktheit wäre, wenn ein kleines Unternehmen sich für eine ISO-Zertifizierung entscheidet. Es ist eine völlige Ressourcenverschwendung, es sei denn, es handelt sich um einen hyperregulierten Markt, in dem du ohne diese Zertifizierung nicht überleben kannst. Was mich interessiert, ist, wie gut du deine begrenzten Ressourcen nutzt, um das Maximum an Nutzen für dein Geld herauszuholen. Ich gehe einfach davon aus, dass deine Ausrichtung stimmt, dass du letztlich, wenn du Erfolg hast, Geld verdienen wirst. Aber trotzdem – wenn ich deine Geschäftsstrategie als gegeben voraussetze – sage ich: Okay, geben wir zu, wenn diese Sache abgeschlossen ist, wirst du in diesem Markt wettbewerbsfähig sein und es wird Geld zu verdienen geben. Das nehme ich hin. Nun, jeder Dollar oder Euro, der dafür ausgegeben wird, in diesem Markt die Nummer-eins zu werden – wird er weise ausgegeben? Absolut. Man könnte fragen, ob du das richtige Talent hast. Manchmal geben sie auch zu wenig aus. Es kommt vor, dass ein Unternehmen einen gewissen Erfolg erzielt und man sich nicht von Personen trennt, die ursprünglich eingestellt wurden, weil sie super günstig waren. Das passiert auch ziemlich häufig bei Tech-Startups. Besonders wenn der Gründer kein Tech-Gründer, sondern ein Vertriebsgründer ist und dann hast du den CTO, der ursprünglich der erste Softwareingenieur war, der jemals im Unternehmen eingestellt wurde. Das kommt oft vor, und diese Person ist dann nicht auf dem erforderlichen Niveau. Wiederum variieren hier die Ausnahmen – deine Erfahrungen können anders sein.
Conor Doherty: Genau. Meine Frage ist, gab es Situationen, in denen du in ein Unternehmen gegangen bist und nach der Bewertung gedacht hast: “Ich habe gerade den nächsten Elon Musk getroffen”? So, dass du dachtest: “Der Typ ist ein Genie, sie sitzen auf einem Diamanten”?
Joannes Vermorel: Oh ja, das kommt vor.
Conor Doherty: Teile gern, aber nenne keine Namen.
Joannes Vermorel: Einige Softwaretechnologien entwickeln sich ziemlich schnell. Zum Beispiel habe ich in den letzten zwei Jahren etliche Unternehmen auditiert, die sich mit NLP beschäftigen. Diese Unternehmen wurden 2018 oder 2019 gegründet, sind in diese KI-Welle eingestiegen und haben NLP (Natural Language Processing)-Technologien entwickelt – aber in der Zeit vor LLMs (Large Language Models). Es gab eine enorme Literatur zu NLP-Modellen sowie zu maschinellem Lernen und Deep Learning, aber keine LLMs. LLMs waren ein Aussterbeereignis für all diese NLP-Technologien. Für diese Unternehmen war mein Fazit, dass sie 20 ziemlich ausgefeilte NLP-Modelle entwickelt hatten, die alle völlig veraltet sind. LLMs übertreffen all das einheitlich. Man kann einfach den Tech-Stack wegwerfen und von Grund auf mit einem LLM im Mittelpunkt neu starten. Es gibt nichts zu retten. Es passiert ziemlich häufig – vielleicht eins von zehn oder eins von zwanzig –, dass die Technologie aus irgendeinem Grund einfach veraltet ist. Manchmal haben die Menschen nicht genau gesehen, was der Ersatz sein wird. Wenn ich sehe, dass diese Sache einfach so abläuft, löst man ein Problem, das bereits gelöst ist. Normalerweise ist es nicht Unsinn im Sinne davon, dass diese Leute Idioten sind. Es gibt ein Problem, das gelöst werden muss, und sie haben etwas Schönes entwickelt – aber es gibt etwas viel Besseres, das bereits gefunden wurde und möglicherweise kostenlos ist. Diese Sache ist noch nicht populär, noch nicht super bekannt. LLMs sind ein extremer Fall, bei dem Unternehmen ziemlich verzweifelt waren, weil sie wussten, was kommen würde, und es ein Aussterbeereignis war. Du bist der Gründer eines Unternehmens, hast bereits das Geld aus Seed-Runden investiert, um das zu tun, und nun stehst du vor der Aussicht, dass deine Technologie irgendwie wertlos ist. Du versuchst vielleicht, eine Investition zu bekommen, die dir erlauben würde, die Technologie neu zu entwickeln. Schwierig. Meine Auffassung ist nicht, den Investoren zu sagen, sie sollen nicht investieren. Meine Botschaft lautet, dass der Technologie-Stack, den sie haben, einfach nichts wert ist. Wenn die Leute gut sind, könnte es immer noch Sinn machen, in sie zu investieren – aber nur zu einer viel niedrigeren Bewertung, weil das, was sie haben, nicht mehr ein Asset, sondern eine Verbindlichkeit ist.
Conor Doherty: Am anderen Ende dieses Spektrums – bist du schon einmal in ein Unternehmen gegangen und hast gedacht, ich habe gerade den nächsten Elon Musk getroffen? So, dass du meintest: “Der Typ ist ein Genie, sie sitzen auf einem Diamanten”?
Joannes Vermorel: Auf dieser Skala, nein. Aber ja, ich habe mich manchmal ein wenig neidisch gefühlt im Vergleich zu meinem eigenen Unternehmen. Vor allem, wenn Menschen solch wunderschöne Nischen haben. Es gibt so viele idyllische Nischen. Die Fälle, die mich am meisten neidisch machen, sind schöne Probleme, die super nischenspezifisch sind. Niemand weiß überhaupt, dass dieses Problem existiert. Es stellt sich heraus, dass dabei Zehn-Millionen – möglicherweise sogar eine Milliarde – im Spiel sind. Das ist ein Nischenmarkt, und einige bringen eine Lösung für diese Nische, und sie ist wunderschön. Sie ist sehr einfach, unkompliziert und zielgerichtet. Anstatt durch einen hyperkompetitiven Markt zu gehen – zum Beispiel Lokad, das supply chain optimization betreibt – haben wir weltweit über tausend Wettbewerber. Es ist ein sehr überfüllter Markt. Wir haben einige Konkurrenten, die Multi-Milliarden-Unternehmen sind. Das Wettbewerbsumfeld ist hart. Manchmal treffe ich Unternehmen, bei denen sie buchstäblich null Wettbewerber haben. Sie sind die Einzigen. Ihre Kunden sind zufrieden, sie haben eine Lösung, die wirklich auf ein Nischenproblem abgestimmt ist, von dem ich noch nie zuvor gehört habe.
Conor Doherty: Gibt es Beispiele oder wäre das zu viel verraten?
Joannes Vermorel: Nein, das wäre leider zu viel preiszugeben. Ich versuche es, aber letztlich: Denke an – sagen wir – alles, was super spezialisiert ist.
Denke an die spezialisierte Wartung einer Offshore-Ölplattform. Es gibt Unmengen an Dingen, die erledigt werden müssen, und einige Spezialoperationen benötigen Software als Unterstützung. Es gibt Unternehmen, die das machen. Denke an jede erdenkliche Nische, die vermutlich sehr dedizierte Lösungen benötigt.
Es gibt zahlreiche Situationen, in denen man sich vorstellen kann, wie viel technologische Ausrüstung ein Chirurg im Operationssaal verwendet. Unmengen an Ausrüstung, selbst wenn du etwas messen möchtest. Zum Beispiel gab es in diesem Gebäude eine Kontrolle, um festzustellen, ob Asbest vorhanden war. Es gab ein Gerät mit Software, um Asbest in diesem Gebäude zu erkennen. Irgendwo gibt es ein Unternehmen, das das macht. Diese können sehr spezifische Nischen sein, die klein erscheinen mögen, aber wenn man den globalen Markt betrachtet, sind sie gar nicht so klein.
Diese super kleinen Nischen könnten weltweit ein Volumen von ein paar hundert Millionen Dollar haben, und ein Unternehmen hat die Möglichkeit, einen 50%-Marktanteil zu erobern, weil es keine Wettbewerber gibt. Die Alternative ist, dass die Menschen traditionelle Methoden mit Stift und Papier verwenden.
Conor Doherty: Im Laufe dieser 10 Jahre und nachdem du eine Vielzahl unterschiedlicher Beispiele gesehen hast, gibt es allgemeine Best Practices und Worst Practices, die dir in Bezug auf Software oder Startups aufgefallen sind? Fangen wir mit den Dingen an, die man vermeiden sollte, und enden dann mit einer positiven Note. Also: Was ist absolut zu vermeiden?
Joannes Vermorel: Wenn dir deine Technologie egal ist, wird sie dir das Genick brechen. Mangelnde Sorgfalt ist ein Killer. Immer wenn ich Unternehmen sehe, bei denen den Leuten die Technologie egal ist, ist sie normalerweise kompletter Mist.
Conor Doherty: Definiere, was du mit “egal sein” meinst. Heißt das, dass sie nicht daran interessiert sind, sich darüber zu informieren, oder dass sie es einmal waren und jetzt nicht mehr, oder ist es ein Mangel an Können? Was meinst du damit?
Joannes Vermorel: Am besten lässt es sich so beschreiben: Wenn der CTO duscht, denkt er dann an seine Technologie oder an Golf? Menschen, denen wirklich etwas daran liegt, zeigen eine gewisse Intensität. Es hört nicht mit den Bürozeiten auf; es geht darüber hinaus. Sie sind extrem neugierig, eifrig und leidenschaftlich. Sie wollen wirklich das Richtige tun. Es gibt dieses Element leichter Verrücktheit, bei der es nicht nur darum geht, das Richtige für den Kunden zu tun, sondern auch das Richtige für die Technologie selbst.
Entwickelst du etwas, das wirklich schön ist? Es gab eine Anekdote über Steve Jobs. Er wollte, dass das iPhone auch von innen gut aussieht. Wenn man es auseinandernimmt, sollen die Komponenten im Inneren des iPhones elegant sein – mit der richtigen Farbauswahl und allem Drum und Dran. Dieser Grad an Sorgfalt zeigt, dass dir nicht nur das äußere Erscheinungsbild wichtig ist, sondern auch die technologischen Teile, die kein Kunde jemals zu Gesicht bekommt.
Wenn den Leuten etwas egal ist, ist das wirklich schlecht. Am schlimmsten ist wahrscheinlich, wenn Technologieunternehmen die Entwicklung ihrer Technologien an freiberufliche Mitarbeiter outsourcen. Es spielt keine Rolle, wie gut oder schlecht diese Freelancer sein mögen; das Endergebnis ist meist, dass die Technologie ein komplettes Chaos ist.
Conor Doherty: Ich denke, die meisten würden zustimmen, dass die innere Leidenschaft und der Antrieb, etwas gut zu machen, eine fantastische Eigenschaft sind. Aber wenn du nur 20 Minuten mit dem CTO hast, wie beurteilst du diese immateriellen Werte ohne eine Checkliste?
Joannes Vermorel: Jemand mit Intensität wird mir sagen: “Wir haben diese Technologie aus diesem Grund gewählt.” Sie kennen das Warum. Es ist nicht einfach: “Ich brauchte eine Webschnittstelle, also habe ich diese ausgewählt.” Sie haben klare Meinungen zu ihren technologischen Entscheidungen. Menschen mit Leidenschaft haben so viele Meinungen – sie strömen förmlich aus ihnen heraus. Sie können sich nicht zurückhalten. Jedes Mal, wenn ich einen Teil der Technologie berühre, sagen sie: “Wir machen es so, aus genau diesen Gründen.”
Conor Doherty: Es ist die Leidenschaft, an der sie interessiert sind.
Joannes Vermorel: Ja, und man sieht die Intensität ihres Denkens. Es ist nicht einfach ein Stück Technologie, das sie umgesetzt haben, weil es Anforderungen gab. Menschen, die Code in Kilometern produzieren, verfolgen einen ganz alltäglichen Ansatz, bei dem Anforderungen vom Vertriebsteam kommen und sie einfach umgesetzt werden. Das ist ein Rezept für einen Tech-Stack, der absoluter Mist ist.
Conor Doherty: Zum Beispiel, wenn du in der Vergangenheit Steve Jobs auditiert hättest und er dir gesagt hätte: “Schau dir das Innere dieses Telefons an, ich habe es schön gemacht”, dann würde dein Memorandum besagen, dass er leidenschaftlich ist – aber das ist eine verrückte Sache, um Geld dafür auszugeben.
Joannes Vermorel: Nein, nein. Die Frage ist: Wirkt es so, als würden sie sich ablenken lassen, oder verleihen sie dem Ganzen einfach diesen extra Feinschliff? Diese Dinge sind vielleicht nicht sehr kostspielig. Es ist einfach die Intensität. Du gibst ein paar Prozent mehr, damit alles wirklich straff und schön wird. Das ist keine Verrücktheit. Menschen, die es übertreiben, unterliegen typischerweise dem Second-System-Effekt. Das passiert, wenn ein Team von Ingenieuren bei ihrem zweiten Versuch in Dinge überinvestiert, die sie nicht brauchen, weil der erste Versuch aufgrund mangelhafter Technik gescheitert ist.
Der häufigste Fall ist, wenn Menschen in Skalierbarkeit überinvestieren, die sie so bald gar nicht benötigen werden. Sie sagen: “Schaut euch unsere wunderschöne Architektur an; sie kann 10 Millionen Benutzer verarbeiten.” Wie viele Benutzer habt ihr in diesem Moment? “Oh, 200.” Es gibt eine gewaltige Diskrepanz zwischen dem, was benötigt wird, und dem Over-Engineering.
Außerdem diejenigen, die bei den falschen Dingen geduldig sind. Hast du Geduld für eine bestimmte Eleganz und Schönheit der Technologie um ihrer selbst willen oder verfolgst du irgendein Dogma? In der Softwareindustrie gibt es alle Arten von Dogmen im Umlauf. Wir müssen es wie Scrum machen, oder Domain-driven Development, oder Test-driven Development, oder Microservices. Es gibt viele guruartige Ansichten in der Softwarebranche, und du findest Leute, die Eiferer dafür sind. Wenn ich von Intensität spreche, meine ich Menschen, die lieben, was sie erschaffen, aber nicht fanatisch gegenüber einer bestimmten Ideologie sind. Fanatiker tun Dinge, die selbst ihren eigenen praktischen Anforderungen völlig widersprechen. Sie sagen: “Oh, aber wir müssen es so machen, weil es testgetriebenes Design ist.” Die Tatsache, dass es testgetriebenes Design ist, rechtfertigt es nicht, es so zu machen. Ergibt es wirklich Sinn, es so zu tun im Hinblick auf die Probleme, die du hast?
Conor Doherty: Und in Bezug auf Best Practices, sag nicht einfach das Gegenteil von dem, was du gerade gesagt hast. Fallen dir spontan irgendwelche Dinge ein, bei denen du denkst: “Oh, das ist ein gutes Zeichen”?
Joannes Vermorel: Klare Dokumentation. Das hast du schon einmal gesagt. Klare Dokumentation. Jeder einzelne Abschnitt muss präzise, scharf und knapp sein. Hast du Seiten voller Kommentare im Code, die bloß bürokratisch sind, wie: “Oh, wir müssen das kommentieren”? Gibt es ein Template, und du hast eine Seite voller Kommentare, die niemand lesen wird? Oder hast du super prägnante Kommentare, die sehr aufschlussreich sind? Schon allein das Lesen eines Kommentars erhellt die gesamte Code-Datei. Wenn ich mir die Tickets ansehe, ist eure Problembeschreibung klar formuliert oder ein unverständliches Durcheinander? Wenn du eine technische Herausforderung hast, gibt es eine sehr aussagekräftige Diskussion des Problems und der Möglichkeiten, oder hast du eine miese Folie mit absurden Stichpunkten, die nichts aussagen? Die Qualität der Schrift ist eines der aussagekräftigen Merkmale. Ein weiteres Merkmal ist, wenn Leute ungewöhnliche Technologien verwenden, die sich dennoch als sehr gute Entscheidungen erweisen. Wenn sie ein ungewöhnliches Stück Technik einsetzen, liegt das sehr oft einfach an Unwissenheit. Sie wussten nicht, dass es eine viel mainstreamigere Lösung gibt, die deutlich besser wäre. Normalerweise ist das negativ, aber wenn sich herausstellt, dass ein relativ seltenes Technologieelement überraschend genau zu dem passt, was sie tun, ist das sehr gut. Das bedeutet, dass sie die technologische Landschaft, besonders die Open-Source-Technologielandschaft, sehr umfassend erkundet haben. Das ist wirklich erfreulich. Heutzutage würde es niemand überraschen, wenn Leute sagen: “Oh, wir verwenden Python, PostgreSQL, Tailwind for CSS, React.” Das sind Komponenten, die jeder halbwegs kompetente Softwareentwickler kennt. Aber wenn sie etwas super Spezifisches kennen, das wirklich zu ihrem Problem passt, ist das auch sehr interessant.
Conor Doherty: Cool. Nun, wir sind jetzt seit etwa einer Stunde unterwegs. Ich achte auf die Zeit, also zum Schluss: Gibt es abschließende Gedanken, die du gern mit allen teilen möchtest?
Joannes Vermorel: Ja. Ich denke, was mich in diesem Jahrzehnt der Audits am meisten überrascht, ist, wie oft Tech-Unternehmen buchstäblich Jahre und manchmal aufeinanderfolgende Investitionsrunden verbringen, ohne dass sich jemand die Technik wirklich angeschaut hat. Man würde denken, dass Theranos, dieser große Betrug, eine Ausnahme war. Eine solch massive Investition und niemand hat die Technologie gründlich überprüft. Aber das Lustige ist, dass dies die Regel ist. Für mich ist es besonders faszinierend, wie selten diese technologischen Audits stattfinden. Wenn ich mit den Startup-Gründern spreche, sagen sie normalerweise: “Wir hatten keine Ahnung, dass du solche Fragen stellen würdest.” Sie denken, ich käme mit einer verrückten, dummen Checkliste. Stell dir Theranos vor; die Leute hätten die Checkliste leicht überlisten können. Es gab genügend Checklisten, die fragten: “Seid ihr konform mit diesem oder jenem?” Ja, ja, ja, ja. Aber die Kernfrage, nämlich “Ist eure Blutanalysentechnologie real?” wurde von niemandem gestellt. Diese Fragen waren super grundlegend.
Conor Doherty: Das führt zurück zu dem Punkt, den du vorhin über “Skin in the Game” erwähnt hast. Wenn Risikokapitalgeber Millionen in dein Unternehmen investieren, dann haben sie auch entsprechend ein Risiko.
Joannes Vermorel: Was mich besonders überrascht, ist, dass in der Regel, selbst wenn ich in der dritten Runde dazukomme, niemand das technologische Fundament ernsthaft unter die Lupe genommen hat. Das ist sehr merkwürdig. Du hast Prüfer, die einfach nur Kästchen abhaken, aber in meinen Augen zählt das nicht. Sie tun nur so, als würden sie die Arbeit erledigen. Sie leisten nichts Substanzielles. Es ist super einfach, diese Leute zu täuschen, denn alles, was du tun musst, ist zu lügen. Sag einfach: “Macht ihr das?” “Ja, machen wir.” “Zeig es uns.” Du zeigst etwas, das überhaupt keinen Sinn macht. Der Auditor ist kein Technikexperte, sodass du ihm alles zeigen könntest und er einfach sagen würde: “Okay, Kästchen abgehakt.” Am Ende dieser Audits ist es sehr aufschlussreich. Bei klassischen Audits wird der Auditor sagen: “Bitte unterschreibt dieses Papier, das bestätigt, dass ihr uns nicht belogen habt, und falls ihr gelogen habt, lehnen wir jegliche Verantwortung ab.” Meiner Meinung nach werde ich so etwas definitiv nicht machen. Ich setze nicht voraus, dass die Leute mir die Wahrheit sagen. Deshalb möchte ich den Code sehen. Ja, du kannst mich täuschen und mir jede Menge Dinge erzählen, aber wenn wir uns den Code anschauen – eine gefälschte Codebasis, gefälschte Tausende von Commits, gefälschte Hunderte von Tickets, gefälschte unterstützende Dokumente – das ist viel schwieriger. Was mich überrascht, ist, dass die Kosten nur einen Tag Audit betragen. Ja, ich bin nicht gerade billig, aber trotzdem, es ist nur ein Tag. Selbst nachdem ich diese Audits seit über einem Jahrzehnt durchführe, fällt mir immer noch auf, dass selbst in der zweiten oder dritten Runde niemand die Technologie wirklich hinterfragt. Die Leute nehmen einfach an, dass sie gut ist, funktioniert, und dass sie ihren Fahrplan umsetzen werden. Keine Prüfung irgendeiner Art. Für mich ist das ein wenig verblüffend.
Conor Doherty: Nun, hoffentlich wird etwas von dem, was wir heute besprochen haben, einen Unterschied machen und vielleicht sogar einige Leute dazu inspirieren, dich zu kontaktieren. Du stehst auch für Bat Mitzvahs und Geburtstage zur Verfügung, glaube ich.
Joannes Vermorel: Ja.
Conor Doherty: Nun, Joannes, vielen Dank für deine Zeit und dafür, dass du all meine Fragen beantwortet hast. Vielen Dank und danke fürs Zuschauen. Wir sehen uns beim nächsten Mal.
