Wird geladen…

Reicht ein hohes Gehalt allein wirklich nicht, wenn der Job dir sichtbare Erfolge verweigert?

senior_slacker
Öffentlich 11 Gespräche 17 Gedanken 82 Zustimmungen 13 stimmen ab 0 Serien 161 Aufrufe

Große Firmen sind strukturell schlecht darin, abgegrenzte, zurechenbare, sichtbare Erfolge zu produzieren. Ein Teil des Gehalts ist die Bezahlung dafür, ohne sie zu leben.

In groups

Diskussionsinhalt

Ich habe das oft genug erlebt, dass das Muster inzwischen klar ist. Ein paar Jahre im Job, gutes Gehalt, Benefits, Impact auf FAANG-Niveau (maango, was auch immer). Du machst gute Arbeit und bekommst Gehaltserhöhungen, aber irgendwas stimmt nicht. Du bist noch nicht ausgebrannt. Aber wenn du auf etwas zeigen und sagen willst „das ist passiert, weil ich das gemacht habe“, hast du nichts, worauf du verweisen kannst. Wenn du deine Familie, deine Freunde triffst und sie fragen, was du machst, bleibt es vage und du kannst es nicht wirklich erklären. Das Projekt hatte achtzehn Stakeholder. Die Entscheidung lief durch vier Freigabe-Ebenen, oft im Kreis, und weiß Gott, wer genau sie beeinflusst hat. Das Ergebnis steht auf einem Dashboard, das du lesen, aber nicht wirklich beeinflussen kannst. Dein Beitrag ist wahrscheinlich real, aber ob er etwas bewirkt hat und wie viel, bleibt ehrlich unklar.

Dieses Gefühl ist kein Charakterproblem, große Firmen lassen alle gleich empfinden. Es liegt nicht an dir allein. Was fehlt, jedenfalls so würde ich es nennen, ist Win-Density. Erfolge, die dir zurechenbar sind, und das häufig. Ein Win ist: 1) abgegrenzt, zurechenbar und sichtbar; 2) er endet und du hast etwas fertig gebracht; 3) du kannst ihn auf das zurückführen, was du getan hast. Du kannst auf die Spur zeigen, die er hinterlassen hat. Große Firmen unterdrücken alle drei auf einmal. Arbeit zieht sich über Quartale. Ownership verteilt sich auf so viele Leute, dass niemand mehr die eigene Kontur darin erkennt. Der Feedback-Loop kommt spät, gefiltert durch Dashboards, Ebenen und Review-Zyklen. So koordinieren große Organisationen Arbeit in diesem Maßstab.

Der Startup-Deal ist das Gegenteil. Niedrigeres Gehalt, höhere Win-Density. Du bringst jeden Tag etwas fertig, und das macht süchtig. Das Problem ist, dass Startups oft scheitern und du am Ende ausbrennst, mit wenig Erspartem.

Mentale Gesundheit

Was niedrige Win-Density mit Leuten macht, ist nicht dramatisch, es bringt dich nicht dazu, türenknallend rauszugehen, oft gewöhnst du dich einfach daran. Aber es macht dich erpicht darauf, etwas fertig zu bringen, etwas Neues. Engineers fangen an, zu overengineeren, weil ausgedachte Milestones besser sind als gar keine. Wenn die Arbeit dir keine saubere Ziellinie gibt, erfindest du eine: noch ein Refactor, noch ein Re-Architecture-Doc für einen Service, der einwandfrei läuft, ein Cleanup-Projekt, das vor allem existiert, weil man es abschließen kann, irgendeine neue Lösung fürs Testing... Andere werden einfach grau und sterben innerlich. Sie machen genau das, was man ihnen sagt. Sie tauchen immer noch auf. Sie wirken im Status-Meeting immer noch in Ordnung. Aber ein Teil des Gehalts fängt an, sich wie Bezahlung dafür anzufühlen, die Arbeit nicht landen zu sehen.

null
Manchmal fühlt es sich an, als zahle die Firma die Leute nur, damit sie nicht weggehen und woanders wirklich etwas fertig bringen...

Das ist überwiegend eine White-Collar-Klage. Viele Leute haben niedrige Bezahlung UND niedrige Win-Density. Hier geht es um die White-Collar-Variante des Deals. Ja, oft sind unsere Gehälter top und die Lebensqualität ist top. Aber wir verbringen nun mal 8+ Stunden am Tag bei der Arbeit, oft mehr. Und wir müssen das mit der Art zusammenbringen, wie unser Antrieb und unser Kopf funktionieren. Ja, die Arbeit ist bequem und oft werden wir gut bezahlt. Und ja, du kannst White-Collar-Jobs extrem angenehm und erfreulich machen. Mein Punkt ist, dass es dafür Win-Density braucht. Du brauchst Erfolge, die deine eigenen sind, und das häufig, damit es sich nach Gewinnen anfühlt.

An die Manager

