|
|
|
|
|
by ruff
5771 days ago
|
|
This is a good point and something I should have made clearer. As PM, you ar first and foremost the customer advocate. Drop the ball here and you fail. Engaging at a more technical level needs to be about ensuring focus, not meddling where you don't understand. For example, cootdinating architectural decisions does not mean designing the solutions (your senior devs do that) but it does mean infusing those discussions with customer centric decision making. The worst thing a PM can do is act like they know something without actually doing so--as others have noted, you need to listen and learn. My experience may be a bit different; when I started, my boss was checked-out and looking for a career change. To learn the role, I got to know our developers really well (in the end, they have lots of power) and asked them what the PMs did well and didn't do well. |
|
Then PM made the mistake of talking within earshot about how he was going to decide the timeline and budget for my team without talking to me. My attitude toward the guy instantly went from "whatever it takes" to "do your own homework next time, buddy".
This is a small startup. We need every win possible to succeed. And I just don't give two shits about the guy anymore. Am I wrong to think this way?