Daniel Pinho

§ 9 Stakeholder Relationships

Context

Software projects are collaborative efforts, with people from various backgrounds and performing myriad roles working together to reach a common goal. Developers, alongside project managers, users, and product owners, are examples of stakeholders: people who are invested in the project and want to see it through.

Problem

The inherent differences in viewpoints that come from having differing knowledge, specialisations, and tasks can be a hurdle to maintaining positive relationships between developers and other stakeholders, which can, in turn, hinder the developers’ experience.

How can we strive for positive relationships between developers and other stakeholders?

Forces

  • Many people, from developers to business stakeholders, want to contribute to the project, but they can have conflicting priorities, goals, and values.
  • Developers are often fully dedicated to one project, but stakeholders often split their attention across multiple ones.
  • Business stakeholders seek predictability and reduced risk, but software development is uncertain and things are subject to change.
  • Stakeholders set direction and requirements, but developers bring technical expertise and have to manage what is asked of them with what is feasible to~do.

Solution

Build bridges between the team and the stakeholders through employing effective communication strategies, understanding differing viewpoints and seizing them as opportunities to learn, and fostering trust and respect.

Effective communication is a critical component in the relationship between developers and other stakeholders[1][2][3]. As all stakeholders want the project to succeed[3], they should strive towards minimising potential liabilities and weak points in their processes.

Each type of stakeholder has their own motivators, goals, and responsibilities that they need to attend to. For instance, while a developer is focused on programming and other development tasks and can be driven by wanting to learn new technologies, a project manager can work on keeping the team on schedule and budget while meeting with other stakeholders to assess their needs[3]. To avoid potential disagreements on priorities, technical opinions, resources and scheduling, the stakeholders should identify each role and its needs to ensure they understand where their colleagues are coming from and where their points of view lie[1][2].

Effective communication techniques include frequent and transparent communication, continuously updating the project calendar[3], understanding shared goals, maintaining a receptive attitude, performing active listening, and employing critical thinking[4].

It is worthwhile for stakeholders to develop trust, as it reduces communication barriers. For instance, if something happens during a software project, a developer may be more confident in having a potentially uncomfortable conversation with a client or another stakeholder if they know they have each other’s trust in seeing the project through. Trust can be built by encouraging participation, providing feedback, and practising accountability by admitting mistakes[1][5].

Support materials, such as comprehensive documentation, glossaries, and value maps, can be an additional tool in the stakeholders’ belt to ensure everyone is informed and up to date on current project developments[1][2], which is crucial in maintaining a high-quality level of communication. These are worth having when project personnel changes, as tacit knowledge is hard to record, and domain-specific jargon can induce misunderstandings due to differences in background[1].

Examples

  • Extreme Programming advises developers to include a customer representative in the development team, enabling quick feedback from them, clarifying requirements, and quickly informing any new decisions[6].
  • Free and open source software projects run heavily on volunteer work. In these instances, the end users, maintainers, and contributors function as stakeholders[7][8]. Decisions are often made asynchronously through open communication channels, based on mailing lists, forum posts, issue trackers, and pull request discussions[9].
  • Spotify employed a mechanism based on Request-for-Comments (RFC) documents to work on their in-car experience, making it possible for stakeholders to provide inputs early and asynchronously. The diagrams, code snippets and information shared in the RFCs enabled the multiple teams involved to be aligned, reducing misunderstandings in the process[10].

Consequences

  • Fostering positive relationships between developers and other stakeholders can help in achieving a smoother developer experience by reducing conflict and creating a more supportive social environment.
  • Strong relationships improve feedback loops, enabling developers to make adjustments to their work and plans early, avoiding wasted effort.
  • Developers cannot employ this pattern by themselves, needing engagement and support from the remaining stakeholders to implement these practices.
  • Managing relationships takes time and energy, which people may prefer to spend on their other tasks.
  • Power imbalances or misaligned values between the developers and the rest of the organisation can contribute to dissatisfaction, limiting the effectiveness of this pattern (see §10 Breathable Atmosphere for more on this).

The pattern §8 Team Players shifts the scope and goes into details about the relationships that exist within the team. As mentioned in this pattern’s consequences, §10 Breathable Atmosphere deals with organisation culture, which can also influence how relationships between stakeholders play out.

References

  1. B. J. Galli, “Barriers to Effective Communication and Stakeholder Management in Project Environments and How to Overcome These Barriers:” International Journal of Applied Logistics, vol. 9, no. 2, pp. 39–57, July 2019, doi: 10.4018/IJAL.2019070103.
  2. K. Kuusinen, “Value Creation and Delivery in Agile Software Development: Overcoming Stakeholder Conflicts,” in Global Thoughts, Local Designs, T. Clemmensen, V. Rajamanickam, P. Dannenmann, H. Petrie, and M. Winckler, Eds., Cham: Springer International Publishing, 2018, pp. 123–129. doi: 10.1007/978-3-319-92081-8_12.
  3. W. G. Poole, “The softer side of custom software development: Working with the other players,” in Proceedings 16th Conference on Software Engineering Education and Training, 2003. (CSEE&T 2003)., Madrid, Spain: IEEE Comput. Soc, 2003, pp. 14–21. doi: 10.1109/CSEE.2003.1191341.
  4. R. E. Burnett, Technical communication, 6th ed. Boston, Mass: Thomson/Wadsworth, 2005.
  5. P. Lencioni, The Five Dysfunctions of a Team. John Wiley & Sons, 2006.
  6. K. Beck and C. Andres, Extreme Programming Explained: Embrace Change, 2nd ed. Addison-Wesley, 2004.
  7. J. Coelho, M. T. Valente, L. L. Silva, and A. Hora, “Why We Engage in FLOSS: Answers from Core Developers,” in Proceedings of the 11th International Workshop on Cooperative and Human Aspects of Software Engineering, May 2018, pp. 114–121. doi: 10.1145/3195836.3195848.
  8. C. Jensen and W. Scacchi, “Role Migration and Advancement Processes in OSSD Projects: A Comparative Case Study,” in 29th International Conference on Software Engineering (ICSE’07), Minneapolis, MN, USA: IEEE, May 2007, pp. 364–374. doi: 10.1109/ICSE.2007.74.
  9. K. Crowston, K. Wei, J. Howison, and A. Wiggins, “Free/Libre open-source software development: What we know and what we do not know,” ACM Comput. Surv., vol. 44, no. 2, pp. 1–35, Feb. 2012, doi: 10.1145/2089125.2089127.
  10. M. Khalid, “Technical Decision-Making in a Fragmented Space: Spotify In-Car Case Study.” Accessed: Oct. 13, 2025. [Online]. Available: https://engineering.atspotify.com/2024/7/technical-decision-making-in-a-fragmented-space-spotify-in-car-case-study

Last updated: December 18, 2025