How Product Managers Can Empower Engineers in Stakeholder Conversations
Product Managers are good at engaging with stakeholders, it’s what we do. But with some strategic mentoring, we can help our engineering colleagues be more effective in stakeholder interactions.
I bumped into a software engineer I worked with several years back. I was somewhat taken aback when, over a few beers he thanked me for bringing him out of his shell. As he put it, he had been a ‘headphones in’ engineer who had no motivation to deal with stakeholders.
He explained how he perceived that interaction as a difficult proposition, but also a major distraction from what he enjoyed doing: coding.
He reminded me that we had been working together for about a month when it became clear that we had to work closely with a 3rd party development team to get an exciting product to market, and that the founders would be heavily involved in the entire process too. He was very uncomfortable about this, and via his team lead I was made aware of his discomfort.
However, not interacting with the stakeholders and the 3rd party team simply wasn’t an option for us. He had to grasp the nettle, and so I worked with him to help him transition from a ‘headphones in’ engineer to an engaged tech partner to stakeholders.
So in this article, I will share some strategic mentoring tips product managers can use to help our engineering colleagues be more effective in stakeholder interactions.
Key takeaways include:
Learning to empower your colleagues
It’s a cliché in the world of Product, but my path to this point is far from straightforward. I started out my career as a sound engineer with ambitions to break into the world of music production, but instead, I moved into audio production for multimedia which later encompassed video production for corporate multimedia.
When a global shockwave impacted that world I founded a multi-site coffee retail business which I ran for several years before drifting back into tech and product management.
Thinking back over my journey for this article, it’s clear there is a commonality of being responsible for creating a comfortable environment for people to do their best work, whether that be a musician, an actor, a camera person, a barista or an engineer… but also empowering people to develop their skills and abilities and push through that initial discomfort to take on new challenges.
What struck me over drinks with my former colleague was the fact that I had gone through this process with him in a completely intuitive way. It hadn’t dawned on me that this was anything special or difficult to tackle.
So if you are a product person and are wondering how you can help a talented engineer step up and engage with stakeholders, whilst helping them understand the boundaries, here are some of the lessons I’ve learned to help that process…
Laying the foundations
Setting communication expectations for an engineer that’s moving towards more stakeholder engagement is vital from the very start of the process.
As PMs we should cover:
- dealings & meetings we will have with stakeholders
- which channels of communication will be utilized
- inputs we will require of the stakeholders
- support we will provide as we move into this unfamiliar territory
It’s key for trust to grow between the PM and engineer, and so there should be ample opportunity for honest feedback—this might be scheduled 1:1s but personally I lean towards informal chats throughout the working week.
Along with a Product’s UI/UX Lead, trust must exist to facilitate the hard conversations, and this doesn’t simply happen overnight. All parties need to earn that right, and that can take time on any product team.
Providing the wider context
As a PM you should be regularly communicating the roadmap to the whole engineering team.
And I don’t mean visibility of the current and next sprint…
I mean providing the bigger picture of how the Now/Next/Later roadmap items and tactics feed into the product strategy.
Familiarity with the strategy and vision will help an individual engineer anchor their communications in facts and bring enormous context to stakeholder conversations, whilst keeping everyone focussed. For an interactive engineer, this broader view will keep meetings focused and avoid revisiting old conversations and decisions with stakeholders.
This will prove to be invaluable when deciding on tech solutions for a Next item and how that might inform the approach taken on items in the Later column, but also help the wider team understand the uncertainty PMs become comfortable with.
An added bonus of course, is that over several months the team will notice how much the roadmap and tactics can change depending on external and internal forces, and why a PM will often answer a question with the classic “It depends…”.
Debugging stakeholder presentations
Presenting is an area that is feared and misunderstood in equal measure.
For an engineer new to the world of stakeholder presentation, it is vital for them to know what is expected of them. In almost all circumstances, the PM will, with key input from the Tech and UI/UX Leads, prepare decks, presentations and drive the agenda for calls with stakeholders (whether regular weekly check-ins or product discoveries).
It is their role to ensure these meetings are prepared for and that the team has all the facts and preparation time they need in advance of the call, and any input required is understood in advance.
Where more substantial input is required of the engineer, syncing ahead of time or even ‘dry runs’ can be key to ensuring that difficult concepts are delivered appropriately, covering all necessary topics whilst leaving the stakeholders confident that they have a grasp of the facts.
Again, the PM/engineer relationship is vital so that any rehearsals are done with enough time for sufficient feedback to be actioned, and the necessary confidence to be gained.
One thing I’ve seen again and again in fledgling presenters is the instinct to cover every word of every talking point in the presentation.
A slide deck should be a guideline and framework for a presentation, not a script. So when preparing presentations with an engineer, make sure to have the word ‘brevity’ to the fore.
I like to think of the Rule of Three when preparing a presentation—aim for 3 bullets per slide with 3 words per bullet—to be honest I never actually succeed, but the approach helps me keep things to a minimum.
Speaking to a non-technical audience
The funny thing about simple things is that they are not simple for everybody all of the time.
A common pitfall is when a newly interactive engineer presents a solution, approach or even responds to a question with deeply technical language- for a non-technical audience.
The simple fact is that most (though not all) non-technical stakeholders don’t care as much about how elegant the code is or how clever a solution is as an engineer might believe.
So it is important to:
- keep the focus on the Whys and the Whats
- steer away from the How
There are always exceptions, however, and I do believe it is worthwhile briefly highlighting great work completed by the development team, but it should be done in a tone appropriate for the audience and with a focus on the value delivered to the end-users.
When we talk about building confidence to communicate, an interactive engineer needs to demonstrate their own confidence in their abilities and domain knowledge and this will then foster confidence from stakeholders in them.
It quickly becomes a virtuous circle.
Learning to listen
So how can a newly interactive engineer build confidence to talk effectively with stakeholders?
Ironically, the key is to learn to listen—this is more difficult than it sounds.
Instead of waiting their turn to speak, they should actually:
- listen to what the other parties are saying and take notes;
- listen out for repeated concerns or fixations on one area of the product;
- and also listen out for what they don’t say.
I’ve known a senior stakeholder who didn’t mention a key feature in development for several weeks because they didn’t understand how it worked technically and didn’t want to appear weak by displaying a lack of knowledge.
An interactive engineer should listen out for what a stakeholder doesn’t say so they can be proactive in filling knowledge gaps and earning trust. Similarly, they will need to learn how to decipher vague stakeholder statements—this will take time, but use those informal chats and post-meeting debriefs with your product trio to decode statements and ensure that you all have the same takeaways.
Handling difficult conversations
Taking criticism is difficult, but it is never personal.
Or at least it shouldn’t be.
In high pressure scenarios, stakeholder feedback can sometimes appear to be less than diplomatic.
Now is the time to display your empathy—when stakeholders are giving you and your team what feels like an unwarranted hard time, it’s often the result of them having had a similar experience with their manager or client.
Show your team how to stay focussed and then pull apart what the core of the issue is—the Five Whys is a dependable go-to in this scenario.
There will always be relevant points communicated by the stakeholder, so put the ‘how’ they’re communicating to one side and focus on the actions. Calmly agree on the next steps, assign actions and repeat those back to the group.
An interactive engineer should be aware that if point estimates can be given then do so with clear caveats, otherwise inform the group when they will provide the solutions and level of effort once the problem is better understood, and if possible give a timeline for coming back with that.
I know I’m repeating my point here, but keeping the detail appropriate to the stakeholder—using analogies can work wonders in diffusing a situation and help a stakeholder grasp the situation and then communicate upwards effectively.
Silence can be golden
One thing talked about less in stakeholder communications is the ability to bite your tongue.
Where there is tension or even a disagreement, an engineer should take cues from their other team members on how they move those into separate conversations.
And when they do, do so in a collaborative and constructive tone ensuring that everyone is reminded that they are all on the same team and have a common goal in mind.
In short, they need to learn the importance of being able to pick their arguments. This is where PMs can provide guidance on when it's best to hold back.
Confidence is king, but…
It’s true that we can all build confidence by exuding it, but there is also a need to know where the line is.
A newly interactive engineer needs to be careful not to come across as over-confident or even cocky because they have a particular knowledge set unique to them in the room. This behavior can often be a defense mechanism, but they should strive to present themselves (verbally and through their body language) with a quiet, open, self-assured zen.
Provide regular feedback so that balance is managed—your input will help the newly interactive engineer walk that fine line.
Demonstrate great behavior
Helping a reticent engineer become more interactive by working in a collaborative and structured way to address skills gaps, will require leaning into your past experiences and transferable skills—much like other vital areas of Product Management.
It’s vital that you bring your A-game to provide the best example. Be conscious of performing at your best.
Consciously demonstrate:
- how to operate when things are going well
- how to prepare so that everything should go well and how to conduct yourself and how to refocus when things don’t.
Despite what junior engineers might think, there are no hard capabilities that are gained once and for all. The same is true for engineers, designers, and product managers.
What I have outlined above isn’t a simple process and it will take an investment of time and effort from you in the short term (and as a PM you know how precious a commodity time is) but the rewards will be reaped in the medium to long term, for you, your team, your stakeholders and most importantly, your product.