(In)competence Inventory

Recently I heard a talk by the founder of a company specializing in making competence inventories. The talk was quite impressive. The speaker showed several colorful slides, and talked about the very advanced software the company uses to collect information about employees, and present it in a manner that is easy for managers to understand and use.

Still, there was something that wasn't quite right. I grew suspicious at the beginning, when the speaker talked about the purpose of making a competence inventory. Knowing the skills, and the level of skill, of each employee is very important, he said, because it makes it easier to decide whom to fire when cutting costs.

Not only was that the most important purpose of having a competence inventory, he gave no other reason. (But see below for an analysis of the reasons given at the competence inventory company's web site.)

Let's think about that, not from a human point of view, but from a business point of view. (The audience consisted chiefly of Human Resources people, and nobody protested. Therefore, I suppose from a Human Resource point of view, firing people on the basis of a competence inventory is OK.)

From a business perspective, if we do a competence inventory, there should be a good reason for it. After all, making the inventory costs money, and requires people to spend time being interviewed. (An hour or two per employee, using the methods the speaker advocated.)

The idea is that having the inventory will enable us to get more of what we want than we had to spend to get the inventory in the first place.

Suppose, for the sake of argument, that what we want is more money, now and in the future. There are three ways we can get that:
  • Increase Throughput (optimize the value stream)
  • Reduce Inventory (reduce waste, work-in-process)
  • Reduce Operating Expenses (pay less for consumables, fire people)
It seems pretty clear that a competence inventory can be useful whichever way you go here. (I hope you forgive me for not going into details and proving it.) This means that a company that wants a competence inventory is likely to want it for whatever they try first.

It has been proven over and over again that increasing Throughput and reducing Inventory are much better ways of improving profitability than reducing Operating Expenses. (The Goal by Goldratt, Lean Software Development by the Poppendiecks, Out of the Crisis by Deming, The Toyota Way by Liker, etc.)

Thus, a company with reasonably competent managers would make a competence inventory for the purpose of either increasing Throughput, or reducing Inventory. Only when all else fails do they resort to reducing Operating Expenses.

We can conclude that the act of ordering the Inventory for the purpose of reducing Operating Expenses, as the speaker suggested managers should do, is itself an indicator of lack in competence at the management level.

Looking at the speakers web site, another argument is presented: they create the inventory based on current and expected future competence needs. In other words, they look at the company's current strategy, and decide which competences to look for.

This is extremely dangerous. Strategy is based on incomplete information about an environment that can change very quickly. Therefore, strategy must be emergent, and the organization must be structured so that it can take advantage of emergent strategies.

An important factor shaping emergent strategy is management's knowledge of the resources and competences that are available. It follows that if you ask people questions about a fixed set of skills, there is a great risk that you miss something important. An employee (or group of employees) may have knowledge that would reshape management's strategy dramatically, if they had known about it. (If you know what a Johari Window is, you will understand. The knowledge that affects us the most is often the knowledge others have that we don't even know exists.)

For example, the speaker showed results from a competence inventory for programmers. The inventory focused solely on programming skills and domain modelling skills. Care to guess how many important skills that were missing from that inventory? Many more things than were in it, I can promise you that.

Thus, a good competence inventory must be open-ended.

What do you think happens when employees figure out that the company makes a competence inventory in order to decide whom to fire? The most obvious consequence is that they will distort the data by lying.

Another consequence is that the people remaining in the company after the pogrome will have lost all trust in their management, and will perform significantly worse than before. (Read Business Dynamics by John D. Sterman if you want to know how serious the consequences can be, and how long they last.)

Finally, the speaker mentioned that a competence inventory must be made quickly, in order to be as cheap as possible. OK, I agree, you need to keep the cost down, but then he mentioned that his company uses one to two hours to interview each employee.

Well, if I am asked to do a competence inventory, I use Crawford Slip, which takes an hour or two for each group of people I interview. A group can be up to 500 people.

Of course, even though I am a great fan of competence inventories, I do not do one unless I am pretty sure the inventory will help the company and the people in it, rather than sink it.

You know, if I was considering hiring someone to help with competence development, the first thing I'd ask that person is what the person does to develop his/her own competence. And I'd be sure to ask specific questions: Bring four books you have read recently, and show. Show me what you have written about competence development. Show me an example of a plan that shows how increased competence leads to improved profitability (or whatever the goal is). Show me Negative Branches (undesired effects of increasing the competence within my company) and how to deal with it.


Popular posts from this blog

Waterfall - The Dark Age of Software Development Has Returned!

Waterfall vs. Agile: Battle of the Dunces or A Race to the Bottom?

Interlude: The Cost of Agile