Staff Engineers erfinden Arbeit, statt sie zu bekommen
A Staff Engineer's Guide to Inventing Work
In Platform-Teams gibt es keinen Product Manager, der eine Roadmap vorgibt, keine Umsatzlinie und keinen Markt zu verlieren. Arbeit existiert nur, wenn Engineers sie erfinden. Der Autor zeigt elf Signale aus System, Nutzern, Organisation und Branche – von Crash-Postmortems über Cost-Center bis zu überladenen Use-Cases – und wie man sie gewichtet: nach Evidenz und ob sie führend oder nachlaufend sind.
Der Fehlermodus eines engineering-getriebenen Platform-Teams ist kein leeres Backlog; es ist ein Backlog, das aus den lautesten Signalen zusammengesetzt ist – meist dem Crash, manchmal dem Skip-Level.
- dabedee
> Plattform-Teams werden von der Technik geleitet, nicht vom Produkt. Es gibt fast nie einen Produktmanager, der dir eine Roadmap in die Hand drückt, keine Umsatzlinie, der man folgen könnte, und keinen Markt, den man verlieren könnte.
Genau wegen dieser Sichtweise und Mentalität dienen Plattform-Teams den Leuten nicht wirklich gut und sind meist hochgradig dysfunktionale Türme von Menschen, die Arbeit erfinden.
Die Lösung dafür, keinen Markt zu haben, ist, sich so zu verhalten, als könnten die Teams, denen man dient, abspringen. Dieser ganze Artikel listet Signale auf, und keines davon ist das. Gefangen zu sein bedeutet nicht, dass die Nutzer oder internen Teams keine anderen Optionen haben und das nicht bemerken. Produktgeleitet zu sein bedeutet, sich um seine Nutzer zu kümmern. Ein Plattform-Team sollte produktgeleitet sein, nicht technikgeleitet in diesem sehr engen Sinne. Sonst erfindet man Arbeit, wie dieser Artikel so wunderbar aufdeckt.
- fsloth
"diese Arbeit existiert nicht, es sei denn, ein Ingenieur erfindet sie."
Das ist so seltsam. Meiner Meinung nach ist der einzige Zweck, aus dem Unternehmen Ingenieure einstellen, das Geschäft zu unterstützen. Der Staff Engineer sollte keinen Projektmanager brauchen, der ihm sagt, was für geschäftliche Aspekte interessant ist – auch wenn die Ziele wahrscheinlich größtenteils technisch sind.
Ich weiß schon, dass das nicht immer standhält. Aber für mich gilt: Wenn man keine Begründung für seine Arbeit in Geschäftskennzahlen liefern kann, nimmt man an einer akademischen Übung teil.
- juancn
Ich benutze die Philosophie "Was wird uns als Nächstes umbringen".
Finde heraus, was das ist, und tu etwas, um es zu vermeiden.
Waschen, spülen, wiederholen.
- nmehner
"Arbeit erfinden" = "Requirements Engineering"
"Arbeit erfinden" ist meiner Meinung nach eine seltsame Formulierung.
- stephbook
Der Inhalt des Artikels ist sowohl wahr als auch seltsam gerahmt.
Glaubt der Autor, dass "Produktkunden" dir eine ordentliche Liste von Anforderungen in die Hand drücken, die der dumme Programmierautomat nur noch in Code übersetzen muss? Offensichtlich nicht. Kunden wissen auch nicht, was sie wollen oder wollen könnten. Bekanntlich behaupten sie, schnellere Pferde zu wollen.
Dann listet der Autor "crash led discovery" auf, als wäre das so anders als das Priorisieren von Bugs in der Prod. Oder, wenn man keine Ahnung hat, einfach die Effizienz zu verbessern. Oder mit Kunden zu sprechen, äh, Nutzern.
All das ist wahr und nichts davon unterscheidet sich von irgendeiner anderen Software, nur in einen anderen Jargon übersetzt.