Empathizing with Engineers
One of the most critical value multipliers that a product manager can bring to the table is the ability to empathize with their engineers.
A product manager who deeply understands their engineers can unlock value in many ways:
- Ensure that the highest-value functionality is built in the most effective way
- Unblock and accelerate engineers in their day-to-day work
- Provide engineers with business context and user context
- Create a sense of meaning, purpose, and progress for engineering teams
- Empower engineers to make decisions without the PM’s involvement
Most aspiring product managers and new product managers understand the fundamental importance of engineering.
However, I find that they typically bring the wrong lens to the conversation.
I frequently get this question: “how technical do I need to be as a product manager?”
I honestly don’t think you need to be technical at all to be a product manager.
I have an undergraduate degree in Business Administration, yet I’ve successfully delivered highly-technical
integration products and platform products alongside teams of 20+ engineers.
I certainly don’t know how to code, and I certainly can’t read code either.
Yet, my engineering teams regularly tell me that I’m one of the most effective product managers they’ve worked with. Why is that?
Because engineers are just like any other stakeholder. When you empathize with stakeholders, you deliver outsized impact.
After all, stakeholders are human beings with their own dreams, ideas, concerns, pains, and perspectives. By understanding the human being behind the role, you can transform every interaction you have from tense conflict into fruitful collaboration.
When you treat engineers as colleagues and as human beings, you can quickly establish engineering empathy, and that dramatically amplifies your impact and your effectiveness as a product manager.
First, I’ll share why you don’t need to be technical to work with engineers.
Then, I’ll share my own learnings of what engineers look for in product managers, based on my own experiences.
Note that my learnings apply only to me; your mileage may vary because you’re working in a different context. Engineers are people, and you shouldn’t stereotype or generalize people, even if the stereotype is positive.
You Don’t Need to Be Technical with Engineers
Let’s take a step back. What kinds of colleagues do product managers work with? Here’s a non-comprehensive list:
- Engineers
- Designers
- User researchers
- Data analysts
- Quality testers
- Sales
- Marketing
- Support
- Legal and compliance
- Information security
Let’s put engineers aside for a moment.
Product managers don’t need degrees in human-computer interfaces or graphic design to work with design teams.
Product managers don’t need degrees in psychology to work with user researchers.
Product managers don’t need degrees in data science or statistics to work with data analysts.
Product managers don’t need degrees in law to work with legal and compliance.
So why would we ask product managers to have degrees in engineering to work with engineers?
One reason why some companies have this requirement is due to the history of Silicon Valley.
10 or 20 years ago, back when product management was a new field, most product managers were ex-engineers. Why? Because engineers discovered that they needed product managers to handle the business context and the customer context.
But that’s history. It’s the past.
In today’s world, some of the most effective product managers I know come from literature backgrounds, anthropology backgrounds, communications backgrounds, and sociology backgrounds.
And the reason why those kinds of backgrounds are so effective in product management is that those backgrounds require deep empathy for others.
You can’t make the correct tradeoffs as a product manager if you don’t have a clear understanding of customer context, business context, and engineering context.
And, you can’t get that kind of context if you don’t have empathy.
Here’s the thing: engineering context doesn’t require a degree in engineering.
It simply requires deep empathy and relentless curiosity.
Regardless of what some organizations may demand, you do not need to have an engineering degree to be a successful product manager at many different organizations.
By using the three cornerstone methods below to establishing stakeholder empathy, I’ve established a deep appreciation and understanding of my engineering counterparts:
- Informal interactions
- Formal interviews
- Regular checkpoints
Using these touchpoints, I’ve gathered a strong understanding of how I can best empower my engineering teams. I’ve learned which behaviors are effective and which behaviors are ineffective for the engineers that I work with.
You can also learn how other product experts deal with their engineering teams within the PMHQ community.
My Experiences with Engineers
Most engineers have worked with product managers before. So, if you ask them what they would like from a product manager, they’ll have fantastic perspectives.
And, if you ask them about what kinds of product managers drive them crazy, you can also ensure that you don’t replicate those behaviors.
Here are my own findings of what my engineers want from me.
What Do Engineers Want from Product Managers?
In working with various engineering teams, I’ve found that different teams prioritize their wants and needs differently. However, in general, my engineering teams expect the following from me.
The most crucial information that an engineer will want to know is: “Why does my work matter?”
A highly competent engineer needs to know the following information to gauge whether their work matters and in what specific ways can it make the most impact.
First, they need to know who is using the functionality. They need to have a clear understanding of the user personas that they need to support, and they need to know what other tools and functionality they use.
So, the more context I can provide around various user personas, the more I can empower her to make the right decisions when optimizing for particular factors over other factors.
They also need to know why the user is using our functionality. In other words, they need to understand the value proposition of our product.
What do our users love about our product? What do our users hate about our product? Why are they using it and what are their alternatives? What other products of ours are they using, and why, and how?
On top of that, they needs a clear understanding of why this use case matters to our company. Just because it solves a user need doesn’t mean that it enables our business to move forward.
The reality is that businesses need revenue to survive. Without revenue, businesses cannot sustainably and scalably solve pain for their customer base. If this use case doesn’t drive revenue, then we need to focus on something else that will drive value for us and for our customers.
That means that I need to bring a clear perspective on how this use case increases the value of our product, how it increases the value of our company, and how it increases the willingness of our customers to pay us for our products.
They also need to know what the company’s vision and strategy are and how our roadmap and functionality fit in.
As soon as they have a clear understanding of the vision and the strategy, a highly competent engineer will understand how to optimize their decisions accordingly and how to work with others to ensure that everyone’s decisions align to successfully complete a job.
Furthermore, they’ll feel empowered as part of a deeper, more meaningful mission, which enables them to push through times of uncertainty or frustration.
After all of the above, a highly competent engineer also needs to know whether their proposed approach is solving the problem.
It’s my job to bring the user’s context and the user’s story to life. After all, all solutions come with tradeoffs, and all solutions create pain in other ways.
A highly competent engineer expects their product manager counterpart to clearly lay out the downstream impact of the proposed solution, across multiple systems, workflows, and features.
A highly competent engineer also understands that they need deep time to focus. Therefore, they will expect me to set expectations for upcoming work so that they can plan for it accordingly. They also expect me to control the flow of information appropriately so that they get the right information at the right time, whether through Slack channels or through in-person meetings.
They will expect their product manager counterpart to lay out clear principles for how they prioritize work as a unit and team, and to have clear reasoning for why we’re making the tradeoffs that we’re making.
A highly competent engineer expects their product manager counterpart to communicate feasible timelines to customers, business counterparts, and engineering teams.
On top of that, a highly competent engineer expects that I will protect the engineering team from thrash (i.e. last-second changes in priority) and that projects are logically sequenced to unlock maximum value in minimum time.
Finally, a highly competent engineer expects that I will empower them to make independent decisions and that I will arm them with context so that they aren’t constantly relying on me.
If I fail to bring them enough context upfront, I’ll wind up slowing down their ability to work.
Even worse, if I bring the incorrect context or if I communicate the wrong context, they will naturally build something that doesn’t meet the true needs of the customer and the business.
So, it’s absolutely crucial that I bring them accurate context as soon as I possibly can, that I admit areas where I have insufficient context, and that I seek out the missing context ASAP to feed it back into their decisions.
What Do Engineers Dislike About Product Managers?
In empathizing with my engineering teams, I’ve found a couple of product manager traits that seem to be universally disliked.
First, my engineers would prefer that they don’t need to spend time translating everything for me. If they explain something once to me, they’d prefer that I remember it.
In practice, I’ve found that when I keep good notes about engineering decisions, engineering constraints, system architecture, mental models, and terminology, I can significantly decrease my onboarding time, and I can save my teams lots of heartache in needed to continuously re-educate me.
That doesn’t mean that I shouldn’t ask questions. In fact, I’ve found that my teams hate it when I don’t ask questions early enough because that means that I’ve lost out on a bunch of critical engineering context.
My teams love seeing their product manager counterparts demonstrate genuine curiosity towards all things technical. And of course, the best way to demonstrate curiosity is to ask thoughtful questions.
What does this mean for me? It means that I should ask lots of questions upfront, take notes, and internalize my learnings so that I don’t repeat questions!
Second, engineers want to know that their work is valuable. They don’t want to be tasked with meaningless work for the sake of working.
I’ve found that sometimes product managers will create work that doesn’t actually drive value, because they want to ensure that engineering teams feel that the product manager is “useful.”
Don’t do that.
Engineering teams have nearly infinite backlogs of technical work that they can tackle in the meantime, and this technical work enables them to build products even faster in the future.
If you give them low-value work and you prioritize it as high-value, you’re robbing from the customer, from the company, and from yourself. Just don’t do it.
Admit that you don’t currently have product work to tackle, and let them focus on paying off technical debt.
In other words, ensure that you bring them only high-value work that makes the user’s life better.
Third, I’ve found that engineers are frustrated when product managers frequently change their priorities. This can be especially problematic mid-sprint, because it throws off everyone’s workloads and estimates.
Every time you thrash the team, you destroy momentum and focus. Be consistent with your principles in terms of prioritization, and protect the sprint.
It’s your job to let customers and client-facing teams know what’s feasible. You shouldn’t accept every inbound work item.
And finally?
Engineers hate it when they aren’t treated as people. Everyone deserves to be acknowledged as a human being worthy of respect and attention.
While it’s true that all corporations see all employees as resources, the word “resource” is dehumanizing.
Everyone has different interests, different skill sets, different growth trajectories. People aren’t fungible – that is, you can’t trade one person for another.
So, when discussing workload balance, check in with each engineer as a person.
Does this initiative make sense? Does it move you towards your growth goals? Does it make sense for you to swap ownership with someone else? Are you comfortable with this set of work, or is there a better way for us to sequence this work across teammates and across sprints?
Give people ownership and optionality. They’ll buy in more strongly that way, and their commitments will mean so much more to them, to you, to your customers, and to your business.
Give people visibility over the next couple of sprints. Let them know what kinds of work will likely come up next, and why that work is important.
Give people agency to shape the way the team works together. In retrospectives, genuinely ask each person how we can all improve as a team. Ask for feedback on how you can serve their needs better.
Treat others the way you want to be treated. You aren’t just a cog in the machine, and neither are your engineers.
Closing Thoughts
In general, I’ve found that for the engineering teams I work with, they care the most about context.
Context comes in many flavors:
- Business context – industry trends, business priorities, revenue and costs, competitive landscape.
- Customer context – pains, personas, promoters and detractors, customer goals and roadmaps.
- Product context – how this feature impacts the rest of the product portfolio, why particular decisions were made in the past, principles for making future decisions, upcoming work, and why that work matters.
Why do my engineers want context?
They want to ensure that they can independently and confidently make the right call across their engineering decisions.
They want to feel that they’re a part of something much bigger than their code or their features.
They want to know that the company is tackling something worthy of their time, energy, and deep thought.
They want to know how to best serve the customer. After all, they understand that without the customer, they would have nothing of value to build.
I’ve found that by providing as much context as I can, and by being relentlessly curious about their work and their decisions, I’ve been able to establish strong working relationships with my engineering counterparts.
That enables us to move quickly as a team and to ensure that we’re working towards the same goals together.
Rather than spending my time learning SQL or React, I’ve found that stakeholder empathy is one of the most powerful skills that I can learn.
Learn what drives your engineering team. Learn what they love and what they hate.
Then, serve those needs. Give your immediate attention and your fullest energy to serving their pain points.
To me, all of my stakeholders are customers. It’s my job to serve them. And that includes my engineers.
It’s absolutely worth my time to dive deep into their pains, so that I can serve them in the most effective way possible.
Don’t wait on “becoming more technical.” You can act right now to provide multiplicative value, simply by empathizing with your engineers.
Again – don’t just reuse my learnings! Engineers are people, and every person has different pains. Go speak with your engineers to learn what their needs are.
I’ve met engineers who would prefer not to be distracted by context. For them, the highest value a product manager can provide is project management, planning, certainty, and shielding from thrash from other stakeholders.
I’ve met engineers who don’t have an engineering manager, and they look to the product manager for engineering management. For them, the highest value a product manager can provide is career growth, technical advice, and workload management.
It all depends on who you’re working with. Be empathetic. Understand the pains of your specific engineers, and serve those unique pains to the best of your abilities.
It’s worth the time and energy.
Additional Resources
Here are some additional resources on how to effectively work alongside engineers:
Have thoughts that you’d like to contribute around empathizing with engineers? Chat with other product managers around the world in our PMHQ Community!
