Time To Proficiency

There are two metrics that are at the core of any sales systems success. I have never heard of them measured or discussed. Because our language of technology (at least in the world of recruiting) does not include handy references to these factors, our discussions of technology keep coming up short. And we keep getting low adoption rates for the systems that we install.

Today we talk about the first and most important metric: Time to Proficiency (TTP).

All sales software is proportionally diminished by the amount of training that is required to make an average user proficient in the use of that tool. We don't pay sales professionals to run software. We pay them to close deals. (Through my previous posts you can see that I believe that recruiting, or as

Doug Miller

says even more eloquently "Talenteering", is a sales function.) There is an inverse relationship between the talent of a sales person and the probability that we will hold them accountable for using any particular toolset to achieve the stated objective. In English: good sales people don't get fired for not using their computer. This, coupled with the tendency to have a high degree of turnover in sales positions (especially recruiting), means that a lot of time and money is wasted training users how to use systems that you can't make them use and which will probably only have a limited utility to them anyway.

Those of who chose, implement and manage sales and sales management systems because we think they add strategic value to the enterprise (including their first cousins Applicant Tracking and Recruitment Management Systems) have to ask ourselves if we aren't just wasting our time and everybody else’s.

I don't think we are. But the only way to measure the utility of our time is to measure the value of the sales person’s. Specifically, we need to know how long it takes the average sales person (talenteer) to become proficient using the tools we provide for them.

Something that I have advised people to do (and which they never do, so my particular brand of salesmanship must stink) is to have a standard user (I will write about user types in future blogs) sit down in front of a demo system, give them a standard task (i.e. “open a req”), and time them as they try to make it happen. Make sure you get a wide enough sample, take out the high and low score to normalize for standard deviations in any user group’s technical proficiency, and average the number. This is the "Time to Proficiency." If a user can't figure it out at all, give them access to resources to educate themselves or solve the problem, but then add a preset amount of time to the score as a penalty for having to use those resources.

Anybody who has spent a lot of time installing and managing sales systems knows that non-regulatory users (that is, those users that are not required by their job descriptions to use a particular tool), will spend twice as much time figuring out how to manage around a system as they will trying to figure out how to manage with it. So your applied penalty for taking time to find an answer should be significant in that it is likely that such a requirement will put the user off using the system altogether.

Time to Proficiency therefore becomes a quantitative measure for system quality. The specification for any system should include the amount of time (and the associated cost of that time) that it will take to have an average user become proficient with the system. Therefore, testing a system for its ability to meet that specification is a statistical method for determining the quality of a system.