First, thanks for becoming a regular here. I really appreciate the conversation.

Now, I am not sure if treating employees as a “tangible asset” is a good idea either, as that could get twisted as well. However, you do have a key phrase here:

“Organisations need to realize that their knowledge employees hold the potential to improve the productivity of their operation.”

If employers really understood that, things could change drastically.

Organisations need to realize that their knowledge employees hold the potential to improve the productivity of their operation. Smarter people uses better ways to get things quicker and better.

One way for company to embrace knowledge as an important asset is to have them put in knowledge sharing or creation activities sas a part of their employee KPI and overall company strategic agenda.

This will encourage people to share their expertise and minimize the effect of turnover.

I really hope that one day organisations will start treating knowledge workers like us as a tangible asset rather than resource.

Absolutely agree on still requiring management. I hope I did not make it seem like management was not required at all.

“So what is being said here is that companies, their owners and their managers should respect their employees and give them a fair deal.” Amen to that!

With respect to the substitution of people, the idea stems more from when software engineers are not seen as more than hours for a project. Granted, this is more of an extreme case of the “resources” problem, but it does exist in many environments. Logically, that should never happen. I do not want to go as far as saying managers like these are inept, just that they have to get out of the manufacturing mindset (or however they got there).

Alternative words may help a little, but it is the concept that needs changing. I would go so far as to say that you include proposed titles of the engineers on the team. That way you know what you might be sacrificing if you do not get the appropriate engineers.

“Any physical or virtual entity of limited availability, …”

Some companies don’t look at their employees as anything other than machines to churn out code. Some treat them well – pay them well, give them a comfortable workplace, give them flexibility in work hours etc. But at the end of the day both are dealing with a limited resource that they have to use to produce.

So what is being said here is that companies, their owners and their managers should respect their employees and give them a fair deal. Knowledge Building will happen in almost all circumstances but is best fostered in an atmosphere of openness and respect where the individual has the opportunity to explore.

In such an atmosphere the word “resource” does not have the same negative connotation as in a place where people are not treated well and are mere “resources”. I have worked with both kind of organizations, both as a software engineer & as a manager, and have used the objectionable word in reports and general dialogue. In the companies where people are treated well the word is not offensive to almost everybody, including the so called resources.

Rob, you posed the question of staffing a project where a more knowledgeable person is being replaced with somebody without the same level of knowledge. What are the factors involved? No manager in his or her right mind will willfully do such a thing unless the first, more knowledgeable person is no longer available. And in such a scenario he or she might not have a viable alternative. Of course if the manager then measures the individual’s performance with the same criteria as that used for the more knowledgeable person then the manager is at fault – not the word “resource”. Or are you saying that our managers are so inept that they don’t see the difference?

Finally, do you have an alternative word to suggest that would convey the same well understood meaning? “People” perhaps?

Your comment is very related to what Ken is saying as well. Performance cannot be directly measured just like productivity. So, we default back to the task management perspective, just like I mentioned in my response to Ken. Then, we get those people that manage tasks best moving into management. The initial path may be different, but the end state is the same.