DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports
Events Video Library
Refcards
Trend Reports

Events

View Events Video Library

Related

  • Choose Software Engineering Career Path: Top 25 Reason to Know
  • Advice to My Younger Self as a Software Engineer
  • AI in Software Engineering: 3 Critical Mistakes to Avoid (and What to Do Instead)
  • How AI Is Transforming Software Engineering and How Developers Can Take Advantage

Trending

  • Mocking Kafka for Local Spring Development
  • Introduction to Tactical DDD With Java: Steps to Build Semantic Code
  • Exactly-Once Processing: Myth vs Reality
  • From APIs to Actions: Rethinking Back-End Design for Agents
  1. DZone
  2. Culture and Methodologies
  3. Career Development
  4. Multiple Stakeholder Management in Software Engineering

Multiple Stakeholder Management in Software Engineering

This article explores practical strategies to help engineering leaders effectively manage multiple stakeholders with competing priorities.

By 
Nikhil Kapoor user avatar
Nikhil Kapoor
·
Jul. 08, 25 · Opinion
Likes (5)
Comment
Save
Tweet
Share
1.9K Views

Join the DZone community and get the full member experience.

Join For Free

One of the key challenges faced by the engineering leaders is to manage multiple stakeholders. These stakeholders often have different project priorities. This article suggests strategies to deal with the challenges encountered by engineering leaders in managing multiple stakeholders with often conflicting priorities. 

Background

Managing a mid size engineering team of size ~20 engineers presents multiple challenges, specifically when it comes to stakeholder management and project execution. Engineering leaders in this position frequently find themselves juggling the needs and expectations of multiple stakeholders across multiple projects. This results in the below challenges:

  • High Work Volume per Stakeholder: Stakeholders can be internal (e.g. product management and internal DEV teams) or external (e.g. clients and partners). All stakeholders have their own list of requirements. Meeting each stakeholder's requirements increases the team's workload. This further leads to burnout risk, impacting focus and quality of work delivered. Thus not meeting the project deadlines.
  • Inter-Organizational Stakeholders and Prioritization Challenges: When stakeholders come from different organizations such as client, or client-vendor relationship, it becomes more challenging to manage the priorities. Each organization has its own strategic goals, and timelines. This can result in conflicting priorities, making it challenging for the engineering leader to figure out which projects to prioritize. For example, one stakeholder might require an epic or feature to be delivered urgently for a product launch, while another stakeholder wants to prioritize a different set of epic or features for a long term strategic goal. 
  • Lack of Vision and Communication: By working on a project as requested by different stakeholders can lead to a divided approach to project execution. Without a clear, centralized vision and effective communication mechanism, the engineering team can become overworked and lose vision of the overall objectives and goals of the team. This can also result in duplicated effort, missed project deadlines, and dissatisfaction among stakeholders.
  • Resource Allocation and Dependency Management:  Allocating engineers becomes a challenge when managing multiple projects and stakeholders. It's important to avoid context switching for engineers and make sure that the right engineers are working on the right projects at the right time. This requires careful planning, monitoring, and communication. Further, projects have dependencies on other projects, meaning that the progress of one project can impact the timeline of others. Managing these dependencies is important for avoiding delays and making sure the project is executed properly.

Strategies 

Strategy 1: Divide the Larger Team into Smaller, Stakeholder-Dedicated Sub-Teams

As part of this strategy, divide the engineering team into smaller virtual sub-teams. Each sub-team is assigned to a specific stakeholder or a small group of closely related stakeholders. For instance if the team is of size 20, divide the team into 3 or 4 smaller sub-teams with a dedicated Technical Lead (TL). Here TL is leading the technical aspect for the stakeholder.

Pros

  • Dedicated Focus: Each sub-team can have deep expertise in the business domain of their assigned stakeholder. This will allow them to create a backlog of projects with priorities which will further allow for more custom solutions.  This will also provide career opportunities to the engineers.
  • Improved Stakeholder Experience: Stakeholders have a one point of contact from the engineering team, encouraging stronger collaboration and improved communication. This will also establish trust and satisfaction with the stakeholders.
  • Increased Ownership and Accountability: Sub-teams establish a sense of ownership over their assigned stakeholder's projects, leading to increased accountability and motivation. This will also give career growth opportunities to the engineers.
  • Streamlined Communication: Focused stakeholder groups improve communication efficiency and also reduce context switching.

