Staff Engineers on Platform Teams Must Invent Their Own Work
A Staff Engineer's Guide to Inventing Work
Platform teams are engineering-led, with no PM handing out roadmaps or revenue line to follow—so work doesn't exist unless an engineer invents it. A staff engineer shares eleven signals from systems, users, the org, and the industry that reveal what to build next, then ranks them by how much argument they hand you for free and whether they lead or lag. The real failure mode isn't an empty backlog; it's one assembled from the loudest signals.
The failure mode of an engineering-led platform team is not an empty backlog; it is a backlog assembled from the loudest signals - usually the crash, sometimes the skip-level.
- dabedee
> Platform teams are engineering-led rather than product-led. There is almost never a product manager handing you a roadmap, no revenue line to follow, and no market to lose.
It's precisely because of this framing and mentality that platform teams don't actually serve people well and are usually highly dysfunctional towers of people inventing work.
The fix for having no market is to act like the teams you serve could leave. This whole article lists signals, and none of them is that. Being captive does not mean the users or internal teams don't have other options and don't notice. Being product-led means caring about your users. A platform teams should be product-led, not engineering-led in that very narrow meaning. Otherwise you invent work as this article so wonderfully exposes.
- fsloth
"that work does not exist unless an engineer invents it."
This is so strange. To my mind the only purpose companies hire engineers is to support business. The staff engineer should not need a project manager to tell what is interesting for business aspects - even though the goals are likely mostly technical.
I do realize this does not hold up always. But to me if you can't provide some reasoning for your work in business metrics you are participating in an academic exercise.
- juancn
I use the "what's going to kill us next" philosophy.
Figure out what that is and do something to avoid it.
Wash, rinse, repeat.
- nmehner
"inventing work" = "requirements engineering"
"Inventing work" is a strange phrase to use imho.
- stephbook
The article content is both true and framed strangely.
Does the author think "product customers" hand you a tidy list of requirements the stupid programmer automatons just have to translate into code? Obviously not. Customers also don't know what they want, or could want. Famously, they claim to want faster horses.
Then the author goes on to list "crash led discovery", as if this was so different from prioritizing bugs in prod. Or, If you have no idea, just improving efficiency. Or talking to customers, err, users.
All of this is true and none of this is any different from any of the other software, just translated into other lingo.