Establishing Technical Empathy with Engineers
Empathy is a crucial value multiplier for product managers, especially when it comes to understanding and collaborating effectively with product engineers. But, while both aspiring PMs and newly-minted PMs grasp the importance of effective collaboration with their engineering counterparts, they tend to approach the topic from the wrong perspective.
In my PM coaching practice, I commonly receive questions like these:
How technical do I need to be as a PM?
Do I need to know how to code as a PM?
How will my engineers respect me if I don’t know how to code?
What coding languages do I need to know as a PM?
How do I learn how to architect a technical solution?
These kinds of questions miss the point entirely. You don’t need technical expertise to successfully cultivate technical empathy and establish mutual respect with your engineers.
I’ve successfully delivered technical platform products and product integrations alongside teams of 20+ engineers; yet, I never needed to know how to code to succeed in these roles. And, many of the most effective PMs in my network are those who don’t know how to code either.
How are these PMs so effective in working with engineers when they don’t know how to code?
They’re effective because they have technical empathy. That is, they understand the challenges that engineers face, and they’re excellent at eliminating these challenges and empowering their engineers to succeed.
In other words, you can cultivate technical empathy without needing to know how to code firsthand. In fact, I’d argue that technical empathy is even more important than knowing how to code in the first place!
That’s why I’ve created this deep dive on technical empathy. In this guide, we’ll first define what technical empathy is, and why this technical empathy is valuable for product managers. Then, we’ll bust the myth that the only way to get technical empathy is to know how to code.
Afterwards, we’ll discuss effective behaviors for cultivating technical empathy as well as ineffective anti-patterns to avoid. We then conclude with key takeaways for product managers.
Defining technical empathy
Technical empathy is all about understanding the challenges and tradeoffs that engineers encounter in their day-to-day product development work, and using this understanding to help our engineers do the best work that they possibly can.
We can boil technical empathy down into two components:
How to set up engineers for success
How not to interfere with engineers inappropriately
To set our engineers up for success, we should recognize that every engineering decision is a tradeoff that balances speed of execution, quality of product, and long-term scalability. There are no free lunches; every technical decision has both short-term consequences and long-term consequences for the business.
As an example, we could ship a quick-and-dirty implementation within 2 weeks that causes our future velocity to slow down by 10%; or, we could ship a thoughtful implementation in 3 months that causes our future velocity to increase by 5%.
There’s no universally correct answer here! Sometimes, you need to take the quick and dirty path to address an immediate and urgent need; other times, you should take the scalable path.
The key is that your engineers cannot make this decision without you - they need your input as a product manager to decide which path to take, on behalf of your customers and your business counterparts.
Therefore, to help our engineers make the best engineering decision for the product, we need to provide them with business context and customer context.
By providing the broader goals and objectives of the product, as well as the needs and expectations of our end users, we enable our engineers to make informed technical decisions that deliver value to the users, capture value for the business, and align with the long-term vision of the product.
Furthermore, technical empathy requires us to understand the bottlenecks that engineers might run into during development.
Here’s a non-exhaustive set of challenges that might cause engineers to run into friction:
Dependencies on other teams to finish some set of work first
Code reviews from other engineers that keep getting deprioritized
Technical proposal approvals from other tech leads
Lack of documentation for key functionality
Automated test suites that take too long to complete
One of the best ways to gain exposure to “what kinds of challenges come up for my engineers” is to simply ask during sprint retrospectives. After all, each team has a different set of challenges that they run into, and these challenges change over time.
Through regular retrospectives, you’ll quickly identify patterns and/or processes that are slowing the team down. By continuously removing these barriers and bottlenecks, you gain the trust of your technical counterparts.
On the other hand, we need to make sure that we’re not interfering with the subject matter expertise of our engineers. Certain technical decisions, such as architecture or programming language choices, fall within the domain expertise of our engineering counterparts.
It doesn’t really make sense for product managers to unilaterally decide which functions should be bundled together into which microservices, or whether particular API calls should be synchronous or asynchronous, or what the typing of a given database field should be; our engineers know better than we do!
When we incorrectly intervene in these technical decisions as PMs, we create unnecessary friction, cause confusion, and hinder productivity.
Even if you were previously an engineer or an engineering manager yourself, you should not make technical decisions for your engineers, because your engineers have much deeper context about the specific problem to be solved.
And, if you disempower your engineering team by stepping on their toes, they will start to ask you to make every single technical decision, which ultimately slows down the team and reduces the ability for your product to scale.
So, we now have a grasp of what technical empathy means - we want to identify the places where we can help our engineers the most as PMs, and also the places where we definitely shouldn’t interfere as PMs. But, what’s the value of having technical empathy as a PM?
The value of technical empathy
By deeply comprehending the needs of their software engineering counterparts, product managers unlock significant value across multiple vectors:
Unblock and accelerate engineering velocity
Empower engineers to make decisions independently
Provide engineers with the right business and customer context at the right time
Encourage engineers to raise questions proactively about key technical decisions that require more business and customer context
Create a sense of meaning and purpose for engineering teams
As you might imagine, product managers who demonstrate technical empathy are significantly more impactful and more valuable than those who do not yet have technical empathy.
But, at the other extreme, too many aspiring PMs and early-career PMs believe that they need to know how to code, because they mistakenly believe that the only way to acquire technical empathy is to first acquire technical expertise.
Let’s address that myth and break down why coding is not a valuable skill for the vast majority of product managers.
The myth of the PM who codes
To work effectively with engineers, you don't need to possess an engineering degree, nor do you need to know how to code.
Consider this fact: product managers must work alongside specialists across multiple disciplines, including designers, user researchers, data analysts, legal and compliance teams, information security experts, marketers, finance teams, and more.
Yet, we don’t ask PMs to have degrees in human-computer interaction to work with designers, nor do we ask PMs to have law degrees to work with legal teams, nor do we ask PMs to have marketing degrees to work with marketers.
Similarly, product managers don’t need engineering degrees to work with engineers!
In fact, the most successful product managers I know come from humanities-based backgrounds such as literature, anthropology, communications, political science, and sociology; or, they come from customer-facing roles such as consulting, deployments, operations, and customer success.
Remember that the point of a product manager is to make informed trade-offs based on customer, business, and engineering contexts while also dealing with incomplete information and competitive pressures; these tradeoffs require deep empathy for others. Both the humanities and customer-facing roles happen to be excellent ways to cultivate these key traits.
And, to strengthen my point that you don’t need to code as a PM: I’ve spoken with dozens of product managers at Google, Facebook, Microsoft, Amazon, and Apple, and none of those PMs write code on a regular basis. I’ve also spoken with hundreds of product managers working in startups across dozens of verticals and geographies, and none of those PMs code on a regular basis either!
Why does the myth of “the PM who codes” exist, then? To answer this question, we have to look at the history of our profession.
20 to 30 years ago, most product managers really were ex-engineers.
Back when product management was not yet a known profession, groups of engineers identified the need for a dedicated role that could handle customer discovery & prioritization as well as collaboration with business stakeholders.
Within these groups, some engineers courageously raised their hands to take on this new role while staying embedded with their engineering teams. And, this new role eventually formalized into the role we know today as product management.
The earliest wave of PMs were mostly engineers due to sheer proximity. But, the most effective PMs in the world today are no longer limited solely to ex-engineers.
As product managers, we must keep in mind that our profession continues to rapidly evolve. While product management was birthed within engineering groups, product management is now a distinct and separate discipline that requires technical empathy but no longer requires the ability to code.
Here’s an analogy: today, most modern farmers no longer use ox-drawn plows to till their fields. Modern farmers rely on tech-enabled tractors and automation to sustainably maximize yield.
If you forced today’s farmers to use ox-drawn plows to align with their historical skills, tools, and experiences from 100 years ago, they would fail miserably at doing so – even though their fields today are 2-10x more productive than the fields of the past!
Similarly, as product managers, we cannot let our history weigh down our future evolution. While it’s tempting to learn how to code as a PM, I promise you that the vast majority of PM hiring managers would ask you to prioritize a different skill set to focus on instead.
So, now we understand why PMs were historically ex-engineers, and why today’s PMs are no longer required to know how to code. Let’s now discuss how to effectively cultivate technical empathy with our engineering counterparts.
Effective behaviors for cultivating technical empathy
Below, I share four ways to cultivate technical empathy with your engineering partners:
Help engineers understand their impact
Create a dialogue around product vision, strategy, and roadmap
Share business context and customer context
Provide autonomy for technical decision-making
Help engineers understand their impact
Engineers want to know why their work matters. They need a clear understanding of who uses the functionality, the user personas they need to support, and the user's perspective. They also want to know why users choose our product, what they love or hate about it, and how it contributes to the company's goals.
By understanding the kinds of information that your engineers seek from you, as well as understanding how they’ll use that information to inform their technical decisions, you’re much more likely to cultivate technical empathy and deepen your mutual respect for one another.
Create a dialogue around product vision, strategy, and roadmap
Engineers expect product managers to provide them with the vision and strategy of the product, helping them understand how their work fits into the bigger picture. They want to know the purpose behind their tasks and how they contribute to the mission.
By transparently discussing the tradeoffs that went into your roadmap, and by giving your engineers the space to debate your decisions, you empower your engineers to optimize their work and collaborate effectively.
Share business context and customer context
Engineers need product managers to provide them with accurate and comprehensive context. They want to understand the downstream impact of their proposed solutions - not just implications for systems, workflows, and features, but also how their solutions will impact customers and the business itself. They rely on product managers to arm them with the right information at the right time.
Provide autonomy for technical decision-making
Highly competent engineers expect product managers to empower them to make independent decisions. They want to be equipped with the necessary context to make informed choices.
Product managers should provide the necessary information upfront, admit gaps in their own understanding, and actively seek missing context to support their engineers' decisions.
Anti-patterns that block technical empathy
The four behaviors above can help us cultivate technical empathy and gain the respect of our technical counterparts. But, we should also keep in mind that certain behaviors are anti-patterns that cause us to lose the respect of our technical counterparts.
Make sure you avoid the following four anti-patterns:
Failure to establish documentation
Low-value assignments
Repeated thrash and conflicting priorities
Treatment of engineers as resources and not teammates
Failure to establish documentation
Engineers prefer not to spend time repeatedly translating technical concepts for product managers. Keeping good notes, asking thoughtful questions, and demonstrating genuine curiosity can help product managers minimize the need for continuous translation.
By actively listening & taking notes, product managers can decrease onboarding time and save the engineering team from having to repeatedly re-educate their PM counterparts.
Low-value work assignments
Engineers want to work on high-value initiatives that contribute to the growth and sustainability of the company. They don't want to be assigned tasks that lack purpose or drive low-value outcomes.
Yet frequently, I hear product managers say things like “I need to come up with tasks to feed my engineers or else they’re going to be idle.” That never happens; engineers have infinitely many initiatives they could tackle, because they can always reinvest in the technical robustness of their codebase (e.g. refactors, abstractions, configurations, etc.).
Product managers should prioritize high-value work that improves the user's experience and avoids creating tasks for the sake of “progress for progress’s sake.”
Acknowledging the importance of technical debt and empowering engineers to pay off that tech debt is a better use of their time than assigning them low-value work.
Repeated thrash and conflicting priorities
Engineers become frustrated when product managers frequently change priorities, particularly in the middle of a sprint. When we thrash our engineers with ever-changing priorities and deadlines, we disrupt their workflow and we derail momentum and focus.
By using consistent prioritization principles, and by protecting the sprint, we can help our engineers work effectively. We shield them from the fear that their work might be thrown out the window at a whim, and this confidence enables them to accelerate their velocity.
Our responsibility as product managers is to manage inbound requests and to reset expectations; we simply cannot pivot on a dime to do “the latest thing” or “just a small fix.” We’re responsible for educating our customers, stakeholders, and executives that we use a principled approach to slot in work for upcoming sprints, and that we’re not going to break the sprint unless we have a critical outage on our hands.
Treatment of engineers as resources and not teammates
Engineers are human beings, and all human beings dislike being treated as cogs in a wheel rather than as individuals with unique skills, interests, and growth trajectories.
While corporations and annual planning cycles may see employees as resources, we need to acknowledge the humanity of each of our teammates.
Product managers should engage in discussions about workload balance with their engineers, and partner with engineering managers to consider the personal interests, growth goals, and preferences of each engineer on the team.
Giving engineers ownership, visibility into future work, and the opportunity to shape team dynamics fosters stronger commitment and satisfaction.
Closing thoughts
Providing comprehensive context across business, customer, and product aspects enables engineers to make informed decisions and feel connected to a larger purpose.
By empathizing with engineers, actively listening to their needs, and adapting accordingly, product managers can establish strong working relationships and achieve alignment within their teams.
And, we can achieve all of these outcomes without needing to learn how to code!
Instead of focusing on becoming more technical, product managers can immediately provide significant value by empathizing with engineers.
That said, keep in mind that every engineer is unique; be sure to actively engage with the specific pains and needs of your specific engineering team.
By prioritizing technical empathy, product managers can leverage their skills to deliver exceptional outcomes and drive effective collaboration across the organization.
Thank you to Pauli Bielewicz, Goutham Budati, Markus Seebauer, Juliet Chuang, and Kendra Ritterhern for making this guide possible.
