Wie Startups ihre Energie verlieren
(blog.johnqian.com)- In einem gut geführten Seed-Stage-Startup suchen Engineers selbst nach Nutzerproblemen und treiben Umsetzung und Launch direkt voran; je größer das Unternehmen wird, desto stärker verwandelt sich diese Schleife in langsame und fragmentierte Arbeit
- Teams mit weniger als 10 Personen sind dank direktem Nutzerkontakt, Ideenauswahl, Feedback von Kolleginnen und Kollegen, kleiner Codebase und leichtgewichtigem Deployment bei der Umsetzungsgeschwindigkeit schnell
- In Organisationen mit mehr als 100 Personen wird der Nutzerkontakt auf PMs ausgelagert, und durch Security Reviews, CI, PR-Reviews und Infrastrukturprozesse verlangsamt sich die Arbeitsgeschwindigkeit erheblich
- Hinter dieser Veränderung stehen abnehmende Interessenangleichung, O(N^2)-Kommunikation durch wachsende Mitarbeiterzahlen sowie eine sinkende Risikobereitschaft, wenn Nutzerzahlen und Regulierung zunehmen
- Ganz verhindern lässt sich das Verschwinden des Spaßes kaum, aber man kann es verzögern, indem man Prozesse großer Unternehmen nicht vorschnell kopiert, kleine unabhängige Teams und Anreize gestaltet und die Einstellungsgeschwindigkeit drosselt
Warum sich Arbeit in einem kleinen Startup süchtig machend anfühlt
- In einem gut geführten Seed-Stage-Startup besteht die Kernarbeit von Engineers darin, Nutzerprobleme zu verstehen, Ideen zu entwickeln, sie mit Kolleginnen und Kollegen zu diskutieren, umzusetzen und anschließend Launch und Retrospektive immer wieder zu durchlaufen
- In Teams mit weniger als 10 Personen kann jede Phase dieser Schleife Spaß machen
- Man kann Nutzer, die einen interessieren, direkt kontaktieren und bei einem Bier mit ihnen sprechen
- Wenn man eine Idee findet, die für das Unternehmen wertvoll und persönlich spannend ist, kann man die laufende Arbeit unterbrechen und sofort daran arbeiten
- Kolleginnen und Kollegen haben ein direktes Interesse am Erfolg desselben Unternehmens, fördern gute Ideen und haben einen Anreiz, die Probleme schlechter Ideen zu erklären
- Kolleginnen und Kollegen können selbst Nutzer dieser Idee sein, vielleicht mitarbeiten wollen und große Teile der Codebase kennen, sodass sie wahrscheinlich hilfreiche Einsichten beitragen können
Schnelle Umsetzung und hohe Erwartungen
- In kleinen Teams ist die Umsetzungsgeschwindigkeit hoch
- Man kann die gewünschten Tools wählen, und es gibt keine Security Reviews
- Die Codebase ist klein genug, um die gesamte Struktur im Kopf zu behalten, sodass man auch größere Refactorings vergleichsweise entspannt angehen kann
- Dank schnellem Hot Reload lassen sich Trial-and-Error-Debugging-Schleifen schnell wiederholen
- Auch das Mergen von Änderungen ist leichtgewichtig
- In der CI gibt es keine langsamen Tests, und sichere Änderungen benötigen möglicherweise kein blockierendes PR-Review
- Je nach Fall pusht man direkt auf
master, oder bittet bei riskanten Änderungen einen Kollegen per Schulterklopfen um ein Review - Wenn es noch nicht viele Nutzer gibt, kann man für schnelle Backend- oder Datenbankänderungen Downtime in Kauf nehmen
- In kleinen Startups ist die Erwartung stark, dass alles möglich ist
- Ein neues Feature könnte den Wert der Anteile erhöhen, und später könnten andere weiter auf diesem Feature aufbauen
- Man kann auch erwarten, dass ein Nutzer sagt: „Hattest du diese Idee? Sie hat mein Leben gerettet“
- Weil alle Teammitglieder gemeinsame Interessen haben, entsteht eine Atmosphäre, in der man den Erfolg der anderen unterstützt
Wie sich dieselbe Schleife verändert, wenn das Unternehmen wächst
- In Organisationen mit mehr als 100 Personen nimmt der direkte Kontakt zu Nutzern ab
- Mit Nutzern zu sprechen wird zur Rolle von PMs, und Engineers erhalten möglicherweise nur Zusammenfassungen von Nutzer-Insights und Prioritätenlisten
- Im schlechten Fall bekommt man eine verwirrende Aufgabenliste, die auf falschem Nutzerverständnis oder der egozentrischen Vision eines Managers basiert, und es gibt niemanden, der erklären kann, warum die einzelnen Aufgaben wichtig sind
- Es wird schwieriger, einfach die Arbeit auszuwählen, die man selbst machen möchte
- Wenn alle jeweils das tun, was sie wollen, entsteht O(N^2)-Kommunikationschaos
- Manager entwerfen individuelle Pläne unter Berücksichtigung der übrigen Arbeit in der Organisation
- Eigene Ideen muss man möglicherweise erst nach Abschluss der festgelegten Arbeit verfolgen oder heimlich in der Freizeit vorantreiben
- Man kann zwar mit Kolleginnen und Kollegen über Ideen sprechen, aber Interesse und Freiraum nehmen ab
- Kolleginnen und Kollegen profitieren weniger vom individuellen Erfolg und können sogar Konkurrenten um Beförderungen sein
- Alle haben lange Aufgabenlisten und nicht die Freiheit, ihre laufende Arbeit fallen zu lassen und gemeinsam zu arbeiten
- Wahrscheinlich fehlt ihnen auch Erinnerung oder Kontext zu dem betreffenden Code
Warum Umsetzung in großen Organisationen langsamer wird
- In Organisationen mit mehr als 100 Personen ist die Tool-Auswahl bereits festgelegt
- Selbst wenn es ein besseres neues Tool gibt, kann man zu dem Schluss kommen, dass es die Kosten des Bruchs mit der Einheitlichkeit nicht wert ist
- Wer ein neues Tool nutzen will, muss den Manager fragen und dem Security-Review-Team eine E-Mail schreiben
- Große Codebases wachsen vor allem aus Legacy-Gründen
- Es gibt viel Code, den man nur ungern anfasst, und viel Code, den niemand mehr versteht
- Gründliche Tests werden zur einzigen Grundlage für die Gewissheit, dass man nicht das gesamte System kaputtmacht
- Trial-and-Error-Debugging ist nötig, aber lange Kompilierzeiten machen die Iterationszyklen langsam
- Selbst das Mergen eines kleinen PR kann 2 Wochen dauern
- Man wartet 20 Minuten auf die CI, und wenn Tests flaky sind, muss man sie erneut ausführen
- Während man auf Reviews wartet, häufen sich Merge-Konflikte an
- Reviewer haben nicht genug Kontext oder Motivation und können statt wichtiger Vorschläge nur Kleinigkeiten anmerken
- Änderungen nach Request einarbeiten, erneut pushen und wieder 20 Minuten warten – dieser Ablauf kann sich pro PR dreimal wiederholen
- Infrastrukturänderungen können zu einem 14-stufigen Verfahren werden, um Downtime oder Datenverlust für 10 Millionen Nutzer zu vermeiden
- Selbst wenn man nach 3 Monaten stiller Arbeit launcht, können Belohnung und Anerkennung begrenzt bleiben
- Man bekommt vielleicht die Gelegenheit, in einem Meeting am Freitag eine Demo zu zeigen, die der CEO sehen kann, aber tatsächlich konzentrieren sich nur einige Kolleginnen und Kollegen darauf
- Der Manager kann sagen, dass es in 5 Monaten im Performance-Review-Zyklus helfen wird
- Im guten Fall erhält man 20 % Gehaltserhöhung und eine neue Berufsbezeichnung; im schlechten Fall kommt 4 Monate später durch eine Reorganisation ein neuer Manager, und das Projekt rutscht in der Priorität nach unten oder wird eingestellt
Wie man den Tod des Spaßes verzögert
- Diese Veränderung lässt sich eher verzögern als vollständig verhindern
- Die Grundursachen sind abnehmende Interessenangleichung, O(N^2)-Kommunikation und sinkende Risikobereitschaft
- Abnehmende Interessenangleichung und Kommunikationsprobleme werden mit wachsender Mitarbeiterzahl schwer vermeidbar
- Sinkende Risikobereitschaft ist eine Folge wachsender Nutzerzahlen und hängt teilweise auch mit staatlicher Regulierung zusammen
- Startups können die Verwandlung in ein Unternehmen unnötig beschleunigen, indem sie Prozesse großer Unternehmen kopieren
- Wenn man Manager aus großen Unternehmen einstellt, kann deren bisheriges Playbook mit ins Unternehmen kommen
- Viele Startups nutzen Jira, weil große Unternehmen es nutzen; die Position ist jedoch, dass man genau diese Arbeitsweise vermeiden sollte
- Man kann sagen, dass Y Combinator die Erkenntnis verbreitet hat, dass große Unternehmen versuchen sollten, wie Startups zu arbeiten
- Das Playbook großer Unternehmen ist für große Unternehmen gedacht, und wenn ein Startup groß genug wird, könnte es bessere Lösungen für Skalierungsprobleme geben
- Wenn man Skalierungsschmerzen erlebt, ist es besser, sie aus First Principles zu lösen oder sich von Startups inspirieren zu lassen, die bei gleicher Größe schneller vorankommen
- Ein Unternehmen wie mehrere unabhängige Startups zu strukturieren, ist im Rahmen des Möglichen einen Versuch wert
- Rippling wird als Beispiel genannt, dem das in gewissem Maß gelungen ist
- Allerdings sind die Produktkomponenten zu eng miteinander verbunden, und die meisten Komponenten können allein keinen Umsatz erzielen, weshalb es in der Regel Grenzen gibt
- Die Gestaltung von Anreizen kann die abnehmende Interessenangleichung spürbar verzögern
- Doch starke Anreize, die mit großen Anteilen und der Macht, deren Wert zu verändern, vergleichbar sind, sind selten
- Eine der besten Methoden ist, weniger einzustellen
- Viele Unternehmen stellen zu schnell ein, wegen falsch ausgerichteter Manager-Anreize, Investorendruck, wie andere schnell wachsende Startups auszusehen, und weil sie die wahren Kosten einer zusätzlichen Person nicht verstehen
- Je besser Tools, insbesondere AI, werden, desto mehr Nutzer kann ein kleines Team unterstützen
- Gründer der Zukunft könnten sich weniger über solche Skalierungsschmerzen sorgen müssen, und Arbeit könnte für alle mehr Spaß machen
1 Kommentare
Hacker-News-Kommentare
Mir gefiel sehr, wie Netflix vor 10 Jahren gearbeitet hat, als es noch klein war. Man konnte reife Menschen einstellen und dadurch Prozesse abschaffen; tatsächlich versuchte man, alles zu entprozessualisieren.
Das Ergebnis war, dass die Dinge einfach liefen, und bei Netflix wurde damals oft erwartet, dass etwas „ganz natürlich ohne großes Ereignis“ passiert. Active-Active-Regionen waren in wenigen Monaten umgesetzt, das einfach zu nutzende Deployment-Tool Asgard entstand ebenfalls, und auch der Plan, ein eigenes CDN zu bauen und Partnerschaften mit ISPs einzugehen, wurde mit etwa 12 Leuten in sechs Monaten umgesetzt.
Aus Sicht eines Engineers gab es nur ein wöchentliches Teammeeting, und Manager und Direktoren hielten viele Meetings ab, um den Kontext zwischen den Teams abzugleichen, sodass die Engineers nach Herzenslust produktiv arbeiten konnten. Damals hielt ich das für selbstverständlich, später merkte ich, dass das ein sehr hoher Standard war.
Man braucht Entwickler, die Dinge auch ohne Händchenhalten zu Ende bringen können, aber Manager müssen ebenfalls koordinieren können, statt an der Hand zu führen und zu kontrollieren.
Wenn es aber um ein Produkt geht, das subjektives Feedback von mehr als einer Person aufnehmen und iterativ verbessern muss, sind Kommunikation und verteilte Zusammenarbeit wichtig und notwendig. Das heißt nicht, dass es zwangsläufig schmerzhaft sein muss, aber das oben beschriebene Netflix-Modell lässt sich nicht überall anwenden und sollte nicht blind kopiert werden.
An den Orten, an denen ich gearbeitet habe, waren die Produkte nicht klar definiert – nicht aus Nachlässigkeit, sondern weil sie neu und in ihrer Form unbestimmt waren, sodass niemand wusste, was sie eigentlich sein sollten. Bei Netflix hingegen ist das Ziel „Videos möglichst effizient auf Bildschirme bringen“ klar, wodurch es eher zu reiner technischer Problemlösung wird.
Natürlich gibt es weiter Produktentwicklung etwa für Werbung oder Backoffice, aber ich frage mich, ob die Kernmission des Produkts so stabil ist, dass man weniger Zeit darauf verwenden muss, alle auf dieselbe Richtung einzuschwören.
Bei solchen Texten verdrehe ich jedes Mal die Augen. Der Autor wirkt auf mich entweder ziemlich junior oder wie dieser Gründertyp mit seltsam kaputten Erwartungen daran, warum Beschäftigte für seine Firma arbeiten.
Das kommt zu einem großen Teil aus der merkwürdigen Kultur der Tech-Branche in SF, aber außerhalb davon denken Menschen nicht so über ihren Job. Die besten Entwickler, mit denen ich gearbeitet habe, waren nicht von der Arbeit „berauscht“; sie waren Profis, die wussten, was sie taten, für dieses Wissen gut bezahlt wurden und auch außerhalb der Arbeit ein erfülltes Leben mit Freunden und persönlichen Interessen hatten.
Solche Narrative sind im Grunde Propaganda, die junge, beeinflussbare Engineers dazu bringen soll, mehr von ihrem Leben der Arbeit zu widmen, als ihr Gehalt rechtfertigt. Wenn man ein junger Engineer ist, sollte man das nicht tun. Es gibt viele Chefs, die Begeisterung und Naivität ausnutzen, um das Privatleben von Menschen völlig zu ruinieren, aber es gibt auch viele Orte, die ein normales Arbeitgeber-Arbeitnehmer-Verhältnis erwarten.
Als er vorschlug, den Lohn bis zum Produktlaunch aufzuschieben, wurden die über Jahre aufgebauten Vertrauensstrategien schließlich eingelöst, und mir wurde allmählich klar, dass die miese Bezahlung Absicht gewesen war. Er hätte für diese Arbeit einen ordentlichen Lohn zahlen können, aber als ich angemessene Vergütung verlangte, bekam ich nur Widerstand, Brotkrumen-Versprechen und Abblocken zurück.
Als ich später das ausstehende Geld einforderte, sagte er, es gebe „kein Geld“, aber nachdem ich wütend gekündigt hatte, stellte er jemand anderen ein, der mein zweites Projekt von Grund auf neu machen sollte. Ich war nicht der schnellste Entwickler, und der neu Eingestellte war wohl auch ziemlich gut, aber aus Sicht von mir und einem anderen Entwickler erledigte ich meine Arbeit ausreichend gut.
Es sind Situationen wie: „Drei Kollegen wurden entlassen, jetzt mache ich die Arbeit von vier Leuten, aber mein Chef hört nicht zu, wenn ich sage, dass ich überlastet bin.“ Jemand Professionelles wäre vermutlich schon vor der Entlassung gegangen oder hätte, wenn eine solche Situation entsteht, Grenzen gesetzt und verhandelt, was innerhalb einer normalen Arbeitswoche erledigt wird und was nicht.
Unternehmen können ohne nachzudenken Leute entlassen, aber viel zu viele Menschen sind darauf konditioniert, sich mehr um das Unternehmen zu sorgen als um ihr eigenes Leben; das ist absurd.
Danach wechselte ich zu einem Startup und bereue es nicht. Ich arbeite mehr, aber es macht viel mehr Spaß, und auch wenn ich das nicht für immer machen kann, ist die finanzielle Vergütung besser geworden, sodass ich wohl nicht wie in meinen früheren stabilen, langweiligen Jobs bis 65 arbeiten muss.
Das heißt auch nicht, dass ihr Leben nicht erfüllt wäre oder dass sie ausgebeutet würden. Im Gegenteil: Menschen, die das Gegenteil behaupten, scheinen aus ihrer Arbeit weniger herauszuholen, als möglich wäre. 40 Stunden pro Woche so zu verbringen, wirkt ein bisschen verschwendet.
Im Grunde hat er die Kool-Aid getrunken und weiß nicht einmal, was er alles nicht weiß.
Es gibt auch Faktoren, die noch einen Schritt über ein „Aufflammen“ hinausgehen und vollständige Zerstörung herbeiführen können
Eine unvollständige Liste der Dinge, die meiner Ansicht nach bisher stark dazu beigetragen haben, Engineering-Teams und Produkte verfallen zu lassen oder zu Fall zu bringen, sieht so aus: zu technische Führungskräfte, nichttechnische Führungskräfte, problematische Engineers und Micromanagement
Wenn ein Startup wächst, wechseln Superstar-Engineers in Führungsrollen wie VP Engineering, Architekt oder CTO. Wenn sie aber keine Führungspersönlichkeiten sind, wird das Team leicht zu einem Zoo ohne Vision. Umgekehrt sind nichttechnische Führungskräfte mit kaum Engineering-Erfahrung ähnlich gefährlich
Wenn durch oberflächliche Interviews problematische Engineers ins Team kommen und Entlassungen lax gehandhabt werden, reichen schon 5–10 % solcher Leute im Team aus, um Fortschritt zu blockieren, Verantwortung zu vermeiden, nur Reputation aufzubauen und miserable Ergebnisse durchzudrücken, was die Moral stark beschädigt. Ein gutes Engineering-Team und eine gute Kultur zu erhalten, wirkt so schwierig, wie einen Bleistift auf seiner Mine balancieren zu lassen
Unerfahrene Gründer zögern oft zu sehr, negatives Feedback zu geben, übermäßig technische Manager, die ICs hätten bleiben sollen, zurückzustufen oder unpassende Mitarbeitende gehen zu lassen
Ein lokales Startup setzte den UI-Designer-Freund eines C-Level-Executives als VP Product ein. Er war der Aufgabe überhaupt nicht gewachsen, blieb aber zwei Jahre, weil man ihm „eine Chance zum Wachsen“ geben wollte. Alle unter diesem VP wussten, dass er inkompetent war, und sprachen darüber, wie man ihn umgehen konnte
Am Ende kamen Produktinitiativen nicht einmal in Gang, und das Unternehmen musste vollständig auf servicebasierte Arbeit pivotieren. In einem Startup, das an unqualifizierten Führungskräften festhält, die die Leute im Unternehmen bereits aufgegeben haben, sollte man besser nicht bleiben
Dasselbe Unternehmen hatte bei einer Verkleinerung die perfekte Gelegenheit, den VP Product und sein Reich, das kaum mit ihm arbeitete, aufzuräumen. Wegen seiner Verbindungen zum C-Level wurde das aber vermieden, und stattdessen wurden Engineers entlassen. Man baute zuerst hoch vergütete Engineers ab, verlor dabei Kern-Engineers, sendete das Signal, dass Inkompetenz toleriert wird, wenn man nur die richtigen Leute kennt, und in den folgenden Monaten gingen noch mehr Schlüsselkräfte
Einstellungsfehler macht jeder, aber wie man auf diese Fehler reagiert, entscheidet über das Schicksal des Unternehmens
Man kann Faustregeln formulieren wie „ICs sollten so viel Autonomie bekommen, wie sie bewältigen können“, aber jede Regel hat Ausnahmen. Verdichtete Weisheit verliert ihren Kontext und wird leicht falsch interpretiert oder von unerfahrenen Leuten cargo-kultartig nachgeahmt
Ich habe gesehen, wie kleine Dynamiken, die aus feinen Unterschieden in Persönlichkeiten und Organisationsstrukturen entstehen, zu massiven Funktionsstörungen und Produktivitätsverlusten führten, obwohl alle in guter Absicht ihr Bestes gaben. Gute Engineering-Arbeit entsteht nicht durch Befehle von oben und zentrale Planung
Es müssen genügend Menschen, bis hin zu den Engineers an der Basis, Produkt und Geschäft wirklich bis zum Ende verstehen, damit kleine Entscheidungen zum großen Ganzen passen und die richtigen Bedenken an die Führungsebene gelangen können. Kurz- und langfristige Kosten von Produkt, Design, Recht, Finanzen, Support, Security und Operations müssen gemeinsam abgewogen werden
Das ist nur möglich, wenn ein hohes Maß an Vertrauen und Sicherheit herrscht, in dem Fachleute ihre Meinung äußern und passende Kompromisse finden können. Da Ego- und Persönlichkeitskonflikte das leicht behindern, braucht es Reife in der Führung. Die Metapher vom Bleistift auf der Mine passt ziemlich gut
Diese Person schaut sich die App an und beginnt, alle Entscheidungen ohne Kontext als Technical Debt zu bezeichnen. Ich habe das ein paar Mal erlebt und einem neuen VP Engineering einmal gesagt, dass es ignorant wirkt, ursprüngliche Probleme, Entscheidungen und Zeitpläne als schlechte Urteile darzustellen, obwohl man damals gar nicht dabei war
Zum Glück bat er mich später separat dazu, bedankte sich und fragte nach mehr Hintergrund. Nachdem er die ganze Geschichte gehört hatte, stimmte er zu, dass wir die richtigen Entscheidungen getroffen hatten. Ich habe aber auch Fälle gesehen, in denen es anders lief, und dann ist es wirklich hart
Er packte alle Teams in eine Tabelle und versuchte, das Management über einheitliche Kennzahlen zu automatisieren, statt sich darauf zu konzentrieren, seine direkten Reports zu führen und weiterzuentwickeln
Umgekehrt habe ich gesehen, wie eine weniger technische Führungskraft kam und Engineers um sie herum mit einem Hauch von Männerüberlegenheitsgehabe die Augen verdrehten, während sie in Wirklichkeit schlechte Einstellungen gehen ließ, Star-Player einstellte, alle auf gemeinsame Prioritäten ausrichtete und produktiv machte. Führung ist etwas völlig anderes als technische Exzellenz, und Fähigkeiten, die zu oft mit Beförderungen belohnt werden, sollten eher mit Gehaltserhöhungen oder Boni belohnt werden
Menschen mit Führungserfahrung, die zugleich operative Fähigkeiten haben und bei genügend Zeit die Details eines neuen Tech-Stacks oder finanzieller Maßnahmen verstehen können, können sich durch langfristige Führungsbeiträge den Respekt der Superstars an der Front verdienen
Ich stimme nicht zu. Ich habe kleine Unternehmen gegründet und auch in Großkonzernen gearbeitet, darunter FAANG und große Banken, aber eine solche immersive Umgebung lässt sich überall schaffen
Entscheidend ist, dass eine dynamische Führungskraft ein Team aufbaut, in dem die Leute genau wissen, warum sie dort sind, jede Person das tut, worin sie gut ist, und bei Dingen, die sie nicht gut kann, von jemandem unterstützt wird, der es kann. Danach muss klar gemacht werden, welchen Wert die Aufgabe des Teams für die Mission des Unternehmens und seinen Zweck in der Welt hat, und man muss beharrlich die Barrieren beseitigen, die Produktion und Impact im Weg stehen
Behauptungen wie N²-Kommunikation sind reduktionistisch und ungenau. Kein Team hängt von allen Teams in der Organisation ab; normalerweise ist der Zuständigkeitsbereich klein und auch die angrenzenden Teams sind begrenzt. Kernteams sind eine Ausnahme, aber ein gut funktionierendes Kernteam wirkt nicht wie N²-Overhead, sondern wie ein Fokuspunkt und bildet eine N-Struktur, zu der die Teams kommen
N kann groß sein, deshalb sind wirksame Triage, Automatisierung, Self-Service, konsistente Plattformen mit selbstdokumentierendem Charakter und Teammitglieder, die wirklich gern Wissen vermitteln, wichtig. Solche Teams aufzubauen ist aus Managementsicht unglaublich anstrengend und hat mich erschöpft, aber Management sollte eben unglaublich anstrengend sein. Als Nächstes kehre ich als Distinguished Engineer in ein Late-Stage-Startup zurück und gehe für eine Weile zu meinen Wurzeln zurück
Allerdings stimmt es, dass sich eine solche immersive Umgebung überall schaffen lässt und dass eine dynamische Führungskraft wichtig ist, die ein Team aufbaut, in dem die Leute wissen, warum sie dort sind. Trotzdem denke ich, dass es mit Größe und schlechten Anreizen zu tun hat. Ich habe gehört, dass bei FAANG manche Abteilungen wie Startups sind und andere seelenraubende Langeweile
Das angeführte Gegenbeispiel ist kein Beispiel dafür, dass N²-Komplexität nicht existiert, sondern eines dafür, dass diese Komplexität richtig gemanagt wurde
Wenn man sagt, dass nicht jedes Team von jedem anderen Team abhängt, stimmt man dem Text damit eher zu. Dann ist mir nicht klar, welcher Teil falsch sein soll
Die Skaleneffekte, die man in großen Organisationen angeblich bekommt, fühlen sich in Wirklichkeit nicht wie Effizienz an. Gemeint sind Effizienzen durch spezialisierte Rollen wie Recruiting, HR, Qualitätssicherung oder Nutzerforschung
Statt eine „effizientere“ Organisationsstruktur zu bauen, könnte es besser sein, die kleinste Teamform, die effektiv funktioniert hat, immer wieder zu replizieren. Wie diese „Mini-Unternehmen“ dann effizient miteinander kommunizieren, ist allerdings ein anderes Problem
Wenn der Unternehmenswert steigt und Aktionäre sowie Manager mit geringerer Risikobereitschaft hinzukommen, muss man viel Geld für Risikomanagement und Risikovermeidung ausgeben. In einem früheren Unternehmen hat ein Wettbewerber offen gegen Gesetze verstoßen, um Nutzeranforderungen zu erfüllen, kam aber wohl damit durch, weil er klein war und keinen Umsatz machte
Außerdem investieren die meisten Mitarbeitenden meiner persönlichen Erfahrung nach nicht so viel Energie wie Gründer, was vollkommen nachvollziehbar ist. Je kleiner das Verhältnis von Gründern zu Mitarbeitenden wird, desto eher stellt man drei Leute ein, um Dinge zuverlässig und pünktlich erledigt zu bekommen, die man allein tun könnte
Frühe Mitarbeitende sind den Gründern nah und haben bei einem Erfolg des Unternehmens viel zu gewinnen, daher ähneln sie Gründern stärker. Der 213. Mitarbeiter verkauft dagegen 40 Wochenstunden Arbeit und bekommt im Grunde nur ein festes Gehalt. Die romantische Idee eines Großunternehmens aus vielen unabhängigen Startups ist schön, aber ich habe nie gesehen, dass sie tatsächlich funktioniert, und kann es mir auch schwer vorstellen
Der beste Weg zu skalieren besteht meiner Meinung nach darin, Prozesse zu schaffen, die die gewünschten Eigenschaften eines Teams verstärken, und Manager einzustellen, die verstehen, dass Teams Gruppen unterschiedlicher Individuen sind. Manager sollten ihre Leute frei so führen können, dass sie Lieferung optimieren und Fluktuation verringern
Zwischen Teams müssen Kommunikation und Qualitätsstandards für Ergebnisse sehr hoch sein, und die Organisationskultur muss auf Respekt gegenüber jeder eingestellten Person sowie auf einem beharrlichen Fokus darauf beruhen, jede Person in ein Team zu bringen, in dem sie effektiv arbeiten kann
Die Früchte der Arbeit hängen immer höher. In der Frühphase eines Startups ist der Problemraum reichhaltig, der Impact, den Einzelne erzielen können, ungewöhnlich groß, und die Zahl der Menschen, mit denen man diesen Erfolg teilen muss, am kleinsten
Wenn das Unternehmen wächst, geraten alle drei Faktoren unter Druck. Der Problemraum wird knapper, die Anerkennung für großen Impact wird zunehmend weiter oben in der Hierarchie vereinnahmt, und die Zahl der Menschen, die sich den Impact teilen, wächst, während die Anerkennung kurz und verschwommen wird
Am Ende wurde es aber doch zu einer einzigen großen Organisation. Die flache Organisationsstruktur von Valve ist ähnlich. Wenn etwas groß genug wird, wird es letztlich zu einem Klumpen
Die Kunst des Wachstumsmanagements besteht zu einem großen Teil darin, Wege zu finden, Menschen zu befreien, statt ihnen Fesseln anzulegen
Der Satz „Die meisten Startups beschleunigen ihre eigene Verkonzernung unnötig, indem sie Prozesse von Großunternehmen kopieren. Meist holen sie Manager aus Großunternehmen, und diese bringen ihr eigenes Playbook mit“ ist schmerzhaft treffend
Ich habe diesen Zyklus ein paar Mal erlebt. Das Startup, das ich am meisten mochte und das zuletzt erfolgreich war, wurde 2007 im vierten Jahr von einem riesigen globalen Unternehmen übernommen, und ich blieb noch zwei Jahre
Nach dem Produktlaunch wurde es wegen des Bedarfs an Customer Support und Sales Support deutlich langsamer. Ein großartiger VP Engineering wurde CTO, und als ein mittelmäßiger Idiot aus dem Middle Management zum VP gemacht wurde, waren die guten Zeiten vorbei. Der neue VP stellte statt guter Engineers „Teamplayer“ ein, belohnte Loyalität statt Kompetenz, und es passierten absurde Dinge
Meine spaßige, startupartige Zeit schrumpfte auf genau eine Woche im Jahr, zwischen Weihnachten und Neujahr. In dieser Woche war niemand da, sodass ich viel freier an Dingen arbeiten konnte, die ich für wichtig hielt, und eine Alpha-Version eines glänzenden neuen Features bauen konnte, der die Organisation dann folgen musste
Im Kandidatenpool gibt es erstaunlich viele Haifischtypen. Sie tauchen auf, merken, dass man neu ist, erzählen einem alles, was man hören will, und versprechen, alle Probleme zu lösen. Sie behaupten, in jeder früheren Firma genau das getan zu haben, was man jetzt braucht, schmeicheln einem und sagen, sie hätten auf die Gelegenheit gewartet, mit jemandem wie einem zu arbeiten
Man kann sie sich als eine fünfmal stärkere und schwerer zu durchschauende Version des glattesten IC-Kandidaten vorstellen, den man je interviewt hat. Sie haben unglaubliches Charisma, haben aber wenig Interesse daran, harte Arbeit zu leisten, und versuchen, sich in die Firma einzugraben und etwas herauszuziehen
Sie holen Vergütung für sich selbst heraus, Headcount, um Freunde einzustellen, Vergütung für diese Freunde, lukrative Verträge für befreundete Dienstleister und vielleicht sogar Kickbacks. Weil sie viel Aktivität erzeugen, kann es Jahre dauern, bis die Leute merken, dass tatsächlich nicht viel passiert ist. Auf dem Weg dorthin werden fähige Mitarbeiter des Bullshits müde oder gehen, weil sie verdrängt werden, nachdem sie die Inkompetenz benannt haben
Safi Bahcalls Loonshots erklärt dieses Phänomen ziemlich gut. Bei etwa 150 Personen herum kommt es zu einem „Phasenübergang“ der Anreize, der für viele Organisationen tödlich sein kann
Der Trick liegt darin, wie ein Startup über diese Mitarbeiterzahl hinauswächst. Ehrlich gesagt brauchen viele Softwarefirmen vielleicht gar nicht mehr als 150 Leute
Die Dunbar-Zahl ist ein vorgeschlagenes kognitives Limit für die Anzahl von Menschen, mit denen man stabile soziale Beziehungen aufrechterhalten kann. Mit Beziehung ist hier gemeint, dass jede Person weiß, wer die anderen sind und wie sie miteinander verbunden sind
https://en.wikipedia.org/wiki/Dunbar%27s_number
Die Welt ist schon vor Tausenden von Jahren über dieses Limit hinausgewachsen, und Unternehmen können ebenfalls darüber hinauswachsen
Der Wert der Empfehlung, weniger einzustellen, kann kaum überschätzt werden. Anders gesagt: Man sollte nur einstellen, wenn es keinen anderen Weg gibt, ein Problem zu lösen, und selbst dann vorsichtig sein
Man muss in Kauf nehmen, dass Zeitpläne wegen dieses Prinzips deutlich länger werden. Die mittel- und langfristigen Kosten von Overhiring sind viel schlimmer als die Kosten verzögerter Releases. Leider fördern das Finanzierungsumfeld und die Wachstumserwartungen von Startups oft das gegenteilige Verhalten
Allerdings hatte ich ziemlich unterschätzt, wie schlecht die Einstellungssituation bei Silicon-Valley-Startups geworden ist. Viele Leute nutzen Startups als Station im Lebenslauf, während sie sich von FAANG-Burnout erholen oder sich auf Interviews vorbereiten
In einer solchen Struktur neigen Hiring Manager leicht zu übermäßigem Optimismus, weil sie fürchten, die wenigen Leute zu verpassen, die wirklich ein Unternehmen aufbauen können. Am Ende muss man Leute, die nicht passen, konsequent wieder gehen lassen
An diesem Artikel gefielen mir einige Teile, anderen stimmte ich nicht zu
Am meisten zugestimmt habe ich dem Punkt „nicht zu schnell einstellen“. Mir fallen kaum Startups oder Unternehmen ein, die daran gescheitert sind oder gelitten haben, dass sie zu langsam eingestellt haben; aber sehr viele Probleme durch zu schnelles Einstellen fallen mir ein, einschließlich persönlicher Erfahrungen
Beim Punkt „nutzt kein Jira“ musste ich dagegen die Augen verdrehen. So sicher wie die Sonne im Osten aufgeht, ist es ein Lieblingshobby von Engineers, über Jira herzuziehen. Je nach Art des Startups kann Jira ein sehr gutes Werkzeug für diese Aufgabe sein
Wenn ein Unternehmen viele Workflows unterstützen muss, kann enorm viel Zeit verloren gehen, wenn Dinge wegen schlechter Nachverfolgung und unklarer Issue-Ownership durchs Raster fallen. Natürlich kann man auch leicht Zeit verschwenden, indem man Jira mit einer Million unnötiger Status überkompliziert, aber heutzutage ist Jira meiner Meinung nach für kleine Teams einfacher geworden, schnell produktiv zu nutzen
Das heißt nicht, dass Jira das beste Tool für den Start ist; mein letztes Startup begann mit Trello, und das funktionierte gut. Aber sobald man in den Betrieb geht und neben der Entwicklung neuer Features viele operative Issues verwalten und priorisieren muss, braucht man mit hoher Wahrscheinlichkeit ein Tool wie Jira, um alle auszurichten und Informationen zu teilen