5 ms·

I've met Gergely, the author, a couple of times a while back and he's a great guy and I think we work in a similar way. In the majority of my roles I was initia

by keyP 7y ago

I've met Gergely, the author, a couple of times a while back and he's a great guy and I think we work in a similar way. In the majority of my roles I was initially hired as an engineer but then moved to engineering management and the points highlighted in the article are very familiar. I often found that features would be requested from product owners/business and developers would implement it no questions asked but at lunch time, developers would rant about the requested feature's value. When asked if it should be brought to the PO's attention, I often saw the attitude of it not being their problem, they're getting paid either way (whether that's a company culture issue, general developer apathy, or burnt by past experience of questioning management is a different question). I think product-engineers feel a bit more invested in the product and have the soft-skills to influence or provide feedback in a manner conducive to business listening. In my teams, I try to foster this type of communication and I've noticed a lot more developers opening up and providing valuable product-orientated feedback which often has an upward positive spiral of them feeling more appreciated and speaking more. Naturally a lot of engineers still want to just code and go home but team culture can really highlight and encourage engineers who may not be confident to speak up initially. Ironically, as someone with more engineering experience on paper, it's been tricky to find a job directly as any form of product or engineer manager, I always had to go in as an engineer then be promoted after a year or so which isn't always ideal (or referred via a friend). I feel Product and Technical skills are still often considered mutually exclusive a lot of the time but I think that's inertia from when technical skills were still considered a cost to the business.

LegitGandalf 7y ago
>I try to foster this type of communication and I've noticed a lot more developers opening up and providing valuable product-orientated feedback which often has an upward positive spiral of them feeling more appreciated and speaking more I guarantee engineers love working for you because of this. If you look at Maslow's hierarchy of needs you are filling that esteem portion that is really lacking for a lot of software engineering teams in the wild.
- keyP 7y ago
  Thank you, I like to think so. A lot of how I manage my teams come from my experience as an engineer and seeing all the approaches that demoralised my friends and colleagues. A lot of it isn't a complex secret, it's really doing what you pointed out - make people feel appreciated, listened to, and actually part of the company as a whole as opposed to just a resource. This can be as simple as being more transparent as to why a feature has been requested, even if it's counter-intuitive to reason, or giving context as to where the roadmap is heading so that they're aware on why they're working on something.
  - LegitGandalf 7y ago
    I've run into so many people in organizations who look at me like I'm from another planet when I start asking "why". As an engineer I've always found that knowing why, knowing that there is a real customer out there who really wants what I'm making is very motivating. So often people just come to me because their boss told them to go get engineering to make this thing. They don't know why, and sadly, their boss doesn't know why either as it was just passed to them from an executive mandate. And there is lots of pressure to get to done ASAP!
    - keyP 7y ago
      Agreed, same experience for me as an engineer and it's often the engineers who get the blame as their output is the most tangible in that chain of command. I believe this is why some of the best Product Owners I've worked with have some understanding of the technical side so that they can push back at the point of feature request rather than accept everything to please business/the client and lay it at the feet of engineers a few weeks down the line. For this reason, I think the engineering manager/technical product owner type of role should start becoming a bit more common especially in startups, where I've seen first hand, POs brought in who subsequently drive products into the ground that were initially engineering led (and which raised the investment in the first place).
    - galangalalgol 7y ago
      I don't understand this at all. The first 18 years of my career I never saw any boundaries between those who spoke to customers and designed the software and those who wrot it and I those who tested it. It was always encouraged to fill all those rolls. People who were good at the why got helped up to speed on c++ and the stock programmers got a crash course in domain knowledge an a refresher on the bits of relevant math. Only in the last couple year have I started meeting programmer that didn't wan to learn the domain, and started feeling pressure that because I do (now) uderstand the domain, I shouldn't waste my time programming. We made better software when we were all expected to be multi discipline.
Nursie 7y ago
Conversely, when such feedback and communication is overlooked or ignored, over and over, engineers often stop giving it even when they are interested. POs in my recent experience could benefit from listening more to their developers, who often know the domain much better than they do. (Or perhaps the wrong people are becoming POs)
- keyP 7y ago
  > Conversely, when such feedback and communication is overlooked or ignored, over and over, engineers often stop giving it even when they are interested. This is true but I find if I can explain why the feedback was overlooked, that can help diminish the negative feeling. It hasn't happened often in my experience but sometimes when it has, if the idea is feasible and won't detract too much from the critical path, I would push the business team a bit harder to allow it so as to avoid the constant ignoring feeling that can happen.
  - throwthisaway2 7y ago
    Its power, its overloojed because it can be. If product people cant explain the right feature then they are bad at their job. We implement what you want as engineers. The c reason these jobs are separate is because the concerns are great of both. If you need an engineer to ask why , you have a product person that is bad or an engineer that is not focused.
