Was es in Big-Tech-Unternehmen wirklich bedeutet, „fertig“ zu sein

• In Big Tech bedeutet Arbeit wirklich abzuschließen, sie in einem System, das sich unendlich weiter verbessern ließe, bis zu einem Punkt zu bringen, an dem das Unternehmen zufrieden ist, und dann weiterzuziehen
• Fähige, aber wenig initiative Ingenieur:innen wiederholen immer weiter kleine Verbesserungen und verpassen dabei echte Resultate
• Nur wenn man den Entscheidungsträgern sichtbare, eindeutige Ergebnisse liefert, wird anerkannt, dass man „Arbeit geleistet“ hat
• Man sollte immer prüfen, ob die eigene Arbeit in einer Form vorliegt, die von höheren Führungskräften gelesen und bewertet werden kann
• Nicht alles lässt sich vollständig aufräumen; ab einem gewissen Punkt wird die Fähigkeit, „den Sieg zu erklären und zu gehen“, zur Kernkompetenz

---

„Arbeit“ hat Eigenschaften, die keinen endgültigen Abschluss zulassen

• Anders als Mathematikaufgaben oder Schulaufgaben ist Arbeit in der realen Welt ein offenes System, das sich unendlich verbessern lässt
• Die Entwicklung eines Services ist wie das Pflanzen eines Baums: ein Prozess, der auch danach laufende Pflege erfordert

Der fähige Ingenieur in der Falle

• Ingenieur:innen, die alles selbst schultern und nur kleine, fortlaufende Verbesserungen wiederholen, haben zwar das Gefühl, Leistung zu bringen,
• aus Sicht des höheren Managements wird jedoch entschieden, dass keine „sichtbare Wertschöpfung für das Unternehmen“ entstanden ist
• Dadurch kann man letztlich als beschäftigte Person ohne Ergebnisse missverstanden werden

Was „abschließen“ tatsächlich bedeutet

• Die Arbeit bis zu dem Punkt bringen, an dem das Unternehmen (die Entscheidungsträger) zufrieden ist, und dann zum Nächsten übergehen
• Statt immer weiter zu refaktorieren oder kleine Verbesserungen zu wiederholen, sollte man eine klare Liste von Ergebnissen schaffen
• Wichtig ist die Entschlossenheit, „fertig“ zu erklären und zur nächsten Aufgabe überzugehen

Die „Lesbarkeit“ von Arbeit sicherstellen

• Projekte, die Manager bereits kennen oder angefordert haben, sowie die Reaktion auf große Zwischenfälle, haben eine hohe Lesbarkeit
• Grundsätzlich ist die meiste technische Arbeit für Manager jedoch nur technisches Rauschen, das sich schwer beurteilen lässt
• Deshalb muss man Ergebnisse in eine sichtbare Form bringen oder finanzielle Effekte hervorheben und die Arbeit so aufbereiten, dass sie gelesen werden kann

„Abschließen“ als soziales Konzept

• Philosophisch gesehen ist auch der Begriff „fertig“ ein soziales Konstrukt, in der Realität besitzt er jedoch sehr konkrete Macht
• Wer das ignoriert, wird nicht bewertet und kann am Ende sogar entlassen werden

Zusammenfassung

• Nur weil man arbeitet, ist etwas noch nicht abgeschlossen
• Die meisten Aufgaben können nicht wirklich abgeschlossen werden und lassen sich immer weiter fortsetzen
• Man sollte kein Gärtner, sondern ein ergebnisorientierter Taktiker sein
• Der Maßstab für „fertig“ ist die Zufriedenheit des Unternehmens bzw. der Manager
• „Sieg erklären → gehen → zur nächsten Aufgabe“ ist die Kernstrategie

[aer0700]

Es scheint auch eine wichtige Fähigkeit zu sein, sich Aufgaben auszusuchen, bei denen man den Sieg erklären kann.

[elbanic]

Das Begrenzen des Umfangs nennt man Scoping. Die Fähigkeit besteht darin, gut zu scopen, damit man gewinnen kann.

[bakyeono]

Hanshin vs. Soha

[doolayer]

Nicht Details, sondern quantifizierbare, sichtbare Ergebnisse

[GN⁺]

Hacker-News-Kommentare

• Ich widerspreche der Aussage dieses Beitrags nicht vollständig, aber nach meiner Erfahrung in Big Tech sowie in verschiedenen Startups und Unicorn-Unternehmen fühlt sich das nicht wie besonders praxisnaher Rat an. In den letzten zehn Jahren ist die Arbeit von Entwicklern so stark spezialisiert worden, dass sie von den Bedürfnissen der Entscheidungsträger und Kunden entkoppelt ist. Dieses Phänomen entsteht dadurch, dass Product Manager zwischen den Ingenieuren und dem Rest des Unternehmens stehen. Ich will immer wertvolle Ergebnisse liefern, aber um das tatsächlich zu tun, muss man ständigen Stress in Kauf nehmen. Mein Beitrag wird zwangsläufig durch das Ego der Person gefiltert und angepasst, die mit den Entscheidungsträgern spricht. In den letzten fünf Jahren habe ich nur einmal echte Erfüllung gespürt, als ich neun Monate lang vorübergehend die Rolle eines Product Managers übernommen habe. In dieser Zeit hat unser Team drei Projekte erfolgreich abgeschlossen, an denen andere Teams zuvor mehrfach gescheitert waren. Das Geheimnis war, direkt mit den Stakeholdern zu sprechen und ihre Bedürfnisse zu verstehen, nicht zu versuchen, es auf meine eigene Weise zu lösen. Deshalb werde ich wohl auch künftig einfach nur das liefern, was verlangt wird, für Bugs kritisiert werden und keine Anerkennung für Features bekommen. Immerhin ist die Bezahlung okay. Ich suche weiterhin nach einem Ort, an dem ich wirklich sinnvoll beitragen kann

  • Dieser Teil mit der „Bezahlung ist okay“ ist mir besonders im Gedächtnis geblieben. Ich habe für mich die Ansicht entwickelt, dass auch ein Zustand des „Stillstands“ in Big Tech gar nicht so schlecht ist. Wenn man zum Beispiel bei Google oder Microsoft 300.000 Dollar im Jahr verdient und zehn Jahre lang am selben langweiligen Projekt arbeitet, wird diese Erfahrung trotzdem überall anerkannt. Für ambitionierte Leute wie mein früheres Ich mag das frustrierend sein, aber mit so einer Veranlagung würde man wohl ohnehin in ein kleineres Unternehmen wechseln wollen. Mit dem Alter verlagert sich der Fokus von der Firma hin zu Familie und Freunden. Wenn mir jemand sagen würde, dass ich keine Beförderung mehr bekomme, würde ich nur sagen: „Na und?“ Ich verdiene genug für meine Familie und achte auf meine Work-Life-Balance. Ehrlich gesagt ist das Beste an einem Unternehmen das Gehalt und dass dadurch der Rest des Lebens besser wird
  • Ich habe erlebt, dass die Rolle des Product Managers in der Realität ganz anders aussieht als in idealisierten Beschreibungen: Man steckt in der Mitte fest und repräsentiert oft keine der beiden Seiten wirklich gut. Dadurch habe ich angefangen, selbst Produktmanagement-Fähigkeiten aufzubauen, und diese Skills sind äußerst nützlich, um verschwendete Arbeit zu vermeiden. Deshalb frage ich mich, ob Product Management für einen großen Engineer nicht ebenfalls eine Kernkompetenz sein sollte
  • Ein weiterer Punkt ist, dass dieser Weg in der aktuellen Form direkt in den Burnout führt
  • Mir ist klar geworden, dass Kommunikation in jeder Organisation das wichtigste Skillset ist. Neun Monate in einer Übergangsrolle reichen nicht aus, um ihren ganzen Wert zu erfassen. Der Beitrag liest sich, wie bei vielen anderen Engineers auch, als sei jemand so genervt, dass er glaubt, klüger zu sein als die anderen Leute in der Organisation. Das stimmt oft nicht, und diese Denkweise schadet der Zusammenarbeit
  • Hinter jeder gut funktionierenden Webanwendung steht immer jemand, der wie ein Gärtner arbeitet
  • Ich frage mich, warum du nicht Product Manager geblieben bist
  • Das variiert extrem von Firma zu Firma. Es gibt viele Orte, an denen Engineers mehr Einfluss haben. Selbst in Big Tech gibt es Fälle, in denen man nicht von den Kunden getrennt ist
  • Heißt das, Product Manager sollten entlassen werden?
  • Ich habe selbst als Product Manager gearbeitet, also genau in dieser vermittelnden Rolle zwischen Engineers und Unternehmen, und auch mein eigener Beitrag wurde durch mein Ego gefiltert. So wie du es beschreibst, klingt das allerdings trotzdem ziemlich erfüllend … war offenbar ein recht befriedigender Job

• Ich habe grundsätzliche Einwände gegen die Vorstellung, Erfolg nur daran zu messen, ob man die Mächtigen zufriedenstellt. Wir stecken zwar in lächerlichen Statushierarchien fest, aber ich glaube nicht, dass es am Ende nur darum geht, ein Jira-Ticket auf „Done“ zu setzen oder Compiler-Warnungen zu beseitigen. Niemand sagt später: „Ich bereue nichts, ich habe 40 Jahre lang immer nur meinen Chef zufriedengestellt“

  • Ich arbeite seit 30 von diesen 40 Jahren, und es hatte durchaus einen Wert, meinen Chef und dessen Chef zufriedenzustellen. Eine zynische Sichtweise ist zwar nicht das ganze Leben, aber diese zynische Perspektive zu kennen, bedeutet, der Wahrheit näher zu kommen
  • Eigentlich ist „den Chef und den Chef des Chefs zufriedenzustellen“ die Definition von Beschäftigung. Man macht, was einem gesagt wird, und bekommt dafür Geld

• Insgesamt stimme ich zu, aber ich würde noch ergänzen, dass man das Geschäftsmodell des Unternehmens verstehen muss, wenn man verstehen will, was der Manager möchte. Man muss selbst herausfinden, wie das Unternehmen Geld verdient und was es als wertvoll betrachtet. Wenn man an einem Ort arbeitet, dessen Werte mit den eigenen übereinstimmen, sind Bezahlung und Zufriedenheit höher. Es ist wichtig, direkt mit Kunden, Vertrieb, Marketing und möglichst auch mit dem Management zu sprechen. Selbst wenn man nur an internen Systemen arbeitet, ist entscheidend zu wissen, wo dieses System Wert schafft oder Schutz bietet. Wenn die eigene Abteilung keinen klaren Wert erzeugt, sollte man über einen Wechsel in ein wertschaffendes Team nachdenken. An Dingen zu arbeiten, die nicht zu den Bedürfnissen des Unternehmens passen, war immer ein großer Fehler

  • Ich finde, man kann sich ruhig als Handwerker sehen. Entwicklung bedeutet, die Spezifikation umzusetzen, aber wenn diese Spezifikation unsinnig oder unmöglich ist, muss man das Problem direkt ansprechen. Wenn die Business-Seite ihre Arbeit nicht klar erklären kann, dann versteht sie sie selbst nicht. Und wenn Entwickler wirklich auch noch das Business tief verstehen sollen, dann muss das entsprechend vergütet werden. In derselben Zeit könnte man sich technisch weiterentwickeln; es gibt also Opportunitätskosten
  • Oft ist schon die Annahme falsch, dass ein Manager das Business tatsächlich versteht und Rücksicht darauf nimmt

• Der Autor schrieb, es sei notwendig, Ergebnisse zu liefern, die für Entscheidungsträger sichtbar sind, und ich kann mich mit diesem „Business“-Mindset identifizieren. Viele Entwickler tun sich schwer damit zu erklären, welchen geschäftlichen Nutzen ihre Arbeit hat. Das gilt auch für Refactoring. Codeverbesserungen können kurzfristig völlig bedeutungslos wirken, unter bestimmten Umständen aber enorme Vorteile für die Organisation schaffen. Im Kern geht es darum, die eigene Arbeit mit Umsatz oder Einsparungen der Organisation zu verknüpfen und einen Weg zu finden, das zu kommunizieren

  • Entwickler müssen die Sprache des Business lernen und Probleme so framen, dass Business-Leute sie verstehen und wichtig finden. Die meisten Geschäftsentscheidungen laufen letztlich auf Kosten versus Nutzen hinaus. Tatsächlich behandeln viele Geschäftsleute Software selbst nur als Kostenfaktor. Anders als die für Entwickler selbstverständliche Sicht „Wie kann Software nicht im Zentrum der Wertschöpfung stehen?“ interessiert sich das Business nicht für Software an sich. Wenn man kostenlos verkaufen könnte, wären alle Kosten null und die Marge unendlich — so denken Business-Leute im Kern. Vertrieb ist ein Bereich, in dem Abschlüsse eher über Stimmung, Beziehungen oder sogar Bestechung zustande kommen als über Rationalität. Das klingt irrational, aber man muss es verstehen

