How to work effectively with Engineers.

In my early years I was (process) engineer myself, and I had to collaborate with the so called “experts” as Product Managers and Product Designers, the experience was good for me but unfortunately not good for them. So this is what I want to share with those of you who have never been engineers before, but somehow managed to become PMs or PDs.

My friends I honestly tell you, you can never succeed as Product Manager or Product Designer if you have never worked for a while as engineer first. It’s even impossible if you have never studied engineering before.

In this post, I describe the engineering role (also commonly known as developers or, in some circles, programmers, mechanical designers or electrical/electronic engineers ). But as with my previous post, I’m not trying to tell here how the engineers should be – I’m aiming this discussion mostly at Product Managers who need to learn how to work effectively with engineers.

There’s probably no more important relationship for a successful Product Manager than the one with your engineers.

If your relationship is strong, with mutual and sincere respect both ways, then the Product Manager job is great. If your relationship is not strong, your days as product manager will be brutal (and probably numbered). Therefore, this is a relationship worth taking very seriously and doing everything you can to nurture. This strong relationship begins with YOU: The Product Manager. You need to do your homework and bring to the team the knowledge and skills of good product management.

Engineers are typically smart and often skeptical by nature, so if you’re bluffing, they likely won’t be fooled. If you don’t know something, it’s much better to fess up and say you’ll find out rather than try to bluster. It’s also hugely important that you have an actual appreciation for the demands and complexities of the engineering job. If you were an engineer before or if you’ve studied computer science, mechanical or electrical engineering in school, you’re probably in good shape. But if not, I want to strongly encourage you to take a class at a local community college or online education where you’ll learn a programing language and some mechanical/electrical engineering stuff.

The purpose of developing this programming/engineering literacy is not so you start telling your engineers how to do their job but, rather, to significantly improve your ability to engage with and collaborate with your engineers. Less obviously, but at least as important, this knowledge will give you a much better appreciation for technology and the art of the possible. It’s also critical that you share very openly what you know about your customers-especially their pain-the data, and your business constraints. Your job is to bring this information to your team and then to discuss the various potential solutions to these problems.

There is no thing wrong with you bringing a strong point of view, but you must constantly demonstrate to your team that you’re open minded, you know how to listen, and you want and need their help in coming up with the right product.

As a practical matter, you need to engage directly with your engineers every workday. There are typically two types of discussions going on each day.

In the 1st type of discussion, you’re soliciting their ideas and input for the items you’re working on in discovery.

In the 2nd type of discussion, they’re asking you clarifying questions on the items they’re working on delivering to production.

Where a lot of product managers go sideways is in how they communicate with their engineers. Just as most product managers don’t like it when an executive or stakeholder spells out exactly what they want you to build, engineers generally don’t like it when you try to spell out how to build something. So, while it’s good if you have a strong technology understanding, it’s not good if you use that knowledge to do their jobs for them. You want to give your engineers as much latitude as possible in coming up with the best solution. Remember, they are the ones who will be called in the middle of the night to fix issues if they arise.

One last thing to keep in mind: the morale of the engineers is very much a function of you as the product manager. It is your job to make sure they feel like missionaries and not mercenaries. You do this by involving them deeply in the customer pain you are trying to solve and in the business problems you face. Don’t try to shelter them from this-instead, share these problems and challenges very openly with them. They will respect you more for it, and, in most cases, the developers will rise to the challenge.

The Tech Lead Role

There are, of course, many different types of engineers. Some focus on engineering the user experience (generally referred to as front-end developers, mechanical designers), and some focus on specific technologies (for example, database, search, machine learning). Similarly, as with most other roles, there is a career progression for engineers. Many go on to become senior engineers, and some go from there to principal engineer or architect roles. Others move into more of an engineering leadership path, which generally starts with the tech lead role (aka dev lead, or lead engineer).

In general, from the product management perspective, any senior engineer is helpful because of the broad knowledge he or she brings that pertains to what is possible. However, a tech lead not only has this knowledge-and is responsible for helping to share this knowledge with the other engineers on the team-but the tech lead also has an explicit responsibility to help the product manager and product designer discover a strong solution. Not every engineer or even senior engineer wants to participate in discovery activities, and this is fine. What’s not okay is to have a team of engineers in which none of them wants to engage in discovery activities.

It is for this reason that the product manager and product designer work most closely with the tech lead. In some product teams, there may be more than one tech lead, which is all the better. It’s also worth pointing out that engineers often have different work styles, which is also true for many designers. The product manager needs to be sensitive to the best way to interact. For example, many product managers are happy to speak in front of a larger group, or even a group of senior executives, but many engineers or designers are not. It’s important to be sensitive to this.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s