As a PM, I believe that one of the things that I should focus on making my engineers’ lives easier. I care deeply about our engineers not having a shitty experience with me as the PM on the project. For example:<p>- I never set meeting times with my engineers that will interrupt their working flow (I love PG’s “Maker’s Schedule, Manager’s Schedule” essay)<p>- I always try to clearly explain the “why” of what we’re doing, provide detailed designs/documentation, and remove any blockers when any arise<p>- When possible, I try not to force engineering shortcuts or trade-offs. I prefer that we build features or systems that are well-tested and clean<p>What have the best PMs you’ve worked with done to make your life as an engineer easier?
The best PMs are those who don't act like managers. Engineers don't report to Product nor Project Managers. Unfortunately, many PMs act like they are real managers and bully engineers around.<p>This only leads to confusion and bad culture. Senior devs don't take orders from PMs but junior devs usually end up confused and create more issues.<p>In my 10 years of experience as software engineer, a PM has never forced me or my team to take any shortcuts or work extra hours to meet their deadline. Every time we had disagreement, my boss backed me not PM.
This is more of an attitude but I like it when "we're in it together" so to speak. Rather than the attitude that I've frustrated or upset you due to an unexpected system complexity, for example. When people feel like they are in it together, they are less defensive. I love going to a PM I trust and saying "hey man we have some problems cause XYZ is harder than expected" and knowing they will help us work through the problem, find areas to descope, and manage communication for us.
Best thing you can do is to bring customer problems to engineers & come up with solutions together. Far too many PMs create detailed spec documents (solutions) on their own and throw it over the wall to engineers.<p>Benefits of this approach,<p>1. Engineers get to know more about the customers & their pain points first hand.<p>2. Engineers are bought into the solution as they co-created it.<p>3. You usually come up with better solutions as both business and technical constraints are all on the table.
I think it helps a lot when PMs decide on the lines of responsibility.<p>Like recently we had a project with a lot of mutual dependencies. The app scans a QR code for access and then access is denied. Who is at fault? The app developer? The API developer who gave them the code? The guy who integrated the code? The back end system handling roles?<p>Is this thing being worked on or is the responsible person waiting on someone else for a fix?<p>The lazy approach here would be to adopt scrum, which settles issues like this, at a great cost.<p>But I find a good PM makes it clear what the progress of the project is, without having to bother the engineers for it. They still do things similar to quick 5 minute meetings, but they slot it into the flow, like when the engineer gets back from lunch. Something like Trello helps a lot in this background monitoring, and the good PM encourages them to use it as it's what cuts down the meetings.<p>One thing I did as manager was to print out every page of the app, paste it on a wall, and then tick off whatever was done, whatever was high priority, or who needed to do it.<p>It's also important, but much harder, to make sure that the team gets along. When the team gets along, they communicate. When they communicate, they know what's going on. This might include posting memes on Slack as icebreakers or talking about their favorite football match. This might also mean allowing the team to head down and have a half hour tea break at 4 PM.
- Give them interesting challenges<p>- Make them feel free in boundaries (e.g. allow creativity flow for a period of time)<p>- plan time for personal enrichment (attending conferences, studying new tech improve in other areas rather than coding)<p>- don't make deadly strict timelines that are unreasonable short. Make a buffer in your estimation
Be exceedingly clear when a given task or project has a hard deadline or when someone is picking up a task that is likely to halt production if it isn't completed within a narrow window of time.<p>Some of my worst experiences have been when my boss got on my case for something I said would be done in two days as a best case scenario, and then exploding when I told them I'd need an extra half day for a problem that showed up and required a change of plan (corroborated by other team members or the PM).<p>Or when a PM would let me know they just need a status check, but didn't take care of backing up my decision with my boss - which also leads to my boss exploding. Idk, maybe I had a toxic boss in a shitty org?
Once you define the features that are going to be in a release, don't change them unless you really need to. If you do change them, change the schedule as well. <i>Never</i> add or change features without changing the schedule.<p>And listen to the developers when they tell you how long things are going to take. Don't tell them that they can do it faster.