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
  • 3
    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 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. :)


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. – Devdatta Tengshe 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? – David Espina 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