Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> When this role is dumped into engineering, engineering management or general management, it weakens the engineering practice. If I need engineers, I need to select for that ability and frankly shield them from people on the outside. If the org requires that my teams handle interaction, now I'm hiring people with mixed skillsets in one org, which inevitably waters down the engineering side.

I'd argue that the position taken above weakens the engineering practice. Understanding requirements (e.g. constraints) is a core element of engineering, engineering management, and general management. Part of the problem plaguing the tech industry is the "dumping" of this responsibility, and others such as "project management" into some other role. What some like to call a "specialization" may also be called an abdication of responsibilities and ultimately accountability.

In my opinion, the essence of engineering is the methodical art and practice of solving problems. A fundamental part of engineering is understanding the problem(s) to be solved, the constraints, as well as the trade space and trade offs of solutions for those problems.

Not all aspects of (engineering) problems are "technical" in nature, and a failure to understand this and cultivate this understanding weakens the engineering practice.



It does, but it's still not something engineers do well.

Imagine developing an AAA game with no one in charge of the overall product. Or creating a movie without a producer or a director, expecting the talent to somehow organise itself.

PM isn't an engineering job, it's a vision job - one that needs enough technical knowledge to create a vision that's grounded in reality, while also appealing to customers, while also being able to sell it up and down the org.

That skillset is incredibly rare.


That was well put. Imagine that. Still we train our product managers to follow checklists, write endless documents about personas, have discussions about methodology and such things only loosely connected to the work that goes into making the actual product.

Imagine if a director was a bureaucrat. One who followed checklists and made policy documents, and did not have the slightest clue about the actual craft of setting lights, working the camera, and acting.

What's our profession's equivalent of a film director? One with deep knowledge about data structures, who cared about getting it right, together with professionals?


> What's our profession's equivalent of a film director?

Scrum master.


Hardly. Scrum master is more like a production assistant. Make sure everyone knows when and where they are supposed to be. Communicate any issues with the plan


Separating product from engineering, engineering management, and general management does not mean 1 person is in charge. Integrating them does not mean no one is.

The article was all about the consequences of the skill set being incredibly rare.


Good engineers work to deeply understand the problem given to them. They understand the different possible solutions, and implement the best one they can, given their constraints.

Good product managers identify the problems to be solved, and prioritize which ones should be solved first.


> I'd argue that the position taken above weakens the engineering practice. Understanding requirements (e.g. constraints) is a core element of engineering, engineering management, and general management.

Determination, evaluation, and articulation of requirements is the sweet spot of the product manager role. Understanding those requirements is certainly necessary for an engineer to build to the requirements.


An engineer's understanding of requirements entails determination, evaluation, and articulation of those requirements. Calling oneself an engineer doesn't preclude their ability to do these things, and force them to call themselves a "product manager" for doing so. And quite often, especially at more senior levels, an engineer must do these things.

Once upon a time, this too was a formalized practice in engineering that people called "Systems Engineering":

https://en.wikipedia.org/wiki/Systems_engineering

https://www.nasa.gov/reference/2-0-fundamentals-of-systems-e...


Doesn’t preclude the ability, no, but there are only so many hours in the day.

Writing good code is a very separate skill set from that kind of problem-space work, and software engineers are mostly hired for the former.


Once you get to staff+ level, engineers are no longer hired mostly for writing good code.


That’s fair, but that is… what, 1% of all software engineer hires?


I don’t know about as a percent of total hires, because staff+ engineers tend to stick around a bit longer. But in my current bigco it’s a bit north of 10% and I’ve seen it go as high as 20%.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: