I am a full-time developer; almost everywhere in project management we are listed as resources. Are there better terms to use other than resource?

I feel term resource has a connotation of being temporal: something used and thrown away once tasks are complete, etc. Maybe I am wrong, but it bothers me to be described that way. Are there other ways of referring to tech staff in project management?

  • 5
    Do you know what HR stands for?
    – jiggy
    Feb 10 '13 at 16:45
  • Would you prefer to be considered endless, so no one restricts what they expect from you?
    – Jeff O
    Feb 10 '13 at 16:47
  • 4
    What about "humans" or "employees"?
    – bjarkef
    Feb 10 '13 at 17:03

I prefer the word "people".

However, if you work at a company which treats people as interchangeable cogs with no individuation, you are unlikely to get them to change their terminology. At least "resource" is better than "warm bodies" or "butts in chairs", both of which make it even more clear precisely how valuable the resources in question are.

  • 1
    +1 I've never seen the difficulty with calling people people. Although I also quite like 'Organic Worker Unit' (used sarcastically with anyone who uses 'resource').
    – Ben
    Feb 21 '13 at 9:45


Agile frameworks like Scrum generally refer to developers as "team members." The specific nomenclature can vary from framework to framework, though, and is not prescriptive.

Project Management is About Resource Constraints

Project management is a field built around managing constraints. Those constraints may be time, money, skill, or available labor, but all of those things can be defined as "resources." Almost by definition, employees and contractors provide skill and labor resources, but the use of the word to describe the people themselves is an unfortunate by-product of modern business culture.

It could be worse; in some companies, you may not even rise to the level of a "human resource." You could be labeled a "report" or an "asset," both of which are still better than being a "cost center." Count your blessings and move onto something more productive.

Build Alternative Terminology into Organizational Change

So, from a project perspective, you are a resource. However, the shift to agile practices tries to instill a sense of value for people beyond treating them as fungible assets. The Agile Manifesto explicitly values individuals and interactions over processes and tools.

On projects that I manage, I try to differentiate between the resources that people provide and the people themselves. Treating people as people—and as integral members of a team—is certainly important. However, while words sometimes convey ideas about how a company views the people who comprise its workforce, organizational culture is much more than just a bit of neuro-linguistic programming. Improving organizational culture may include changes in nomenclature, but it shouldn't become an end unto itself. That's just tilting at windmills.


"FTE" (full-time employee) is a somewhat more humane term that I've seen used at various organizations.

The fact that its common form is an acronym helps retain the abstraction so that project estimation and assignment can be done in the aggregate without accounting for individual variance; the long form of the acronym uses the nicer term "employee" which I don't think has the same connotation of something temporary.


The contribution of the people to the project success lives on

If it makes you feel any better, the term project itself has a connotation of being temporal: with a start date and an end date. As a consequence, the association of people to the project is also temporal. In contrast, operations has the connotation of being permanent or ongoing. However, while the association of people to a project may be temporal, the contribution of the people to the project success lives on. That is something you can feel proud about.

Also you, being a software developer, are looking at this from the point of view of IT projects. In IT projects resources are almost exclusively people. However, in construction projects for example, you can have people as well as equipment such as cranes as resources. This is the reason project management tools use the generic term resource.

Beyond the tool though, my suggestion is to use the term "Contributor" for people working on the project.

  • The contribution of the people to the project success lives on, nice said Ashok Ramachandran, thanks.
    – user5629
    Feb 20 '13 at 3:33

One of the tradeoffs is that the methodologies are trying to use generic terms as shorthand to refer to positions on a project. The use of shorthand is to facilitate discussion.

For example, people discussing a certain aspect of a project can say "This new account management functionality is going to require 6 programmers, 2 QA analysts, 1 graphic designer, and 1 product manager." Or they could say "This new account management functionality is going to require 10 resources." It depends on the context and the required level of specificity.

I've been a programmer and a manager. When I was a programmer, I joked with my managers about referring to me as a "resource". When I was a manager, I joked with my developers about referring to them as "resources". I always knew my managers didn't mean anything personal by the term, and I hope my developers knew that I didn't think of them as unemotional automatons.

You could be over-thinking this language thing. But if you're looking for alternative terms, anything term can be looked at as "degrading" to the extent that it anonymizes people or the functions they perform.

If you want something that people won't be insulted by, use something that approximates their actual job titles: developer, programmer, designer, etc. But then of course you have to worry that people will be insulted because you're lumping the Associate Programmer I's with the Senior Principal Developer V's. :)


"Personnel" perhaps? I think it's pretty rude to use a term that doesn't even acknowledge that you're dealing with people at the end of the day. Alternatively (and not quite as nice), you could use "Direct Reports" or "employees" in circumstances where you need to imply something about relative positions in the corporate structure.

There is perhaps a tangential discussion of the homogeneity of developers here. The interchangeability of developers is a common management misconception spread by the sellers of outsource services. Yes, you can swap out one developer for another in the same way that you could probably swap out a heart surgeon for a GP in the long run. The GP knows about the body in a generic way and might eventually be able to do the same work as the heart surgeon, but how long would it take to get there and would they ever be as good? If the answer to that question is clear then the pros and cons of considering developers as easily interchangeable "resources" should also be clear.

Incidentally, I've spent months (maybe years now) trying to get outsource developers to do anything useful in my organization whilst the in house developers get all the real work done. Politics and dogma have prevented the more senior management from seeing or acknowledging the true costs of attempting to outsource. In the end you go from a smaller pool of more expensive but talented and innovative developers to a large pool of cheaper and less talented developers who struggle to do anything without it being described and specified to the Nth degree.

  • Welcome to pmse. Your last two paragraphs don't appear to have anything to do with the question; rather they seem to be arguing for using no term at all. Can you clarify?
    – Sarov
    Jun 29 at 13:05

I've seen the word 'Asset' used as an alternative that might be associated with happier feelings.

Having said that, I feel like employees are resources. Resources can be quite valuable and quite needed.

But they are temporary and they should be interchangeable.

In the US, the median duration of employment in the Software Industry (Computer and mathematical occupations) is about 5 years.


  • That long? I'm surprised. Feb 10 '13 at 16:45
  • 1
    -1 for thinking developers are (and should be) interchangeable. Neither productivity research nor common courtesy support this view.
    – Todd A. Jacobs
    Feb 10 '13 at 21:07
  • 1
    CodeGnome, by interchangeable, do you mean, generic skills such that one developer can move to a different functional area and code or do you mean irreplaceable? Feb 10 '13 at 22:03
  • I'd say that one of the advantages of the 'interchangeability' would be to diminish the risk of losing one developer... so in this sense I'd say everyone (not only developers) should be interchangeable (i.e., everyone must have a backup resource, hehe). But this question is not the focus of the topic.
    – Tiago Cardoso
    Feb 11 '13 at 13:25
  • @CodeGnome - Any qualified plumber should be able to pick up the work of any other qualified plumber. The same should be true of qualified employees. When a CEO dies/retires/quits the company doesn't immediately close it's doors...they get a new one. When a fry cook at McDonald's quits...they get a new one. Saying employees are interchangeable doesn't mean everyone can do every job; it means any reasonably qualified candidate can. If employees were not interchangeable every PM report would include specific names, since they are the only ones who can do that job.
    – Rob P.
    Feb 11 '13 at 19:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy