> Being good at engineering doesn't in any way qualify you for being good at building products.
Being good at engineering is exactly being good at building products, whether its civil engineering and the product is a bridge, or software engineering and the product is an application.
Being good at engineering may not be the same as being good at deciding what the product should be, but no one should mistake "deciding what the product should be" with "building the product".
Agreed. I see many people that aren't that good at anything concrete and just sell themselves as "good at building products". If an engineer is not qualified to build a software (the product), who is?
I get that not everyone is cut for figuring out markets, sales, etc. But this crap about "you're only an engineer, you have no clue how to make a product" is a blatant lie.
Good engineers are all about the product. Coding is just part of it. The assumption about people that don't graduate in business can't create businesses is just pure ignorance.
Gahh, this sentiment from product managers drives me nuts. IMO you will never have the best engineers work for you, because the best are very good at making product decisions / knowing the business in addition to excellent engineering skills.
To me this is the single most differentiating philosophy between great product managers and very mediocre ones.
> "being good at engineering doesn't qualify you for managing product"
Which is demonstrably true. They're two different skillsets. If we reversed the statement:
> being good at product management doesn't qualify you for engineering
We could also agree on that statement. That doesn't mean that there aren't engineers who are/could be kickass product managers, and it doesn't mean that there aren't product managers who could sit down and build the application.
But they're two different roles. Product managers are supposed to identify problems, design requirements, provide engineering with clear context and business data to help inform the priority, and then engineering should get to, based on that information, build the best solution.
The link you provide is interesting, though I think a big factor that it overlooks (that supports the same trend against the value of traditional management) is lean methods, which (while they are now applied other places) really emerged out of the most concave work (routinized production) and while they demand a certain amount of management in the traditional sense, narrow and focus the scope of management (and, in essence, make it more technical) while providing more involvement of line workers in substantive decision making.
Traditional management isn't just becoming less relevant because of "convex work", its become less relevant because it is an outdated social technology even for concave work, for which more-efficient replacements have been developed in the last several decades.
but no one should mistake "deciding what the product should be" with "building the product".
At particularly early stage startups, it not unheard of the developer having a decent say on what product to build. But it largely depends on company to company.
Being good at engineering is exactly being good at building products, whether its civil engineering and the product is a bridge, or software engineering and the product is an application.
Being good at engineering may not be the same as being good at deciding what the product should be, but no one should mistake "deciding what the product should be" with "building the product".