As an aside, a technical tool isn’t just a tool either. When writing requirements for tools, I see people often be a little too literal about easy checklist items (yes/no: integrates with LDAP) and not enough about how it needs to live with other tools and be used.

This post was mentioned on Twitter by johannarothman: Careful of those job descriptions. People are not tools: http://ping.fm/CUaGV…

The words we choose when we express our ideas tend to influence the way in which we think. When we use terminology that reduces people to the level of resources, there’s a danger we will try to apply management techniques and metrics to them that aren’t appropriate for human beings, although those methods might be just fine for telephones and chairs.

Recently I was working with a group of managers at a client company, and we were brainstorming a description of the ideal future state for the company. One of them offered this characteristic of the ideal company: “Our resources are aligned with our business needs.” I asked, “Do you mean that the chairs are lined up straight?” They laughed, and ultimately agreed that they really shouldn’t refer to people as “resources” on a knee-jerk basis, just because it happened to be common biz-speak. Before long, they had started to correct on another when they slipped up and referred to people as “resources.” It was a good moment, IMHO.

Also, job descriptions need to be communicated within the team and preferably to other key stakeholders which is something I rarely see. It’s no good having a great job description if no-one other than your manager gets to know what your job actually entails!