An HSP Perspective on Getting Along with Your Developers

One of the core traits of a good Product Manager is the ability to get along with people. You have to be a people person. No one is going to listen about your vision for your product if you can’t convey your passion to others in a way they can buy into.

An HSP who is also introverted often isn’t a people person. They enjoy being alone in their own head.

It seems counter-intuitive, but I’m an HSP Introvert and I’m a successful Product Manager. Let me tell you how.

I am one of those people who prefers to sit with her own thoughts and my colleagues can attest to it — I often talk to myself at my desk when in the midst of research or a problem solving exercise. But, this isn’t the only way I function. Sitting inside my own thoughts works well when I’m working on strategy. It doesn’t help when I’m working with other teams, including developers. Instead, I deploy a different HSP Introvert trait.

I’m highly empathetic and my capacity to put myself in another person’s shoes allows me to get along really well with my colleagues. I don’t just like sitting in my own head; I like sitting in other’s people’s heads too.

When I first started my current job I really struggled to get along with the lead developer on my team. I have never had this problem before. I’ve always worked really well with software engineers and this is the main reason I’ve stayed in the technology game. I love learning from them. I love their passion for problem solving through code. And most of all I love that most communication is an exercise in deciphering meaning, as if every conversation were a crossword puzzle. Code speak = clue; Business Translation = answer.

My lead developer and I are polar opposites — I’m a Type A get’er done kind of person and he’s a laid-back guy who is more productive the less he is under pressure. When I first started in my current role I had to launch a new video platform on our network of sites. It was a high-pressure eight months to get this project completed. We butted heads a lot during this period and most of it could have been avoided if I just spent more time putting myself inside his head.

It took time but eventually I realized, he worked better if I let him be most days. When I did, I got amazing feedback. When I searched and prodded for feedback I didn’t get anything in return, but when I let the chips fall where they may I got the feedback I was looking for and, sometimes, solutions to problems I hadn’t even known were problems. For example, he changed the structure of how certain functionalities of our video players could be modified so that changes could be made without having to go through a full release cycle. A minor change, with little to no impact to other systems, could now be made within an hour instead of a week. The change could be made, I could monitor, and validate my learning much quicker.

Understanding how your developers think is going to help you improve communication as a Product Manager. This was my path to building mutual respect with my key counterpoint on the development side.

This advice isn’t even limited to developers. As a Product Manager, you have to work with all different departments in an organization and the same methodology applies. A little bit of empathy can help build better products.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.