Cons

  • Resource Imbalance: A risk to this approach is resource imbalance. A stakeholder with a high priority project might be not staffed correctly if their assigned sub-team is too small. On the other hand, a stakeholder with a less important project might have a larger sub-team than required. This will further lead to inefficient resource allocation.
  • Potential Low Impact Work: Another downside with this strategy is sub-teams might focus on projects that are only important to their specific stakeholder but are not aligned with the overall goals of the team and organization. This can have wasted engineering effort and reduced the overall impact of the work done. Further this will have a negative impact on product strategy.
  • Isolated Knowledge: Dividing the team can create knowledge isolation, making it difficult to share best practices and lessons learned across the entire engineering organization.
  • Reduced Flexibility: It becomes more difficult to reallocate resources quickly to address urgent issues or changing priorities across different stakeholders. Also since the sub-teams size is small and if there is a sudden attrition in the team it will have an immediate impact on the stakeholder further having an impact on the reputation of the organization.

Strategy 2: Gather Requirements from All Stakeholders and Stack Rank Them

In this strategy, engineering leaders gather requirements from all the stakeholders and merge them in a single project backlog for stack ranking based on business impact.Once projects are stack ranked, engineering leaders will allocate engineers to top 3 or 4 projects based on the size of the projects.

Pros

  • Centralized Prioritization: Engineering leaders can manage and allocate engineers across all projects easily with a single prioritized backlog. This makes sure that the most important projects are on top of the priority list and are worked on by the engineering team first.
  • Clear Visibility: The entire team and all stakeholders have visibility into the prioritized backlog, providing transparency and clarity on project priorities.
  • Objective Prioritization: Using defined criteria for stack ranking of projects can help remove bias and make sure that projects are prioritized based on objective factors.
  • Efficient Engineers Allocation: With this strategy, engineers are allocated to the highest priority projects only. This will help maximize the impact of the engineering team's work leading to satisfaction.

Cons

  • Stakeholder Dissatisfaction: This strategy can lead to situations where all projects from a stakeholder are consistently stack ranked lower. This can cause stakeholder dissatisfaction and have an impact on relationships.
  • Lack of Context: Having context behind the requirement is important. Objectively stack ranking projects can sometimes remove the business context of the requirements. A relatively small project request might be important for the success of the stakeholder, but this might not be obvious in a simple ranking.
  • Potential for Rigidity: A strict stack ranking can make it difficult to accommodate urgent requests or changing priorities from the stakeholders. It can also prevent innovation since teams are not adapting to changing market dynamics and product needs.
  • Difficult Stakeholder Management: Managing expectations and communicating the rationale behind the stack ranking to all stakeholders can be challenging. This is specially when some stakeholders consistently see their projects ranked lower.

Strategy 3: A hybrid approach integrating Strategy 1 and Strategy 2

This strategy uses the best of both strategy-1 and strategy-2 and provides a customized approach to the engineering leaders.

  • Weighted prioritization approach: Instead of making a use of a simple stack ranking of projects, use a weighted scoring approach. This approach considers multiple factors, such as stakeholder importance, business value, strategic alignment, urgency and size. Further, this approach can help prevent situations where one stakeholder's projects are consistently deprioritized. Using stakeholder importance as a factor in prioritization is the key differentiator from strategy-2.
  • Use sub-teams strategically: Similar to Strategy-1, short lived sub-teams can be formed for projects that need specialized skills or strong stakeholder engagement. But the key difference from strategy-1 is these sub-teams can be dissolved for redeployment, encouraging resource fluidity and knowledge sharing.
  • Communication with stakeholders: It's important to regularly go over the prioritization process and the rationale behind project stack rankings to all stakeholders. This helps manage expectations and address any concerns stakeholders may have.
  • Regularly review and update priorities: Priorities of projects should not be considered as fixed. Engineering leaders should regularly review the backlog and change priorities as required based on changing business needs, stakeholder feedback, and new information.

Conclusion

Effectively managing multiple stakeholders in large engineering teams requires a thoughtful strategy. While stakeholder dedicated teams and centralized prioritization provide many advantages, a hybrid strategy combining weighted prioritization, strategic sub-teams, and transparent communication makes better resource utilization and drives greater organizational success. By carefully considering the pros and cons of each strategy and adopting a flexible approach, engineering leaders can effectively manage multiple stakeholders and make sure that the engineering team is working on the impactful projects.

Engineering Software engineering career

Opinions expressed by DZone contributors are their own.

Related

  • Choose Software Engineering Career Path: Top 25 Reason to Know
  • Advice to My Younger Self as a Software Engineer
  • AI in Software Engineering: 3 Critical Mistakes to Avoid (and What to Do Instead)
  • How AI Is Transforming Software Engineering and How Developers Can Take Advantage

Partner Resources

×

Comments

The likes didn't load as expected. Please refresh the page and try again.

  • RSS
  • X
  • Facebook

ABOUT US

  • About DZone
  • Support and feedback
  • Community research

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Core Program
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 3343 Perimeter Hill Drive
  • Suite 215
  • Nashville, TN 37211
  • [email protected]

Let's be friends:

  • RSS
  • X
  • Facebook