Managing PMs

Microsoft, Google, and the other tech firms may have documents describing the expectations for different levels of software developers, but no one needs to ask, “What is a software engineer?” However, many of these companies have documents entitled “What is a PM?” that are borderline philosophical. Even the meaning of the PM acronym varies—it’s typically “Product Manager,” but sometimes means “Project Manager” (just focused on execution) or, at Microsoft, “Program Manager” (a role similar to Product Manager). The variation in a PM’s title, philosophy, and scope can make it challenging to do the job well.

Naturally, PMs look to their managers to provide priorities and expectations. Unfortunately, those definitions of success are often unclear, even to the managers. If you’re that manager, how do you provide PMs the clarity they need to deliver a positive impact for your team, your business, and your customers? What skills should they develop? How do you measure their success and hold them accountable? And what if your peers, your boss, and your skip (boss’s boss) all see the PM role differently? The situation is a bit chaotic, but so is the PM role. Let’s sort it out and get it on track as good PMs do.

Dos and don’ts

To understand how to guide PMs, it helps to know what they don’t do. Aside from sometimes specifying APIs, PMs don’t write product code. That’s the job of developers. Since product code is the fundamental output of software teams, PMs are useless by themselves, much like managers. (Remember the “M” in PM stands for “Manager.”)

If PMs, like other managers, are useless by themselves, how do they contribute value to the team? By helping developers be successful. That’s why Microsoft originally created the PM role decades ago—to help developers produce the right code at the right time to deliver broad business and customer value.

Please note that the word is “help,” not “force” or “demand.” At the end of the day, PMs are in no position to force or demand anything of a dev team (though they often try). PMs do not write the code. However, when PMs show they can help a dev team succeed by aligning effort, filling in gaps, and unblocking progress, dev teams gladly collaborate and follow PM guidance.

Since each dev team has its own strengths and weaknesses, PMs need to adapt accordingly. Some dev teams understand customers, the business plan, and priorities. Others want a PM to meet regularly with customers, partners, and management to ensure their requirements are reflected in the product plan. Some dev teams produce code reliably on time. Others want a PM to help with project management. Some dev teams can unblock themselves, breaking through bureaucratic and political barriers. Others want a PM to resolve issues and drive progress.

As a manager of PMs, you must help them understand the limitations and opportunities inherent in their role. It’s a fantastic job with tremendous impact as long as PMs collaborate and succeed together with the dev team. Otherwise, the PM role can be frustrating and feel pointless. If the work a PM is doing for your dev team seems redundant or conflicting, encourage the PM and the dev team to find ways of sharing effort and helping reduce each other’s load.

A very particular set of skills

There are several skills PMs need to be successful. Encourage your PMs to hone them all since assignments and team makeup are constantly changing. Fortunately, good books and online training are available for all these skills.

• Influence without authority: As the seminal book Influence describes, there are many ways to attain it. Since PM is a collaborative role, you want your PMs’ influence to feel valuable, not manipulative, so encourage approaches where everyone wins.
• Communication, written and oral: Communicating clearly to a wide variety of stakeholders (management, devs, partners, and customers) is crucial to a PM’s success. Fortunately, AI can make emails, documents, and presentations sound clear and professional, even when your PMs’ initial drafts are fraught with emotion, grammatical errors, and obscurity. Getting practice with presentations is particularly useful since presenting is a physical act. Toastmasters, live classes, and coaching can help.
• Negotiation and empathy: PMs are constantly negotiating with each other, management, the dev team, partner teams, customers, and their friends and family. Learning the essentials of effective and empathetic negotiation is an incredible long-term investment.
• Assertiveness: Advocacy is fundamental to being a PM. Sometimes it can be done quietly, but oftentimes, PMs must be strong and stand up for their teams, their customers, and themselves.
• Project management: For better or worse, project management sometimes falls to PMs. Making sure your PMs are proficient at a variety of traditional and Agile methods (whatever your team prefers) helps your team and provides your PMs with additional opportunities to influence events and drive success.

We have a winner!

If you manage PMs, you will be giving them feedback and determining their rewards. That’s hard to do for any role, but because the PM role is so varied and its influence is so indirect, it’s particularly difficult to ascribe success or blame accurately.

You could simply assess PMs by their projects’ impact on the business and customers. Certainly, that should be part of your evaluation, but for durable success, the how matters as much as the what. Does the dev team appreciate and respond constructively to your PM? Is the dev team delivering more business and customer value as a result? Is your PM replicating effort and fighting for relevance, or is your PM filling gaps and driving shared success?

There’s always room for improvement, even for your best performers. First, examine any high-level opportunities in terms of attitude, approach, and engagement. Are your PMs concerned about themselves and their success, or about the team’s, company’s, and customer’s success? Then consider gaps in your PMs’ skill set. Are they influencing without authority, communicating effectively, negotiating with empathy, asserting themselves when necessary, and keeping the dev team focused and productive?

I don’t think we are on the same page

With so many ways that PMs can contribute, it’s common for your peers and management chain to have differing opinions and expectations about what PMs should do. Some VPs think PMs should only focus on future planning and avoid day-to-day execution. Some directors believe PMs should drive the day-to-day schedule in detail. Some Group Program Managers (GPMs) expect PMs to handle design and customer engagement. No one is wrong because each approach is useful in certain situations; nevertheless, these philosophies often conflict.

What should you do when your approach seems at odds with that of your management or peers? It’s simple. Ensure your PMs help developers deliver broad business and customer value. That’s what matters. Have your PMs tell the VP about their future planning (which they did in collaboration with the dev team). Have them tell the director about the day-to-day schedule (regardless of who the Scrum Master might be). Have them describe the design and its customer focus to the GPM (that they facilitated with the dev team).

If your VP is concerned that your PMs attend daily standups, say they are keeping an eye out for issues that impact future planning. If your director is concerned that your PMs don’t always run daily standups, say that they always attend to mentor the team so things will go smoothly even when they’re away. If your GPM is concerned that the dev team worked on the design and devs sometimes attend customer meetings, say that your PMs are highly collaborative and know that customers get the best product when developers have deep buy-in.

In other words, focus on what’s important: delivering value to the business and customers. Then, manage your management to ensure you remain in alignment with org priorities.

All the pieces seem to fit into place

Managing PMs is difficult because the role is so varied and must adjust substantially to changing dynamics. However, some basics apply to every PM role. PMs generally don’t write product code. Their skill is helping the people who do (the dev team) be as productive as possible at delivering fantastic experiences to customers and partners that are in line with business priorities.

As their manager, you should help PMs adapt to where they are needed most. The most common needs are in customer and partner engagement, planning, design, project management, and unblocking progress. However, different dev teams and situations call for different contributions. To handle all these situations, ensure your PMs are trained in influence without authority, written and oral communication, negotiation and empathy, assertiveness, and project management. Evaluate PMs on their impact and how it was achieved based on their approach and skill set. Finally, manage your management and their varied views of the PM’s role by describing how your PMs are effectively driving results in ways consistent with your management’s expectations.

As a longtime dev manager (aka Group Engineering Manager), I’ve always loved PMs and the unique value they provide. I’ve had the privilege of managing many PMs over the years and have seen how challenging and rewarding that role can be. Great PMs make everyone better. As their manager, you can make them great.