>When we talk on HN about managers that have technical competencies and try to get into the development process we bash them for thinking they understand, but w

>When we talk on HN about managers that have technical competencies and try to get into the development process we bash them for thinking they understand, but we sometimes argue that we need to understand and do all roles and it works... I can't speak for every conversation on HN, but personally, I have no problem with technical managers that know what they're talking about, as opposed to non-technical managers that attempt to make technical decisions. If someone is trying to be a 'product engineer' but doesn't have the first idea what they're doing about anything beyond software development, I agree that would be counterproductive. >I could make any list of desirable characterisics and it would make those that follow it better professionals. Does the list of OP not match any other job than product engineer? Would a tester not be a better employee with the same understanding, or an HR person? Well, it matches the job of... product. Which hasn't always been a separate job from software development, and in some companies it still isn't. I think there's a distinction to be drawn here, though. An HR person certainly might benefit from insights into the company's business, talking to customers, etc., and it very well could make them more effective at their job. But for the person building the product, it's more relevant to what they're doing every day, since it directly determines both the input and output of their work. I suspect sales has a similar dynamic - understanding the customers and the product is going to highly relevant. A software engineer who just completes tickets and focuses only on purely technical problems might be effective, just as a salesperson who thinks that selling cars, selling software, and selling biscuits are all the same process might be effective, based purely on talent in the relevant skills (strong technical skills for the dev, strong interpersonal skills for the salesperson), but I'd expect the same person to be much more effective if they added some of these product skills, where the force multiplier isn't quite there for HR or Accounting. Of course, not every skill is going to be helpful for every role. As a software engineer, interpersonal skills are likely to be very useful, but learning to close a sale probably isn't going to have much benefit. The point of the article is that the author finds that software engineers who have these product skills are much more effective at making good software than software engineers who don't.