Those who are familiar with my background know that I have worn multiple hats over the years as an Engineering Manager (EM) and as a Product Manager (PM). As a result, I often get asked a few questions which are all kind of related:

What do I think of these two roles? Which one do I like better? Do I not miss coding? How do I make sure I am not stepping on the EM’s toes when I am wearing the PM hat ( or vice versa)?

I usually try my best to answer these questions as one-offs and give narrow window into my view of the world on the topic. But most of the times, because of the framing of the questions, I don’t end up providing my entire perspective.

In parallel, over the years, I have seen multiple attempts by various companies and teams to define the roles of EM and PM. More often than not, these tend to be two separate documents independently defining the roles and leaving the interaction between the two roles unaddressed and subject to interpretation. Also the roles are usually defined by describing a laundry list of activities EM and PM are responsible for and expected to conduct.

There is one more observation I have made that I will add here to finish my context for the rest of the post.

What makes interpretation of the EM and PM roles defined in the manner I described above harder in practice is the fact that the EM and PM are usually people with overlapping skills.

The point I am trying to drive is, over the years through these interactions and observing teams struggle to clarify these roles across big organizations, I have realized a need to have something simpler yet powerful and sticky to explain the two roles and the ideal interaction between them. A metaphor, a model, a framework if you will.

Note: The rest of this post is applicable even if you substitute EM title with other similar engineering leader roles like tech lead, lead engineer or architect etc. because the post is about interaction between the engineering leader and the PM discipline.

The Model

I have been thinking about this for a while and have come up with the following model that I think is useful.

EM and PM should act like a  team of  sniper and  spotter respectively.

Think about it. According to Wikipedia in a military Sniper team, “The shooter(s) fires the shot while the spotter(s) assists in observation of targets, atmospheric conditions and handles ancillary tasks as immediate security of their location, communication with other parties; including directing artillery fire and close air support. The spotter detects, observes, and assigns targets and watches for the results of the shot. Also, in conjunction with the shooter, the spotter will accurately make calculations for distance, angle shooting (slant range), mil dot related calculations, correction for atmospheric conditions and leads for moving targets.”

Lets look at the parallels here for the EM as the sniper and the PM as the spotter.

Just like a spotter, the PM should detect the optimal target customer base, observe and document their problems and then inform the shooter about the target customer and the problem worth solving. From then on, just like the sniper and shooter collaborate to make calculations for the shot, the EM and PM collaborate to define product roadmap that will address the target customer. At some point the mission switches over to the execution mode where like the shooter it is the EM who fires the rounds. The spotter’s job in that phase is to observe and report the results of the shots just like a PM reports out customer feedback on the prodcut. You get the idea.

Need more proof? More from Wikipedia: “It is not unusual for the spotter to be equipped with a notepad and a laptop computer specifically for performing these calculations.” Now if that does not sound like a PM then I don’t know what does 🙂

Applying the Model

You can leverage the model in various ways.

You can use the model to create an initial frame in a new team or introduce a new frame to an existing team. The model can help EMs and PMs make sense out of navigating the grey areas of responsibility. Should an EM do a particular task\activity or a PM? You can ask questions like: is the task more about detecting, observing, reporting on the target or is the task more about maneuvering the weapon?

But more importantly, you can use the model to illustrate that EM and PM must operate as a well-cordinated, tight team. They are the co-founders. They don’t jostle for control, they simply complement each other. A great working relationship is critical to their mutual success.

You can also use the model to identify dysfunction in the relationship as well. We all know some shooters who only trust their own spotting and we know some spotters too who love to be in charge of firing the shots as well.

I want to clarify one more thing before we wrap up.

You may ask. What about other disciplines? What about design, QA? Are they not important?  Why are they not part of the model?

My simple answer is of course other disciplines are just as important if not more. The model only addresses EM and PM because of the observation I shared towards the beginning of the post about EM and PM on the team often times having overlapping skills and higher level of  grey areas between their respective responsbilities.

To conclude,  hope you like the model and find it useful. Please share comments or other models if you have found them useful.