Hello Joel:

>I assume you define talent as an individual's natural (or learned) ability to perform a task. Is this correct?<

Talent is something we have before we get to the job. I use the word talent as defined in the book "First, Break All the Rules, what the world's greatest managers do differently."

>In what context would talent be important to defining a specific role or position?<

Talent is what separates the top performers from the rest.

If we want to be sure that all our new hires and employees become long-term successful employees, we need to make sure that all employees are competent and have a talent for their jobs.

For employees to find job success...
talent is necessary, but not sufficient.
skills are necessary, but not sufficient.
training is necessary, but not sufficient.
orientation is necessary, but not sufficient.
knowledge is necessary, but not sufficient.
competency is necessary, but not sufficient.
qualifications are necessary, but not sufficient.
effective management is necessary, but not sufficient.

Talent is the only necessary condition for job success that employers cannot provide their employees and schools cannot provide their students. Employers must hire talent, see the book "First, Break All the Rules, what the world's greatest managers do differently." I can send you my review if you'd like.

Most employers don't measure talent so they can't hire for talent even if they do hire the best and the brightest.

The following ties competence and talent together in a short guide for selecting the right people for a position. Talent and competence are necessary but they are two different things. Selecting for competence and talent avoids many performance problems. You'll notice that there several conditions when Highly Competent people should not be hired or selected for a position. Each position has its own talent requirement.

Job applicants can have
1. Excellent Talent
2. Adequate Talent
3. Inadequate Talent

Job applicants can also be
A. Highly Competent
B. Competent
C. Not Competent

The following is the order in which applicants
and/or employees should be selected for positions.
1A = Excellent Talent and Highly Competent
1B = Excellent Talent and Competent
2A = Adequate Talent and Highly Competent
2B = Adequate Talent and Competent

The following should be selected if they can become competent.
1C = Excellent Talent and Not Competent
2C = Adequate Talent and Not Competent

The following should not be selected.
3A = Inadequate Talent and Highly Competent
3B = Inadequate Talent and Competent
3C = Inadequate Talent and Not Competent

Talent must be hired since it cannot be imparted or acquired after the hire.

I hope that helps.

What is your advice on altering the language in some of the purchases competency model systems - adding in some details like a system name, changing some of the words to be in line with the organizational competencies? I understand the benefit of keeping everything the same (word for word) to make it easier to use supporting development planning or talent assessment tools that the competency company or partner may offer. However, I find the language too different from what the associates would expect too see. In some cases, the description would need to be translated for them - it's on target for the most part in terms of skill and knoweldge requirements but uses different words to describe this.

quote:

Originally posted by PatB:
In the past, I've used the competencies developed by Lominger for such a project.

In terms of issues when selecting a vendor, I think the most obvious is do the competencies make sense in your organizational culture. What I saw when going through the creation of competency models was that during the planning stage, often the title of the competency caught someone's attention as being either important or unimportant, but when you actually examined the definition of the competency, that belief changed. So if you're buying out of the box competencies, make sure the language used in the definition will resonate with your org culture.

I don't know whether or not you've created competency models before, but at the risk of sounding too preachy, and answering a question that you didn't ask, I'll throw some more advice out there.

I spent months on these models and then they were barely used. Not because we didn't put the due diligence into making sure the organization was ready (we did), but because we missed two very important steps--

First, make sure that the competencies are aligned with actual job tasks, and these need to be documented for the organization. So a competency might be Action Orientation (from Lominger), but you've got to answer "What does this mean for my job?"--What do I do every day that shows whether or not I have good Action Orientation?

Second, you've got to provide avenues for development. Not necessarily training--but developmental opportunities and ideas for each competency.

Quote:
What is your advice on altering the language in some of the purchases competency model systems - adding in some details like a system name, changing some of the words to be in line with the organizational competencies? I understand the benefit of keeping everything the same (word for word) to make it easier to use supporting development planning or talent assessment tools that the competency company or partner may offer. However, I find the language too different from what the associates would expect too see. In some cases, the description would need to be translated for them - it's on target for the most part in terms of skill and knoweldge requirements but uses different words to describe this.
*************************

Anny--I know it sounds overly simple, but you need to do what will work for your organization. If that means translating some of the language to fit, I would move in that direction. However, a couple of things I would be wary of:

You've got to be careful that makes sure nothing is lost in translation. Changing a word here or there may not seem like a big deal, but you've got to make sure that the definitions stay consistent, or you run into problems of overlap.

Be aware of copyright issues

I wouldn't get so bogged down in the minutia such as adding in actual systems names (e.g. PeopleSoft for payroll). In cases like that, I think just having the "systems" reference is enough.

"you need to do what is right for your organization" Wise words.

Nero