Hacker News Reader

Comment by keyP | Hacker News Reader

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.

View on HN

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!

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).

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.

Reply on news.ycombinator.com