Balancing Expectations of Multiple Stakeholders
4 June, 2021
The key part of my organization's goal is to enable tens of engineering teams (stakeholders) to build and ship innovative products faster and safer. We enable that by building Developer Infrastructure and running Production Engineering at scale. The good part is everyone uses tools and services that we provide, the bad part is everyone wants them to be enhanced and customized to their specific needs and the ugly part is to say no or not meet their expectations at times. One of our biggest challenges is to manage the expectations of multiple stakeholders to come up with solutions that can benefit many engineering teams and not just a few.
First thing is to engage with stakeholders and understand their expectations. Hear them out and if required have a few brainstorming sessions. Our engineering team often comes to us with a solution that they want us to implement. It is very important to navigate from what they want to what they need. Once you clearly define the problem, turn the gears to establish why it is important to solve it. How will it impact the productivity of their team?
Once you established the need, the next step is to analyze it. You will need data. If you don’t have it, you want to ask for it. It sometimes involves asking open-ended questions but more often you might be creating an infrastructure to generate the required data. Once you have the data you need, we want to know how often this problem occurs for a particular engineering team. Does your analysis support the claim made about their impact on productivity? Often, we see that the data doesn’t support the claim, and solving it will not yield significant benefits to the team. If the problem is worth solving, the next step is to analyze the data and find if the problem is faced across multiple engineering teams. The beauty of being part of the central organization is that we collect data across 50+ product engineering teams that we support.
Oftentimes, teams encounter similar problems in an entirely different context, so it’s important to generalize the problem, identify the common theme, and propose a core solution that allows others to extend it. This is not always easy but it’s an essential step to build widely adopted engineering infrastructure solutions. The goal here is to build a core solution that has the highest reach and biggest impact. The pitfall to this approach is that your core solution may not fully satisfy all requirements of every stakeholder and that’s fine. The next step is to really work with stakeholders to balance expectations.
Honestly, our stakeholders also know that no one can build a solution that can provide what each and everyone wants. The idea here is to bring multiple stakeholders together to educate and explain your rationale for proposing a core solution. Using a data-driven approach and showing varying use models across various engineering teams can help align multiple stakeholders to agree on a core solution. At times, your core solution is not to build any solution, instead, you can offer an alternative. You can share how other teams have solved the problem without a need to implement their requirements. Once they all align on the core solution, you will still find few stakeholders that are not fully satisfied. Alternatively, you can offer a discussion on how they can extend the solution and customize it for their own unique needs. While it’s a delta overhead for certain stakeholders, it allows them autonomy to achieve greater productivity for their teams.
We all work in a hyper collaborative environment, so managing expectations is essential, but it becomes critical when you deal with multiple stakeholders. There is no silver bullet, but one of the key lessons we learned is to balance (not just manage) the expectation. It’s not about saying yes to every request or saying no either but using a data-driven approach to find the right balance. Be ready to constantly pivot. Be collaborative, be honest (let the data speak). Focus on reach and impact.
Scale your coaching effort for your engineering and product teams
Develop yourself to become a stronger engineering / product leader
Manzar Kazi, Software Engineering Manager at LinkedIn, speaks of his experience of holding a partner team accountable with whom his team had multiple dependencies.
Software Engineering Manager at LinkedIn
Heiko Reintsch, Head of Product at GetYourGuide, bears witness to the unifying power that a comprehensive, company-wide vision has over a large team of individual contributors.
Head of Product at GetYourGuide
Tushar Dadlani, Director of Engineering at Standard Cognition, was far from a natural delegator when first starting out in management.
Director of Engineering at Standard Cognition
Rohan Kulkarni, Engineering Manager at Expedia, shares his first significant triumph implementing a new system of cross-functional cooperation across an entire organization, testing, learning, and improving over the course of three quarters.
Sr Engineering Manager at Expedia
Shetal Shah, Director of Engineering at Synopsys, explains how to balance divergent expectations across an array of cross-functional stakeholders by focusing on a core solution and enabling customization to meet their specific needs.
Director of Engineering at Synopsys
You're a great engineer.
Become a great engineering leader.
Plato (platohq.com) is the world's biggest mentorship platform for engineering managers & product managers. We've curated a community of mentors who are the tech industry's best engineering & product leaders from companies like Facebook, Lyft, Slack, Airbnb, Gusto, and more.