> 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.

"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.

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.

"inventing work" = "requirements engineering"

"Inventing work" is a strange phrase to use imho.

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.

I wonder how this applies to personal projects. I find it hard to motivate myself to just "study a textbook". I do do so, but it almost always feels useless compared to actually doing something. It doesn't have to be grand, but it needs to be something I can at least "trick" myself into believing it's useful.

Well, right now, I'm pretty happy and have a personal project that I'm very eager to have done and polished and see the result of. Hopefully life keeps throwing more of them at me. It's been a constant issue for me though.

> no revenue line to follow, and no market to lose

Two paragraphs later, the topic is:

> Cost

I mean this is just incredibly lazy thinking and writing. There's always a cost line to follow, just because there's "not a revenue line" means absolutely nothing it just sounds pithy.

And if you cut your cost hard enough, you will put platform stability in danger, or hamstring your engineering org's ability to test and iterate, which will make you lose your market.

Again, incredibly lazy thinking and writing.

I feel seen, but agree, I would have used "identifying and prioritizing work"...

...but I will admit, it does sometimes feel inventive, and when I describe what I do, it does feel... inventive... in some sense. Particularly "no one in the org asked me to..."... instead it's almost always, identifying and getting ahead of needs, or, responding to overlooked friction/problems, etc...