I was lucky enough to have AMAZING PM partners + learned firsthand how to nurture + structure the relationship for success.
To understand how to create a good relationship, first we should specify the role difference between an EM + PM.
EM: Manage + grow engineers and deliver towards technical goals
PM: Set the roadmap and deliver towards business goals
If the expectations aren't defined well then the team will be pulled in diff directions + not deliver anything substantial.
First thing to remember is that you're on the same team + want the same outcomes. You manage different parts of the team (EM = people + tech, PM = roadmap + delivery), but you need both to succeed. That means you have each other's back.
Now, what you should do as an EM 👇
1/ Respect each other's expertise
Each person has clear expertise + a role on the team (defined high level above). Their job is to create the best roadmap + projects for the team to execute on -- so trust + respect that! Lean in to their strengths of ownership + coordination.
2/ Set clear owners
Write down everything that the team owns + does: manage backlog, sprint planning, set OKRs + goals, prioritize projects, etc.
Then go line-by-line + set the owner. If it's dual ownership, then clarify how you'll make decisions.
3/ Meet often
Set a 45-1hr weekly 1:1 for general discussion. For each task you need to do (ex: sprint planning) set a diff mtng. Time box + limit the discussions for those areas to that mtng.
You'll iron out issues as they happen + won't have to wait a week to discuss.
4/ Ask for input
When sifting through diff tech approaches to a problem, ask the PM what they think. They have insights that you don't! One approach may be quicker to implement, but is it easier to test? Or build on top off? Or turn on/off?
Likewise give your input to the PM.
5/ Get involved with brainstorming
Don't leave the project + roadmap work to the PM. Help them! Get involved with early brainstorming, design sessions, etc. Give insights into tech difficulty for each idea. You should be the first to review the BRD before it goes to an eng.
6/ Set timelines together
PM shouldn't be defining a project in a silo then handing it off to you. Get involved early + help define the project based on what you know are the team's and tech capabilities.
Let the timelines be flexible + communicate as it's developing.
7/ Connect tech work to goals
You really want to refactor a piece of code bc it's clunky + hard to work with, but the PM won't prioritize it. Probably bc you haven't defined the business impact. Will it save eng time, unlock new capabilities, contribute to an OKR?
7 cont/ Define the impact of tech projects
If not, then there's no point doing it (for now).
Every project needs to have some quantifiable impact to the team or the business. As an EM your role is to define + quantify tech debt in these terms.
8/ Co-lead team ceremonies
The PM should actively be part of the team. They can lead half of the sprint ceremonies (like stand-up + planning) + you can lead the other half. They'll also be more up-to-date on the team's work so there's less back and forth for you!
9/ Constantly evaluate ownership
At first, the PM led project kick-offs w engineers. We realized this meant she was more involved in technical details than needed, so we decided that I should take over as EM. It cut down her time spent + increased her visibility into the work.
10/ Encourage relationships between eng + PM
You don't need to be the bottleneck. Encourage your engineers to talk to the PM -- review BRDs, invite them to design reviews, discuss testing plans. As engineers grow, this is an important skill to learn + helps the PM stay involved.
11/ Create a project board
This is an extension of a standard agile sprint board. It should include the work before + after eng work.
This can be embedded in the sprint board or kept separate.
12/ You're on the same side
To reiterate, both of you want the team to succeed. This means you want the engineers to be happy + to deliver impactful work. You'll address it in different ways (product vs tech), but at the end of the day you're on the same team!
Thank you to my past PM partner who thought through this w me!
As always, here's a FREE starting breakdown for ownership areas + suggested owners for each:
Everyone tells you to “protect your mental health”. That’s hard when you’re an employee + not in charge of the situation or environment.
Recently I found myself getting anxious about work bc of multiple factors — morale, teammates, mounting expectations.
What worked (so far):
Told my manager early
I didn’t wait till it got really bad, to the point I was burnt out. I told him I was starting to experience anxiety bc of these factors + foresaw it building w what was coming up.
He appreciated the honesty + ability to course correct.
Pinpoint the issues
Instead of just saying “I’m anxious”, I figured out what was causing me anxiety. For me:
- Specific teammates morale
- Upcoming team changes
- Increased scope
I've been an Engineering Manager for 6 years, at start-ups and big cos. One of the most important lessons I've learned as an EM is a key ingredient to managing well + propelling your growth that most people avoid:
💡Weekly Updates
But you don't write just anything in them.
As an EM, you're managing a lot of people's expectations on top of your team's performance.
Weekly updates are the best way to update leadership, report project changes, and get everyone on the same page.
Why do people tend to avoid them?
More often than not, the update is fine so no one responds. It can feel like overhead to write something weekly that people may or may not read.
BUT if you stop you lose: historical context, ability to course correct quickly, and trust.