Startup-CTO-Handbuch

Startup-CTO-Handbuch

Unverzichtbare Fähigkeiten und Best Practices für leistungsstarke Engineering-Teams

Einführung

• Immer weiter lernen: Der Autor hatte schon in jungen Jahren eine Leidenschaft für Computer und Softwareprogrammierung und erkannte dadurch, wie wichtig kontinuierliches Lernen ist. Um als technischer Leiter erfolgreich zu sein, ist es entscheidend, ständig zu lernen und sich weiterzuentwickeln.
• Das Dilemma des technischen Leiters im Startup: Die meisten Startups haben einen technischen Mitgründer, der die anfängliche Codebasis schreibt und die ersten Engineers einstellt. Wenn das Team jedoch wächst, muss der technische Leiter in eine Managementrolle wechseln, und in diesem Prozess können Leadership-Fähigkeiten fehlen.

Über den Autor

• Der Autor hat in mehreren Startups Erfahrungen gesammelt und dort als technischer Leiter gearbeitet. Durch seine Erfahrungen in verschiedenen Startups hat er ein Verständnis für die vielfältigen Fähigkeiten und Herausforderungen entwickelt, die technische Führung erfordert.

Wie man dieses Buch nutzt

• Dieses Buch ist als Nachschlagewerk für Führungskräfte gedacht, die Software-Engineering-Teams managen, und behandelt verschiedene Themen in eigenständigen Kapiteln. Jedes Kapitel führt in das Thema ein, gibt einen Überblick und stellt Best Practices vor.

Geschäftsprozesse

• Es erläutert Geschäftsprozesse und bietet damit einen Ausgangspunkt für die Problemlösung. Je nach Größe des Teams und des Unternehmens müssen Prozesse angepasst und skaliert werden.

Menschen und Kultur

Grundprinzipien des Managements

• Die Goldene Regel des Managements: Die Leistung des Teams ist der Maßstab, an dem die Leistung des Managers gemessen wird. Teammitglieder sollten dabei unterstützt werden, ihr Bestes zu geben.
• Professioneller Kompetenzbaum: Für technische Führung muss nicht nur in technische, sondern auch in Management-Fähigkeiten investiert werden.

Kontinuierliche Verbesserung

• Kaizen: Sowohl das Team als auch der Einzelne sollten kontinuierliche Verbesserung anstreben. Fehler sollten als Gelegenheit zur Verbesserung genutzt werden.

Coaching

• Manager sollten die Rolle eines Coaches übernehmen, der Teammitgliedern hilft, ihr Bestes zu geben.

Einen Management-Mentor finden

• Für den Übergang in eine Führungsrolle ist es wichtig, einen Management-Mentor zu finden. Mit dem richtigen Mentor lassen sich Leadership-Fähigkeiten verbessern.

1:1-Meetings

• 1:1-Meetings sind eine Gelegenheit, Beziehungen zu Teammitgliedern aufzubauen, ihre Stärken und Schwächen zu verstehen und ihnen zu helfen, ihr Bestes zu geben.

Skip-Level-Meetings

• Durch regelmäßige Gespräche mit den direkten Mitarbeitenden von Führungskräften lassen sich verschiedene Perspektiven sammeln und damit Verbesserungen im Unternehmen anstoßen.

Coaching für Manager

• Die Leistung des mittleren Managements ist entscheidend für die Leistung der Organisation. Manager sollten durch kontinuierliche Weiterbildung und Unterstützung entwickelt werden.

1:1-Meetings mit Engineers

• 1:1-Meetings mit Engineers sind eine Gelegenheit, sich ihre Probleme anzuhören und ihnen zu helfen, Lösungen zu finden. Das Ziel des Meetings sollte klar sein, und das Gespräch sollte produktiv geführt werden.

[GN⁺]

Meinungen auf Hacker News

