Comment by NotAnEconomist | Hacker News Reader

Comment by NotAnEconomist | Hacker News Reader

Parent Full thread

> Conversely, have you ever worked under a non-technical product manager you loved? Would you mind sharing details about your situation?

I've had several.

The key feature is that they bring something to the table: I don't actually need technical guidance on how to build the product -- I (or another engineer) knows enough to solve the technical aspects, that's why the corporation is paying me (or them). But what I do need is help coordinating with other teams, help interacting with executives, help prioritizing tasks, help with the kinds of brainstorming exercises that nucleate the project plan, help with understanding and interpreting customer feedback, etc. Colloquially, the "people side" of the job -- it's just not what my skill set is.

So, I actually prefer non-technical PMs: I want people who complement me, not people who are probably less informed about technical issues trying to micromanage my choices there. A non-technical PM is bring a skill set that diversifies a team of engineers, and helps the team more successfully do its job of interacting with both the corporation and customers.

If the PMs here will indulge a couple questions from me:

1. What skills are most useful in an engineer, and how do we make you look good/help you make us look good?

2. What advice would you give to an engineer looking to move into a role like technical adviser, which more directly interfaces with management and executives?

Love your reflections here!

I'm a non-technical product manager, and I've heard the same sentiment with the engineers that I work with. My engineers want business context and user context - they don't need someone to provide technical guidance.

To address your questions directly:

1) The most helpful skill in an engineer is the skill of speaking up. When I reflect on the dozens of engineers I've worked with, I consistently find that the ones who provided the most value were the ones who would question me constructively.

My specs aren't perfect, because I don't have a detailed understanding of the technical constraints. I love it when engineers tell me why my spec won't work, and then provide multiple alternatives for how to get the spirit of my spec to work.

As for how to help you look good - I really appreciate it when engineers honestly keep me informed about their bandwidth. That way, as I keep stakeholders in the loop, I can accurately set their expectations.

It's never helpful when engineers say "I can complete these 15 tasks by next week", and wind up only completing 2. On the flip side, it's equally unhelpful when engineers say "I can complete only 2 tasks by next week", then wind up knocking out the entire backlog.

2) I can't speak clearly to "technical adviser"-type roles, unfortunately, since I'm not technical to start with. That being said, the technical folks who interface with management and executives are typically managers of managers of engineers.

In other words - the engineers who drive the technical vision of the company are also the ones who are directly responsible for their teams' execution on the tactical work.

>>>> What skills are most useful in an engineer, and how do we make you look good/help you make us look good >>>>

1) I don't think it's technical skills per se (your hierarchy would have reviewed that when you were hired). I think it's more of an attitude. I've lost count of the number of times PMs make a case for a feature to behave in a specific manner and Dev doesn't want to invest the time or effort to even investigate if it's possible/how that can be done. From Dev POV - we already do it this way so live with it. PM makes the argument that is not the best from a functional POV but Dev is simply not interested.

Note: I'm not saying all Devs behave this way, just pointing out a technical way of doing something might not provide the best functional experience and being open to explore or understand what PM is trying to achieve is important.

2) Ability to look at the big picture. Sometimes one is so focused on the immediate tasks and its technical design that they miss the fact that the PM has a road map and this feature or set of features is just one bit on the roadmap. This means that whatever is being built now should if possible make it easier to implement the other features down the line.

Reply on news.ycombinator.com