A product manager’s guide to working with engineers
Many years ago, I interviewed at a startup in Berlin. I still remembered how the hiring manager described what a PM’s job was: “You’re there to unblock the Engineers. So if they’re hungry, it’s your job to buy them pizza.”
I was young and impressionable back then, so I only nodded along. Even though I never got as far as feeding the engineers because apparently they’re unable to respond to their own hunger, I certainly took a similar approach when I was early in my PM career. I thought my job was to make engineers’ lives easy and happy. I bent over backwards trying to attend to their needs.
As I matured in my understanding of product management, I realised that trying to keep all engineers happy is a sure way to be a miserable PM. A product manager should be a multiplier of the engineering resources. To quote Liz Wiseman: Multipliers are the leaders who use their intelligence to amplify the smarts and capabilities of the people around them.
I enjoyed creating the 4-Ts of Codifying Product Discovery, and this one also happens to be acronym-able. (Yes, I also invented my own word.) So here goes.
ARISE: A Product Manager’s guide to working with Engineers
A| Treat them like Adults
In a relationship or an interaction, there are two possible dynamics:
- Parent-to-child, where one person is guiding, nurturing, giving orders or directions, whilst the other person is asking for attention or seeking for validation.
- Adult-to-adult, where both parties are equal and complementing each other.
When I learned this concept from my coach, I realised that my relationship with the engineers in my team were parent-to-child. Maybe it started with me behaving like a parent who wanted to keep them safe and happy, so they became childish and demanding. Maybe it started with them acting like children and I succumbed to take the parent role.
If this is the first time you heard about this concept, let me give an example.
In the first picture, the engineer complained about something without taking the responsibility to think of ways to solve it. The PM then willingly took over that responsibility. Now, this is problematic in many ways:
- The engineers become dependent to the PM and it creates a precedent that it’s a PM’s job to solve all the engineers’ problems.
- It distracts the PM from doing more strategic work.
In the second picture, the engineer stated the problem clearly and asked for something clearly. The PM offered her help. It’s a balanced relationship.
The only way you can break an existing parent-child relationship is by start treating each other like an adult. Using the example above:
Engineer: I can’t work on this ticket because I’m not familiar with this codebase.
PM: What’s the ideal situation for you?
Engineer: Well, somebody else can pick up this ticket. Or I need to talk to somebody who’s more familiar with this codebase, but it’ll take longer.
PM: This project has no hard deadline, and it’s better for the long term if you familiarise yourself with this part of the code. What help do you need from me to do that?
Engineer: Can you give an intro to team X? I’m new and not sure whom to reach out.
PM: Sure thing.
Notice how the PM refuses to solve the problem for the engineer, and acts more as a sounding board to help them get to the solution.
R| Recognise the different types of individuals
I’ve worked with engineers who are hard-core Agile followers. They hated having high-fidelity design on a ticket. They wanted to be involved in all design and research sessions. They wanted to meet the stakeholders and gain all the context.
I then moved to a different team and the engineers in this team hated being distracted from their focused coding time. They wanted high-fidelity design even before they created the technical design. They preferred clear roadmap a quarter ahead, whilst my previous engineers already objected a rigid plan a sprint ahead.
There’s no one-size-fits-all. Within the team, you’ll also encounter some engineers who love being involved in early discussions, and some who like getting their heads down in the code. Recognising their strengths and preference rather than assuming will help you multiply their impact.
That said, it’s also their responsibility to act as an adult, and tell you how they like to work.
I | Involve them early in your thinking process
This is a fairly common advice but I thought it’s worth repeating. As a PM, it’s your job to find a solution that is desirable by the users, viable for the business, and feasible to build with the resources and constraints you have. Engineering input on what’s feasible to build is invaluable and it’s important to get it early.
There are multiple benefits of involving engineers early:
- You get to know what’s possible to build. No point of designing something that can’t be built at all.
- You get to identify some efficiency gains, i.e. small tweaks to the design that doesn’t compromise the user experience, but will cut development time significantly.
- The engineers get to understand the context and longer-term thinking of the solution, which allows them to create a better technical design.
- The engineers are more likely to be motivated by the mission of this solution. They’re not just bricklayers; they know they’re building a beautiful c̶h̶u̶r̶c̶h̶ pub.
S | Give them Space to progress
Many companies implement Engineering Progression Framework such as this one from Dropbox. If an engineer wants to move up in the career ladder, they need to move beyond coding and start developing other skills, such as planning and leadership.
We already talked about treating engineers as an adult. In this section, we take it one step further: give them the opportunities to take the lead role.
You can call it Epic Lead, Feature Owner, or Project Owner. The key is that this person is accountable for the delivery of a specific sets of tickets. They’re responsible to create the technical design, break the requirements down to tickets, and make sure the other engineers have all the context they need to deliver. They’re also responsible for managing and flagging risks and blockers to you (the PM) proactively.
The Engineering Manager in my team, Pedro Lopez, wrote this detailed guidance of a role of Project Owner. Totally worth reading if you’re thinking to implement this in your team!
Giving this delivery responsibility to the engineers is also great to free up your time and brain space to focus on the unique value you bring as a PM.
But Debbie, you might say, you talked earlier about recognising different individuals. Some engineers in my team don’t want to progress to the leadership role; they like to stay as an IC (individual contributor). Should I still ask them to become a lead?
I would argue that even in the IC progression framework, Staff or Principal Engineer still needs to showcase leadership, risk management and organisational skills. They might need extra coaching and support, which brings me to the last point.
E| Invest in good Engineering Managers
It’s a bit cheating to include this point in a PM’s guide to working with engineers, but PMs usually have a say in influencing the company to hire Engineering Managers (EMs). It’s literally one of the best things that could ever happen to you, as a PM, and to the engineers in your team. I’ve worked in many different squads and having a good EM makes such a difference.
Engineers are one of the most in-demand roles nowadays. Without a dedicated effort to nurture them, it’ll be very hard to retain them.
You can also promote your existing engineers to become an EM, but it comes with a caveat. I’m a huge fan of internal progression, but I’m not a fan of promoting people without giving them the required support to succeed. Very few companies have a proper training structure for new managers, which is sad. “It’s like they’re rewarding you for performing as an IC by setting you up for failure as a manager,” one engineer in my team said.
Summary
As a PM, your engineers can make or break your deliverability. It’s one of the most important working relationships you need to get right. I hope this ARISE framework can help you create and nurture constructive relationships with your engineers:
- Treat them like Adults
- Recognise different types of individuals
- Involve them early in your thinking process
- Give them Space to progress
- Invest in good Engineering Managers
👋 Hi, I’m Debbie. I’ve been building products and solving customer problems in tech companies for over a decade. I write about how a PM can bring 10x value to their company, not just 10% improvement. Stay ahead of the game and get insights delivered straight to your inbox — subscribe to my newsletter today!
