If you are reading this post, you are likely working with a very difficult engineer or a group of engineers. You have probably tried everything within your power to establish a healthy, productive, working relationship with your engineering counterpart(s). However, nothing you have done seems to have worked.
You need to take control of this situation FAST. You cannot afford to be undermined as a product manager, and you cannot afford any more damage to your mental health.
Regardless of how hopeless this situation may seem, there is always a path forward. Below are tried and true action steps you can take right now to establish a productive working relationship with your engineering team.
First and Foremost: Identify the Pain Area
How Are They Being Difficult? Without understanding the pain area, it’s hard to know where to start the path of resolution. First things first, put a name to the issue. What is the main area of difficulty?
- No Patience
- Demeaning Personality
- Uncommunicative
- Misaligned views & perspectives
- Differences of opinion
- Stubbornness
- Arrogant personality
- The complainer
- The negative nancy
Without understanding the pain area, it’s hard to know where to start the path of resolution. Always ask “Why?” Why are they acting the way they’re acting? Why are they doing the things they’re doing? Try to put yourself in their shoes and see the world from their perspective, after all, you are the Product Manager. In a previous blog, How to Navigate Your First 30 Days as Product Manager I mentioned:
“A PM’s true nature is in building good relationships and becoming influential. It’s more about managing expectations and growing relationships than the actual management of people.”
Team Dynamic
For every type of difficult engineer you may find yourself working with, there are different pain areas and different solutions to be found. Let’s unpack some of the most common personality types you may run into.
The “Arrogant, Demeaning, Stubborn” Type
This usually comes with the territory, especially if you’re coming onto a team that’s matured past a certain level of development — usually after 3-4 years — and leadership decides to bring in product management to become more strategic. I don’t blame these difficult types. They’ve worked hard, spent time developing a relationship with one another, and now all of sudden a new hire is going to solve all the problems? Implement new processes? Who does this person think they are? This feeling of animosity you’re encountering is based on the fact that you’re the new person on the team, while the rest of the group has been working on the product since the beginning. They’re convinced they know what they’re doing.
Solution:
Believe it or not, these are usually the easiest situations to diffuse once you understand the psychology behind them. No one is ever ready for change, and this type may not know how to approach or accept change. In the end, they’re just passionate and protective of the product they’ve worked so hard on.
The key is to harness the passion and energy they’re exuding and use it to your advantage. Bring everyone together and collaborate. Hold a discussion with the team and talk over the following:
- What is the team’s goal?
- What is the team’s vision for the product/company?
- What has worked? What hasn’t worked?
- Share your strategic vision and goal and ask if it could potentially integrate into what’s existing.
- Share how you will keep an open mindset and listen to everyone’s input.
- Share how you want to collaborate and try to make everyone’s life easier by eliminating inefficiencies.
A combination of actively listening to them and ensuring that they understand the “why” of what you’re asking of them will usually defuse the situation. In some best-case scenarios, you’ve shown them that you share their passion and you gain an ongoing advocate.
The “Know-It-All-Always-Got-An-Opinion” Type
More often than not, there will always be one or two engineers out of the bunch that are really good at what they do. Usually, they’re your lead engineers. These individuals have at one point or another built their own product and have moderately succeeded by doing things their way. By “their way” I mean they usually adopt an entrepreneurial approach, thinking outside the box, going against the grain, questioning authority. This means they want to be the PM or PO and resent the idea that there is someone else coming in telling them what to build and when to build it.
Do not fight this personality directly. If you do, they will view it as a personal attack. They will likely respond by actively undermining your influence on their team.
Solution:
These types of situations could get very sticky. If not navigated properly, it can slide into personal resentment on one end or the other (I’ve been the victim and the perpetrator, so I’m not saying I’m perfect here either). What needs to be realized and acknowledged here is that the engineer wants your role as PM. They usually want to take control and take the lead. From my experience, the best course of action is to guide this individual or team toward new prototypes and new developments — let them feel they still have control. You maintain oversight and a level of direction while including them by asking for their opinion and what they feel is the best execution plan. Leverage their desire to be independent and innovative, rather than forcing them into a controlled environment.
The “Negative-Nancy” Type
This type is probably the most frustrating one to navigate. This is the one that will always find a reason to disagree or try to prove your solution isn’t the best option. Usually, this is caused by the lack of inclusion, communication, and visibility of long-term priority and strategy. Too often, poor management keeps engineers in the dark, thinking that they don’t need to know everything, instead of filling them in on the details. In most cases, this doesn’t make any sense. The more they know the better. They are the subject matter experts on how products are built.
Solution:
One word: Inclusivity.
- Include them in discussions about priority and strategy.
- Triage requirement breakdown with them.
- Ask them for their opinions and thought processes.
- Ask them if they have alternatives or new proposals for what they think is important and why they think it’s important.
- Above all, be honest and straightforward.
The last people you want to beat around the bush with are engineers. They don’t have time to play games with you. They’re smart — sometimes too smart. But most of the time they just want to be treated as equals. Remember, they are masters of their world when it comes to understanding the building blocks of how products are built. Share your world with them and they will open up theirs.
Common Product Manager Mistakes When Working With Engineers
Sometimes the state of difficulty when working with engineers isn’t always on them. It may be with the Product Manager or Product Owner. The following are some tips on what PMs can do to help build a stronger relationship between them and their engineers.
PMs Don’t Understand the Technical Challenges
Do not speak to what you do not know. Inexperienced Product Managers tend to make the common judgemental mistake of thinking something is easy when it is not. “It’s just a button, that’s all you need to build for this one requirement.” It’s not just a button. There are a lot of layers behind what engineers do when they do what they do.
“Programming is art with creativity to build something from scratch, with intelligence to deal with the complexity and with grit to solve technical challenges.”
Solution:
As a PM, do your job.
- Learn the technical jargon.
- Understand the technical processes.
- Speak to the level of difficulty of each task and user story.
- Ask for the engineer’s viewpoint, input, and thoughts, especially when it comes to the development timeline.
- Triage requirements with your engineer and design lead to flush out any ambiguity.
PM is Micro-Managing the Engineers
The job of a PM is to help facilitate the progress of the product development lifecycle and resolve any problems that may arise along the way. The main focus is managing the expectation of the outcome of the product. Sometimes this focus can get derailed to the point where management starts micro-managing the body of work instead of staying at concord level facilitating the work.
Solution:
Plan twice. Code once. Understand the role you’re taking on. As a Product Manager, you have to take the lead, facilitate the expectation, and make sure that everyone is on the same page.
- Thoroughly understand the requirements given.
- Challenge requirements that are ambiguous, too broad, or too general.
- Don’t be afraid to ask stakeholders to be more specific.
- Run the requirements over with your team and make sure everyone understands what is being asked. Take the time to go over the requirement more than once if needed.
- Listen to what your team has to say, especially your engineers.
- Make it known to your team that it’s ok to reach out if they don’t have clarity or direction on what they need to do. It’s your job to provide that direction.
Once you have a good grasp of the work that needs to be done, trust your team to get it done. The focus is usually lost when there is doubt in the team’s capability or when the PM is unsure about the body of work that needs to be done.
Lawrence Tai is a first-generation Asian-American (Taiwanese) born and raised in Baltimore, MD. With a background in Information Technology, he has over 8 years of Management and Development experience spanning across the Technology, Entertainment, and Footwear and Apparel industries. He has developed and maintained healthy relationships with clients and stakeholders such as Cognizant Technology Solutions, Sony Pictures, DreamWorks Animation, The Walt Disney Company, and most recently with Nike. Throughout his career, he has managed and led teams across developing various technologies such as CRMs, Digital Assets, Web Development, Retail Payment, and Order Management systems. He has worked cross-functionally across many departments to achieve company objectives in an Agile Scrum environment while proactively prioritizing product backlogs and roadmaps that reflect the priority of work and development while maintaining client expectations and product vision to achieve company goals. He’s currently a Product Manager at Nike and hopes to share his insights from his experiences to help grow the Product Management community.