• Ich frage mich, ob diese Haltung der Grund ist, warum sich viele Engineers nicht um Codequalität, Tests und Dokumentation kümmern. Wenn man nur auf die sofortige Zufriedenheit der höheren Ebenen achtet, warum sollte sich dann jemand Mühe geben, langfristig wartbaren Code zu schreiben? Man braucht vielleicht keine Qualität über Spezifikation hinaus, aber schon minimale Investitionen können Milliarden sparen

  • Immer mehr Menschen legen keinen Wert mehr auf Handwerk und Qualität. Man hört ständig: „Ich arbeite nur so viel, wie ich bezahlt werde.“ Früher gab es stärker das Gefühl, dass man seine Arbeit unabhängig vom Gehalt sorgfältig machen sollte; das scheint weitgehend verloren gegangen zu sein
  • Jeder übernimmt seine Rolle aus einem bestimmten Grund. Wie am Filmset können auch Engineers unterschiedliche Ziele haben. Wenn man Engineers daran hindert, ihre Leidenschaft einzubringen, bleiben am Ende nur Menschen, die sich allein vom Geld leiten lassen. Das ist riskant
  • Ich glaube nicht, dass jemand absichtlich schlechten Code schreibt. Gleichgültigkeit oder Burnout entstehen in Umgebungen, in denen zusätzliche Anstrengung wiederholt nicht belohnt wird, und dann investiert niemand mehr mehr Aufwand. Außerdem sind viele Entwickler schlicht nicht besonders gut. Es ist kein hochselektiver Beruf wie etwa Versicherungsmathematik; praktisch jeder kann einsteigen, und schon deshalb ist es schwer, von Anfang an wirklich kompetent zu sein
  • Viele Product Manager wollen nur Geschwindigkeit. Wir wollen Tests und Dokumentation, aber CFOs halten solche Zusatzarbeiten oft für unnötig, weil sie „keine Features“ sind
  • Engineers gehen nicht davon aus, lange genug im Unternehmen zu bleiben, um später Verantwortung für die Zukunft tragen zu müssen. Wenn man ständig den Job wechselt, erlebt man die Probleme des Codes, den man im vorherigen Unternehmen geschrieben hat, nie selbst und lernt daher auch nicht aus dem Scheitern. Ich bin seit fast 20 Jahren in derselben Firma und habe die gleichen Fehler immer wieder gesehen. Ich bin auch müde von Veränderungen, die nur die Oberfläche ändern und das eigentliche Problem unangetastet lassen. Veränderung hat keinen Sinn, wenn sie nicht das echte Problem behebt. Mir geht es darum, echte Probleme zu lösen

• Ich habe diese Realität und diese Probleme oft genug erlebt und verstehe sie, widerspreche aber trotzdem. Viele Projekte werden gestartet, dann heißt es „gelöst, done!“, und das Team wird aufgelöst. Aber im Produkt bleiben weiterhin Probleme, neue Funktionen werden nötig, und das Unternehmen verändert sich ständig. Am Ende häufen sich durch schlechte Pflege nur technische Schulden an. Dann kommt ein neuer Manager, startet das alte Projekt neu und wiederholt dieselben Fehler. Diese Arbeitsweise ist ineffizient. Um es mit einer Klimaanlagen-Analogie zu sagen: Es ist effizienter, die Temperatur konstant zu halten, als die Anlage immer wieder auszuschalten und danach erneut herunterzukühlen. Ein Management-Tool, das ich gebaut habe, interessierte die Führungsebene nicht, aber intern brauchten es über 500 Nutzer. Wichtig war, mit geringem Wartungsaufwand dauerhaft Vertrauen zu erhalten. Wenn man es vernachlässigt, zerfällt alles und die Zuverlässigkeit des Tools geht verloren. Schon ein paar Minuten Aufwand hätten gereicht, um die Konsistenz zu bewahren

  • Die Klimaanlagen-Analogie ist thermodynamisch gesehen tatsächlich falsch. Ausschalten und später erneut herunterkühlen ist effizienter

