No one is “non-technical”
When we talk about the makeup of our teams, there’s often an impulse to break people down into “technical” and “non-technical” roles, as code for “engineers” and “everyone else.” The latter comes up often when discussing internal tools or systems, which by definition have to be accessible to those “non-technical” folks. Sometimes the language bleeds out to refer to users of a product, especially if the product has both a developer-facing experience and orientations for other kinds of users. I’ve even used the “non-technical” language myself, bemoaning the lack of a better alternative. But that right there should have been a tell: there’s no suitable synonym because the concept is a fiction. There’s no such thing as a “non-technical” role; there are only different techniques.
The root of the problem with this language is that the distinction attempts, at face value, to be neutral—but no one actually believes that, and there’s little evidence to sustain the facade. People in “non-technical” roles are typically paid less, afforded less flexibility, and granted less prestige. The categories of “technical” and “non-technical” serve wholly to privilege those in the former, at the expense of the latter. But literally no product organization would survive a week without the deep—and, I’d argue, technical—expertise of the people who are usually lumped into the “non” bucket: a bucket that includes knowledge of financial systems, laws, business models, operations, ethics, research tactics, user behavior, cultural patterns, learning development, communication practices, organizational psychology, and so much more than could ever be listed in a single paragraph. The “non-technical” nomenclature not only does a disservice to that work—and to those people—it also diminishes the ability of the organization to really get the most benefit from those skills. It’s difficult to earn value from the things you disparage, even if the disparagement is superficially polite.
But even setting aside the perceived hierarchy in the technical versus non-technical dichotomy, I think applying the “non” prefix to disciplines like design or research or recruiting is simply wrong. The OED has the first definition of technical as, “having knowledge of or expertise in a particular art, science, or other subject; skilled in the formal and practical techniques of a particular field.” Only in later usage does it morph into “expert in or concerned with applied and industrial sciences,” and even that definition doesn’t on its face exclude experts in, say, user experience or SAAS business models. And while it’s natural and good for words to evolve and change, it’s also worth interrogating why they’ve changed over time—and who benefits from those changes, and who might be harmed. The word “computer” once referred to a person who performed computation, and those people were nearly entirely women. The intentional masculinization of computer science as a field (a move I’d argue the technical/non-technical language emerges out of) only came later, and served to push women out of what was then becoming a lucrative sector of work. Likewise, constraining the word “technical” to refer only to “people who write code” serves to uphold a system in which benefits like compensation and prestige are distributed inequitably—regardless of the actual value of the various techniques being deployed.
In that way, the “technical/non-technical” breakdown fails along similar lines as the “hard/soft” skills terminology. The latter language more explicitly harks back to sexist notions of value, where hard/masculine things and behaviors are considered more valid than soft/feminine ones. Ironically, I mostly see the hard/soft language used by people trying to resurrect the value of the latter; but, again, simultaneously arguing for the importance of something while borrowing language that demeans it is like loading up on boulders before you hike up a steep hill. You might get to the top, but not without some bruises, and there are likely easier ways.
As with a lot of problematic language, one way to move forward is to simply choose to be more specific: instead of referring to “non-technical” people, talk about which people you mean. Instead of bucketing all skills that aren’t writing code into a big “non-technical” lump, list out those skills, or choose some representative examples. I think this is about more than being precise, though, and more than a courtesy to those folks unfairly maligned as “nons.” Code is great and important and obviously critical to bringing many a product to life. But too many of our digital products suffer from a lack of input from other fields and perspectives—especially when it comes to a nuanced understanding of how products interact with systems of oppression and power. Nearly everyone I talk to about their work—whether they are an engineer or a designer or a product manager or a CEO—says they want to do some good with their work. They want the things they build to lead to some improvement in people’s lives. Even the best code can’t do that alone; and a culture that values code above all else cannot be depended on to consider our lives in full.