Not to dismiss the importance of a strong Product lead, but often the role is a permanent stopgap for engineers who lack the talent and discipline demonstrated in this article. (Easter egg aside.)
Not to dismiss the importance of a strong Product lead, but often the role is a permanent stopgap for engineers who lack the talent and discipline demonstrated in this article. (Easter egg aside.)
This is politics baked into the heirarchy, not a lack of "talent and discipline".
I had devs who told me they don’t care about product features. "Just tell me what to do, it’s my job to implement."
No more extra miles, not a single one.
I am merely saying that maybe there should be a stronger discussion than just dismissing engineers as mere "thing-doers". I also accept that there are many people here who are exactly that, and I and they should find it shameful.
We can't control that, but maybe we should try harder to do instead of being lazy and assuming market forces are the boss... maybe we are the boss (we are).
Having someone to discuss the business with engineers is important, that's clearly not the thing being criticised here.
Most PMs I worked were nowhere near being able to guide anyone, especially on B2B domains. I had to train a lot of them just to do basic follow up stuff, and honestly the vast majority was below expectation, and mostly just receiving requests from customers and giving opinions on designs.
And even in the best cases, an understanding of the product filtered by a product lead was nowhere near as good as actually having engineers who care, dogfood, talk with customers, read feedback, design solutions and verify them with end users.
IMO the concept of product leads, PMs, etc, is ok, but the implementation is always lacking. It's always a "creative type" that is stifling creativity of engineers while not really adding a lot of value.
I much prefer the concept of "Product Owner" of Scrum: someone that brings the tasks but isn't really dictating taste (except via feedback) or removing the creative part of engineering work.
Usually what you end up with is a "three blind men and the elephant" situation; the product is simply too large for any one person to "fully" understand. Humans have a finite context window too.
So ending up with a product manager who is standing far enough away to see the whole elephant, but not in detail, while the engineers have detailed views of their part of the product but not the whole thing, is a reasonable position.
Not personal towards you, but we're gonna wheel that one out again? Bullshit.
We're living in a time where people who can't code and aren't organized enough by anyone's standards who actually gets shit done are under serious threat and hoping their AI god(s) will save them. None of these arguments surprise me.
Always was it so; the play remains the same, only the names are changed.
But that doesn't challenge the validity of what pjc50 wrote: literally nobody has time to count the transistors on a modern CPU (exceeds maximum human heartbeats), nor even the much easier task of skim the lines of code in say Windows 10 and the bundled drivers and apps.
We have division of labour because we need it, we have abstractions because we need them.