What steps can a non-technical PM do to get the respect of their developers and engineers?

There’s no question that managing teams of developers and engineers is one of the greatest challenges for a PM. Without the technical background, it can be hard to get things done without the help of engineers and developers. However, this doesn’t mean that technical knowledge is necessary for a PM to get their team to respect them.


Ask questions and engage in discussion about the art of product management with accomplished and aspiring members of the community.


@Jesusrojas, this is deceiving or misleading. The PM should be well-versed in the system architecture, development, and business operations. Domain knowledge is insufficient on its own.


Humbleness. Instead of assuming you already know what it will require, spend a lot of time investigating the requirements and getting their input. Additionally, encourage them to offer feedback on the decisions and business values.


This is absolutely true @CarlosDubois. Recognize them as professionals in their field. Pay attention, make notes, and request clarifications. It turns out that most professionals love to share their knowledge with others.

  1. Listen to them.
  2. Allow them to come up with solutions.
  3. Share their good works with leaders.

There are plenty of excellent suggestions here. Be frank and honest about your ignorance, and I’d include that as well. Don’t rely on others to teach you everything or go over concepts that are simple to understand on your own; instead, ask questions when needed. Make every effort to create a path that will allow them to concentrate and complete the assignment while adopting a servant leadership mindset.


I can only think of the following:

  1. Avoid being a snob. Not just the PM, but the entire team, is the product.

  2. Make room for research, not only development, paying off technical debt, or general advancements. People can better feel connected thanks to it.

  3. Look for opportunities to make them more prominent in front of the leadership. Not only present their work, but also help them prepare and deliver it.


Try to become tech savvy. It’s quite significant (at least has been for me). By identifying as non-technical, you appear to be embracing your lot in life. TRY to pick it up. Pose inquiries. In general, engineers enjoy making complex concepts simple. By attempting to learn their trade, you kill two birds with one stone: you get knowledge, and they gain respect.


I imagine that this is an unpopular viewpoint on this site, but I should pick up some technical knowledge. Many engineering teams won’t fully appreciate you if you don’t have a basic understanding of how applications and APIs operate. Obviously, a lot of this depends on the business and the engineers. However, understanding how to create a simple application, some programming concepts, and how to use APIs is not a particularly challenging ability to pick up. You can probably learn it for less than $50 in a 50–100 hour online course. Think of managing a restaurant without ever having prepared a meal. There are many things you’ll lose out on. I’m not saying that if you lack technical skills, you can’t be a competent product manager. I just believe that anyone would be better if they learn some minimum skills.


@NathanEndicott, 100% agree. It won’t take you long to at least have a rough idea of how an actual application functions. You can connect with the team more successfully if you can navigate an architecture diagram and comprehend what each frontend and backend component accomplishes.

Since I prefer to communicate visually, I frequently include wireframes and diagrams in addition to potential API/DB calls and any functionality we might require.

This isn’t everything; some of it makes sense to me and some of it involves higher-level ideas. In my opinion, a lot of the potential aesthetic and structural elements just magically come in your head when you combine persona with user flow mapping.

This develops with time, but in my opinion, if you’re a dedicated PM, you’ll learn enough about everything to speak well to any audience. You must be constantly learning for this position.


Agree :100:. I was about to mention the same, but your response covers it. I am not sure why people continue to think not having enough technical knowledge is ok. The world has changed a lot and if you are a PM for a digital product, you should spend a lot of time to update basic technical skills needed. Domain knowledge is important, but we are already in the age where a ‘tech’ suffix is being added to a lot of domains. Understanding the functional aspects of domain and continuous learning of technology is the way to go. Not an expert in tech by any means and navigating the same rough seas as of now. All the Best!


Stop coming up with solutions. Just state the problem, and if they’re interested, the motivation in solving it.

Also, give them a seat at the table. Ask what they think needs to be built.


I’m curious if you’re more referring to not coming up with HOW the solution is built. In my experience, the PM is accountable for WHAT solution is built.


Correct. Highly technical PMs can offer advice on how it should be created. Engineers still possess the greatest technical expertise and don’t “require” advice on the best way to construct something. If there are guardrails that engineering may not be aware of, that might change. But that shouldn’t happen. They must be aware.


Over time I think most PM’s will become technical just from being around highly technical people on a daily basis. Most PM’s I know are naturally curious people so we tend to dabble in everything anyways.


It’s undoubtedly a case of leading a horse to water. Though being willing to be in error is extremely valuable.

Typically, I have a problem that is clearly stated: “The user does X because they want Y, but they receive Z.” If an engineer offers a worse option than what I was considering, I politely challenge the assumptions with my questions. Either they identify the problem and propose a different strategy (not necessarily mine), or they respond by letting me know that I was overthinking the situation.

I’ve doodled a solution on a napkin and said, “Make it happen by tomorrow,” on teams with EXTREMELY high trust, pressing deadlines, and technical applications. It was successful in both instances, and the engineers thoughtfully iterated the problems in more subdued follow-ups.


Don’t go too far with your suggestions but do show interest in and appreciation for their work. Create a comfortable environment for dialogue by asking them questions. Make sure their success is compatible with the success of the product. This holds true for all fields (dev, design, research, marketing, sales, etc.).


If you’re a “non-technical” PM working with a technical team, I’d encourage you to familiarize yourself with the more technical aspects of the product. Of course, not to the level where you’re doing the job of an engineer, but to the level where you’re able to have an in-depth discussion and make informed decisions weighing all factors vs just the non-technical factors.


There are some excellent answers to consider here. I would advise, though, panning out and adding this query. Has a non-technical PM ever gained the respect of the developers and engineers on their team? Do your best to take something away from them.

Your queries involve a wide range of variables. Do engineers and developers have a reputation for being pretentious jerks, for instance? I’ve met the most intolerable undeserved, haughty “devs” in wonderful cultures, and I’ve met great and helpful developers in poor cultures. The problem is that you might not get paired with that one good developer if you live in a toxic culture. In a good culture, the terrible developer will ultimately leave/get fired, or if they are the only one, there will be less likelihood of you working with them.