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?
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.
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 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.
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.
"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.
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.
