Balancing Expectations of Multiple Stakeholders

Problem

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.

Actions taken

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.

Lessons learned

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.