Skill – The ability to execute a practice, process, or procedure successfully; the ability to accomplish.
Competence – The ability to increase or acquire skill over time; the ability to grow in capacity.
Talent – The ability to decide which skill is best to apply, and/or invent and execute practice, process, or procedure, where no skill exist with reasonable success, and/or the propensity to gain competence in acquired skills.
If you take the definitions above from my prior post, you will start to recognize that much of what IT does requires talent. That skill and competence deal primarily with repetitive activities, that support an essential certainty about their execution. While these activities require decision making, the decisions and the decision criteria are constrained, they follow patterns.
Those of you who have spent their careers in IT will recognize that many of the activities that IT professionals do are not repetitive. They require invention, hypothesis, or discovery. These activities present new and unconstrained decisions. In short, they require talent.
Even in the lower level positions where staff are required to troubleshoot or diagnose problems, speed and effectiveness that a resource exhibits are often the evidence of talent rather than skill or competence. The diagnostic process typically requires us to rule out factors as causal to the symptom reported. The sequence in which those factors are ruled out is the predictor of speed. The talented problem solver will gather information in a way that allows them to select an optimal sequence. They don’t do this because they are experienced at solving that kind of problem, they do this because they intuitively understand the problem domain, and the relationships between symptoms and causes. Their diagnostic search for the causal factor is optimized, and when they lack information to further optimize their search they will gather that information. They hold the entire “system” in their mind, and examine it from different perspectives, looking for possible causes. If they don’t know what the current “system” looks like, they design their own, and compare that one, to the parts that they can see.
The same evidence of talent is present in the best “programmers”, even at an entry level. They can envision the part that they have been asked to build, and they envision how it works in concert with the whole system. They don’t merely write code, they craft it. They don’t need to be told to test their output, they want to certify the operation themselves. They think beyond how their component is supposed to work, to what it is supposed to do, and beyond that to why it is important in the larger context of the whole system or business. This “talent” makes him many times more effective than his peers, as he can be relied on to deliver well. When they are asked to do something that does not fit with their understanding of the larger system or goals of the organization, they do not blindly go forward and do what they are asked – but they make sure that they and their customer (or boss) are aware of the ramifications of the activity.
IT requires skill and competence. Those things are important, but IT thrives on talent. That is what makes the engine of IT go. Not skill, not competence. TALENT.