• Wenn ich solche Dokumente lese, gehe ich meistens zuerst zu dem Teil, den ich gut kenne, und schaue, was dort gesagt wird. Hier heißt es, dass die Vorbereitung und Durchführung von PCI-DSS- oder SOC-2-Audits normalerweise 6 bis 12 Monate dauert und man nicht bis zur letzten Minute mit der Zertifizierung warten sollte. Startups würde ich aber fast das Gegenteil raten.
  Gerade eine SOC-2-Attestierung ist relativ leicht zu bekommen, und proaktiv Geld auszugeben, bevor eine Bestellung davon abhängt, ist Verschwendung. Natürlich ist es gut, Dinge wie Single-Sign-on-Konfiguration oder geschützte Git-Branches früh einzurichten, weil sie später die Grundlage für eine Attestierung bilden. Aber das sind eher grundlegende Best Practices, die man ohnehin umsetzen sollte, selbst wenn man gar keinen SOC 2 plant. Wenn kein großer Kunde es verlangt, sehe ich keinen Grund, SOC 2 zu machen. Es wäre gut, wenn jemand auch die anderen Teile dieses Dokuments prüfen würde.

  • Guter Ansatz. Ich habe den Datenbankteil durchsucht, und der war insgesamt in Ordnung. Allerdings sehe ich nicht, warum sich ein Startup 2025 auf SQL vs. NoSQL konzentrieren sollte. Die beliebten SQL-Datenbanken unterstützen JSON gut; man kann also PostgreSQL oder MySQL verwenden, womit die Engineers vertrauter sind, und CloudSQL oder RDS für Backups und Replikation nutzen.
    Mit einer Read Replica für BI und einem ordentlichen Visualisierungstool kommt man ziemlich lange aus, und das reicht völlig, bevor man fünf- bis sechsstellige Beträge für etwas wie Snowflake ausgibt.
  • Meiner Erfahrung nach haben Unternehmen, die bereit sind, mit frühen Startups Geschäfte zu machen und einen SOC-2-Bericht verlangen, meistens kein Problem damit, im Vertrag SOC 2 Type 1 innerhalb von 6 Monaten festzuschreiben und trotzdem loszulegen, solange die technische Ansprechperson das IT-Team der Gegenseite in einem Gespräch davon überzeugen kann, dass die Kompetenzen stimmen.
  • Für den Fall, dass Buchhaltung und Supply-Chain-Prozesse in einem Enterprise-ERP liegen, widerspreche ich höflich. Nicht auditierbare Prozesse später zurückzudrehen kostet zu viel Zeit und Geld, und währenddessen muss das Geschäft weiterlaufen. In diesem speziellen Fall ist es meiner Ansicht nach günstiger und besser, von Tag eins an Auditierbarkeit herzustellen.
  • Wie gut dieser Rat passt, hängt stark von der Branche ab. Wenn man ein B2B-Produkt verkauft, das personenbezogene Daten verarbeitet, braucht man SOC 2 praktisch, wenn man in Pitch-Meetings nicht ausgelacht werden will.
    Je nach Finanzierung kann ein automatisierter SOC-2-Compliance-Checklist-Service wie Secureframe ein paar Tausend Dollar kosten. Er hilft nicht nur dabei, Best Practices einzuhalten, sondern organisiert die Dinge auch auf die für SOC 2 typische Weise und macht damit das Audit einfacher. Verglichen mit der Entwicklungs- und Projektmanagementzeit, die nötig ist, um eine Organisation mit bereits tief verankerten nicht-konformen Prozessen auf den SOC-2-Pfad zu bringen, ist das keine große Investition.
  • Ich kenne mich mit Compliance nicht besonders gut aus, aber das klingt ziemlich seltsam. Wenn man SOC 2 grob liest, braucht man in den Monaten vor dem Audit enorm viel Evidenzsammlung. Wenn man vorher keine Zeit investiert hat, weiß ich nicht, wie man später wissen soll, was man alles braucht.
    Die Aussage, dass eine SOC-2-Attestierung leicht zu bekommen sei, steht auch im direkten Gegensatz zu dem, was ich von anderen zu diesem Thema gehört habe. Normalerweise höre ich, dass es sehr schwierig und zeitaufwendig ist. Ich frage mich, was mir entgeht. Wenn es wirklich einfach ist, hoffe ich, dass ich falschliege.

• Ich sehe oft die Aussage, dass man mit dem Wechsel zum VP oder CTO aufhört zu programmieren. Ich verstehe, dass Managementkompetenz nicht dasselbe ist wie Coding-Kompetenz, aber ich finde es schwer nachvollziehbar, warum Leute die Tastatur weglegen und ihre erste Superkraft verschwenden.
  Man kann von Anfang bis Ende ein technischer CTO bleiben. Man sollte Team und Unternehmen wie einen Service behandeln, der aktive Beiträge, Wartung und On-Call-Support braucht, und zugleich sowohl allein als auch gemeinsam mit dem Team selbst die Hände schmutzig machen und bauen.

  • Auf VP-/CTO-Ebene hat man keine Zeit, Code beizutragen und zu warten. Wenn man sie hat, ist der Titel vermutlich eher symbolisch, etwa beim „CTO“ eines dreiköpfigen Startup-Teams.
    Das eigentliche Problem ist, früh in der Karriere Rollen anzunehmen, in denen man keine Zeit zum Programmieren hat. Zum Beispiel eine Architektenrolle, in der man nur Kästchen auf Whiteboards zeichnet und von Meeting zu Meeting zieht, oder eine Rolle, die faktisch Management ist, aber „Tech Lead“ genannt wird. Man gewöhnt sich daran, keinen Code zu schreiben, und wenn man Jahre später einen neuen Job suchen muss, sitzt man in Interviews für Programmierrollen und muss sich der Tatsache stellen, dass man einen erheblichen Teil der Programmierkarriere ohne Programmieren verbracht hat. Bei vielen kommt das Gefühl dafür nicht schnell zurück.
  • Nach meiner Erfahrung war das Problem, dass der Tag nur begrenzt viele Stunden hat. Sieben Jahre lang war ich direkt oder indirekt für etwa 20 bis 25 Personen verantwortlich, und es blieb wirklich zu wenig Zeit, um im Code noch Nützliches zu erledigen.
    Meine Zeit war viel besser dafür eingesetzt, Probleme zu lösen, die andere nicht lösen konnten. Gelegentlich habe ich eine sehr einfache Änderung übernommen, um unseren Prozess selbst zu durchlaufen und zu sehen, wo wir ihn verbessern können. Abends oder am Wochenende habe ich weiter programmiert, aber es fühlt sich nicht gleich an, und mit der Zeit rostet man zwangsläufig etwas ein. Trotzdem hat es während einer Auszeit großen Spaß gemacht, den ganzen Tag praktisch zu coden.
  • Wenn man kein reiner Individual Contributor ist, entstehen andere Prioritäten. Deshalb kann Individual-Contributor-Arbeit jederzeit unterbrochen werden. Dann kann man keine Aufgaben übernehmen, die nahe am kritischen Pfad liegen; tut man es doch, blockiert man andere oder muss die Aufgabe übergeben.
    Reviews oder Design-Meetings sind möglich, aber wenn man Kernarbeit übernimmt, führt das am Ende zu Problemen.
  • Ich glaube nicht, dass es eine einzige richtige Antwort gibt, aber ab einem gewissen Punkt haben Dinge wie den nächsten wichtigen Engineer einzustellen, eine Technologie-Roadmap zu erstellen, um der Konkurrenz voraus zu sein, oder die Engineering-Organisation mit dem Rest des Unternehmens auszurichten, deutlich mehr Hebelwirkung als Codebeiträge eines VP/CTO.
    Den Code, den ein VP/CTO schreiben könnte, kann auch jemand anderes im Team schreiben, vielleicht sogar besser. Die anderen genannten Aufgaben dagegen sind im Unternehmen wahrscheinlich genau die Dinge, die der VP/CTO am besten kann. Es ist eine ziemlich vernünftige Entscheidung, die praktische technische Arbeit größtenteils loszulassen, um sich auf das zu konzentrieren, was für Team und Unternehmen wichtiger ist.
  • Meine letzte CTO-Rolle war in einem Team mit 40 Personen, und ich war vom ersten Tag an völlig überlastet. Dabei bin ich eigentlich gut im Zeitmanagement. Wenn möglich, hätte ich 50 % meiner Zeit programmieren wollen, aber dafür gab es keine Zeit und auch keine Support-Struktur, an die ich Dinge hätte abgeben können; die musste ich mühsam selbst aufbauen. Genau das war wiederum einer der Gründe, warum keine Zeit blieb.
    Die Idee, weiter zu programmieren, ist schön, aber normalerweise ist das nicht der Grund, warum man bezahlt wird. Ich halte mich für einen sehr starken Entwickler, aber solche Entwickler kann man günstiger bekommen als zum CTO-Gehalt. Wenn ein teurerer CTO diese Arbeit macht, ist das ineffizient. Nebenbei: Ein paar Jahre später bin ich wieder Individual Contributor geworden, und so will ich auch den Rest meiner Karriere verbringen.