- plutonorm 7y ago
  I've been trying to get out of development for the last month. I've sent 180 CVs for business analyst roles. I've had 2 recruiters call me back, otherwise dead. This is the CV that the CTO of my last company helped me write. You don't get many ex technical product managers or business analysts because it's pretty much impossible to transition.
  - keyP 7y ago
    This was my experience too, and after speaking with recruiter friends, often the company doesn't know where this person would sit. The title is still quite new and whilst the job spec may imply technical, the reality often is that they still just want a full on Product person who happens to know some coding (as opposed to a full on coder who happens to be involved in product). I've generally just had to go in as an engineer and be promoted by showing them what TPM's value is first hand.

by keyP 7y ago

LegitGandalf 7y ago

>I try to foster this type of communication and I've noticed a lot more developers opening up and providing valuable product-orientated feedback which often has an upward positive spiral of them feeling more appreciated and speaking more I guarantee engineers love working for you because of this. If you look at Maslow's hierarchy of needs you are filling that esteem portion that is really lacking for a lot of software engineering teams in the wild.

keyP 7y ago
Thank you, I like to think so. A lot of how I manage my teams come from my experience as an engineer and seeing all the approaches that demoralised my friends and colleagues. A lot of it isn't a complex secret, it's really doing what you pointed out - make people feel appreciated, listened to, and actually part of the company as a whole as opposed to just a resource. This can be as simple as being more transparent as to why a feature has been requested, even if it's counter-intuitive to reason, or giving context as to where the roadmap is heading so that they're aware on why they're working on something.
- LegitGandalf 7y ago
  I've run into so many people in organizations who look at me like I'm from another planet when I start asking "why". As an engineer I've always found that knowing why, knowing that there is a real customer out there who really wants what I'm making is very motivating. So often people just come to me because their boss told them to go get engineering to make this thing. They don't know why, and sadly, their boss doesn't know why either as it was just passed to them from an executive mandate. And there is lots of pressure to get to done ASAP!
  - keyP 7y ago
    Agreed, same experience for me as an engineer and it's often the engineers who get the blame as their output is the most tangible in that chain of command. I believe this is why some of the best Product Owners I've worked with have some understanding of the technical side so that they can push back at the point of feature request rather than accept everything to please business/the client and lay it at the feet of engineers a few weeks down the line. For this reason, I think the engineering manager/technical product owner type of role should start becoming a bit more common especially in startups, where I've seen first hand, POs brought in who subsequently drive products into the ground that were initially engineering led (and which raised the investment in the first place).
  - galangalalgol 7y ago
    I don't understand this at all. The first 18 years of my career I never saw any boundaries between those who spoke to customers and designed the software and those who wrot it and I those who tested it. It was always encouraged to fill all those rolls. People who were good at the why got helped up to speed on c++ and the stock programmers got a crash course in domain knowledge an a refresher on the bits of relevant math. Only in the last couple year have I started meeting programmer that didn't wan to learn the domain, and started feeling pressure that because I do (now) uderstand the domain, I shouldn't waste my time programming. We made better software when we were all expected to be multi discipline.

Nursie 7y ago

Conversely, when such feedback and communication is overlooked or ignored, over and over, engineers often stop giving it even when they are interested. POs in my recent experience could benefit from listening more to their developers, who often know the domain much better than they do. (Or perhaps the wrong people are becoming POs)

keyP 7y ago
> Conversely, when such feedback and communication is overlooked or ignored, over and over, engineers often stop giving it even when they are interested. This is true but I find if I can explain why the feedback was overlooked, that can help diminish the negative feeling. It hasn't happened often in my experience but sometimes when it has, if the idea is feasible and won't detract too much from the critical path, I would push the business team a bit harder to allow it so as to avoid the constant ignoring feeling that can happen.
- throwthisaway2 7y ago
  Its power, its overloojed because it can be. If product people cant explain the right feature then they are bad at their job. We implement what you want as engineers. The c reason these jobs are separate is because the concerns are great of both. If you need an engineer to ask why , you have a product person that is bad or an engineer that is not focused.
plutonorm 7y ago
I've been trying to get out of development for the last month. I've sent 180 CVs for business analyst roles. I've had 2 recruiters call me back, otherwise dead. This is the CV that the CTO of my last company helped me write. You don't get many ex technical product managers or business analysts because it's pretty much impossible to transition.
- keyP 7y ago
  This was my experience too, and after speaking with recruiter friends, often the company doesn't know where this person would sit. The title is still quite new and whilst the job spec may imply technical, the reality often is that they still just want a full on Product person who happens to know some coding (as opposed to a full on coder who happens to be involved in product). I've generally just had to go in as an engineer and be promoted by showing them what TPM's value is first hand.