- Nach vier Jahren als Softwareentwickler bei Google und dem Ausscheiden am 1. Februar standen hinter dieser Entscheidung Erfahrungen mit der Beförderungsbewertungsstruktur und wiederholten Projektabbrüchen, durch die das Gefühl der Kontrolle über die eigene Karriere schwächer wurde
- Über Beförderungen entschied nicht der direkte Manager, sondern ein Gremium aus höheren Ingenieuren und Managern, die den Kandidaten nicht kannten und ein promo packet prüften
- Die Verbesserung einer Legacy-Pipeline, Bugfixes, Tests, Dokumentation und Teamunterstützung waren zwar tatsächlich nützlich, ließen sich aber schwer als messbarer Einfluss darstellen und wirkten sich bei der ersten Beförderungsrunde nachteilig aus
- Als danach nur noch Arbeit ausgewählt wurde, die bei einer Beförderung half, gab es zwar die höchste Leistungsbewertung Superb, doch wiederholte Projektstreichungen und Teamumbesetzungen führten erneut zum Scheitern der Beförderung
- Über Indie Hackers wurde eine Alternative in Form kleiner profitabler Softwaregeschäfte entdeckt, und es war geplant, jeweils einige Monate lang KetoHub, ein auf Sia basierendes Geschäft und die Monetarisierung des Schreibens auszuprobieren
Die ersten zwei Jahre bei Google und die Erwartung einer Beförderung
- Die ersten zwei Jahre nach dem Eintritt waren so zufriedenstellend, dass angenommen wurde, lange im Unternehmen zu bleiben
- In der Umgebung gab es hervorragende Ingenieure, außerdem fortschrittliche Entwicklungstools und kostenlose Mahlzeiten
- Die jüngste Leistungsbewertung lautete Strongly Exceeds Expectations, und vom Manager kam die Aussage, dass die Beförderung zur nächsten Stufe, Senior Software Engineer, nahe sei
- Der Manager war der Ansicht, dass die Arbeitsleistung bereits auf Senior-Niveau lag, sagte aber, es brauche ein geeignetes Projekt, um dies dem Beförderungsgremium zu beweisen
So funktioniert das Beförderungsverfahren bei Google
- Bei Google kann ein direkter Manager einen Mitarbeiter nicht selbst befördern und hat auch kein Stimmrecht
- Ob jemand befördert wird, entscheidet ein kleines Gremium aus höherrangigen Softwareingenieuren und Managern, die den Kandidaten an diesem Tag zum ersten Mal sehen
- Der Bewerber erstellt ein promo packet und reicht es ein
- Empfehlungsschreiben von Teammitgliedern
- Verfasste Designdokumente
- Ein kurzer Text, der erklärt, warum die eigene Arbeit einer Beförderung würdig ist
- Das Gremium prüft die Pakete mehrerer Kandidaten gemeinsam und entscheidet innerhalb eines Tages über die Beförderungen
- Anfangs wurde dieses Verfahren als Möglichkeit gesehen, Vorurteile und interne Politik zu verringern und Codequalität sowie technisches Urteilsvermögen fair zu bewerten
Warum die Verbesserung der Legacy-Pipeline in der Bewertung nicht sichtbar wurde
- Die Hauptverantwortung war eine alte Legacy-Datenpipeline
- Sie war jahrelang im Wartungsmodus, stand aber durch steigende Last unter Druck
- Sie fiel häufig still aus oder lieferte fehlerhafte Ausgaben
- Nach dem ursprünglichen Designdokument gab es keine Dokumentation mehr, sodass die Diagnose von Störungen Tage dauern konnte
- Um die Pipeline zu stabilisieren, wurden mehrere Verbesserungen umgesetzt
- Dutzende Bugs wurden behoben
- Automatisierte Tests wurden geschrieben, um Rückfälle zu verhindern
- Tausende Zeilen toten Codes und Code, der durch moderne Bibliotheken ersetzt werden konnte, wurden entfernt
- Erkenntnisse wurden dokumentiert, damit Wissen nicht nur im Kopf einzelner Personen blieb
- In der Beförderungsrunde kehrte diese Arbeit als nicht quantifizierbares Problem zurück
- Durch das Auffinden von Bugs wirkte es sogar so, als sei die Gesamtzahl der Bugs gestiegen
- Weil Auffälligkeiten nicht mehr stillschweigend übergangen, sondern zu schnellem Fehlschlagen umgebaut wurden, stiegen auch die Störungskennzahlen
- Die Zeit, die Entwickler zur Behebung von Störungen brauchten, sank stark, aber dafür gab es keine Metrik
- Um das Release-Risiko für Teammitglieder zu senken, wurden eigene Projekte teils um Wochen oder Monate verschoben
- Für das Team war das die richtige Entscheidung, im promo packet sah es jedoch nicht beeindruckend aus
- Für das Gremium wirkten die Projekte von Teammitgliedern wie wichtigere Arbeiten mit größerem Koordinationsbedarf, während die eigene Arbeit wie leicht unterbrechbare Arbeit erschien
- Das Ergebnis der ersten Beförderungsrunde war die Einschätzung, dass Belege für den Umgang mit technischer Komplexität und für den Einfluss auf Google fehlten
Wie sich die Arbeitsweise nach der Ablehnung veränderte
- Nach der ersten Ablehnung wurde gedacht, dass dieselbe gute Arbeit ausreiche, wenn sie nur besser dokumentiert werde
- Selbst als das Team viele E-Mail-Benachrichtigungen mit Fehlalarmen bekam, wurde das Problem nicht sofort behoben; stattdessen sollte zuerst eine Metrik zur Alarmhäufigkeit erstellt werden, um historische Daten zu sammeln
- So hätte sich bei der Beförderung ein Diagramm mit sinkenden Alarmzahlen zeigen lassen
- Ein später zugewiesenes Projekt schien für eine Beförderung vorteilhaft zu sein
- Es stützte sich stark auf Machine Learning, ein für Google wichtiges Feld
- Es automatisierte Arbeit, die zuvor von Hunderten Beschäftigten manuell erledigt wurde
- Ein Junior-Entwickler musste angeleitet werden, was in Beförderungsrunden üblicherweise Pluspunkte bringt
Der Vorfall mit den Jahresendgeschenken und die Erkenntnis einer „Geschäftsbeziehung“
- Google beendete die langjährige Tradition luxuriöser Jahresendgeschenke und kaufte stattdessen vom Geschenkbudget Chromebooks für einkommensschwache Schüler, was es in die Schlagzeilen brachte
- In einer internen Unterhaltung dazu sagte ein Mitarbeiter, die Beziehung zwischen Google und den Beschäftigten sei eine Geschäftsbeziehung
- Diese Unterhaltung führte zur Erkenntnis, dass Google und man selbst weniger eine Gemeinschaft als vielmehr eine Beziehung aus Bezahlung gegen Leistung waren
- Wenn das Beförderungsgremium Bugfixes oder Teamunterstützung nicht belohnte, musste auch neu überlegt werden, warum dafür Zeit aufgewendet werden sollte
Beförderungsoptimierung und veränderte Qualitätsmaßstäbe
- Die Lehre aus der ersten abgelehnten Beförderung erwies sich später als falsch
- Statt dieselbe Arbeit nur besser zu verpacken, wurde dazu übergegangen, ausschließlich die Arbeit auszuwählen, die das Beförderungsgremium sehen wollte
- Die neue Strategie bestand darin, vor Beginn jeder Aufgabe zu fragen, ob sie bei der Beförderung half, und sie nicht zu tun, wenn das nicht der Fall war
- Auch die Maßstäbe für Codequalität sanken
- Statt „Ist das in den nächsten fünf Jahren wartbar?“ galt „Hält es bis zur Beförderung durch?“
- Bugs, die den Projektstart nicht bedrohten, wurden weder erfasst noch behoben
- Verantwortung für Wartung wurde vermieden
- Die freiwillige Mitarbeit bei Campus-Recruiting-Veranstaltungen wurde eingestellt
- Die zuvor ein- bis zweimal pro Woche geführten Interviews wurden auf null reduziert
Wiederholte Projektabbrüche und der Verlust von Kontrolle über die Karriere
- Durch geänderte Prioritäten wurde ein Projekt, das für eine Beförderung gut aussah, an ein Schwesterteam in Indien übergeben
- Das stattdessen erhaltene Projekt war undokumentiert, lief auf nicht mehr unterstützter Infrastruktur, war aber ein wichtiger Bestandteil der Produktion
- Die neue Aufgabe bestand darin, dieses System aus dem Code des Schwesterteams herauszulösen und in ein neues Framework zu migrieren, während Betrieb und Performance-Metriken in Produktion erhalten blieben
- Aus Sicht der Beförderung war das ein Rückschritt um mehrere Monate
- Das gestrichene Projekt wurde nie veröffentlicht, wodurch zwei Monate Arbeit bedeutungslos wurden
- Das Verständnis des neuen Systems erforderte mehrere Wochen
- Zusätzliche Zeit konnte für die wiederkehrende Betriebsarbeit anfallen
- Innerhalb von sechs Monaten war es bereits die dritte Umzuweisung mitten im Projekt, und jedes Mal lagen die Gründe nicht in der Qualität der Arbeit, sondern in Strategien des höheren Managements oder Änderungen bei der Teamaufstellung
- Google sagte, Arbeit könne erst nach Abschluss eines Projekts beurteilt werden, unterbrach Projekte aber gleichzeitig unterwegs und wies neue Aufgaben zu, was den Abschluss erschwerte
- Die Karriere war damit von einem anonymen Gremium abhängig, das einen nur etwa eine Stunde lang prüfte, sowie von Managemententscheidungen, auf die kein Einfluss bestand
Der letzte Beförderungsversuch und die Entscheidung zur Kündigung
- Da bereits drei Jahre bei Google in das Ziel einer Beförderung investiert worden waren, sollte vor dem Abschied noch ein letzter Antrag gestellt werden
- Sechs Wochen vor Ende des Leistungszeitraums wurde das Projekt erneut gestrichen, diesmal sogar das gesamte Team
- Bei Google war das häufig genug, dass es dafür den Euphemismus defrag gab
- Das Projekt des Teams wurde an das Schwesterteam in Indien übertragen
- Die Teammitglieder mussten in anderen Bereichen des Unternehmens neu anfangen
- Trotzdem wurde die Beförderung beantragt, und das Ergebnis war die höchste Leistungsbewertung Superb
- Diese Bewertung erhalten in jedem Zyklus etwa 5 % der Beschäftigten
- Das Beförderungsgremium sah in den letzten sechs Monaten einen klaren Nachweis von Arbeit auf Senior-Niveau
- Diese sechs Monate waren die Phase, in der nach der Logik der Beförderungsoptimierung gearbeitet wurde
- Dennoch erfolgte keine Beförderung, weil sechs Monate nicht als ausreichend langer Leistungsnachweis galten
- Der Manager sagte, bei weiteren sechs Monaten auf diesem Niveau sei die Beförderung wahrscheinlich, doch nachdem bereits zwei Jahre lang immer wieder „in sechs Monaten wahrscheinlich“ zu hören gewesen war, fiel die Entscheidung zu gehen
Indie Hackers und der Plan für unabhängige Entwicklung
- Etwa zur selben Zeit wurde Indie Hackers entdeckt
- Indie Hackers war eine Online-Community von Gründern kleiner Softwareunternehmen
- Im Mittelpunkt standen weniger Menschen mit dem Traum vom riesigen Startup, sondern solche, die kleine profitable Geschäfte aufbauen wollten, mit denen sich der Lebensunterhalt bestreiten lässt
- Zuvor war angenommen worden, dass man als Softwaregründer dem Startup-Pfad im Silicon-Valley-Stil folgen müsse
- Darunter wurde verstanden, den Großteil der Zeit für Fundraising aufzuwenden und sich darum zu sorgen, wie die nächsten eine Million Nutzer gewonnen werden
- Der Ansatz von Indie Hackers war eine andere Alternative
- Viele Mitglieder starteten ihre Geschäfte mit eigenen Ersparnissen oder als Side-Project neben dem Hauptjob
- Es gab keine Verpflichtung, Investoren Rechenschaft abzulegen
- Es war auch nicht nötig, sich vor einem anonymen Gremium zu beweisen
- Die Nachteile waren ebenfalls klar
- Das Einkommen war weniger stabil
- Es gab mehr existenzielle Risiken
- Wenn bei Google ein Fehler mit 10 Millionen Dollar Schaden passiert wäre, hätte man ein Postmortem geschrieben und es als Lernchance gesehen; für kleine Gründer konnte so etwas hingegen das Ende des Geschäfts und hohe Schulden bedeuten
- Trotzdem war an den Gründern von Indie Hackers attraktiv, dass sie ihre Entscheidungen selbst trafen, egal ob ihr Geschäft stark wuchs oder jahrelang stagnierte
- Nach dem Ausscheiden war geplant, über jeweils einige Monate hinweg verschiedene Projekte auszuprobieren und die Resonanz zu testen
- KetoHub weiterentwickeln und das Monetarisierungspotenzial prüfen
- Ein Geschäft auf Basis der dezentralen Speichertechnologie Sia aufbauen
- Mehr Zeit ins Schreiben investieren und Wege zur Monetarisierung finden
- Google war ein guter Arbeitsplatz und ein Ort, an dem wertvolle Fähigkeiten gelernt wurden, doch es wurde entschieden, dass es auch künftig Arbeitgeber wie Google geben wird, während die Freiheit, ein eigenes Unternehmen zu gründen, nicht immer vorhanden ist
1 Kommentare
Meinungen auf Hacker News
Interessant ist auch die Reihe von Jahresrückblicken desselben Autors, in der er offenlegt, wie er versucht hat, mehrere Softwareunternehmen aufzubauen, und dabei auch seine finanzielle Lage ziemlich ehrlich behandelt
Wer sich dafür interessiert, ein Softwareunternehmen per Bootstrapping aufzubauen, sollte sie unbedingt lesen:
https://mtlynch.io/tags/annual-review/
https://mtlynch.io/i-sold-tinypilot/
Erfolgsgeschichten hört man oft, und wenn man erfolgreich ist, lässt sich leicht groß darüber reden. Aber man sollte nicht vergessen, dass in der Realität die meisten Unternehmen scheitern. Dieser Autor fand im dritten Jahr etwas, das Geld einbrachte, aber die meisten haben nicht den finanziellen Spielraum, so lange ohne Einkommen durchzuhalten
Nur wenige schreiben so nahbar und ehrlich. Ich verfolge ihn seit Jahren; er ist eine großartige Quelle der Inspiration
Die wichtigste Lektion für jede Karriere lautet: „Der Kunde ist nicht der Kunde.“ Die eigentlichen Kunden sind die Menschen, die über Gehaltserhöhungen, Boni und Beförderungen entscheiden
Ein Kunde ist die Instanz, die für ein Produkt oder eine Dienstleistung bezahlt, die sie als wertvoll betrachtet; meist ist das der Manager oder, wie im Beispiel des Originaltexts, ein Beförderungskomitee. Aus dieser Perspektive sollte man seine Karriere wie ein Geschäft führen und sich darauf ausrichten, schneller Wert an diejenigen zu liefern, die Geld gegen diesen Wert tauschen können. Dass Kunden ihre Meinung ändern, der Markt seine Maßstäbe verschiebt oder man merkt, dass man sich auf das Falsche konzentriert hat, kommt auch im Geschäft häufig vor. Wenn man dem Kunden nicht liefern kann, was er will, kann er problemlos zu jemand anderem gehen; daher muss man die Strategie ständig anpassen und sich am Kunden ausrichten
Am Ende ist der eigentliche Kunde nicht einmal mehr ein Mensch, sondern ein Prozess. Gute Ideen, die Menschen helfen, mit Leidenschaft zu verfolgen, ist der beste Schnittpunkt für Karriere und Gesellschaft. Die Passage aus dem Original zeigt das gut: „Es ist nur natürlich, dass mein Schicksal in den Händen eines mysteriösen Komitees liegt, das mich nie getroffen hat. Sie werden frei von Bevorzugung oder Politik sein und meinen hochwertigen Code und meine scharfsinnigen Engineering-Entscheidungen erkennen.“
Dieses Muster führt zu sinkender Produktqualität und schlechterer Teamdynamik. Besser ist es, diesen unvermeidlich wirkenden Trend ausdrücklich zu bremsen oder ein Unternehmen zu finden, in dem er noch gar nicht entstanden ist. Wenn man gute Qualität schafft und dafür Anerkennung bekommt, fühlen sich alle besser
Wenn man im Auftrag etwas baut, können die Wünsche des Käufers und das, was tatsächlich gebraucht wird, auseinanderfallen, und am Ende kann trotzdem Unzufriedenheit bleiben. Arbeitet man für einen Vorgesetzten, kann dieser selbst zum Hindernis werden. Es reicht nicht, einfach zu tun, was der Kunde will; der Vorgesetzte kann verlangen, dass es „auf meine Art“ gemacht wird, und dadurch bekommt der Kunde am Ende nicht, was er wollte. Auch wenn ein Kunde etwas für jemand anderen kauft, kann diese Indirektheit zum Scheitern führen; bei maßgeschneiderter Unternehmenssoftware passiert das häufig
Es fällt mir schwer, diesem Beitrag vollständig zuzustimmen. Es ist sehr ärgerlich, wenn ein Projekt vor der Fertigstellung zerbricht, aber der Autor wirkt auch so, als sei er dort nur wegen der Beförderung gewesen.
Beförderungen sind gut, aber es wurde nicht ausreichend erklärt, warum genau das so ausschlaggebend war, dass er ging. Wenn der einzige Grund, in einem Job zu bleiben, die Aussicht auf einen besseren Titel ist, kann das ein schlechtes Zeichen sein. Danach hatte er bei Google in vier Jahren genug Geld für ein ganzes Leben verdient und traf mit dieser finanziellen Stabilität eine Hochrisiko-Entscheidung, die sich die meisten nicht leisten könnten. Jedenfalls freut es mich, dass er etwas gefunden hat, das zu ihm passt, und ich hoffe, dass er auf dieser Stabilität aufbauend etwas Nützliches und Wirkungsvolles schaffen kann.
All diese Faktoren waren früher sehr öffentlich, es gab jede Menge Präsentationen, Folien, Dokumente usw. Es war wichtig, auf welchem Level man selbst war und auf welchem Level die Person war, mit der man sprach. Das Ziel war nicht, ein guter Engineer zu werden oder ein gutes Produkt zu bauen, sondern nur die Arbeit zu machen, die ein namenloses Komitee dazu bringt, diese magische Zahl zu erhöhen. Selbst wenn man nicht aus diesem Grund zu Google gegangen ist, lernt man am Ende, was erwartet wird. Leider hat eine ganze Generation von Software Engineers diese Lektion gelernt.
Der Druck, Wirkung zu erzeugen oder fragwürdige Kennzahlen zu verbessern, hört nie auf, während sich technische Schulden ansammeln. Dazu kommt ständig Unsicherheit durch Reorganisationen und Entlassungen, und die Angst vor dem nächsten Bewertungszyklus ist groß. Nach ein paar Jahren scheint Geld die Hauptmotivation zu sein. Allerdings will ich wegen des zusätzlichen Stresses keine Beförderung, und da es sehr schwierig wäre, anderswo mehr zu verdienen, möchte ich so lange wie möglich in diesem Unternehmen bleiben.
So funktioniert die menschliche Psyche nicht. Man konkurriert mit den Menschen um sich herum, und es ist schwer, glücklich zu sein, wenn sie befördert werden, während man selbst zurückbleibt.
Lange auf einem Level unterhalb von Staff zu bleiben, konnte sich negativ auswirken, und wenn man nicht befördert wurde, konnte man in einen Performance Improvement Plan geraten, weil man die erklärten Erwartungen nicht erfüllte. Google hat diese Formulierung schließlich entfernt, weil man gelernt hat, dass es in einem Unternehmen mit 100.000 Mitarbeitenden nicht genug Plätze in der Pyramide gibt und man Menschen verliert, die sich nicht selbst vermarkten, aber das System am Laufen halten. Wenn ich mich richtig erinnere, wusste man das 2018 noch nicht.
Ich bin der Autor. Schön zu sehen, dass dieser Beitrag wieder aufgetaucht ist.
Wenn es Fragen zu diesem Beitrag gibt, kann ich sie beantworten.
Es klingt so, als hättest du die Strömungen beobachtet und diejenige gewählt, die am besten aussah, aber oft gibt es noch andere Optionen. Einen Damm bauen, also das Gelände verändern. Das Geschäft auf eine Weise verändern, die niemand versuchen wollte oder konnte. Rückblickend war ich am glücklichsten und erfolgreichsten, wenn ich meinem Chef sagen konnte, was ich tun werde, statt darauf zu warten, dass er mir interessante und wirkungsvolle Arbeit gibt. Wenn man diese Option nicht sieht, ist es vielleicht Zeit zu gehen, aber oft lohnt es sich, es zuerst zu versuchen. Manchmal musste ich mich durch schmutzige Arbeit kämpfen, um mir das Recht zu verdienen, mein eigenes Schicksal zu gestalten, aber sobald Managementstruktur und Vertrauen da waren, konnte ich dieses Kapital nutzen, um etwas Großes, Neues und Spannendes vorzuschlagen. Es überrascht mich jedes Mal, wenn ich sehe, dass Kühnheit belohnt wird. Noch letzte Woche hat ein Kollege mit einem ehrgeizigen und umstrittenen Vorschlag aus dem Finanzierungsstein Blut gepresst, und diese Woche wurde er Tech Lead eines neuen Teams. Immer wenn ich mich festgefahren fühle, öffne ich ein leeres Dokument und fange an, einen neuen Entwurf herunterzutippen. In dem Moment denke ich nicht an Beförderung, aber am Ende hat es irgendwo zu einer Beförderung oder einer größeren Chance geführt.
Ich frage mich, ob du an einem neuen Projekt arbeitest. Ich habe den Beitrag zum Fuzzing eines PDF-Parsers gesehen, aber nicht verstanden oder vielleicht den Kontext verpasst, ob das mit einem neuen Projekt zusammenhängt.
https://mtlynch.io/i-sold-tinypilot/
Danke, dass du öffentlich schreibst und deine Reise dokumentierst; ich bin sicher nicht der Einzige, dem das geholfen hat. Außerdem lese ich deinen Nutzernamen jedes Mal wie „Mount Lynch“.
Was ich aus diesem Beitrag mitnehme, ist, wie gnadenlos eine Struktur ist, die von einem Beförderungskomitee abhängt.
Ich verstehe, dass Google so ein System eingeführt hat, weil es eine ingenieurszentrierte Kultur schaffen wollte. Die Absicht war wohl, dass hervorragende Engineering-Arbeit anerkannt wird, selbst wenn der Manager sie nicht würdigt. Aber gerade bei schwer quantifizierbarer Arbeit wie kulturellen Verbesserungen klingt es nicht so, als könnten solche Komitees gutes Engineering wirklich erkennen. Das Leben wird besser, wenn man Gegenüber findet, Kunden oder Führungskräfte, die den Wert erkennen, den man einbringt, und diese Anerkennung in Beförderungsentscheidungen zeigen können. Ein gesichtsloses Komitee, das sich auf Pakete stützt, kann strukturell keine Beziehungen schaffen, in denen echte Anerkennung entsteht. Wenn die Führung eines Unternehmens mich nicht anerkennt, warum sollte ich mich zwingen zu bleiben? Dann sollte ich einen Ort finden, der es tut. Wenn Google nicht lernt, dass es unvermeidlich gute Leute durch schlechtes Management oder schlechte Prozesse verliert, ist das ihr Verlust. Man kann eine halbwegs gute Leistungsbewertung nutzen und langsam seinen Ausstieg planen. Das Leben ist zu kurz, um in einer Organisation zu arbeiten, die den Aufbau authentischer und unterstützender beruflicher Beziehungen aktiv verhindert.
Für viele Menschen ist eine Beförderung wie ein Tortenwettessen, bei dem der Preis noch mehr Torte ist. Man sollte anerkennen, dass die eigenen Interessen und die des Arbeitgebers nur locker zusammenhängen, und dass es in Ordnung ist, das Spiel, das das Unternehmen spielen will, abzulehnen.
Beförderung ist mir egal; ich möchte Arbeit machen, die mir intrinsische Motivation gibt – also Arbeit, die sinnvoll ist, inspiriert und in die ich eintauchen kann –, und ich möchte nur so viel verdienen, dass ich meinen Lebensunterhalt bestreiten und vernünftig sparen kann.
Das Problem sind drei Dinge: Viele Unternehmen zahlen so schlecht, dass man befördert werden muss, wenn man etwas sparen will; sinnvolle Arbeit selbst ist so selten wie ein Einhorn; und am nervigsten ist, dass selbst Beschäftigte, die in ihrer Rolle stabil und konstant gute Arbeit leisten, in US-Unternehmen zwangsläufig unter Druck gesetzt werden, zu „wachsen“ und „ihre Karriere zu entwickeln“, oder als „abgehängt“ gelten. Auf einem bestimmten Level dauerhaft hervorragende Leistung zu bringen, kann nicht Stillstand, sondern bewusste Stabilität sein. Unendliches Wachstum im persönlichen Kontext – oder zumindest endloses Herumgeschubse – ist ein schwer nachvollziehbarer Wahnsinn amerikanischer Unternehmen.
Der Satz des Autors ist eindrucksvoll: „Um meine Karriere weiterzuentwickeln, brauchte ich Projekte mit größerem Umfang und Zusammenarbeit mit mehr Partnerteams. Aber das bedeutete, dass Projekte wegen noch mehr Faktoren außerhalb meiner Kontrolle scheitern konnten und Monate oder Jahre meines Lebens verschwendet werden konnten.“
Wenn man zurückblickt und reflektiert, wird man wohl anerkennen, dass auch Startup-Erfolg von über 100 Faktoren abhängt, die außerhalb der eigenen Kontrolle liegen. Es ist keine verschwendete Lebenszeit. Man hat gelernt, wie die Welt funktioniert.
Bei einem wachstumsstarken, venture-finanzierten Startup müssen für den Erfolg vielleicht mehrere Sterne richtig stehen. In einem gebootstrappten Unternehmen braucht es im Grunde aber nur eine Sache für den Erfolg: Product-Market-Fit. Wenn man ein Produkt baut, das die Leute wollen, hat man trotz vieler anderer Fehler meist gute Erfolgschancen. Als ich TinyPilot startete, wusste ich nichts über Hardware und nichts über den Verkauf physischer Produkte, und ich machte zahllose Fehler. Aber ich fand ein Produkt, für das Menschen bereit waren zu zahlen, und einen guten Weg, es vor die Kunden zu bringen – deshalb lief das Unternehmen. Es gab Dinge, die ich gut machte, aber im ersten Jahr fühlte es sich überwiegend so an, als wüchsen die Umsätze von selbst und ich versuchte nur hinterherzukommen. Um Product-Market-Fit zu finden, braucht man weiterhin Glück, denn viele plausibel klingende Ideen scheitern. Trotzdem wartet man nicht darauf, dass viele Dinge gleichzeitig glücklich zusammenfallen; man muss nur einmal Glück haben.
Wieder so ein berüchtigter „Warum ich Google verlassen habe“-Text aus dem Jahr 2018.
Und solche Texte beginnen immer damit, zu sagen, dass Google-Ingenieure die klügsten Menschen der Welt seien. Wirklich gehirngewaschene Leute.
Ich denke aus ähnlichen Gründen darüber nach, Google zu verlassen. Ich sitze in Meetings, versuche, notwendige Arbeit auf andere abzuwälzen, und habe kaum Interesse daran, das Spiel mitzuspielen, während es in meinem Projekt Hunderte kleiner Aufgaben gibt, die ich erledigen müsste.
Bei einem Wechsel könnte ich pro Jahr 50.000 bis 100.000 Dollar mehr verdienen. Das nächste Unternehmen wird meine Erfahrung tatsächlich wertschätzen, obwohl diese Erfahrung technisch gesehen für Google viel nützlicher wäre.
Jetzt arbeite ich bei einem kleinen Unternehmen mit fokussierten Projekten schneller und effektiver als in einem 100.000-Personen-Unternehmen, das alles macht, und verdiene dabei auch mehr Geld.
Die Struktur war: „Befördert dich dein Manager nicht?“ „Nein. Google-Manager können ihre Direct Reports nicht befördern. Sie haben nicht einmal ein Stimmrecht. Stattdessen werden Beförderungsentscheidungen von einem kleinen Komitee aus höherstufigen Software Engineers und Managern getroffen, die dich an diesem Tag zum ersten Mal kennenlernen.“
Soweit ich weiß, wurde das nach 2022 wohl so geändert, dass der Manager die einzige Stimme hat.
Die Beförderung geht weiterhin an ein Beförderungskomitee. Nur versucht man inzwischen, das Komitee organisatorisch näher dort anzusiedeln, wo die Kandidaten zumindest schon einmal bekannt sein könnten, und im Meeting Prüfer mit hohem Kontext einzubeziehen, die nicht die Manager sind. Was aus dem früheren System fortbesteht – und was solche Texte oft übersehen –, ist, dass es für jedes Level explizite Erwartungen dazu gibt, welche Tätigkeiten man Personen auf diesem Level zutraut, eigenständig auszuführen. Eine Beförderungsentscheidung ist keine Belohnung dafür, dass jemand die aktuelle Arbeit gut gemacht hat, sondern eine Entscheidung darüber, ob ausreichend gezeigt wurde, dass die Person die Arbeit des nächsten Levels leisten kann. Wenn jemand lange auf einem Level bleibt, liegt das meist daran, dass keine Signale für das nächste Level gezeigt wurden. Natürlich kann es Teams geben, in denen Chancen fehlen, solche Signale zu zeigen, oder Projekte, bei denen die Impact-Bewertung Jahre dauert und die Arbeit erst anerkannt wird, wenn der operative Impact bewertet wurde – das kann sich unfair anfühlen. Trotzdem ist es oft nicht so willkürlich, wie es klingt.
Es ändert sich jedes Jahr, daher würde ich Google 2024 nicht nach meiner persönlichen Erfahrung beurteilen, aber in einem Jahr, in dem ich dort war, wusste mein Manager kaum, wo mein Sitzplatz war. Meine Promotion Packets für L5 und L6 wurden von Peer-Komitees bewertet, und ich weiß nicht einmal, ob sie die Managerbewertung gesehen haben. Auch als ich in einem L5-Beförderungskomitee saß, hatte die Managerbewertung kein großes Gewicht. Damals ergab das Sinn, weil Manager sich aus den Bereichen, die als Gründe für eine L5-Beförderung zählten, sehr stark heraushielten.
Aber das ist kein Mysterium; am Ende liegt die Verantwortung beim Manager, ein starkes Packet zu erstellen, aus dem klar hervorgeht, warum der Kandidat befördert werden sollte. Schon der Beförderungsversuch selbst ist die Stimme des Managers, und danach hängt es davon ab, wie stark er die Beförderung des Kandidaten unterstützt. Ich halte das für die einzige Möglichkeit, Konsistenz zwischen Beförderungen sicherzustellen.