3 ms·
There's a common complaint among developers that they wished their PMs were more technical. When I started as a PM I incorrectly took this feedback to heart and
by mips_avatar 4y ago
There's a common complaint among developers that they wished their PMs were more technical. When I started as a PM I incorrectly took this feedback to heart and leaned into my technical strengths. This was a mistake, as much less technical PMs who focused on people had much more success than me. I was exhausting myself understanding the technical details of the projects and aligning execution, when in some cases I was missing out on what the customer really wanted. It's great to be good at everything, but I'm not going to let myself get distracted from listening to what customers/partners have to say. And if you're a developer who thinks your PM isn't technical enough, you may not be correctly appreciating what they're bringing to the table.
- dgb23 4y agoThe best PMs involve devs early and trust them to make technical decisions - including saying “no”. A PM who cannot do this _has_ to be on a higher technical level. That’s why we sometimes think we want that. But what we really want is trust and agency.
- HeyLaughingBoy 4y ago> But what we really want is trust and agency. Yup. One of the best PMs I've had the pleasure of working with secretly thought we were doomed, but she still gave us what we asked for and supported us all the way to success. When people trust you like that, you do all you can to not let them down.
- cauch 4y agoI think one problem is that it is a vicious circle: it is not always that the PM cannot involve devs early and trust them to make technical decisions, it's that sometimes, devs are not trustworthy because they are not understanding people. Why would a PM involves devs early if the dev team has demonstrated that they are not interested in understanding the rest of the business? I'm not saying it's always the case, but I have the feeling that in these conversations, the discussion is often a one-way street: a lot of devs are talking a lot about how they wish their PM is more technical or gives them more trust or freedom of decision, but a lot of them seems at the same time totally uninterested or oblivious in the possibility of changing themselves to satisfy the PM's wish. Why should the PM change to please the dev when the idea of changing to please the PM is so remote from all dev's considerations?
- dgb23 4y agoIt's really a two way street and both sides need to grow into earning each other's respect and trust. > Why would a PM involves devs early if the dev team has demonstrated that they are not interested in understanding the rest of the business? They wouldn't. Because in order to really trust someone to take more responsibility this interest is a prerequisite. In the ideal case the developer _wants_ to hear about the problems that need solving, not be assigned specific tasks. And a PM _wants_ to leave technical responsibility and agency in the hands of the developer, shield them from politics and trust their decisions. Mistakes happen and there are ups and downs to these relationships. But it has to start with building mutual trust.
- cauch 4y agoI agree and I think it's the point of this article: the ideal case is when the developer want to hear about the problems that need solving, aka need to understand people rather than focusing on understanding technology. I still feel that there is a lot of developers expecting that everything should revolve around them without caring about the other members of the company. At least more than PM not caring about the developers needs. I feel that I can see this behavior in the comments here, for example in some comments criticizing the article that show that their author really don't care about reaching a two way street situation.
- PeterisP 4y agoIDK, quite often the PM has to manage external people/teams who need to do stuff in a project but clearly have their own interests (either their employer or personal) in mind than the organization who wants to use their services. Purchasing and outsourcing (which are key parts of most non-tiny projects) does require being able to make technical decisions that are best for the project, not the most profitable or easiest for some of the vendors implementing their parts.