- Bietet die Inhalte des aktuellen Buchs Startup CTO's Handbook; der Text ist im Markdown-Format lesbar
- Das Buch kann bei Amazon und Audible gekauft werden
- Der Link zu einer als PDF gerenderten Version der aktuellen Markdown-Fassung ist noch Coming Soon; das ursprüngliche Manuskript liegt derzeit als veraltete Version im Google Doc vor
- Beiträge über Issues und Pull Requests für Ergänzungen, Änderungen, Vorschläge und Kritik werden empfohlen, damit sie in künftige Ausgaben einfließen können
- Die Lizenz erlaubt das Kopieren, Ändern und Weiterverbreiten unter der Bedingung, dass kein Wiederverkauf erfolgt, der Name des Autors und der Urheberhinweis erhalten bleiben und spätere Versionen unter einer ähnlichen oder identischen Lizenz veröffentlicht werden
1 Kommentare
Hacker-News-Kommentare
Einigem stimme ich klar zu. Zum Beispiel bin ich für die Aufzeichnung aller Meetings. Bei Themen wie Performance-Management[0] gibt es aber auch vieles, dem ich persönlich nicht zustimme
Das ist nicht unbedingt als Kritik gemeint, sondern eher so, dass sich je nach Problembereich die Herangehensweisen und Führungsstile unterscheiden können. Ich hoffe, dass dieser Leitfaden nicht als unantastbar angesehen wird. Wenn das hier nicht zu den eigenen Erfahrungen passt, würde ich eher empfehlen, den eigenen Erfahrungen mehr zu vertrauen
[0] https://twitter.com/bcantrill/status/1216491216356823040
Als CTO wüsste ich nicht, wie man diese Bitte ohne Druck ausüben könnte
In der Praxis gibt es allerdings oft echte Kompetenzlücken, und ich denke, dass eine Führungskraft in der Rolle eines Coaches Wachstum und Leistung mancher Menschen schneller voranbringen kann
Dort geht es um prospektives Performance-Management, also darum, wie man Leistung in Zukunft verbessert. In den meisten Unternehmen sind Leistungsbeurteilungen aber eher retrospektive Bewertungen, bei denen vergangene Leistung für die Verteilung von Vergütung und Beförderungen eingeordnet wird
Ein prospektiver Prozess ist großartig, aber am Ende braucht man trotzdem ein gewisses Maß an Bewertung vergangener Leistung
Ich hatte die Gelegenheit, mit dem Autor in zwei Unternehmen zusammenzuarbeiten, und es ist schwer in Worte zu fassen, wie groß der Unterschied ist, wenn die hier beschriebenen Dinge tatsächlich umgesetzt werden
Die Wirkung bleibt nicht auf Produkt oder Engineering beschränkt, sondern breitet sich auf die gesamte Organisation aus. Jedes System und jede Empfehlung muss am Ende an die eigene Organisation angepasst werden, aber ich würde sehr empfehlen, Zachs Ansatz so weit wie möglich zu nutzen
Ich mag Meeting-Aufzeichnungen. Nicht als Beweismittel, wenn ein Team anfängt, sich gegenseitig die Verantwortung zuzuschieben, sondern weil es wirklich hilfreich ist, Meetings und Diskussionen noch einmal ansehen zu können
Wenn ich in wichtigen Diskussionen oder Alignment-Meetings einen großen Teil meiner Fähigkeiten einsetzen muss, ist es schwer, mich gleichzeitig auf das Thema zu konzentrieren, Notizen zu machen und mir alles zu merken. Wenn ich weiß, dass es eine Aufzeichnung gibt, kann ich mich im Meeting voll auf Konzentration, gute Fragen und das Prüfen von Annahmen fokussieren
Am nächsten Tag kann ich den Call noch einmal anhören, anhalten, ihn mit 2x oder 3x Geschwindigkeit hören, persönliche Notizen machen, Protokolle oder interne Zusammenfassungen schreiben, Denk-Diskrepanzen entdecken oder passend zu meinem Zeitplan ein KI-Notiztool laufen lassen
Es hilft auch, wenn jemand krank ist, die Schwiegermutter vom Flughafen abholen muss, gleichzeitig in einem anderen Meeting steckt oder erst eine Woche nach einem wichtigen Alignment-Meeting dazukommt. Wenn ein Meeting nicht wichtig ist, kann man es einfach ignorieren, und mit sinnvollen automatischen Löschregeln ist das Thema erledigt
Ich glaube außerdem nicht wirklich, dass Menschen ihre Zeit damit verbringen, heimlich in Bereiche zu gehen, in denen sie nichts zu suchen haben, daher halte ich das nicht für ein großes Problem
Team-Meetings neigen außerdem dazu, das Gespräch in Richtung derjenigen zu kippen, die sich beim Sprechen sicher fühlen. Das ist besonders nachteilig für neue Teammitglieder oder Menschen, deren Hauptsprache eine andere ist
Ich bin nicht grundsätzlich gegen Meetings. Manche Menschen kommunizieren viel lieber mündlich als schriftlich, und gute Teams sollten in der Lage sein, die bevorzugte Arbeitsweise jedes Mitglieds zu berücksichtigen
Aber wenn ein Team-Meeting wichtig ist und den Teilnehmenden viel abverlangt, dann sollte es kein Meeting sein. Meetings sollte es nur geben, wenn alle Beteiligten für ein bestimmtes Gespräch entscheiden, dass ein Meeting das beste Medium ist
Meetings sind wie aus einem Feuerwehrschlauch zu trinken: Details gehen dabei verloren
Wir sind zu Google Workspace gewechselt, weil dort Meeting-Aufzeichnungen leicht durchsuchbar sind. Zum Beispiel ist die Aufzeichnung direkt in den Kalendereintrag eingebettet
Wenn ein Meeting nicht wichtig genug ist, um es aufzuzeichnen, war es wahrscheinlich auch nicht wichtig genug, um es überhaupt abzuhalten
Ich investiere persönlich mehr Stunden pro Tag als andere, aber das geschieht nicht aus innerem Antrieb. Es kann Überschneidungen bei wichtigen Meetings geben, und wenn man nur das Protokoll liest, gehen viele Nuancen verloren. Außerdem lesen Leute Protokolle ohnehin selten
Wenn Meetings aber aufgezeichnet werden, kann man Protokolle schnell und korrekt prüfen, was extrem nützlich ist. Deshalb treibe ich Meeting-Aufzeichnungen ziemlich stark voran
Je schneller man die eigentliche Ursache versteht, desto schneller kann man das Problem beheben. Um dieses Konzept und seine Anwendung im Unternehmen zu verstehen, empfehle ich sehr Extreme Ownership von den ehemaligen Navy SEALs Jocko Willink und Leif Babin
Asynchrone Teilnahme an Meetings ist aus den oben genannten Gründen großartig. Sie macht die Informationen in Meetings durchsuchbar. Meetings können inzwischen per Natural Language Processing untertitelt werden, und dieser Inhalt kann von LLMs gefunden werden
Wir trainieren derzeit einen internen Chatbot auf Confluence-Inhalten und wollen das auf Inhalte aus aufgezeichneten Meetings ausweiten
Ein bisschen Eigenwerbung: Ich baue https://designpro.ai, ein Tool, das Eingaben aus verschiedenen Quellen in Erkenntnisse und Aufgaben umwandelt. Ich habe es genutzt, um aus Gesprächstranskripten Erkenntnisse zu ziehen, und weiß, dass es tatsächlich funktioniert
Ich bin vor Kurzem CTO geworden, und eine der größten Schwierigkeiten ist die Kommunikation mit dem CEO. Vielleicht wird das im Buch behandelt, aber ich habe nur das Inhaltsverzeichnis gelesen
In den letzten 8 Monaten wollte der CEO keine Alignment-Meetings, nichts planen, keine Vision vorantreiben und sich nur auf Killer-Features konzentrieren
Er will nicht einmal Mockups oder Prototypen bauen, um sie mit Nutzern zu testen, und wenn doch, dann müssten sie schön sein. Alles, was länger als eine Woche dauert, will er nicht machen, und effektive Meetings hat er ebenfalls abgelehnt
Was ich sagen will: Genau die Dinge, die nicht im Buch stehen, sind das, was mir fehlt. Zur Einordnung: Wir sind nur drei Mitgründer
Der CTO war der „Technikmensch“ des CEO, im Grunde einfach der fähigste oder wichtigste Technikmensch, der deshalb den CTO-Titel bekommen hat
Es ist unangenehm, das zu hören, aber du solltest die Möglichkeit in Betracht ziehen, dass der CEO dich als einen weiteren Mitarbeiter mit coolem Titel sieht. Mit dieser Haltung wird es aus Sicht des CEO wie Verschwendung wirken, dich in seine Entscheidungen einzubeziehen
Ich erinnere mich bis heute genau an Marcs Antwort: „Wenn du Zweifel hast, brauchst du nicht an den Zweifeln zu zweifeln“
Ich weiß, dass das eine zu große Entscheidung ist, um sich von irgendeinem Internetkommentar überzeugen zu lassen, aber trotzdem: Es sind schon 8 Monate vergangen. Wahrscheinlich hast du bereits alles versucht, was einen Versuch wert war
Was bleibt noch, das du nicht ausprobiert hast? Was erwartest du logisch betrachtet, dass hier noch passieren soll? Du könntest leicht an einen produktiveren Ort wechseln, also solltest du darüber nachdenken, wie viel mehr von deinem Leben du noch in diese Situation investieren willst
Im Ernst: Das, woran du gerade stößt, ist genau das, was diesen Job schwierig macht
Erstens wäre es gut, 1:1-Gespräche mit anderen Führungskräften zu vereinbaren. Wenn es außer dem CEO noch andere Executives gibt, mit denen du arbeitest, kannst du mehr Kontext dafür bekommen, in was für eine Situation du da geraten bist. Wenn du ihre Bedürfnisse verstehst, erkennst du auch die Bedürfnisse der gesamten Organisation
Du wurdest dafür eingestellt, die Probleme des CEO aus dem Weg zu räumen, auch wenn er dich nicht ausdrücklich darum bittet. Die Fähigkeit, dich ins Executive-Team einzufügen, ist eine der besten Möglichkeiten, deine Kompetenz zu beweisen, und dafür braucht es Konsistenz, Gewissenhaftigkeit, Offenheit und die Bereitschaft, aufrichtig hilfreiche Fragen zu stellen
Zweitens: Wenn sich der CEO und das Executive-Team regelmäßig treffen, bitte darum, teilzunehmen; wenn nicht, versuche selbst, so etwas zu organisieren. Idealerweise stimmst du dich vorher mit den anderen Führungskräften ab. Selbst wenn der CEO nicht zu allen oder zu den meisten Meetings kommen kann, wird er diese Initiative wahrscheinlich zu schätzen wissen, und es schafft Vertrauen
Du hast schon gesagt, dass der CEO solche Meetings nicht will, also musst du dich vielleicht zunächst indirekt über eine andere Führungskraft bewegen, die Einfluss auf ihn hat
Drittens wird ein CEO bei einem CTO mit hoher Wahrscheinlichkeit zumindest deshalb regelmäßige 1:1-Gespräche wollen, um sicherzugehen, dass du nicht gehst. Wöchentlich, zweiwöchentlich, monatlich – finde einfach einen Rhythmus, der zum Kalender des CEO passt
Das Ziel dieses Gesprächs ist, Alignment mit dem CEO herzustellen und Feedback dazu zu bekommen, was gut läuft und was besser werden muss. Wenn du das nicht hinbekommst, würde ich sagen, dass es kein Umfeld ist, in dem du erfolgreich sein kannst, und ich würde empfehlen zu gehen
Wenn schon das Ansetzen dieses Meetings schwierig ist, dann dränge zuerst die beiden vorherigen Ansätze voran, baue Beziehungen auf und versuche es dann erneut. Wenn du mit dem CEO und den anderen Führungskräften überhaupt keine regelmäßige Zeit in irgendeiner Frequenz vereinbaren kannst, bist du faktisch nicht der CTO, und du solltest einen Wechsel in Betracht ziehen
Über diesen Unterschied habe ich hier geschrieben: https://www.mooreds.com/wordpress/archives/2555
Dass es an Planung und an einer vorangetriebenen Vision fehlt, ist allerdings besorgniserregend. Beides gehört zum Kern der Rolle eines CEO in der Frühphase. Weißt du, warum er sich nur auf so kurzfristige Dinge konzentriert? Drückt er auf ein MVP für Fundraising oder Vertrieb, oder fehlt ihm schlicht die Vision? Ich würde an dieser Stelle nachhaken und versuchen, die Gründe zu verstehen. Oder du gehst, wie andere schon gesagt haben
Bist du schon an den Punkt gekommen, an dem du die zwingend nötigen kurzfristigen Schritte auflistest und der CEO sagt: „Ja, genau, das ist es, was wir tun werden“?
Oder bist du eher in der großartigen Phase, in der du eine SOC2-Zertifizierung vorantreibst und der CEO sagt: „Noch nicht“, aber im Sales-Pitch erzählt: „Wir arbeiten auf eine SOC2-Zertifizierung hin“?
Keine Sorge. Nicht du bist hier der Widersprüchliche
Wikipedia beschreibt DevOps als eine Praxis, die Softwareentwicklung und IT-Betrieb verbindet, aber die Formulierung als „alles, was sicherstellt, dass Business-Software nicht nur auf der Entwickler-Maschine läuft“ wirkt wie eine etwas seltsame Abweichung von der eigentlichen Definition
Besonders der Teil mit dem DevOps-Spezialisten
Ich werde das umschreiben, damit es besser rüberkommt
Ich kenne weder die Firmen noch die Leute, die hier erwähnt werden. Mich würde interessieren, ob andere sie kennen
Um es vorwegzunehmen, bevor ich Zeit ins Lesen investiere: Ich habe grundsätzlich ein gewisses Misstrauen gegenüber Leuten, die sich „Chief Technology Officer“ nennen. Lohnt sich das zu lesen?
Die Zielgruppe scheinen Leute zu sein, die kaum oder gar keine Berufserfahrung haben und als technische Mitgründer in einem Startup den CTO-Titel geerbt haben
Ich war in den letzten 10 Jahren bei drei Firmen CTO, und vielleicht bin ich inzwischen einfach älter und ungeduldiger geworden, aber wie andere schon sagten, wirkt es eher wie ein Buch für frisch aus der Uni gekommene Leute, die als Mitgründer gerade erst CTO geworden sind. Solchen Leuten gebe ich technische Beratung
Meiner Erfahrung nach sucht man, je länger man in dieser Rolle ist, nach konkreteren Informationen, wie in Büchern wie Accelerate
Langweilige Technologie ist wirklich wichtig. Startups im Privatsektor sind ohnehin schon fragile Gebilde — warum das Risiko mit unbewährter Technologie noch weiter erhöhen?
Zum Beispiel gab es zwischen 2013 und 2016 eine Phase, in der MongoDB aus schwer erklärbaren Gründen de facto zur Standarddatenbank wurde. Es sah so aus, als wäre etwa ein Drittel der Startups von MySQL oder Postgres zu MongoDB gewechselt. Das war ein völliges Chaos und eine dumme Katastrophe
In so einem Fall ist schwer vorstellbar, warum man sich für Mongo entscheidet. Außer dass die ersten paar Entwicklungstage etwas schneller gehen, weil man kein Schema entwerfen und aktualisieren muss, gibt es dafür kaum einen Grund
Das Problem ist: Sobald die Daten komplexer werden und Dinge wie BI nötig sind, zahlt man diesen anfänglichen Vorteil mit gewaltigen Zinsen zurück
Und selbst wenn die Daten nicht relational sind, funktioniert das JSON von Postgres ohnehin besser als Mongo
Manche neuen Technologien verschwinden, andere bleiben
Zu Beginn meiner Karriere war SQL eine glänzende neue Technologie. Ich habe stark dafür geworben, dass das Unternehmen Netzwerkdatenbanken aufgibt und auf SQL umsteigt, und das Ergebnis war sehr gut
Mit objektorientierter Programmierung im Vergleich zu traditionellem C war es genauso
Manche Technologien schaffen es am Ende nie auf das versprochene Niveau und werden zu Fesseln für die Organisationen, die sie übernommen haben
Es gab Zeiten, in denen es noch zu früh war, LLM-Technologie verantwortungsvoll einzuführen. Aber bald wird die Phase kommen, in der der Vorstand fragt, warum man sie nicht eingeführt hat. Für externe Anwendungsfälle vielleicht, für interne ganz sicher
Eine der schwierigen Aufgaben eines CTO besteht darin, den Zeitpunkt für die Einführung neuer Technologien zu beurteilen. Man muss einschätzen, wann langweilige Technologie das Beste für das Unternehmen ist, wann frühe Technologie vertretbar ist und wann eine neue Technologie ein so großer Beschleuniger ist, dass sie unbedingt eingeführt werden muss
Interessant fand ich die Einteilung des CTO in drei Typen: technikorientiert, menschenorientiert und außenorientiert
Ein Startup in sehr früher Phase bietet gerade eine CTO-Rolle an. Es gibt noch kein Produkt, nur ein paar grundlegende Demos, und das Unternehmen bereitet sich auf eine Pre-Seed-Investition vor
Ich frage mich, was in dieser Rolle am dringendsten gebraucht wird. Ein technischer CTO oder ein People-CTO? Anfangs scheint es vor allem eine technische Rolle zu sein, weil man erst einmal das Produkt bauen muss. Aber ich frage mich, ab wann der Wechsel zu einem stärker menschenzentrierten CTO sinnvoll wird. Falls jemand dazu Einsichten oder Erfahrungen hat, würde ich sie gern hören
Werde hauptsächlich das, stütze den Rest so gut es geht mit ab, und wenn diese Arbeit zu viel oder zu wichtig wird, stell jemanden ein, der eine oder mehrere der anderen beiden Bereiche übernimmt
Die schwerer zu beantwortende zweite Frage ist, was sie — also die anderen CXOs — wollen, dass du wirst. Das kann die erste Frage überlagern. In manchen Fällen ist man ein CTO ohne C, also nur eine Technikperson, der gesagt wird, was sie zu tun hat, die Demo-Spielzeug für Selbstdarstellung am Laufen hält und nie das „Warum“ des Geschäfts zu hören bekommt
Ich habe ein paar gebookmarkte Links dazu, was ein CTO eigentlich ist
http://www.startuplessonslearned.com/2008/09/what-does-start...
https://www.allthingsdistributed.com/2007/07/the_different_c...
Camille Fourniers The Manager’s Path kann ich ebenfalls empfehlen
Es heißt zwar, „Schulden proaktiv zurückzuzahlen ist eine notwendige Investition in die allgemeine Engineering-Gesundheit“, aber bei manchen technischen Schulden ist es insgesamt billiger, sie ausfallen zu lassen, statt sie zurückzuzahlen
Vorausgesetzt natürlich, der Product Manager versucht nicht, sie einzutreiben
Aber dass ein Projekt mit einer gewissen Größe und Komplexität in die technische Insolvenz gerät, passiert nur, wenn man den Ratschlägen des Buches nicht folgt. Wenn man technische Schulden ignoriert, um Features auszuliefern, werden Releases immer schwieriger und Bugs immer häufiger
Glückwunsch zur Veröffentlichung des Buches
Auf Basis meiner Erfahrungen als CTO in einem kleinen Startup und als VPoE in einem börsennotierten Unternehmen schreibe ich Opinionated Launch(https://opinionatedlaunch.com), um praktische Ideen weiterzugeben
Als ich damit angefangen habe zu schreiben, habe ich gemerkt, dass sich die Themen in zwei Stränge aufteilen: Management/Team/Menschen und Technik. Ich habe mich dann auf die technische Seite konzentriert, für die ich mehr Leidenschaft mitbringe, und freue mich, dass jemand anderes den Rest übernimmt