5 Tips to Improve Your Relationship with Engineers
Photo by Brooke Cagle on Unsplash
It is common for people in departments such as Sales and Customer Success to have a social gap when dealing with the Engineering team. There isn’t much crossover in regards to shared responsibilities and collaborative projects besides general company vision. But as a Product Manager, your role is cross-functional and you need to be chummy with everyone in the company in order to fulfill your duties. I often hear that Product Managers have a harder time connecting with Engineering than they do with Sales or CS, likely due to the PM’s background before coming into this role. And while Technical PMs are on the rise, how do you bridge the gap with dev when you don’t have a tech-heavy background? I have a slightly technical background with a majority of my work experience being from customer service. However, my relationship with Engineering is much stronger than my relationships with Sales and CS. I wanted to share my experience and lessons in hopes it will help you improve your relationship with the engineers on your team (and if you have tips on how others can improve their relationship with Sales and CS departments, please share in the comments!).
Why should you improve your relationship with Engineering?
Developers are in the code and product all day, every day. Many successful startup gurus like Peter Thiel insist on utilizing developers to come up with the majority of product direction. Why? Because they can see patterns within the products they are developing that no one else can see. When I am stumped on solving a problem, I always go to dev first and get their feedback because they can easily think of inventive and strategic paths to get to the solution quicker based on their knowledge of the existing codebase. Involving development as you flesh out your product roadmap ideas result in faster-built products, period. Besides, you can’t spell “devour your competitors” without dev!
5 tips to improve your relationship with Engineering
1.) Take the bullet in public for your dev team. My least favorite human trait is the inability to take responsibility. It shocks me how many people avoid taking the blame or responsibility of “mistakes” when all it does it earn the respect of your peers. People don’t necessarily remember the mistakes, but they do remember how you made them feel. When taking risks and quickly making compromises, I always tell developers, “I’ll take the blame if this goes down.” You can see the tension lift from their body and there is an immediate sense of partnership. At the end of the day, you are responsible for the product. Even if a developer has caused a delay in a release, (you can handle it privately if necessary) you should always try to take the bullet publicly to earn trust and respect. I assure you, the faster you take responsibility for a mistake, the sooner people forget about it and move on, but dev will always know that you have their backs. And when dev knows your ass is on the line too, you become an honorary member of the team.
I’m a fine Product Manager but an even better meme maker
2.) Respect development’s time and energy. This one may seem obvious but it isn’t for those who aren’t familiar with the work that goes into developing a product. Missing dates and removing already-developed tasks from a release is sometimes necessary, but it hurts dev the most. One time, I led a huge product release that took a few months of 60+ hour weeks and weekends for dev to finish in time. When we were getting ready to release it, completely electric with excitement, I heard from an exec in a different department that they weren’t ready and to push the release out a month or two. The other departments had no idea why this would be a problem. In fact, they thought they were doing dev a favor by giving them more time. In reality, it was completely devastating to morale because dev pulled long nights and weekends to get the release done on time and we ended up having to sit on it for an entire month. And while this is an extreme example, making a habit out of moving dates and changing the spec of a release can really lower the morale of your dev team. Be aware of this, communicate with other departments, and defend engineering’s time. Understanding what offends and upsets development is so important for the success of your company. That being said, celebrate the wins when you can. Getting a release out on time feels great and gives everyone a sense of accomplishment. Try your best to identify and resolve any possible external or internal obstacles that could get in the way of a successful release.
Call me Father Karras cuz I’m gonna exorcise some demons
3.) Don’t talk shit on the product and protect engineering from those who do. Software products are not perfect. It’s easy to want to be frustrated when your own product is being difficult. Regardless of whether it’s an annoying little bug or a dusty set of features that no one uses but you have to upkeep, complaining about the product to those who have built it or have to maintain it is not a good way to make friends. Beyond watching how you yourself interact with the dev team, you need to watch others as well. There is often a disconnect between dev and other customer-facing departments which can create the illusion that development is just a sweatshop churning out whatever feature they’re told. A dramatic analogy, I know. But it creates an assumption that developers are disconnected from product criticism because all they are doing is building what they’re told…right? Wrong.
Customer-facing departments can complain ad-nauseum of the annoying facets of the product that they hear from customers. This is completely normal and expected of these departments, but they don’t realize that the people behind the actual product are, well, people. Therefore, you should act as a barricade for these complaints. You can absolutely lend an ear to these departments, sympathize with them, and consider possible solutions if necessary. But often, the main purpose of venting is just to be heard and validated. Don’t let others venting about the product get to those who build and maintain it.
Pour one out for my devs
4.) Block ad-hoc requests. Make it a habit of protecting your dev team from getting distracted by ad-hoc requests coming straight from other departments. You need to intercept these as they come, investigating and prodding into these requests, while your engineering team can continue to work without distraction. What may seem like an easy-to-handle request from CS’s point of view can throw a developer off course, get them distracted by something that doesn’t add value, and push them away from important projects. You need to be the barrier and mediator for these departments. If you make it a habit of fielding off ad-hoc requests to protect a developer’s time and energy, you will win their trust. And by doing so, you create a reverse boy-cried-wolf scenario which will give you credibility when the time comes that you actually have to cash in an urgent favor for an ad-hoc request to be developed (it happens).
Yeah sex is great, but have you ever said “No” to a feature request?
5.) Have fun and be authentic. This isn’t only true for handling developers, but good for handling people in general. I try to use humor and vulnerability to connect with people and create a lasting relationship with them. Owning up to mistakes, sharing your hardships, and being authentic is a fast way to make connections. As an extrovert, it is easy for me to be publicly vulnerable, gregarious, and socially comfortable. But I have realized that regardless of how nervous you are of making those social risks, making them helps others take risks too. I find that using comedy like self-deprecation humor or vulnerability like showing your emotions and being honest makes delivering any kind of news a lot more palatable. If you make personal connections with the people on your team and tailor your communication methods to best suit their needs, it is a lot easier to keep morale up and get shit done.
I’ve always wanted to be a clown but Product Management is a close second.
Conclusion
As a Product Manager, it’s hard enough as it is always playing the middle and trying to keep everyone happy. Improving your relationship with the Engineering team will not only make your job so much easier but also fulfill you! There are so many things you can learn and benefit from by establishing closer relationships with engineers. As you improve on these relationships, they too learn from you and take on product-focused traits that end up helping your job in the long-run.
