Get the highlights in your inbox every week.
What does being 'technical' mean? | Opensource.com
What does being 'technical' mean?
Dividing people into "technical" and "non-technical" labels harms people and organizations. Learn why in part 1 of this series.
The word "technical" describes many subjects and disciplines: technical knock-out, technical foul, technical courses for rock-climbing competitions, and technical scores for figure skating in sports. The popular cooking show The Great British Bake-Off includes a technical baking challenge. Anybody who has participated in the theatre may be familiar with technical week, the week before the opening night of play or musical.
As you can see, the word technical does not apply strictly to software engineering and operations, so when we call a person or a role "technical," what do we mean, and why do we use the term?
Over my 20-year career in tech, these questions have intrigued me, so I decided to explore this through a series of interviews. I am not an engineer, and I don't write code, yet this does not make me non-technical. But I'm regularly labeled such. I consider myself technical, and through this series, I hope you will come to understand why.
I know I'm not alone in this. It is important to discuss because how a person or role is defined and viewed affects their confidence and ability to do their job well. If they feel crushed or disrespected, it will bring down their work quality and squash innovation and new ideas. It all trickles down, you see, so how can we improve this situation?
I started by interviewing seven people across a variety of roles.
In this series, I'll explore the meaning behind the word "technical," the technical continuum, the unintended side effects of categorizing people as technical or non-technical, and technical roles that are often considered non-technical.
Defining technical and non-technical
To start, we need definitions. According to Dictionary.com, "technical" is an adjective with multiple meanings, including:
- Belonging or pertaining to an art, science, or the like
- Skilled in or familiar in a practical way with a particular art or trade
- Technically demanding or difficult (typically used in sports or arts)
The term "non-technical" is often used in tech companies to describe people in non-engineering roles. The definition of "non-technical" is "not relating to, characteristic of, or skilled in a particular field of activity and its terminology."
As somebody who writes and speaks about technology, I consider myself technical. It is impossible to write or speak about a technical subject if you aren't familiar with the field and the terminology. With this understanding, everyone who works in tech is technical.
Why we assign labels
So why does technical vs. non-technical matter in the technology field? What are we trying to achieve by assigning these labels? Is there a good reason, was there a good reason, and have we gotten away from those reasons and need to re-evaluate? Let's discuss.
When I hear people talk about technical vs. non-technical people, I can't help but think of the Dr. Seuss story The Sneetches. Having a star (or not) was seen as something to aspire to. The Sneetches got into an infinite loop trying to achieve the right status.
Labels can serve a purpose, but when they force a hierarchy of one group being viewed as better than another, they can become dangerous. Think about your organization or your department: Which group—sales, support, marketing, QA, engineering, etc.—is above or below another in importance?
Even if it's not spoken directly or written somewhere, there is likely an understood hierarchy. These hierarchies often exist within disciplines, as well. Liz Harris, a technical content manager, says there are degrees of "technicalness" within the technical writing community. "Within technical writers, there's a hierarchy where the more technical you are, the more you get paid, and often the more you get listened to in the technical writing community."The term "technical" is often used to refer to the level of depth or expertise a person has on a subject. A salesperson may ask for a technical resource to help a customer. By working in tech, they are technical, but they need somebody with deeper expertise and knowledge about a subject than they have. So requesting a technical resource may be vague. Do you need a person with in-depth knowledge of the product? Do you need a person with knowledge of the infrastructure stack? Or somebody to write down steps on how to configure the API?
Instead of viewing people as either technical or not, we need to start viewing technical ability as a continuum. What does this mean? Mary Thengvall, a director of developer relations, describes how she categorizes the varying depths of technical knowledge needed for a particular role. For instance, projects can require a developer, someone with a developer background, or someone tech-savvy. It's the people who fall into the tech-savvy category who often get labeled as non-technical.
According to Mary, you're tech-savvy if "you can explain [a technical] topic, you know your way around the product, you know the basics of what to say and what not to say. You don't have to have a technical background, but you need to know the high-level technical information and then also who to point people to for more information."
The problem with labels
When we're using labels to get specific about what we need to get a job done, they can be helpful, like "developer," "developer background," and "tech-savvy." But when we use labels too broadly, putting people into one of two groups can lead to a sense of "less than" and "better than."
When a label becomes a reality, whether intended or not, we must look at ourselves and reassess our words, labels, and intentions.
Senior product manager Leon Stigter offers his perspective: "As a collective industry, we are building more technology to make it easier for everyone to participate. If we say to everyone, 'you're not technical, or 'you are technical' and divide them into groups, people that are labeled as non-technical may never think, 'I can do this myself.' We actually need all those people to really think about where we are going as an industry, as a community, and I would almost say as human beings."
If we attach our identities to a label, what happens when we think that label no longer applies? When Adam Gordon Bell moved from being a developer to a manager, he struggled because he always identified as technical, and as a manager, those technical skills weren't being used. He felt he was no longer contributing value. Writing code does not provide more value than helping team members grow their careers or making sure a project is delivered on time. There is value in all roles because they are all needed to ensure the creation, execution, and delivery of goods and services.
"I think that the reason I became a manager was that we had a very smart team and a lot of really skilled people on it, and we weren't always getting the most amazing work done. So the technical skills were not the limiting factor, right? And I think that often they're not," says Adam.
Leon Stigter says that the ability to get people to work together and get amazing work done is a highly valued skill and should not be less valued than a technical role.
Impostor syndrome is the inability to recognize your competence and knowledge, leading to reduced confidence and the ability to get your work done and done well. Impostor syndrome can kick in when you apply to speak at a conference, submit an article to a tech publication, or apply for a job. Impostor syndrome is the tiny voice that says:
- "I'm not technical enough for this role."
- "I know more technical people that would do a better job delivering this talk."
- "I can't write for a technical publication like Opensource.com. I work in marketing."
These voices can get louder the more often you label somebody or yourself as non-technical. This can easily result in not hearing new voices at conferences or losing talented people on your team.
What image do you see when you think of somebody as technical? What are they wearing? What other characteristics do they have? Are they outgoing and talkative, or are they shy and quiet?
Shailvi Wakhlu, a senior director of data, started her career as a software engineer and transitioned to data and analytics. "When I was working as a software engineer, a lot of people made assumptions about me not being very technical because I was very talkative, and apparently that automatically means you're not technical. They're like, 'Wait. You're not isolating in a corner. That means you're not technical,'" she reports.
Our stereotypes of who is technical vs. non-technical can influence hiring decisions or whether our community is inclusive. You may also offend somebody—even a person you need help from. Years ago, I was working at the booth at a conference and asked somebody if I could help them. "I'm looking for the most technical person here," he responded. He then went off in search of an answer to his question. A few minutes later, the sales rep in the booth walked over to me with the gentleman and said, "Dawn, you're the best person to answer this man's question."
Over time, we've inflated the importance of "technical" skills, which has led to the label "non-technical" being used in a derogatory way. As technology boomed, the value placed on people who code increased because that skill brought new products and ways of doing business to market and directly helped the bottom line. However, now we see people intentionally place technical roles above non-technical roles in ways that hinder their companies' growth and success.
Interpersonal skills are often referred to as non-technical skills. Yet, there are highly technical aspects to them, like providing step-by-step instructions on how to complete a task or determining the most appropriate words to convey a message or a point. These skills also are often more important in determining your ability to be successful at work.
Reading through articles and definitions on Urban Dictionary, it's no wonder people feel justified in their labeling and others develop impostor syndrome or feel like they've lost their identity. When performing a search online, Urban Dictionary definitions often appear in the top search results. The website started about 20 years ago as a crowdsourced dictionary defining slang, cultural expressions, and other terms, and it has turned into a site filled with hostile and negative definitions.
Here are a few examples: Urban Dictionary defines a non-technical manager as "a person that does not know what the people they manage are meant to do."
Articles that provide tips for how to talk to "non-technical" people include phrases like:
- "If I struggled, how on earth did the non-technical people cope?"
- "Among today's career professionals, developers and engineers have some of the most impressive skill sets around, honed by years of tech training and real-world experience."
These sentences imply that non-engineers are inferior, that their years of training and real-world experiences are somehow not as impressive. One person I spoke to for this project was Therese Eberhard. Her job is what many consider non-technical. She's a scenic painter. She paints props and scenery for film and theatre. Her job is to make sure props like Gandalf's cane appear lifelike rather than like a plastic toy. There's a lot of problem-solving and experimenting with chemical reactions required to be successful in this role. Therese honed these skills over years of real-world experience, and, to me, that's quite impressive.
Using labels erects barriers and can lead to gatekeeping to decide who can be let into our organization, our teams, our communities.
According to Eddie Jaoude, an open source developer, "The titles 'technical,' 'developer,' or 'tester' create barriers or authority where it shouldn't be. And I've really come to the point of view where it's about adding value to the team or for the project—the title is irrelevant."
If we view each person as a team member who should contribute value in one way or another, not on whether they write documentation or test cases or code, we will be placing importance based on what really matters and creating a team that gets amazing work done. If a test engineer wants to learn to write code or a coder wants to learn how to talk to people at events, why put up barriers to prevent that growth? Embrace team members' eagerness to learn and change and evolve in any direction that serves the team and the company's mission.
How to retire the labels
If you're ready to shift the way you think about the labels technical and non-technical, here are a few tips to get started.
Find alternative words
I asked everyone I interviewed what words we could use instead of technical and non-technical. No one had an answer! I think the challenge here is that we can't boil it down to a single word. To replace the terms, you need to use more words. As I wrote earlier, what we need to do is get more specific.
How many times have you said or heard a phrase like:
- "I'm looking for a technical resource for this project."
- "That candidate isn't technical enough."
- "Our software is designed for non-technical users."
These uses of the words technical and non-technical are vague and don't convey their full meaning. A truer and more detailed look at what you need may result in:
- "I'm looking for a person with in-depth knowledge of how to configure Kubernetes."
- "That candidate didn't have deep enough knowledge of Go."
- "Our software is designed for sales and marketing teams."
Embrace a growth mindset
Knowledge and skills are not innate. They are developed over hours or years of practice and experience. Thinking, "I'm just not technical enough" or "I can't learn how to do marketing" reflects a fixed mindset. You can learn technical abilities in any direction you want to grow. Make a list of your skills—ones you think of as technical and some as non-technical—but make them specific (like in the list above).
Recognize everyone's contributions
If you work in the tech industry, you're technical. Everyone has a part to play in a project's or company's success. Share the accolades with everyone who contributes, not only a select few. Recognize the product manager who suggested a new feature, not only the engineers who built it. Recognize the writer whose article went viral and generated new leads for your company. Recognize the data analyst who found new patterns in the data.
In the next article in this series, I'll explore non-engineering roles in tech that are often labeled "non-technical."