Are developers of a product considered stakeholders?

  • Maybe... it might depend on the system.
    – FrustratedWithFormsDesigner
    Jan 13, 2011 at 15:18
  • Stackholder as in responsible for failures. Not as in one who benefits from the success monetarily.;)
    – abel
    Jan 13, 2011 at 15:26
  • "Stakeholder" is kinda Newspeak for "Someone who things they should have a say, but have no legal right to it." What is the real question, we wonder?
    – Tony Ennis
    Jan 15, 2011 at 16:57
  • Depends on the system.
    – Dynamic
    Jun 19, 2012 at 15:27
  • Please specify if you mean specifically "stakeholder" as defined by scrum or if you are just using the term in a general sense? The answer is completely different based on this context. Nov 15, 2012 at 16:40

11 Answers 11


Generally, yes, developers are stakeholders on a software project. That's consistent with the dictionary definition of the term. Here are a few definitions of stakeholder, from various publications:

Karl Wieger's Software Requirements:

stakeholder A person, group, or organization that is actively involved in a project, is affected by its outcome, or can influence its outcome.

Ian Sommverville's Software Engineering 8:

The term stakeholder is used to refer to any person or group who will be affected by the system, directly or indirectly. Stakeholders include end-users who interact with the system and everyone else in an organisation that may be affected by its installation. Other system stakeholders may be engineers who are developing or maintaining related systems, business managers, domain experts, and trade union representatives.

Roger S. Pressman's Software Engineering: A Practitioner's Approach (6th Edition) defines five groups or stakeholders: senior managers who define business issues, project/technical managers who organize and control the practitioners, the practitioners who engineer the system, customers who specify the requirements for the software, and end-users who will interact with the delivered system.

Scott Ambler's Active Stakeholder Participation: An Agile Best Practice:

My definition of a project stakeholder is anyone who is a direct user, indirect user, manager of users, senior manager, operations staff member, the "gold owner" who funds the project, support (help desk) staff member, auditors, your program/portfolio manager, developers working on other systems that integrate or interact with the one under development, or maintenance professionals potentially affected by the development and/or deployment of a software project.


In this definition I have chosen to exclude the developers who are working on the project. This may seem strange at first because developers clearly have an important stake in the projects that they work on. Yes, developers are definitely project stakeholders. Why do I continue to distinguish between developers and project stakeholders? Because I want convenient terms to distinguish them, I really don’t like “developer stakeholder” and “non-developer stakeholder”, and because they have different roles to play on a project.

In practice, I've typically seen stakeholders broken down into groups, and one group contains the people building the system. It is important to recognize that, when building a system, the developers do have needs and concerns that need to be balanced with the needs of everyone else. However, these need to be prioritized and taken into consideration with every other need.


Usually no, but there can be exceptions. "Eating your own dog food" comes to mind as the main exception as in this case the developers may be using what they build directly and thus they are stakeholders to some extent. However, I'd question if this was more than a few percent of developers overall though.

  • Stakeholders != Users.
    – Doc Brown
    Jan 6, 2021 at 11:59

Yes - for a system that will live on and be maintained. Developers are likely to work with the code to fix bugs and introduce new features long after the initial team closed the project. An important requirement for long lived systems are maintainability and who should put their stakes in this if not developers?


If this is being asked in relation to Scrum then no...

...definition of a project stakeholder is anyone who is a direct user, indirect user, manager of users, senior manager, operations staff member, the "gold owner" who funds the project, support (help desk) staff member, auditors, your program/portfolio manager, developers working on other systems that integrate or interact with the one under development, or maintenance professionals potentially affected by the development and/or deployment of a software project...

Stakeholders are individuals external to the current product development team in one form or another. If you are on team X and another developer is on team Y and you are working on differing products which interact with each other at a later point in time then you become a stakeholder in each others product.

  • 1
    -1. You missed "Yes, developers are definitely project stakeholders".
    – MIA
    Jan 13, 2011 at 17:44
  • 3
    @Jim I don't agree with the fact that developers within the direct team are stakeholders. The whole idea is that stakeholders prioritize the backlog, stakeholders appear at the sprint review meeting, stakeholders make decisions about the project outside of the coding approach, etc... The developers within the direct team working on the project by the above mentioned items are not stakeholders. Are they part of the overall team be it Scrum or some other methodology? Yes; but stakeholders they are not. The pig and chicken fable is about commitment to the project...not being a stakeholder. Jan 13, 2011 at 17:54
  • 1
    I'm just pointing out that you're citing someone to support your position who would not agree with your position. For the purposes of that discussion, he's using "Stakeholders" in the narrow sense, but also says that he considers the concept to normally encompass the developers as well. Why cite someone who disagrees with you to make a point? You're better off stating your point of view without reference and letting it stand on merit of your own arguments.
    – MIA
    Jan 13, 2011 at 18:16
  • 1
    @Jim I quoted what was relevant and gave credit to the source. Surely you wouldn't expect me to cite a passage in a novel yet expect that everything within the novel was relevant to my citing? Same idea. Jan 13, 2011 at 18:26
  • 1
    Alright then, I guess I can buy that. Sometimes folks cite others without reading the whole thing. I made a whitespace edit so I could pull the downvote off.
    – MIA
    Jan 13, 2011 at 20:38