Genau deshalb betrifft das Problem auch die Manager, selbst wenn sie das zugrundeliegende Skalierungsproblem nicht vollständig lösen können. Manche Arbeit ist von Natur aus langsam, nicht alles lässt sich in einem Ein-Wochen-Loop shippen. Aber Teams laufen besser, wenn Arbeit abschließt, die Zurechnung echt ist und Leute trotzdem sehen können, was sich durch sie bewegt hat. Trotzdem spüren können, dass es ihnen von Anfang bis Ende gehört hat und sie es fertig gebracht haben. Höhere Shipping-Frequenz korreliert oft mit besserer organisatorischer Leistung und stärkerem Engagement Der praktische Punkt ist einfacher als das Forschungsargument: wenn niemand sagen kann, was fertig wurde, wem es gehörte oder was sich verändert hat, dann gerinnt Ehrgeiz langsam zu Wartung.

Du musst die Leute nicht mehr bezahlen, um sie glücklicher zu machen (wtf, was hab ich da gerade gesagt???). Oft musst du den Job einfach „gamifizieren“. Gib deinen Engineers oft und häufig Dopamin-Schübe. Manche nehmen diesen Deal bewusst in Kauf. Ich habe ihn früher bewusst in Kauf genommen. Aber im Idealfall gib ihnen auch Geld.

  1. Die State-of-DevOps-Literatur von DORA findet durchgängig, dass höhere Deployment-Frequenz mit stärkerer organisatorischer Leistung und oft mit höherem Engagement korreliert, auch wenn die kausale Richtung umstritten bleibt.

Thoughts

  • release_woche

    Ich seh den Punkt, aber der Post tut so, als wäre niedrige Win-Density vor allem ein Koordinationsproblem. Bei mir ist es ein Prestige-Problem. Die Arbeit, die einen Launch rettet, die geflickte Pipeline, der Rollback um Mitternacht, taucht in keinem Dashboard auf, das jemand liest. Sichtbare Feature-Arbeit kriegt den Win zugeschrieben, der Rest wird als selbstverständlich verbucht. Mehr Shipping-Frequenz löst das nicht, solange ihr die falsche Hälfte der Arbeit feiert.

    Permalink
  • technische_schuld

    Win-Density ist ein hübscher Name für etwas, das ich operativ jeden Tag sehe. Was dir in großen Firmen die Zurechnung klaut, ist meistens nicht die Größe an sich, sondern wie viele Hände eine Entscheidung anfassen, bevor sie deployt wird. Wenn fünf Leute ein Design Doc abgenickt haben, gehört der Outage hinterher allen und keinem, und der Fix steht trotzdem auf deinem Pager. Genau die Asymmetrie meinst du: das Risiko bleibt zurechenbar, der Win nicht.

    Permalink
  • ewiges_onboarding

    Der Absatz über die erfundenen Milestones hat mich erwischt. Ich arbeite mich seit zwei Reorgs in einen Stack ein, der vor der nächsten Reorg abgekündigt wird, und ja, irgendwann schreibst du dir ein Re-Architecture-Doc für einen Service, der einwandfrei läuft, nur um eine Ziellinie zu haben. Ich kenne den Nachfüllplan vom Cold Brew im vierten Stock auswendig. Was mein Team diesen Sprint liefert, müsste ich raten.

    Permalink
  • der_fahrplan

    Beim Manager-Teil bin ich halb dabei. Die Diagnose stimmt, der Rat verkürzt. Aus der Product-Sicht sehe ich drei verschiedene Hebel, die der Post zu „gamifizieren" zusammenzieht:

    • Scope kleiner schneiden, damit Arbeit überhaupt abschließt statt über Quartale zu zerlaufen

    • Ownership benennen, bevor das Projekt achtzehn Stakeholder hat, nicht hinterher

    • den Feedback-Loop kürzen, der bei euch durch Dashboards und Review-Ebenen läuft

    Gamification klebt nur ein Dopamin-Pflaster auf das dritte und ignoriert die ersten beiden.

    Permalink
  • schaufenster_buero

    „Gib deinen Engineers oft und häufig Dopamin-Schübe." Wir hatten so ein Programm. Es hieß Spot Award, war ein digitales Abzeichen, und es kam freitags um 17:30. Du beschreibst keinen Win, du beschreibst eine Weihnachtsfeier, die niemand wollte, mit Konfetti aus einem Dashboard.

    Permalink
  • unsichtbare_arbeit

    Was im Post fehlt: Win-Density ist im selben Team sehr ungleich verteilt. Im Frontend lande ich ständig auf der Arbeit, die alle für Politur halten, gerade dort, wo die Product-Ambiguität sichtbar wird. Mein „Win" ist dann, dass ein Edge Case keinen Support-Sturm auslöst, also ein Nicht-Ereignis, das sich schlecht zurechnen lässt. Manche Leute sitzen strukturell auf abgegrenzten Wins, andere räumen das auf, was an keiner Ziellinie endet.

    Permalink

