- Der Alltag und die Karrierewege von Engineers hängen stark davon ab, aus welchem Budget ihr Gehalt kommt: Sales/Marketing, Forschung und Entwicklung oder Wartung
- Engineering aus dem Sales-/Marketing-Budget ist nah am Geld und leicht messbar, kann aber zu Stack Ranking und einer Kultur internen Wettbewerbs führen
- Das F&E-Budget beschäftigt unter Produktorganisationen die meisten Engineers und priorisiert langfristigen Wert und Vermögensaufbau über mehr als ein Quartal statt kurzfristiger Experimente
- Das Wartungsbudget wird als Ziel für Kostenoptimierung behandelt; sysadmins, der Betrieb alter Systeme, Teile des Platform Engineering und interne Tool-Arbeit können darunterfallen
- Wer weiß, zu welchem Budget die eigene Arbeit gehört, kann häufige Wechsel in Growth-Aufgaben, langfristige Investitionen in F&E und die niedrige Priorität von Wartung in Karriereentscheidungen einbeziehen
Drei Budgets teilen Engineering-Arbeit auf
- Software-Engineering-Gehälter stammen grob aus einem von drei Budgets
- Sales/Marketing
- Forschung und Entwicklung
- Wartung
- Die Art des Budgets beeinflusst die alltägliche Arbeitsweise und die Karriereausrichtung von Engineers
- Diese Einteilung kann nützlich sein, wenn man über Karrierevision oder Positionierung nachdenkt
Sales-/Marketing-Budget: messbare Sofortergebnisse
- Engineering in Growth-Organisationen lässt sich leicht quantifizieren
- Die Struktur, bei der bestimmte Arbeit Kennzahlen steigen lässt, ist vergleichsweise klar
- In diese Kategorie fallen Rollen wie Growth Engineer, Sales Engineer und DevRel
- Sie sorgen dafür, dass bestehende Produkte sich besser verkaufen
- machen Menschen auf Funktionen aufmerksam
- und helfen Käufern, Tools in ihre Arbeitsabläufe zu übernehmen
- Was das Unternehmen erwartet, ist sofortiger Impact
- Der Vorteil ist, dass sich der Return on Investment leicht erkennen lässt und die Arbeit direkt mit Umsatz verbunden ist
- Weil die Messung leicht ist, wird auch der Vergleich zwischen Personen einfacher
- Zwischen Mitarbeitenden kann Stack Ranking entstehen
- Statt einer Kultur, in der man gemeinsam Probleme löst, kann eine Kultur internen Wettbewerbs stärker werden
- Der Arbeitsrhythmus ist meist kurzfristig orientiert
- das nächste Experiment
- der nächste Kunde
- der nächste Marketingtrend
- Das Unternehmen bewertet den Wert anhand des Multiplikators, den das Geld in diesem Budget erzeugt; im Streben nach Optimierung kann dabei ein Drehtüreffekt entstehen
F&E-Budget: Vermögenswerte, die mit der Zeit wachsen
- Forschung und Entwicklung, also R&D, ist der Bereich, der die meisten Engineers beschäftigt
- Üblicherweise ist er unter der Produktorganisation angesiedelt
- In größeren Unternehmen kann es echte Forschungs- oder Wissenschaftsorganisationen geben
- In diese Kategorie fallen Rollen wie Product Engineer, Researcher und Architect
- Sie bauen, was das Unternehmen verkauft
- oder erkunden Dinge, die das Unternehmen verkaufen könnte, wenn sie gut funktionieren
- Was das Unternehmen erwartet, ist Wachstum über die Zeit
- Das Umfeld ist vergleichsweise ruhiger
- Es achtet auf die Balance zwischen der Bindung bestehender Nutzer und Funktionen, die neue Nutzer anziehen
- Es kann sich in Richtung Growth neigen, indem Funktionen gebaut werden, die nach der Registrierung zur tatsächlichen Nutzung führen
- Manchmal neigt es sich auch in Richtung Forschung, wenn neue Produktlinien erkundet werden
- In Unternehmen mit einer echten Forschungsabteilung gibt es auch Menschen, die an Ideen arbeiten, die erst in einigen Jahren produktisiert werden
- Forschung und Entwicklung sind im Grunde zwei unterschiedliche Budgets, die in einer Kategorie zusammengefasst sind
- Entwicklung und Forschung sind verschieden
- Gemeinsam ist ihnen aber der Fokus auf langfristige Ergebnisse
- Der kürzeste relevante Zeitraum ist ein Quartal
- Die Arbeit von Engineers ist darauf ausgelegt, zu einem Vermögenswert zu werden, der über die nächsten Jahre Wert liefert
- Kürzere Experimente sind Trittsteine auf diesem Weg
- Die Erfolgsmessung ist schwierig, aber das Unternehmen betrachtet diese Arbeit als Investition
- Die Annahme ist: Je besser das Produkt wird, desto besser werden auch Verkauf und Retention
Wartungsbudget: Kosten, die man senken möchte
- Wartung ist im Allgemeinen in Entwicklungsarbeit aufgegangen
- Was dieses Budget will, ist Kostenoptimierung
- sysadmins, Menschen, die alte Systeme weiter betreiben, und manchmal Platform Engineers fallen in diese Kategorie
- Das Unternehmen betrachtet diese Arbeit als reine Kosten und versucht, sie zu minimieren
- In vielen Unternehmen sind Wartungsrollen in die Produktentwicklung hineindiffundiert
- Es ist Arbeit, die nicht hoch bewertet wird
- aber am Ende erledigt wird, wenn jemandem die Situation unangenehm genug wird
- Unternehmen verpacken die Zeit, die sie Engineers für NFRs, also nicht-funktionale Anforderungen, geben, manchmal wie einen besonderen Vorteil
- Etwa wenn man in jedem Sprint 2 Tage bekommt, um lästige Dinge zu erledigen
- Auch der Aufbau interner Tools kann in diese Kategorie fallen
- Etwa Admin-Dashboards, die den Betrieb des Unternehmens ermöglichen
- aber nie genug Priorität erhalten
Was die Budgetposition für Karriereentscheidungen signalisiert
- Zu welchem Budget eine Arbeit gehört, bestimmt die Alltagserfahrung von Engineers
- Growth-Arbeit ist messbar und verändert sich häufig
- Forschungsarbeit ist ruhiger, aber die Ergebnisse sind unscharf
- Entwicklungsarbeit gilt als wertvoll und sammelt sich mit der Zeit an
- Wartungsarbeit wird als etwas behandelt, das jederzeit gestrichen werden kann
1 Kommentare
Meinungen auf Hacker News
Nicht nur, aus welchem Budgetposten das Gehalt kommt, sondern auch, wie die Organisation Softwareentwicklung bewertet, hat großen Einfluss auf die Karriere.
Wenn das Unternehmen eine Beratung ist, die Entwicklungszeit verkauft, werden Fähigkeiten im Kundenmanagement und die Fähigkeit geschätzt, schnell brauchbare Software zu bauen. Wenn es ein Produktunternehmen ist, das Softwareprodukte verkauft, werden die Fähigkeiten geschätzt, Software zu entwickeln und zu betreiben.
Handelt es sich um ein anderes Geschäft, das teilweise Software enthält oder durch Software ermöglicht wird, wird die Fähigkeit geschätzt, innerhalb des Budgets zu liefern, aber man wird schwerlich die Hauptrolle auf der Bühne spielen.
Interessanterweise passt diese Unterscheidung gut zu den drei Kategorien des Autors: Beratung entspricht Vertrieb/Marketing, Produkte entsprechen Forschung und Entwicklung, der Rest entspricht Wartung.
Als Senior Engineer in einem Software-Startup gab es Star-Behandlung, Aktienoptionen und die erwartbare Bürokultur; als Senior Consultant in einer IT-Beratung musste ich eher ein Verkäufer sein, der gute PowerPoint-Folien macht.
Ich musste abrechenbare Stunden maximieren und durfte Projekte nicht schnell oder mit minimalem Code abschließen.
Wo ich jetzt bin, kann man sich ungefähr denken.
Das ist nichts, was man als fertiges Produkt von der Stange kaufen kann; meist ist es eine stark angepasste, mühsam zusammengefügte Verbindung mehrerer Systeme, die oft ursprünglich nicht dafür entwickelt wurden, zusammenzuarbeiten.
Jedes Unternehmen macht es außerdem anders.
Ich mag diese Arbeit und bin gut darin, über das gesamte, abteilungsübergreifende System nachzudenken.
Um sich durch die Probleme zu arbeiten, braucht man auch Wissen über interne Politik, und genau dort entsteht mein Wert.
Als Programmierer bin ich auch okay, aber ich reiche nicht an die Expertise von Leuten heran, die Programmierung zu ihrer Karriere gemacht haben.
In den beiden anderen Fällen ist man ein Kostenfaktor, der minimiert oder eliminiert werden soll.
Nur wenn man am Kernprodukt des Unternehmens arbeitet, ist man ein Asset, das Umsatz bringt.
Ich habe diesen Fehler auch gemacht, wurde in ein Meeting gerufen, gefragt „Wie läuft es?“, und direkt danach hieß es: „Erzählen Sie mir keine Details.“
In Nr. 3 zu arbeiten bedeutet, langweilige und vergessbare Lösungen zu bauen; man kann dabei Lösungen schaffen, die technisch plausibel, politisch aber Selbstmord sind.
Wenn man zum Beispiel bei einem Hardwarehersteller arbeitet, ist man nicht nur nicht die Hauptrolle, sondern bekommt kaum Respekt.
Softwareleute gelten als Kosten, und zwar als Kosten, die man möglichst nicht tragen möchte.
Selbst wenn man pünktlich und unter Budget liefert, fällt man nicht auf, sondern verschwindet eher aus dem Blickfeld.
In der modernen Tech-Kultur fällt es mir schwer zu verstehen, wenn gesagt wird, Wartung stehe immer ganz unten auf der Liste, Budgets würden gekürzt und sie bekomme kein angemessenes Budget
In 20 Jahren in verschiedenen Unternehmen habe ich das immer wieder gehört, aber nur selten zugestimmt
Unternehmen wollen zwar neue Funktionen auf den Markt bringen, gleichzeitig wollen sie aber auch, dass der Dienst ordentlich funktioniert
Selbst bei Entlassungen oder Einstellungsstopps habe ich gesehen, dass SRE-artige Organisationen sich besser halten als Forschungs- und Entwicklungsorganisationen
Allerdings wandelte sich die Kultur in einem Unternehmen dahin, ständig Neues zu bauen und das Bestehende nicht für seine Pflege zu belohnen; es folgten dauernde Migrationen interner Tools, fortlaufende Stilllegungen und halb fertige Migrationen
Wenn die Leute, die ein Produkt gebaut hatten, befördert wurden und zur nächsten Portfolio-Arbeit weiterzogen, wurde selbst das Neue und Glänzende bald vernachlässigt, und ein neues Team baute wieder einen Ersatz
Innerhalb von sechs Jahren wurde ein internes Tool viermal durch ein neues internes Tool ersetzt, und die Nutzer verteilten sich über vier Tools
Man könnte das schlicht als Ausführungsversagen bezeichnen, aber eine Kultur, die sagt, das Business sehe Wartung nicht als wertvoll an, ist sehr schädlich und führt zur Selbstzerstörung
Nehmen wir an, ein Entwickler verbraucht jedes Mal, wenn er eine neue Funktion hinzufügt, Speicherplatz im Wert von 1.000 Dollar und erzeugt 10.000 Dollar neuen Umsatz
Der Systemadministrator kauft einen großen Fileserver, und ein neuer Server koste 500.000 Dollar
In einer bürokratischen Organisation stellt der Systemadministrator dem Entwickler die Kosten für den Speicherplatz intern in Rechnung, und wenn ein neuer Fileserver nötig ist, liegt das Geld bereits bereit
In einer gut geführten, weniger bürokratischen Organisation versteht das Management, dass eine Rechnung über 500.000 Dollar ein Projekt ermöglicht, das 5 Millionen Dollar zurückbringt, und zahlt sie gern
In einer schlecht geführten Organisation ist das Management entsetzt, weil 500.000 Dollar teuer sind und nicht mit einem bestimmten Projekt verknüpft werden; der Systemadministrator sagt dann der nächsten Person, die Speicherplatz im Wert von 1.000 Dollar braucht, sie solle 500.000 Dollar zahlen, und diese lehnt ab
Am Ende lehnt der Systemadministrator die Anfrage ab und überzeugt die Entwickler, die Log-Aufbewahrung von 7 auf 3 Tage zu reduzieren, und ehe man sich versieht, hört das Management negatives Feedback über den Systemadministrator
Das beschriebene Umfeld wirkt eher wie eine Realität, in der das Business Wartung nicht als wertvoll ansah
Die Aussage „Wartung steht ganz unten“ ist weniger eine Empfehlung, es so zu machen, sondern eher eine Beschreibung dessen, was tatsächlich passiert
Der Autor analysiert zwar nicht, warum das so ist oder ob ein anderer Ansatz besser fürs Geschäft wäre, aber wenn man Wert darauf legt, dass etwas zuverlässig funktioniert und hohe Qualität hat, würde man natürlich ein anderes Ergebnis erwarten
Wenn allerdings nur sehr wenige Unternehmen so handeln, liegt vermutlich ein Grund in der Ausrichtung der Anreize
Denn man kann Kunden keine Wartung verkaufen; verkaufen lassen sich nur Funktionen
Auch aus Entwicklersicht ist Wartung Arbeit, die man lieber vermeiden möchte
Wartung lässt sich schwer als glänzender Punkt in den Lebenslauf schreiben, und alle wollen Erfolge, ausgelieferte Projekte und moderne Technologien sehen
Einen Service auf dem von Kunden geforderten Niveau am Laufen zu halten, hat für alle hohe Priorität
Kein Unternehmen will SRE so weit kürzen, dass Kunden wegen Ausfällen abwandern
SRE ähnelt aber eher dem Betrieb in traditionellen Unternehmen, also einer Funktion, die unvermeidlich ist, wenn man einen Service anbieten will, und unterscheidet sich von Wartung, die man möglichst aufschiebt
Aus dieser Perspektive meint Wartung Dinge wie den Abbau technischer Schulden, die Verbesserung interner Tools und kürzere Iterationszeiten für Experimente; solche Arbeiten werden meiner Ansicht nach im Verhältnis zu ihrem Produkteffekt oft unterschätzt
Der Text behandelt Letzteres und sagt, in Kategorie 3 zu gehen sei Karriereselbstmord
Wenn man nicht der Typ „Beförderung oder raus“ ist, kann man durchaus darüber nachdenken, Zeit in Kategorie 3 zu verbringen
Natürlich altert Software in dem Moment, in dem sie genutzt wird; daher verbringen auch Leute, die glauben, in Kategorie 2 zu sein, in Wirklichkeit womöglich den Großteil ihrer Zeit in Kategorie 3 und nur einen sehr kleinen Teil in Kategorie 2
Trotzdem werden Budgets einmal im Jahr, höchstens ein paarmal, zugewiesen; wenn man zu diesem Zeitpunkt in einem Bereich ist, der als Kategorie 2 eingestuft wird, ist man weiterhin in einer besseren Position
„Vertrieb/Marketing“ und „Forschung & Entwicklung“ sind Kategorien, die man in Geschäftsberichten von Unternehmen sehen kann, Wartung taucht aber nicht auf diese Weise auf
Es lohnt sich, die Finanzberichte eines Unternehmens zu lesen
Dort sieht man Posten wie „Umsatzkosten“ bzw. COGS, „allgemeine Verwaltungskosten“ und einmalige Kosten wie Fusionen und Übernahmen; jeder Posten hat eine andere Dynamik und funktioniert zudem von Unternehmen zu Unternehmen unterschiedlich
Wichtig ist auch, die Business-Struktur der eigenen Branche zu verstehen
Selbst in diesem Thread wird häufig geurteilt, ein Unternehmen sehe Software Engineering „nicht als wertvoll“ an, aber es ist naiv, ein Social-Media-Unternehmen mit 70 % Bruttomarge mit einem Auto- oder Luftfahrtunternehmen mit 15–20 % zu vergleichen
Es ist selbstverständlich, dass eine Branche mehr Ingenieure einstellen, besser bezahlen und mehr Goodies und Benefits anbieten kann
Selbst innerhalb desselben Unternehmens erhalten manche Produktlinien und Funktionen langfristige Investitionen, während manche Produktlinien höhere Margen haben als andere
Je nach Budget unterscheidet sich das Geld, das für Softwareprodukte ausgegeben werden kann, erheblich
Ingenieure sollten bei der Betrachtung ihrer Arbeit auch die Finanzen des Unternehmens mit einbeziehen
Ein Unternehmen ist keine Wohltätigkeitsorganisation und keine Kirche, sondern ein Geschäft, das Cashflow, Umsatz, langfristige Strategie und die Kosten der Produktentwicklung ausbalancieren muss
Dieser Text ist gut, aber auch der Beitrag von patio11 erklärt die Unterscheidung zwischen Kostenstellen und Profit-Centern sehr gut
Er legt überzeugend dar, warum man an einem Profit-Center hängen sollte, und wenn man ihn noch nicht gelesen hat, enthält er auch sonst viel Gutes
https://www.kalzumeus.com/2011/10/28/dont-call-yourself-a-pr...
Regel Nummer 2 ist, innerhalb dieses Profit-Centers eine Rolle zu übernehmen, die glaubwürdig mit nachhaltiger Profitabilität verbunden ist
Man muss nicht direkt Geld verdienen, aber es sollte klar sein, dass es direkte Auswirkungen aufs Geld hat, wenn ich aufhöre zu arbeiten
Etwas anderes Thema, aber ich fand das Serverless Handbook, das Swizec vor einigen Jahren geschrieben hat, sehr nützlich und lese seit Langem gern seinen durchdachten und einsichtsreichen E-Mail-Newsletter
Er steht klar im Lager „Learning by doing / öffentlich lernen“ und ist sehr gut darin, den Lernprozess zu teilen
Ich empfehle dringend, ihm zu folgen oder ihn zu abonnieren
Historisch war Software Engineering Teil der IT-Funktion, und die IT ging aus der Buchhaltung hervor.
Bevor Maschinen das übernahmen, war „Computer“ im Wortsinne die Berufsbezeichnung einer Person.
Auch heute ist in vielen Unternehmen die Buchhaltung weiterhin der wichtigste Treiber von Software und die Quelle des Budgets.
Tatsächlich gibt es vier Budgetkategorien.
Nummer 1 ist Forschung und Entwicklung, wofür in der Regel besondere steuerliche Behandlungen und Steuergutschriften gelten.
Nummer 2 ist Vertrieb/Marketing, einschließlich Pre-Sales Engineers und mitunter Implementierungsarbeit.
Nummer 3 ist Wartung: Entwickler, die Bugs beheben und an Code arbeiten, der nicht F&E ist und normalerweise nicht unter besondere steuerliche Behandlung oder Förderungen fällt.
Nummer 4 ist Operations bei Hosting-Services, PaaS und SaaS, wo in der Regel ebenfalls ein gewisser Anteil an Gehältern von Software Engineers enthalten ist.
Es ist sehr wichtig, die steuerlichen Auswirkungen zu verstehen, je nachdem, aus welchem Budget das Geld kommt und welche Arbeit geleistet wird; mit zunehmender Größe wird das deutlich komplexer.
Ich halte das Modell Profit Center vs. Cost Center für besser.
Idealerweise ist jede Abteilung sowohl für Umsatz als auch für Kosten verantwortlich.
Wenn man es nicht messen kann, ist das ein KPI-Problem.
KPIs können kostenorientiert und dadurch falsch ausgerichtet sein, aber das macht die Abteilung selbst nicht zu einem Cost Center.
Allerdings gefällt mir, dass hier die F&E-Unterscheidung hinzukommt.
Auch wartungsorientierte Teams sollten F&E betreiben, um Wartungskosten zu senken, genauso wie ein gutes Vertriebsteam F&E betreibt, um den Vertriebsgewinn zu steigern.
Es liefert unterschiedliche Einsichten und kann sich ergänzen.
In keinem Unternehmen, in dem ich gearbeitet habe, kamen die Gehälter für Growth Engineering aus dem Marketingbudget.
Ein separates „Wartungsbudget“ gab es ebenfalls nicht; alles war schlicht F&E/Engineering.
Je nach Team oder Rolle konnten die Erwartungen sehr unterschiedlich sein, aber das ist keine Budgetfrage, sondern hängt davon ab, wie das Unternehmen Ziele nachverfolgt.
Entweder verdient man jetzt Geld, schafft langfristigen Wert oder geht mit einem bestehenden Produkt langsam unter — eines von dreien.