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?
No they have to be product led.
> Our PMs invent capabilities
this is not a good reason for it to be not.