Related discussions

  • Lässt sich mit KI kaum noch unterscheiden, wer wirklich gut programmiert und wer nur Lärm macht?

    Ich höre dasselbe Feedback in immer neuen Formen: „starke Velocity“, „toller Throughput“, „schöner Einsatz von KI“. Von außen sieht es wirklich so aus, als würde mehr passieren: mehr Code Reviews, mehr angefasste Tickets, mehr Updates, mehr E-Mails, mehr Tasks, mehr Designs. Mit KI lässt sich diese Schlagzahl mühelos halten, ohne die übliche Reibung des Schreibens, des Denkens oder auch nur des Zögerns. Aber mitten in der Arbeit steckt ein Dilemma, das immer größer wird.

  • Glauben Tech-Konzerne, sie profitieren von Beschäftigten, die nicht kündigen können?

    Ich bin lange genug durch Tech-Unternehmen gewandert, um ein Muster zu erkennen, das viele von euch genauso kennen werden. Manche Teams sind passiv, sie liefern pünktlich, treffen ihre Ziele, fahren saubere Prozesse, und trotzdem killt nie jemand eine schlechte Idee im Meeting. Niemand sagt, dass man hier das Falsche baut. Auf der Roadmap steht eine Sache, oder sechs, von denen drei Leute hinter vorgehaltener Hand reden, dass sie nicht funktionieren wird, aber sie zieht ohne ein Wort durch die P

  • Leute, die zusammen essen, kämpfen zusammen

    Starke Gruppen werden nicht nur stark, weil sie sich auf eine Mission einigen. Sie werden stark, weil die Leute aufhören, einander abstrakt zu erscheinen, weil sie sich als Menschen und als Freunde sehen. Das ist ein Grund, warum gemeinsame Mahlzeiten mehr ausmachen als die meisten offiziellen Kulturprogramme. Du brauchst keine teuren Workshops und Offsites, um eine Team-Kultur aufzubauen. Du musst nur da sein. Iss mit deinem Team zu Mittag, sorg dafür, dass sie zusammen essen. Trinkt zusammen K

  • Sind deine 0,05 Prozent und das Wort Familie etwa ein Gehalt?

    Der Startup-Typ wird dir erzählen, er sei im Grunde Mitgründer. Er hat 0,05 Prozent. Der Gründer hat das im Offer-Call so beschrieben: „könnte eines Tages Millionen wert sein", im warmen Ton eines Mannes, der die Cap Table persönlich gelesen hat und genau weiß, dass nach drei weiteren Runden und einer 1,5-fachen Liquidationspräferenz 0,05 Prozent vom Exit gerade für einen gebrauchten Subaru reichen, falls der Exit überhaupt kommt, was er nicht tun wird. Er setzt darauf, dass du nicht nachrechnes

  • Sucht sich Oracle wirklich keiner aus – und ist Oracle das recht?

    Oracle ist die Kakerlake der Enterprise-IT, von allen gehasst, von allen benutzt und bemannt von Leuten, die schon zur Clinton-Ära aufgehört haben so zu tun, als wäre das cool. Das Produkt ist der Vertrieb, und die Datenbank ist die Geisel.

  • Regt man sich über Konzern-Bullshit nur auf, weil man die Anreize dahinter nicht verstanden hat?

    Irgendwo in deiner Firma liegt ein Status-Deck, das niemand liest. Es wird alle paar Wochen aktualisiert, in einem Meeting gezeigt und wieder vergessen. Dein Chef weiß das auch. Er hat dieselben Decks auf dem Weg nach oben gebaut und versteht genau, wie wenig Gedanken da normalerweise drinstecken. Die übliche Erklärung für Konzern-Beschäftigungstherapie ist, dass irgendjemand weiter oben verwirrt ist oder den Bezug zur Realität verloren hat. Das ist tröstlich, aber meistens falsch. Diese Artefak

  • Der Apple-Mitarbeiter hat wegen eines Handys ein Schweigegelübde abgelegt

    Apple baut das beste Handy der Welt. Das soll zu Protokoll, bevor ich anfange, denn alles andere, was ich gleich sage, wird von Leuten bestritten, die rechtlich nicht einmal bestätigen dürfen, welche Farbe ihr Gebäude hat. Die Hardware ist tatsächlich die beste der Branche, die Verarbeitung ist richtig gut, und die Art, wie Watch, Laptop, Handy und Earbuds miteinander reden, hat keine andere Firma je zweimal hinbekommen. Nichts davon ist umstritten, ich bin selbst Apple-Fanboy, nachdem ich als s

  • Trägt der Amazon-Mitarbeiter seinen Verschleiß wie eine Auszeichnung?

    Amazon ist die effektivste Maschine der Tech-Branche, und seine Leute haben irgendwie beschlossen, dass Brennstoff zu sein dasselbe ist wie der Motor. Die Leadership Principles werden zitiert wie die Heilige Schrift in einem Gebäude, das brennt, und die Median-Verweildauer von achtzehn Monaten trägt man wie einen Einsatz-Patch.