2 ms·

There are several points here where you assume that as an engineer, you need to learn to do another job entirely, here: >This paragraph encompases the job titl

by Hasu 7y ago

There are several points here where you assume that as an engineer, you need to learn to do another job entirely, here: >This paragraph encompases the job title of business analyst, project manager and business intelligence. >Let’s just assume I do have time in my workday for developer, business analyst, project manager, business intelligence and business strategy. Here: >Architect, strategy, consultant. EZPZ I am 10x. Here: >I thought I was the only one with the time needed to handle ~ 10 roles to perfection. Here: > It’s ok, I just need to brush up on my data science. 51% filled. Here: >I don’t need no CEO, CFO, CIO and / or ang form of c-level. I got this guys. >There’s something missing though, my 8 hours are filled with so many roles and I am still bored. I know! And here: >Can’t wait to brush up on my design and UX, luckily I already know Data Science and Operations from my other roles. But I think the point you're missing is that you don't need to do all those jobs fulltime, you just need to have a baseline level of understanding of the underlying principles and needs of those roles. Which isn't that crazy - the "product manager"/"product owner" roles are a smorgasbord of skills and responsibilities, and most people who fill those roles aren't experts in every single skill and responsibility, just like every engineer isn't an expert in both kernel code and frontend frameworks. The way I see it, the "product engineer" is between a product manager and a full stack engineer - someone with a certain level of understanding of different parts of the code, and different parts of the business, but not an expert at any. A generalist whose generalist skills go beyond just the engineering domain, but that doesn't mean they're specialized in all of those skills. Is it easy to acquire all of those skills, even to the generalist level needed to be useful even though you're not an expert? No, of course not. But you also don't have to do it all at once. Doing any of the items on this list can add value, and once you get used to doing it, it's part of your daily routine. Then you pick up something else. It adds up over time.

ThalesX 7y ago
I understand you need to be a bit of everything. 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 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?
- Hasu 7y ago
  >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.
- therealdrag0 7y ago
  Maybe this can be abstracted into being focused or being a generalist. I think OP is arguing that there is value in being a generalist and you are resisting that. I sympathize with OP, I've seen a lot of managers appreciate generalists and I've gotten a lot of value out of them myself. Maybe not everyone needs or wants to be one, but it's fair enough to outline it as a way of operating that provides a lot of value.

by Hasu 7y ago

ThalesX 7y ago

I understand you need to be a bit of everything. 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 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?

Hasu 7y ago
>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.
therealdrag0 7y ago
Maybe this can be abstracted into being focused or being a generalist. I think OP is arguing that there is value in being a generalist and you are resisting that. I sympathize with OP, I've seen a lot of managers appreciate generalists and I've gotten a lot of value out of them myself. Maybe not everyone needs or wants to be one, but it's fair enough to outline it as a way of operating that provides a lot of value.