• Ich würde sagen, so etwas wie synchronen Chat gibt es nicht.
  Wenn es synchron sein muss, sollte es nicht im Chatfenster stattfinden – jedenfalls nicht, außer man hat vereinbart: „Lass uns ein paar Minuten lang in Echtzeit auf diesen Chat konzentrieren.“ Remote sollte man telefonieren, vor Ort von Angesicht zu Angesicht sprechen. Man sollte keine Nachricht in den Chat werfen und eine sofortige Antwort erwarten.

• Ich frage mich, ob es im „Zwei-Teams“-Modell Fälle gab, in denen kein Groll entstand. Ich weiß nicht, ob es auch Situationen gab, in denen Leute nicht von selbst ins Zukunftsteam wechseln wollten.
  Auf dem Papier klingt das nach einer guten Idee, aber es fällt mir schwer zu glauben, dass es in der Praxis gut funktioniert. Die nächstliegende Form, die ich gesehen habe, war eher ein Library-Team, das Services wie ein Designsystem und Komponenten baut, damit andere Teams sie nutzen können.

  • Bei einem früheren Arbeitgeber gab es eine Version eines On-Premises-Produkts, für die das Unternehmen extrem langfristigen Extended Support verkauft hatte, obwohl sie eigentlich auslaufen sollte. Ein kleines Team, wahrscheinlich etwa drei Personen, war ausschließlich dafür verantwortlich, dass diese Version unterstützt wurde, die Pipelines funktionierten und bei Bedarf auch große Fixes ausgeliefert werden konnten.
    Solange sie diese Verantwortung erfüllten, konnten sie in der übrigen Zeit frei an Dingen arbeiten, die sie für wertvoll fürs Unternehmen hielten. Das war ein ziemlich guter Deal. Die anderen waren dankbar, dass dieses kleine Team die Drecksarbeit übernahm, und das Wartungsteam mochte es, in der übrigen Zeit Dinge zu reparieren, die sie schon immer gestört hatten, oder zu forschen. Die Details habe ich vergessen, aber ich erinnere mich, dass daraus ziemlich coole Verbesserungen und Forschungsergebnisse entstanden. Dass die Leute in diesem Team sehr stark und selbstorganisiert waren, half ebenfalls beim Erfolg, kostete aber auch mehr.
  • Im Buch scheint als Lösung für dieses Problem regelmäßige Rotation vorgeschlagen zu werden. Der Microsoft-Blogpost empfiehlt, jede Woche einige Teammitglieder zwischen den beiden Teams auszutauschen und das Kundenteam als temporäres Team zu definieren.
    Ich habe tatsächlich einige Orte erlebt, an denen vollständig getrennte Teams gut funktionierten. Bei Games kann man an Engine-Team und Game-Team denken. In einer früheren Rolle übernahm man sogar innerhalb des Game-Teams Features, die 6 bis 12 Wochen dauerten, veröffentlichte sie und kümmerte sich danach um Wartung, Updates und technische Schulden. Das gerade veröffentlichte Feature stand im Mittelpunkt, aber es gab auch Zeit, zu früherer Arbeit zurückzukehren; andere Teams waren im selben Zyklus und wurden dann 6 bis 8 Wochen später auf ein neues Feature onboarded, und so wiederholte es sich.
  • Ich habe früher einmal mit einem Zwei-Teams-System experimentiert. Feature-Entwicklung lag beim Red Team, Stabilität und Bugfixes beim Blue Team.
    Wir behandelten das nicht als feste Teams, sondern als Arbeitsfluss, bei dem die Leute jeden Sprint, also alle zwei Wochen, hin und her wechselten. Etwa drei Monate lang lief das gut, danach passte es nicht mehr, und ungefähr zu dieser Zeit wuchs die Organisation, sodass wir die Teams nach Business-Fähigkeiten oder Domänen neu aufstellten.
  • Ähnlich haben wir einmal ein Rotationssystem ausprobiert, bei dem Engineers jeweils eine Woche lang Support und Bugreports bearbeiteten. Damit ließen sich viele Fallen vollständig getrennter „Zwei Teams“ vermeiden. Unter https://news.ycombinator.com/item?id=43337703#43339972 habe ich etwas mehr dazu geschrieben.
  • Wenn das „Kundenteam“ genug Ressourcen hat und auch angemessen belohnt wird, würde man vermutlich gar nicht unbedingt ins „Zukunftsteam“ wechseln wollen. Aber auch ohne Trennung wird Wartung normalerweise ausgehungert, während neue Features alle Aufmerksamkeit und Ressourcen bekommen. Mit zwei Teams wirkt es so, als könnte es eher noch schlimmer werden.

• Solches Material ist nicht dazu gedacht, wie eine Bibel verwendet zu werden; gut daran ist, dass es einen breiten Überblick über Verantwortlichkeiten und Anliegen gibt.
  Wenn man keinen großartigen Mentor hatte oder nicht unter wirklich hervorragenden Leuten gearbeitet hat, setzt sich niemand neben einen, wenn man in diese Position kommt, und nennt einem die Liste der Dinge, um die man sich kümmern muss. Jede Sektion hilft, Fragen zu stellen wie: „Was ist unsere Antwort?“, „Stimmen wir zu?“, „Ist unser Prozess besser?“, „Was übersehe ich?“

• Dass die Trennung in „zwei Teams“ so ausdrücklich erwähnt wird. Eine fantastische Methode, um so lange weiter Releases zu machen, bis die Kosten, etwas Brauchbares auszuliefern, zu hoch werden.
  Wenn man den Feedback-Loop zu den Leuten kappt, die die Software ursprünglich gebaut haben, sind diese Leute kurzzeitig glücklicher und andere kurzzeitig unglücklicher. Dann will das Feature-Team nie wieder gestört werden, und das Kundenteam bekommt keine Ressourcen, um irgendetwas ordentlich zu reparieren.
  Noch schlimmer ist, dass das Feature-Team nichts lernt außer, Zeilen auszuliefern. Der Grund, warum es mit der Zeit langsamer und teurer wird, ist, dass man die einzige Fitnessfunktion guter Softwareentwicklung entfernt hat: negatives Feedback wieder in den Entwicklungsprozess als Quelle einzugliedern. Ein echtes CTO-Leadership-Handbuch sollte klar sagen: „Es ist deine Verantwortung, Entwicklern zu helfen, während des Release-Prozesses besser zu werden, und sie werden das nicht immer mögen.“

  • „Das Feature-Team kann sich zu 100 % auf die Zukunft konzentrieren, ohne von Kundensupport-Arbeit gestört zu werden“ bedeutet eher: Das Feature-Team darf weiterarbeiten, ohne etwas von dem Chaos zu wissen, das es angerichtet hat, bis das Schiff vollständig in den Eisberg gekracht ist.
    Außerdem entstehen Merge-Konflikte zwischen einem vom Sales getriebenen Feature-Team und einem von Kundenbetreuern getriebenen Wartungsteam. Solange das „Kundenteam“ als Phase beschrieben wird, aus der man später herauskommt, ist klar, wer den Prioritätenkampf gewinnt. „Ein weiterer Weg für einzelne Engineers, insbesondere Juniors, zu lernen und zu wachsen“ klingt am Ende nach: „Seniors wollen den Mist nicht wegmachen, also geben wir ihn den Juniors.“
  • Verwandt damit: In den Unternehmen, in denen ich gearbeitet habe und die ein Plattformteam hatten, war meistens Overengineering eingezogen. Mit Plattformteam meine ich hier so etwas wie ein drittes Support-Team, das Tools, Practices und gemeinsamen Code verwaltet.
    Solche Teams ziehen tendenziell Leute an, die das Ausliefern von Features und das Beheben von Bugs geringschätzen und Probleme übermäßig abstrahieren wollen. Statt Bugs zu fixen, bauen sie immer komplexere Abstraktionen, um zu verhindern, dass Bugs überhaupt entstehen — das Ergebnis ist absehbar.
  • Das ist die Aufgabe des PM. Es braucht eine Person oder einige wenige, die mit Kunden arbeiten und auf Basis des Feedbacks eine Vision festlegen, wie alle Features zusammenspielen sollen.
    Kunden, insbesondere nichttechnische Kunden, haben keine konsistente Produktvision und wollen oft nur den unmittelbaren Fix, unabhängig von anderen Plänen. Da Kunden nicht miteinander kommunizieren, kann ihr Feedback auch widersprüchlich sein. Wenn man diese Last Entwicklern auferlegt, müssen sie zusätzlich zur technischen Kompetenz, die Codebase zu kennen und gut zu pflegen, auch die gesamte Kommunikation managen; außerdem müssten alle Entwickler dieselbe konsistente Vision haben, um durchdachte Entscheidungen zu treffen. In Zeiten, in denen Entwickler auch noch Infrastruktur betreiben, macht eine Person damit im Grunde zwei oder drei Jobs.
  • Um das auszugleichen, haben wir die Teams jeden Sprint oder alle paar Sprints gewechselt. Die Leute sammelten vielfältigere Erfahrungen, und wenn sie fehleranfällige Features bauten, mussten sie sie am Ende selbst reparieren und bekamen so weiterhin Feedback.
    Die Leute schienen diese Arbeitsweise deutlich lieber zu mögen. Sie wurden nicht davon erschöpft, ständig nur Bugs zu fixen, und zugleich vermied man den von dir treffend beschriebenen Bruch im Feedback.
  • Entwickler müssen die Software, die sie bauen, betreiben und warten. So einfach ist das Prinzip.

