The Engineer Whisperer
Lately I’ve been asked a few questions about how to reach and connect with those developers who are so deep into writing and debugging their code, so dedicated to their own vision that they never ask for feedback once they’ve been tasked. Then, in the off chance late in the development stage they are asked to change direction, they either refuse, or become so difficult your job as product manager or program manager becomes a living hell. Sometimes, they even quit, which may be your worse case scenario.
To be frank, I’ve seen this happen many times on projects I’ve worked on, whether it be in product management, shepherding a specific program pre or post-launch, or just trying to help business development when they bring questions back to the engineering team. After many years working with software and hardware engineers, I’ve found three key ingredients are necessary to build a mutually beneficial bridge between engineer and customer. The first is empathy (for the engineers and their work), the second is trust and the third is respect. In fact, I have found them to cascade from one to the other. The second is actually a byproduct of the first, and if it continues in a productive manner, you are then able to build respect. Without their trust and respect, you won’t get very far with engineers.
Developing empathy, definitely a key soft skill, is easiest if the product or program manager has a keen sense of what needs to be done technically. Empathy is gained by focusing on mutual interests and a shared stake in the value of the work at hand, but is nurtured by listening, truly listening to the engineer first, and the customer second. I know this sounds paradoxical as the engineer is there to develop a product the company wants to sell, and the customer’s (or stakeholder’s) requirement should come first, but if you don’t listen to the developer and the vision they have of the problem, you may miss some important benefit that perhaps even the customer hasn’t thought of and marketers are not even aware of. In fact, so many of the products we use today that enthrall us did not come from customer requirements but from creative people with a vision and the means to achieve their vision (through strong engineering followed up by great marketing). By listening closely and asking engineers questions about the technology, their work, their challenges with the project and what they perceive as their value to the product’s end use, you will learn a lot and you will be on your way to establishing the empathy you need to gain their trust.
Likewise, sharing your own vision and institutional knowledge with the engineer also helps as they often feel isolated due to the sheer effort of their own contributions. Sometimes you will agree with an engineer, sometimes you will not. When you do, and you act as their champion to key stakeholders, you have then won their respect as well. Do it repeatedly and you will win their trust. Conversely, you can still win their trust and respect even if you (or upper management) do not agree with them after you’ve established empathy by providing honest feedback followed up by supporting them in any way feasible as they cope with the challenge of working on something they do not agree with, or do not wish to work on.
You may be thinking, “easier said than done” but every real world software and hardware project has trade-offs introduced by the stakeholders or the creatives peppered with the temperaments of those who deliver said products. Many years ago when I was an intern at Bell Labs in N.J., a wise person once said to me “where there is talent, there is temperament.” This truth has not changed in all my working years. Sometimes the higher the temperament, the greater the talent, but sometimes great talent is meek. Regardless, everyone working on a product or program should to be heard, understood and represented. This is both a product manager’s and a program manager’s role.