Mitra Raman Profile picture
Feb 18 18 tweets 4 min read
EM / PM Relationship

Most requested topic by far: The EM / PM Relationship

EMs + PMs are partners + co-leads of their team. But most EM / PM relationships sour bc of competing priorities + poor communication.

🧵

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.

Backlog -> Design -> BRD -> Ready -> ENG -> QA -> Release -> Analyze

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:

mitraraman.gumroad.com/l/empmownership

• • •

Missing some Tweet in this thread? You can try to force a refresh
 

Keep Current with Mitra Raman

Mitra Raman Profile picture

Stay in touch and get notified when new unrolls are available from this author!

Read all threads

This Thread may be Removed Anytime!

PDF

Twitter may remove this content at anytime! Save it as PDF for later use!

Try unrolling a thread yourself!

how to unroll video
  1. Follow @ThreadReaderApp to mention us!

  2. From a Twitter thread mention us with a keyword "unroll"
@threadreaderapp unroll

Practice here first or read more on our help page!

More from @ramannoodlez

Feb 19
How technical do you need to be to be an Engineering Manager?

Most people will tell you VERY.

I think not. You can be an avg engineer + a great EM. In fact, if you’re too technical of a manager it could hurt you.

Speaking as a software engineer turned manager, here’s why:
Engineering Managers’ primary responsibilities are two-fold:

1. Steer engineers to build the right things
2. Retain, hire + promote engineers

Let’s dig into the skill set you need for each one.
To build the right things, you need to know:

- the problem it’s solving
- system capabilities + blockers
- how the user will interact w it

Do you need to be extremely technical to do this? Absolutely not!

You need a *good enough* understanding of the tech. What does this mean?
Read 9 tweets
Feb 17
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

Now we could problem solve on each one.
Read 5 tweets
Feb 13
Here’s the problem with 1:1s as an engineering manager:

Most engineers don’t come to 1:1s with set agendas, so it turns into you talking for >30% of the time.

🤔 As an EM, how do you make the most of 1:1 time for your direct report?
1:1s are the time for you and your DR to connect. Most managers use this time to ask about ongoing project status.

Or even worse, you may find yourself talking most of the time!

Leave project updates to stand-ups.

Create a 1:1 structure that lets DRs take the lead.
First, creating a running agenda doc shared between the two of you and write down EVERYTHING.

Encourage them to add to it before your 1:1.

After some time you’ll have historical context that will help with promos + if they change managers.
Read 11 tweets
Feb 9
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.
Read 11 tweets

Did Thread Reader help you today?

Support us! We are indie developers!


This site is made by just two indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member ($3/month or $30/year) and get exclusive features!

Become Premium

Don't want to be a Premium member but still want to support us?

Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal

Or Donate anonymously using crypto!

Ethereum

0xfe58350B80634f60Fa6Dc149a72b4DFbc17D341E copy

Bitcoin

3ATGMxNzCUFzxpMCHL5sWSt4DVtS8UqXpi copy

Thank you for your support!

:(