News for hackers. Stuff that matters.
Re:A Staff Engineer's Guide to Inventing Work by oldnewthing on Wednesday September 30, 2026 @10:03AM (#49909162)
Somewhat true. Platform teams have to be engineering & product led. I run a platform team and we work very closely with our customers to understand what problems they are facing and identify platform level solutions for those problems. But we are still hampered by the team not using the platform for their everyday work, reducing the empathy they have towards its papercuts. However, being purely product focused can lead you astray of your users. Our PMs invent capabilities that no one really asked for ignoring the rather large backlog of capabilities that they already need. That's also bad.

The problem with every platform team is that, impact is hard to nail down. Does X using your platform Y to generate revenue mean your platform Y has indirect impact same as X? Most companies don't think so and end up destaffing their platform teams. Until, the destaffing ends up in much more inefficiency because everyone is inventing their own crooked wheel, spending time on the same capabilities and detracting from product development.

Re:A Staff Engineer's Guide to Inventing Work by dominotw on Wednesday September 30, 2026 @10:45AM (#49909706)
> Platform teams have to be engineering & product led.

No they have to be product led.

> Our PMs invent capabilities

this is not a good reason for it to be not.

Re:A Staff Engineer's Guide to Inventing Work by quietbritishjim on Wednesday September 30, 2026 @11:30AM (#49910283)
I suppose there's the "better type of horse" issue. Maybe the engineering side can come up with something that users wouldn't think to ask for, or whose benefits aren't obvious until it's actually up and running.
Re:A Staff Engineer's Guide to Inventing Work by nsxwolf on Wednesday September 30, 2026 @11:23AM (#49910187)
The platform is partly a product for the engineers.
Re:A Staff Engineer's Guide to Inventing Work by sharts on Thursday October 01, 2026 @10:00AM (#49921818)
definitely wrong. they need to be independent.
Re:A Staff Engineer's Guide to Inventing Work by oldnewthing on Sunday October 04, 2026 @12:03PM (#49955079)
Not really. Not unless your PM is also an extremely deep technology person. Here is a simple example from our current debate: should we build the resiliency capability that hurts multiple customers and who have asked for it because it reduces their toil or the AI feature that nobody has asked for that our PM wants? The AI "feature" is consuming 6 engineers, is behind schedule and turns out to be significantly more complicated than anticipated and won't hit the end of year timeline. We don't know what uptake is going to be like. The resiliency feature could be shipped in 2 months and cut human interventions >70% of the time. Customers are already lined up waiting for it.

One argument is that the AI "feature" is forward looking and can bring more customers into the platform. Agreed. And then what? They are also stuck on the resiliency feature right?