“She just doesn’t seem technical enough.”
“We need someone a little more technical.”
I’ve heard phrases like this too many times at software companies over the years, mostly while discussing job candidates with colleagues.
Similarly, while talking to people interested in building an app or joining a software company, I’ve heard things like, “I’d love to do that, but I’m just not technical.”
“Technical” is not a useful adjective to describe human beings. Here’s why.
It’s Too Vague
Referring to someone as “technical” is usually shorthand for saying that someone possesses technical skills.
Well… which technical skills? A technical skill is an ability to perform certain specialized tasks within some domain.
The ability to write code in Python is a technical skill.
The ability to manipulate photos in an image editor is a technical skill.
The ability to compute sums is a technical skill.
The ability to use a fork or chopsticks to eat is a technical skill.
The ability to run on steep, rocky terrain is a technical skill (one I learned the hard way when getting into trail running!).
No one’s born knowing how to do any of these things, but people can learn, and then they have a technical skill in the corresponding domain.
Therefore, when we say someone is “technical” or “not technical” or “not very technical,” we’re communicating virtually nothing. Everyone is “technical” by some definition in some domain and is capable of learning other technical skills in other domains. Being more precise in our language will improve our communication.
It Hides Bias in Hiring Decisions
I frequently hear people labeled as “technical” or “not technical” in evaluations of job candidates.
For example, I’ve seen candidates rejected for reasons like, “She just doesn’t seem technical enough.”
Because of the inherent ambiguity in the term “technical” as applied to people, it’s important to consider the reasons someone might not “seem technical.”
Is it because she doesn’t remember the required arguments for a common standard library method?
Or because she happens to be a good communicator (and she couldn’t possibly be good at speaking and coding)?
Or because she doesn’t look like other engineers you’ve known?
It’s better to be more specific — “We decided before we started interviewing that we need someone who has already built X using technology Y or Z, and this candidate has not done that.”
Identifying more specific reasons for rejecting candidates helps to reduce unconscious bias.
The added benefit of specificity here is it helps you identify any ludicrous implicit requirements lurking behind your interview process. For example, “The candidate must have all the standard library method definitions memorized,” or even, “The candidate must have the same subset of standard library method definitions memorized that I looked up right before this interview.”
When discussing candidates, don’t say, “She just isn’t technical enough.” Rather, identify which required technical skills she lacks, so that others involved in hiring can understand — and yes, potentially challenge — your decision.
It Blocks Technical Contributions From “Non-technical” Employees
If you draw a clear boundary between your “technical” and “non-technical” employees, you’re almost certainly missing out on opportunities to get more value out of your employees.
I once worked with a social media manager who expressed an interest in learning web development. I spent a little time introducing her to version control and HTML, and within hours, she was contributing content updates to the company website.
Is she “technical” now? Did she magically become “technical” when she wrote her first bit of HTML? Or when she made her first commit to the repository?
I would argue that it doesn’t matter. At all.
She can write some HTML now, so allow her to write some HTML, and yes, have it reviewed by peers as all code should be.
If the company had decided she was firmly in the “non-technical” bucket, then we never would have benefited from her contributions.
While teaching a kids’ coding workshop recently, I noticed all of the “non-technical” volunteers were helping the kids troubleshoot bugs in their coding projects. How was this possible when they were “non-technical” volunteers?
It’s because all humans have reasoning and problem-solving skills, and in many contexts, this is most of what being “technical” really requires.
Maybe your manual QA tester wants to learn a little Python to automate tests. Maybe your salesperson wants to learn a little bit of HTML and CSS to customize demo pages for clients. Maybe your customer service representative wants to learn a little JavaScript to help troubleshoot customer issues on your website.
Encourage all of this!
A supportive culture that emphasizes cross-domain learning and collaboration can flourish only when we abandon vague, polarizing labels like “technical.”
It Limits Your Potential
“I’m not technical” is such a disempowering expression.
First of all, it’s just not accurate. I’m confident that you have some technical skill. Maybe you can make helpful spreadsheets, maybe you can do basic arithmetic, or maybe you know how to send email from your iPhone. Since “technical” is so vague, yes, you are “technical.”
Now, it also may be the case that you lack a certain technical skill in a specific domain. For example, it may be accurate for you to say, “I don’t know how to code in Ruby,” just like you may say, “I don’t know how to read English.”
Both of those, however, are temporary conditions that you have the power to change. You can learn to read. You can learn to code.
Describing the situation in terms of which skills you have and which skills you lack is much more helpful than, “I’m not technical,” which just creates a self-limiting identity.
There’s no magic to coding or any other technical skills. People are not “technical” or “not technical.” We all have a variety of skills already and the potential to learn any others that we choose.
Especially in this age of online education programs and short-term engineering academies, people’s skill sets are changing daily if not hourly.
The false dichotomy between “technical” and “not technical” people is helping no one, so let’s move past it.
About the Author
April Wensel has spent the past decade developing software and leading teams at various startups, research institutions, and a couple giant tech companies. She’s passionate about the intersection of technology and the human experience. She tweets and responds to email.