• Ich habe gemischte Gefühle. Für Sichtbarkeit und Beförderung stimmt der Beitrag sicher, aber in der Praxis ist es sehr managerzentrierter Rat: Hauptsache, der Vorgesetzte ist zufrieden. Was aber, wenn es keine klare Richtung gibt und sich die Prioritäten ständig ändern? Dann ist es schwer, überhaupt sinnvolle Ergebnisse zu liefern, und die Beziehung zwischen Manager und Mitarbeiter wird zu einer reinen „Yes-Man“-Struktur. Das ist kein gutes Ergebnis

  • Die Antwort ist einfach. Wenn du das Gefühl hast, unter einem dummen Chef zu arbeiten, kündige einfach. Der Schmerz ist vorübergehend, am Ende wird es besser. Das ist viel besser, als Zeit damit zu verschwenden, einem Idioten deine Arbeit zu erklären
  • Umgekehrt kann man mit einem wirklich guten Manager allein dadurch, dass man „den Manager zufriedenstellt“, sowohl in der Karriere als auch bei den Ergebnissen sehr schnell wachsen

• „unagentic engineer“ bedeutet ein Engineer ohne Eigeninitiative. Wenn ein Engineer auf diese Weise arbeitet, kann das zu Ineffizienz und ernsthaften Problemen führen, etwa zu überhöhten Cloud-Kosten, Sicherheitsvorfällen oder unzufriedenen Kunden. Beispiele für nie endende Arbeit sind Sicherheits-Patches, das Beheben von Fehlern, Kostenoptimierung und die Reaktion auf Kundenfeedback. Wenn ein Unternehmen diesen Wert nicht versteht, sollte man wechseln

  • Genau darum geht es in dem Beitrag. Manche Organisationen sind realitätsorientiert, andere statusorientiert. Realitätsorientierte Organisationen handeln langfristig rational, während statusorientierte Organisationen nur darauf aus sind, den Chef zufriedenzustellen. Dort zählt Hierarchie mehr als Produktqualität oder Kundenbeziehungen. Solche Organisationen müssen nicht zwangsläufig scheitern, können aber irgendwann abrupt zusammenbrechen
  • „Unagentic“ bezeichnet jemanden ohne agency, also einen Mitarbeiter ohne Eigeninitiative. Man wünscht sich, dass er selbstständig handelt, doch in der Praxis ist es eher eine Falle, in der die eigene Existenz als Entwickler unsichtbar wird
  • Es muss nicht zwangsläufig so sein, aber wenn sich die Führungsebene nicht kümmert, setzt sich diese Kultur standardmäßig durch. Ich zum Beispiel beschäftige mich gern mit den Details von Interface-Design. Aber solche Sorgfalt wird nur dann belohnt, wenn die Organisation darin auch einen Wert sieht. An vielen Orten interessiert das niemanden
  • Mit „unagentic engineer“ ist ein Typ gemeint, dem die Fähigkeit fehlt, eigenständig Entscheidungen zu treffen und Dinge aktiv voranzutreiben, der sich also einfach treiben lässt
  • Gemeint ist ein nicht eigenständiger Engineer, also jemand mit wenig Entscheidungsspielraum
  • Das Gegenteil von „high agency“: jemand, der klug und kompetent wirken mag, aber immer auf Anweisungen wartet und nie selbst die Initiative ergreift

• Ich hasse Buzzwords wie „Alignment“ zutiefst. Trotzdem ist es im Kern ein wichtiges Konzept. Idealerweise sollten ich, mein Manager und sogar das Management darüber übereinstimmen, welche Arbeit am wichtigsten ist. Wenn das nicht der Fall ist, ist das aus Sicht eines Mitglieds der Organisation ein Problem. Ob das richtig oder fair ist, spielt dabei keine Rolle; wir leben nun einmal danach. Letztlich werden wir dafür bezahlt, das zu tun, was von oben angeordnet wird. Nur sehr wenige genießen das Privileg, nach oben Einfluss auszuüben. Genau das ist das sogenannte „managing up“

• Der Originalbeitrag ist nützlich, aber mir scheinen wichtigere Kernpunkte zu fehlen:

  • Im richtigen Team zu arbeiten ist wichtiger, als an den richtigen Dingen zu arbeiten
  • Ein guter PM und ein guter Manager sind wichtiger als gute Arbeit
  • Eine gute Reporting-Struktur ist wichtiger als der Wert der Ergebnisse
  • Arbeit, die zu den Zielen der Führung passt, wird viel höher bewertet als tatsächliche Unterstützung des laufenden Geschäfts
  • Man muss immer bereit sein, alles selbst zu machen, und in der Politik großer Unternehmen gibt es ständig Fehlanreize gegen Zusammenarbeit

[heal9179]

Diese Meinungen treffen eher den Kern.

[roxie]

Stimmt schon, haha