After a bit of googling, I must say that this is an unanswerable question. There is no one definition of a stakeholder and different sources use it differently.

As the Scott Ambler reference by Aaron points out, more than one methodology avoids the term altogether. Others try to break it down into different categories of stakeholders. The result is that while there's a general meaning that stakeholder is "someone with interest", the precise meaning is lost.

What that interest is comes down to one of two meanings in my mind:

  • Those who expect to derive primary value from the application


  • Those who will invest in the outcome of the project.

The sponsorship body fits either definition. How end users fit into the sponsorship body is another topic entirely. For now, lets assume they do fit in because I'm not willing to split hairs on it. Anyone on the project team fits the second meaning as well.

In the end what matters is that value is derived from our applications and we understand that the sponsors get the final word.

My general feeling is that people who want to lump in developers into the "Stakeholders" group largely care because they have seen situations where developers are treated as cogs in a machine and often treated poorly as a result. Feedback on requirements is not allowed, significant unpaid overtime is mandatory, etc. Because you're giving up time and sanity above what should be expected, there are people inclined to see that as an investment. Investment = stake so in their minds the development team are stakeholders.

As a result, I'm not a fan of the term. "Sponsors" is clear. "Stakeholders" is not.


I'll answer this question from a different point of view.

In every project I worked on, not treating the needs of developers, testers, help desk, operations the same way as the needs of users of the system, with the same process for prioritization and refinement, resulted in half-assed, difficult to maintain, to operate and to support products, with unhappy users, regardless of how well other processes were performed.

Therefore, if you want an outcome that makes users and their managers happy, you need to consider developers, testers and all other technical personel stakeholders, and give them the same treatment you give to any other stakeholder. The same way there's more to a car than the engine, the drivetrain and the wheels, a software system needs a lot of supporting components, besides the business logic implementation. These components are what the technical personel needs, in order to make the system run in production. There's no way to properly manage the development of those parts unless you consider the people using them stakeholders too. If you don't, you get the equivalent of a 1800s steam powered vehicle, not a modern car.


They may be. If their postion after the product is finished will be different than before, they are a stakeholder. For instance, if a developer is paid a salary to develop software for a company, chances are he is not a stakeholder because nothing will change afer the product is delivered. However, if he is a partner in a startup, where his financial position depends on the product being successful, I would argue that he is a stakeholder.

Another example would be the (admittedly rare) case of a developer making software that he will use. In that case, he definately is a stakeholder because he has a vested interest in having that software work correctly.


Developers are indeed stakeholders (affected by what is produced): both those who initially develop a system, and those who maintain it. The former tend to be interested in new technologies and increasing their skill base, whereas the latter want to be able to keep up with the usually large number of systems they have to maintain.

However, 'legitimate' stakeholders is another question. When balancing requirements, all stakeholders are certainly not going to find their concerns addressed to their satisfaction. Is your company worried about losing top developers? Bump up developer concerns. If not, developers tend to end up fairly low on the totem pole. Unfortunately, this can have the effect of ignoring maintainability as well, building up technical debt like there's no tomorrow.


No, they're not.

Stakeholder: A person or organization that may be affected by the success or failure of a project or organization

Source: http://www.site.uottawa.ca:4321/oose/index.html#stakeholder

  • 8
    What? So you're saying that if the programmer creates crappy software and as a result the company that sells the software cannot survive, that the programmer would not care? Jan 13, 2011 at 15:21
  • @Klaus - I think it assumes a basic level of professionalism, that is he won't produce crappy software. Jan 13, 2011 at 15:43
  • 5
    If I lose my job as a result of the project failing, I'm guessing I'm affected. If I'm the one working 60+ a week, I'm affected. Please clarify your definition of affected.
    – MIA
    Jan 13, 2011 at 17:47
  • 1
    Developers are among those most affected by the success or failure of the project. Personal stress, corporate status, current and future employment -- all these and more are affected by the progress and outcome of the project. Jan 27, 2012 at 23:08
  • By that definition, considering the chicken and pig fable, developers, who are archetypal pigs, are definitely stakeholders.
    – user625488
    Jan 11, 2021 at 16:46

Basically, a Stakeholder is an individual or organization or, put it simply, "is an entity which is having good/bad influence on the project completion".

Stakeholders are very important in project accomplishment. Stakeholders may be a client, usergroup, project manager, project leader or coordinator.

You have to satisfy expectations of stakeholders in project completion.


I think it depends on the project.

A stake holder includes anyone who has a stake or interest in what the system does because then they will have some requirements to say what it should do. Therefore I wouldn't include developers in a project where the code is simply pushed out the door and forgotten but would include them if they are supporting the project or extending it as it is then the developers require the system to be maintainable/extendable.