Dear (Senior) Engineer Friends,
I was thinking more about the time you told me that your PM sucks. They might.
There’s three options:
1) Your PM is awesome, and you are wrong.
2) Your PM is awesome, but you don’t know what they’re doing for you.
3) Your PM might suck. Or they might not suck, but they could be better.
I have some good news! Regardless of which of these options it is – you can help improve the situation.
To start with, it’s important to understand why your PM might not know how to do their job.
You probably got to go to college where you learned how to write software. You probably had internships and wrote software professionally. If not, you at least did a lot of projects and practiced on your own.
Your PM didn’t get that. They didn’t go to college to major in “PM.” They majored in Engineering (like you), or Design, or Business, or Liberal Arts. It’s hard to practice being a PM on your own time – you have to find other people to work with.
Plus, practicing PM skills is a lot more complicated than just starting a side project. I’m envious every time Tom says “I want to learn Go, I’ll just start a project.” If I want to learn how to be a PM for internationalization, there’s not much of an equivalent.
If you have a brand new PM, at best, they got a three month internship being a PM. There’s a decent chance they never even got to finish an entire project.
Even if you have a PM who’s done a couple projects, there’s a chance what you’re working on is something they’ve never done before. Plus, PMs don’t get that much tangible feedback. At a bigger company they might, but at a smaller company, most of the time they are on their own.
So yeah, I’m not surprised when you say your PM sucks. No one ever taught them how to be a PM. I know you don’t want to teach them, and it isn’t your “job,” but it’ll save you a lot of time in the long run. Here’s a few common ways PMs tend to screw up, and how Engineers can help. Of course, this isn’t an exhaustive list.
1) Your PM isn’t doing the right work.
This happens a lot, especially with people who studied Engineering and then decide to go into PM.
You might find your new PM is annoying because they try to dictate how to write the code, instead of what the code should be.
You also might find that your PM feels closer to marketing/sales. Those PMs tend to like a conduit – “well the Account Manager says we need X” instead of synthesizing how the Product works.
The PMs manager won’t always notice either of these situations. If you do notice this, the best way to solve it is just to tell them.
In my first project I worked Nokia on Office Mobile for Symbian. There were a lot of discussions between the Nokia PMs & myself. I was much more junior than the Nokia PMs and came into the project late. Unfortunately, I just ended up telling the Engineering team whatever Nokia said. They didn’t know when I passed information along to our Engineering team, and didn’t feel the cost the same way I did. As a result, they tended to change their minds, and I’d just change the spec. It didn’t seem like a big deal to me.
Until in my first review. The engineer I worked most with wrote something like “Ellen has the potential to be a great PM. Unfortunately, I feel like she doesn’t yet have judgment for what things in the Product will change. The PM’s job is to prevent churn. Since she isn’t doing that, we’ve had to rip out code several times when the spec changed.”
This was the most important feedback I’ve gotten to date. No one had told me my job as a PM was to “prevent churn” until that piece of feedback. I was doing lots of work, but not a core piece of my role. I wanted to be a good PM, and had no idea I was messing up such a key piece.
As an Engineer, if your PM isn’t doing the right work, figure out a way to tell them. If you don’t feel comfortable telling them, see if you can find someone else who does.
2) Your PM isn’t doing the work well.
A new PM is doing everything for the first time. They might have a vague idea that their job is “defining things,” but not a clear impression of all the details.
The first project I did on Office Mobile was writing the spec for a Sprint on error cases. I knew nothing about error cases. I did my best to write a spec, but because of my inexperience, it basically said “we should take care of error cases.” (in four pages). My version of a spec review was reading the entire four pages out loud to the entire team and then saying “Okay? Thoughts?” I’m pretty sure the spec review was painful for everyone involved. Me included.
The development lead I was working knew it was wrong. He didn’t embarrass me in front of the room, but he pulled me aside and pointed out I hadn’t specified anything. He made it crystal clear that I needed to go back, figure out what types of errors happen in mobile apps, and specify what to do in each one.
As a Senior Engineer, you can look at a spec or direction and know if it tells you what you need to implement things well. You’ve seen specs before. Honestly, you could write the spec better than your junior PM can.
So when your new PM doesn’t do it right, don’t just sigh and do it yourself. Instead, tell them what’s wrong. It doesn’t even have to be confrontational – “I took a look at your spec, but I saw you haven’t defined the error cases yet. Could you add those and get back to me so I can give you a better cost estimate? Let me know if you need help figuring out how to do that.”
Next time, they’ll give you a better spec, and you won’t have to write it yourself.
3) Your PM is overwhelmed and can’t focus on anything.
Starting a PM job is complicated. You need to be thinking about lots of moving pieces. New PMs often seem to be like chickens running around with their heads cut off. If your PM seems stressed and is doing badly at everything, see if you can figure out a way to lighten the load.
You can split the PM role into a few big pieces. Two of those are “vision/direction/spec” and “project management.”
As an Engineer, you’re used to managing your own time. You figure out your own estimates, talk to your manager about your own estimates, etc.
If your PM seems overwhelmed it can be really helpful to take on some of the project management yourself.
As a new PM one of the worst moments is when you go into a 1:1 with your manager, they ask about a specific project, and you have to stare blankly.
As an Engineer, if you have a new PM, go out of your way to let them know how long things will take, and if things are progressing. Don’t wait for them to come to you. Plus this lets you do it when you want, and doesn’t result in the PM interrupting you while you’re trying to work.
If you’re an Engineering Lead, you can do even more for this. As much as I kept track of the projects I worked on at Microsoft, I knew the Engineering Lead knew far more than I did. If I were to make a mistake, he’d be there to step in and fix it. He had enough experience that it made sense for him to do that – it helped de-risk our project, and also helped me learn.
Again, as an Engineer, this is more work for you in the short term. But in my mind, having a PM that does one thing well is better than having a PM that does two things badly. In the long term, it’ll help your PM master one thing. As they get more comfortable there, they’ll start getting better at other skills, too.
4) Your PM has bad judgment.
This is probably the most common reason Engineers get frustrated with PMs. The first three happen a lot more in the first few years of a PM’s career. This can happen continuously, and each time you start a new job.
One common way is not having a good sense of what is “hard” or “easy” to do from an Engineering perspective. The way to fix that isn’t to say each time if something is hard or easy – it’s to explain why. Again, like all of these suggestions, it’s more work in the short term.
It pays off when your PM starts to get better judgement for how long things take, and why. (“I remember this part of the codebase is old, and in a technology we don’t typically work with, so that’ll be hard.” or – “These types of stats queries are ones we don’t usually do, and we’ll have to invest in new infrastructure.”)
Another way is when your PM has bad Product sense. While the PM usually owns “what” and the Engineer owns “how” – you should still say something if things seem wrong.
The solution here is to ask more questions. You shouldn’t say “no, we should spec like this instead” – that’ll just make the PM defensive. Instead, try to make sure their decisions were deliberate. “Why do you think we should build this feature vs. this other feature?” “Did you consider X as an alternative? What were the problems there?”
This makes you seem interested in the Product work, and helps the PM see alternate perspectives, without feeling undermined.
The common thread running between these suggestions is that you need to tell the PM what you need. There’s no “PM school” they went to where they learned a proper process. Especially starting out, you’re their best hope for learning to be a good PM. So yes, they might suck right now. I can’t fix that for you, but you can. Set clear expectations, and invest in teaching them early on. Let me know how it goes!