• An diesem Punkt habe ich so viele Interviews geführt, dass ich sie nicht mehr zählen kann, daher fällt es mir etwas schwer, dem zuzustimmen. Eine Schwierigkeit ist, dass es in der Eingangsphase sehr viele oder potenziell sehr viele Bewerber geben kann und in dieser Phase normalerweise das Recruiting-Team mit den Bewerbern interagiert.
  Die Beispielfragen aufzunehmen ist in Ordnung, aber um ungeeignete Kandidaten herauszufiltern, braucht man Fragen, die nicht einfach mit Ja/Nein oder auf einer Skala beantwortet werden. Ich bevorzuge sehr einfache Fragen mit einer eindeutigen Antwort. Es ist erstaunlich, wie viele Leute angeben, mit JavaScript „sehr vertraut“ zu sein, aber nicht wissen, was === ist. Daher stelle ich Fragen wie: „Was ist der strikte Gleichheitsoperator in JavaScript?“ Jeder JavaScript-Programmierer weiß das, aber schon eine einzige solche Frage filtert 50 % des Bewerberpools heraus und spart der Organisation enorm viel Zeit.

• Es wird viel über Culture Fit gesprochen, aber ein großer Teil davon scheint eine Schicht versteckter Diskriminierung hochzuholen, die dem Unternehmen schadet. Ich denke, kulturelle Offenheit ist ein Erfolgsfaktor, und Diskriminierung führt in die entgegengesetzte Richtung.
  Bei dem Satz „Die besten Führungskräfte verfolgen Erfolgsquoten, scheuen sich nicht, Einstellungsfehler einzugestehen, stellen langsam ein und entlassen schnell“ möchte ich das Bild posten, das JWZ (Jamie Zawinski) anzeigt, wenn er einen Referrer-Header erkennt, der auf diese Website verweist. Sucht bei Google nach dem, was Jamie Zawinski über Y Combinator gesagt hat. Er ist außerdem die Person, der die Entscheidung von Netscape zugeschrieben wird, Netscape Navigator als Open Source freizugeben, sowie der Großteil der Arbeit, die daraus zur Rendering-Engine dieses Browsers führte. Deshalb gibt es Firefox.

  • „Culture Fit“ als versteckte Diskriminierung zu sehen, ist eine zynische Auslegung; in den Fällen, die ich gesehen habe, wurde es häufiger genutzt, um Kandidaten davor zu schützen, Aufgaben zu übernehmen, die sie nicht mögen würden.
    In einem meiner frühen Jobs versuchte man, alles aus den Einstellungskriterien zu verbannen, was man als Culture Fit bezeichnen könnte. Das Ergebnis war, dass einige Leute die Firma praktisch direkt nach dem Einstieg nicht mochten und nach Wochen oder Monaten kündigten. Ein Kandidat betonte Planung und Vorhersehbarkeit und beschwerte sich, dass seine früheren Firmen sich zu schnell bewegt hätten. Wir waren ein Startup, und wie zu erwarten war, hasste er das Unternehmen. Aber im Einstellungsprozess durften wir solche Bedenken nicht äußern, weil man es als „Culture Fit“ sah und meinte, das könne zu Diskriminierung führen. Nachdem Ähnliches noch ein paar Mal passiert war, verschwand diese Richtlinie stillschweigend, und wir konnten wieder bewerten, ob jemand mit der Engineering-Kultur kompatibel war.
  • Jeder Einstellungsprozess diskriminiert. Entscheidend ist, welche Eigenschaften er begünstigt oder benachteiligt und was er ausschließt.
    „Culture Fit“ ist im Wesentlichen ein Tausch: Man gewinnt effiziente Kommunikation und hohes Vertrauen, gibt dafür aber einen Teil der gedanklichen Vielfalt auf. Weil die Leute bereits wissen, wie sie sich verhalten sollen und was sie voneinander erwarten können, muss man nicht viele Richtlinien aufstellen; dafür wird man anfälliger für Gruppendenken und damit verbundene kognitive Verzerrungen. So nach dem Motto: „Auf diesem Schiff gibt es alle Farben des Regenbogens, aber selbst wir Klingonen halten Klingonen für böse.“
  • Ich habe mich auf den Abstecher eingelassen und gesucht, aber die Ergebnisse auf der ersten Seite waren allesamt nur Kommentare auf Hacker News, die Jamie Zawinski erwähnten, also habe ich dort aufgegeben. Es wäre daher schön, wenn jemand erklären könnte, worum es geht.

• Ich bin mir nicht sicher, ob der Rat, „eine Bibliothek mit Erklärvideos anzulegen“, gut ist. Für bestimmte Dinge wie UI oder Animationen kann das sinnvoll sein.
  Im Allgemeinen ist es aber effizienter, Text zu lesen, als ein Video anzusehen. Wenn es eilig ist, ist es außerdem viel einfacher, in einem Text zu den wichtigen Stellen zu springen als in einem Video.

  • Manche Menschen mögen Videos, andere mögen Text. Beides ist eine Investition, die Aufwand und Wirkung erfordert. Dank generativer KI ist es inzwischen einfacher geworden, beides zu erstellen.