People are Not Tools

I've been reviewing job descriptions from clients that are a laundry list of tools. Or, that ask for “significant experience” with a particular technology.

No, no, no. People are not tools. They are human beings who have specific qualities, preferences, and technical and non-technical skills.

When you think about those personal qualities, think about these questions:

  • With whom does this person work?
  • What kind of deliverables does this person have in the short term and the long term?
  • What kinds of interpersonal skills does this person need to do their job well?

Take a look at the job analysis template to see more questions. Now you're ready to think about technical skills.

Here's how I categorize technical skills: functional skills, subject matter domain expertise (problem-space and solution-space), tools and technology, and industry skills. Of these four areas, functional skills–how good a developer, tester, architect, designer, etc the person is, and subject matter domain expertise–how quickly the person can learn the internals of your system, matter the most. Most people can learn new tools relatively quickly. But it takes much longer to learn how to test first, or use combinatorial testing, or see the whole picture and what can go wrong, and so on. Functional skills require experience, and more than the same year of experience again and again.

When you think about the people you need, think hard about those technical skills, and which skills you really need. Tools, and familiarity with a particular tool may not be as important as the ability to work in small chunks and finish things. Or to explore the product to find really bad defects. Or to see how the system flows–or doesn't–together.

People are not tools. Look for people, not tools.

10 Replies to “People are Not Tools”

  1. Pingback: People are Not Tools- Forex4Trader
  2. I find it interesting that hiring descriptions always seem to differ from actual job specifications, and in far to many cases neither are of any real value.

    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!

  3. The people == resources thing is one of my pet peeves. I think of a resource as an asset that can be substituted for another asset of the same type. For instance, if your telephone stops working, you can substitute another telephone and it will work the same. If your chair breaks, you can substitute another chair and it will work the same. If a particular make and model of computer breaks, you can substitute another of the same make and model (and operating system) and it will work the same. People don’t function in that way, and you can’t “manage” them in that way.

    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.

  4. On a related note: In addition to not being tools, people are also not “resources”. I’ve never understood why HR insists on using the term “resource” instead of “person”. As in: “We’ll need one more resource on this project”. It’s dehumanizing.

  5. So what should I put on my job reqs when I am hiring a Sharepoint consultant? I can’t hire a great consultant and train them in Sharepoint in a week and then send them on the job- that’s the what the company I am working with did with their developers which is why they are calling me. I fairly often need someone with “significant experience” with a tool to mentor others.

  6. I agree. Many of those intangibles (true analytical thinking, ability to see the big picture, ability to work effectively with non-technical stakeholders, etc) are often more important than highly detailed, tool-specific requirements (a programmer could probably pick up another language fairly reasonably).

    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.

  7. I agree, I think that a lot of skills that senior technical people have are intangible, how do you put a value on industry specific experience scenarios?

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.