Skills versus Tools
by J. Edward Durrett
In reviewing applications, discussing roles, reading the news and reading job descriptions, I have found that there is a great
confusion as to what constitutes a skill (the ability to accomplish x,y or z) and a tool (the means by which x,y or z is
accomplished). This is problematic for achieving a goal or engineering a solution requires the understanding of the difference
between the two. A few years in the work force is enough to show anyone what happens when the solutions are created for the
tool being used rather than using analytical skills to create a solution using the best tool possible. The tool becomes the
focus of attention rather than providing the solution that aligns with the overall goal of the organization. The old analogy
of someone with a hammer sees every problem as a nail is apt here.
Expanding on the above definition of a skill, the ability to accomplish x, y or z, it is important to note that skills have
very little to do with technology as technology itself is merely a tool. The most important skills in engineering in general
and InfoSec in particular is the analytical thinking. This is not knowledge or the memorization of a charted out process, but
the ability to start from zero and create the process. Of course experience and practice lends a guiding hand; however, the
difference between analytical thinking and following an established routine is that the former means you can break, when
needed, from the latter.
Skills are abstract and very difficult to quantify. Added to that, the attempt to quantity them is often by using tools. The
idea being, when one is able to solve a problem with a tool, that person must posses the analytical thinking that is required
for a particular role. The problem is that only measures the ability to use a tool on which the person might have been
previously trained. A simple example is someone who was trained to use a particular word processing program. They might be
whizzes at it. What happens, though, when a new version comes out? What happens if the company decides to switch software
vendors for the the program? Analytic thinkers will adapt quickly. Someone trained to use the tool won't until they get
So, then how does one measure this thing which is so difficult to quantify? Education is certainly a measurement as the
college one attended and the degree received is an indication of possessing analytical skills. So too are experiences. For
example, if someone knows one programming language and has been using that language to perform specific non-creative functions
at a company for their entire career, that is not an indication of analytic ability. However, if someone knows a myriad of
programming languages and has worked on projects spanning the entire stack, the likelihood she has analytical skills is much
higher. The same is true for people who have worked with multiple systems and in fast paced changing environments.
Tools, the means by which x, y or z is accomplished, differ from skills in that they exist to fill a function. Take the hammer
example. A hammer drives a nail. There are different size and type of hammers ranging from hand held to air driven hammer
guns. I would find an advertisement for a carpenter position (which, incidentally requires analytical thinking) to be
laughable if it stated the carpenter must have a 12 oz Stanley Hammer skill. Yet, in positions ranging from office assistant
to programmer, specific software, including versions, are often listed. On resumes, people list software and versions as
If I were hiring a carpenter, I would look for one who could logically find the best tool for the job even if they had never
used that tool before. That seems logical. The difficulty is, when writing a job description, it is nearly impossible to say
this succinctly. Some examples I have come across which approximate this are along the lines "2 or more programming
languages" or "multiple OSes" yet that is rare. Again, the difficulty is in trying to quantify something which
is very abstract, skills, into an easily read form which by definition is not abstract.
 Having conducted training, I must note that this is not impossible and employees who require training after an upgrade
should not be discounted. It is poor management, however, to expect all employees just 'get' a new software system. The number
of people who can do that are very rare and particularly suited to the types of roles which require using software to do the
same thing day in and day out (like data entry, for example).