← Back
Aug 16, 2021
Why we don't use "technical" and "non-technical" at Mem
By Priscilla Mok - Lead Designer
A few little words. "Technical" and "non-technical". They seem innocent enough, and pretty much standard parlance in Silicon Valley—such as "a startup looking for its first non-technical hire". Yet as I've realized, these little words can have a big impact on an early-stage company looking to build an inclusive and high-performing culture.
During my seven years as a designer at Google, I was part of the Engineering organization which included engineers, designers, and product managers. (The other big part of Google was Sales/Global Business Operations.) Being in the engineering org felt normal to me. After all, I'd always considered myself "technical": I'd taught myself to code in middle school (learning via Neopets), troubleshooted my parents' computers, worked in specialized software like Figma, and collaborated with engineers every day. Belonging to the engineering org of a big tech company helped reinforce that self-identity.
So I would've thought nothing of those labels when I joined Mem, where the terms "technical" and "non-technical" were also used casually, in everyday chats and light jokes about how to split up into teams for a board game... except for the times when I was put in the "non-technical" bucket.
I'd feel a small jolt whenever that happened. Not necessarily because being labeled "non-technical" was bad or there was any malice behind it (although because of Google's engineering-centric culture, I'd enjoyed some perks that made one bucket seem better than the other). I started paying attention because for the first time, the label was different from my own self-identity. My first thoughts were to prove to people that I was just in the "wrong" bucket. But then that got me thinking—what did these labels even mean? What was the point of using them? And more importantly, how might thinking about our teammates in this way affect Mem's culture?
I talked through these thoughts with our founders, Kevin and Dennis, as well as others on the team, who were supportive and receptive. I did some more reading on the topic from others in tech who felt similar reservations about these labels. And as it turns out, little words can mean a lot. Little words can affect the way people view and treat each other, and themselves— everything from creating an unspoken social caste system where "technical" people's time is prized over all others', to preventing "non-technical" people from wanting to write and deploy code to production (e.g. making changes to the marketing site).
And so, drawing from our past experiences at other companies, and discussing more intentionally the type of culture we do want to foster at Mem, I worked with the team to draft up an internal memo for how we'd like every Memer to see themselves, and each other. We're sharing this memo below, and hope it inspires you to reflect on the kind of default labels and categories that might exist in your own organization.
Everyone is a builder
At Mem, we value all the skills that a Memmer brings to the table. As such, we don't use the terms "non-technical" and "technical" to label people and functions.
At its core, "technical" oftentimes refers to a "technical skill that is an ability to perform certain specialized tasks within some domain". Which means coding is definitely a technical skill, but so is running analyses using Mixpanel, interviewing customers, writing/producing content to explain how to use Mem, or creating designs in Figma.
"Non-technical" skills often refer to "soft" skills such as communication, mentoring, conflict resolution and negotiation, diplomacy, and the like.
Over time, these terms have been co-opted by the tech industry to describe some roles (either strictly engineering roles, or ones that involve building the product like product management and design) as "technical", whereas roles that did not contribute to building the actual product were "non-technical". This has led to the terms also being used to commonly describe people and functions, such as a "startup looking for its first non-technical hire".
However, there are subtle problems with using "technical" and "non-technical" to refer to people and functions that can cause unintended consequences for a company's culture. Here are some examples:
It can lead to misguided engineering elitism of companies over-valuing engineering and product, and people in "non-technical" roles feeling like second-class citizens (e.g. outsized recognition for the engineer(s) who build and ship a feature, free lunches for engineers but not sales in some companies)
Labeling someone as non-technical can discourage them from learning technical skills and contributing in new and creative ways to the company. At worst, it can create a self-limiting identity that creates a fixed mindset over a growth mindset.
In 2021, anyone performing almost any role inside of a technology company can benefit from an understanding of code, and at Mem, we encourage anyone who wants to learn, to learn!
The converse is true: an engineer who's always been given feedback that they are "technical" (even in a positive way) may feel like they would never be a good people manager or a captivating presenter.
It can perpetuate a misunderstanding of other functions (e.g. marketing, data analysis, design) entail that just happen to not involve writing production code
It can create bias in the hiring process—describing someone as "not technical enough" is an easy and vague way out versus saying "the candidate had great communication skills but we would've liked to see more proficiency in TypeScript"
Instead of saying that a candidate was "not technical", we just describe what skill it was that they were lacking in
In other words, we believe that while skills can be described as technical or non-technical, people shouldn't be.
At Mem, we set a high hiring bar in both technical and non-technical skills and believe both are important to build a healthy, diverse company. We value people who are always looking to grow and improve, in both of those skill sets. We believe that everyone who joins should be proud of their role and that everyone has important contributions to make to Mem—whether that's coming up with creative ways to engage our community, shipping features, or cooking up the next great Tweet storm. For many of us, we do all of the above.
So instead of thinking of people in terms of "technical" or "non-technical", at Mem we'd like to think that everyone is a builder. It doesn't matter whether you're building up the codebase, the design system, relationships with our customers, or more efficient processes. While we may still use "technical" and "non-technical" to describe skill sets out of convenience, when it comes to your role and contributions, the sky's the limit.
Further reading
And many thanks to Jennifer Kim, April Wensel, and Dawn Parzych for their writing that helped inform this memo.
By Priscilla Mok - Lead Designer
A few little words. "Technical" and "non-technical". They seem innocent enough, and pretty much standard parlance in Silicon Valley—such as "a startup looking for its first non-technical hire". Yet as I've realized, these little words can have a big impact on an early-stage company looking to build an inclusive and high-performing culture.
During my seven years as a designer at Google, I was part of the Engineering organization which included engineers, designers, and product managers. (The other big part of Google was Sales/Global Business Operations.) Being in the engineering org felt normal to me. After all, I'd always considered myself "technical": I'd taught myself to code in middle school (learning via Neopets), troubleshooted my parents' computers, worked in specialized software like Figma, and collaborated with engineers every day. Belonging to the engineering org of a big tech company helped reinforce that self-identity.
So I would've thought nothing of those labels when I joined Mem, where the terms "technical" and "non-technical" were also used casually, in everyday chats and light jokes about how to split up into teams for a board game... except for the times when I was put in the "non-technical" bucket.
I'd feel a small jolt whenever that happened. Not necessarily because being labeled "non-technical" was bad or there was any malice behind it (although because of Google's engineering-centric culture, I'd enjoyed some perks that made one bucket seem better than the other). I started paying attention because for the first time, the label was different from my own self-identity. My first thoughts were to prove to people that I was just in the "wrong" bucket. But then that got me thinking—what did these labels even mean? What was the point of using them? And more importantly, how might thinking about our teammates in this way affect Mem's culture?
I talked through these thoughts with our founders, Kevin and Dennis, as well as others on the team, who were supportive and receptive. I did some more reading on the topic from others in tech who felt similar reservations about these labels. And as it turns out, little words can mean a lot. Little words can affect the way people view and treat each other, and themselves— everything from creating an unspoken social caste system where "technical" people's time is prized over all others', to preventing "non-technical" people from wanting to write and deploy code to production (e.g. making changes to the marketing site).
And so, drawing from our past experiences at other companies, and discussing more intentionally the type of culture we do want to foster at Mem, I worked with the team to draft up an internal memo for how we'd like every Memer to see themselves, and each other. We're sharing this memo below, and hope it inspires you to reflect on the kind of default labels and categories that might exist in your own organization.
Everyone is a builder
At Mem, we value all the skills that a Memmer brings to the table. As such, we don't use the terms "non-technical" and "technical" to label people and functions.
At its core, "technical" oftentimes refers to a "technical skill that is an ability to perform certain specialized tasks within some domain". Which means coding is definitely a technical skill, but so is running analyses using Mixpanel, interviewing customers, writing/producing content to explain how to use Mem, or creating designs in Figma.
"Non-technical" skills often refer to "soft" skills such as communication, mentoring, conflict resolution and negotiation, diplomacy, and the like.
Over time, these terms have been co-opted by the tech industry to describe some roles (either strictly engineering roles, or ones that involve building the product like product management and design) as "technical", whereas roles that did not contribute to building the actual product were "non-technical". This has led to the terms also being used to commonly describe people and functions, such as a "startup looking for its first non-technical hire".
However, there are subtle problems with using "technical" and "non-technical" to refer to people and functions that can cause unintended consequences for a company's culture. Here are some examples:
It can lead to misguided engineering elitism of companies over-valuing engineering and product, and people in "non-technical" roles feeling like second-class citizens (e.g. outsized recognition for the engineer(s) who build and ship a feature, free lunches for engineers but not sales in some companies)
Labeling someone as non-technical can discourage them from learning technical skills and contributing in new and creative ways to the company. At worst, it can create a self-limiting identity that creates a fixed mindset over a growth mindset.
In 2021, anyone performing almost any role inside of a technology company can benefit from an understanding of code, and at Mem, we encourage anyone who wants to learn, to learn!
The converse is true: an engineer who's always been given feedback that they are "technical" (even in a positive way) may feel like they would never be a good people manager or a captivating presenter.
It can perpetuate a misunderstanding of other functions (e.g. marketing, data analysis, design) entail that just happen to not involve writing production code
It can create bias in the hiring process—describing someone as "not technical enough" is an easy and vague way out versus saying "the candidate had great communication skills but we would've liked to see more proficiency in TypeScript"
Instead of saying that a candidate was "not technical", we just describe what skill it was that they were lacking in
In other words, we believe that while skills can be described as technical or non-technical, people shouldn't be.
At Mem, we set a high hiring bar in both technical and non-technical skills and believe both are important to build a healthy, diverse company. We value people who are always looking to grow and improve, in both of those skill sets. We believe that everyone who joins should be proud of their role and that everyone has important contributions to make to Mem—whether that's coming up with creative ways to engage our community, shipping features, or cooking up the next great Tweet storm. For many of us, we do all of the above.
So instead of thinking of people in terms of "technical" or "non-technical", at Mem we'd like to think that everyone is a builder. It doesn't matter whether you're building up the codebase, the design system, relationships with our customers, or more efficient processes. While we may still use "technical" and "non-technical" to describe skill sets out of convenience, when it comes to your role and contributions, the sky's the limit.
Further reading
And many thanks to Jennifer Kim, April Wensel, and Dawn Parzych for their writing that helped inform this memo.
By Priscilla Mok - Lead Designer
A few little words. "Technical" and "non-technical". They seem innocent enough, and pretty much standard parlance in Silicon Valley—such as "a startup looking for its first non-technical hire". Yet as I've realized, these little words can have a big impact on an early-stage company looking to build an inclusive and high-performing culture.
During my seven years as a designer at Google, I was part of the Engineering organization which included engineers, designers, and product managers. (The other big part of Google was Sales/Global Business Operations.) Being in the engineering org felt normal to me. After all, I'd always considered myself "technical": I'd taught myself to code in middle school (learning via Neopets), troubleshooted my parents' computers, worked in specialized software like Figma, and collaborated with engineers every day. Belonging to the engineering org of a big tech company helped reinforce that self-identity.
So I would've thought nothing of those labels when I joined Mem, where the terms "technical" and "non-technical" were also used casually, in everyday chats and light jokes about how to split up into teams for a board game... except for the times when I was put in the "non-technical" bucket.
I'd feel a small jolt whenever that happened. Not necessarily because being labeled "non-technical" was bad or there was any malice behind it (although because of Google's engineering-centric culture, I'd enjoyed some perks that made one bucket seem better than the other). I started paying attention because for the first time, the label was different from my own self-identity. My first thoughts were to prove to people that I was just in the "wrong" bucket. But then that got me thinking—what did these labels even mean? What was the point of using them? And more importantly, how might thinking about our teammates in this way affect Mem's culture?
I talked through these thoughts with our founders, Kevin and Dennis, as well as others on the team, who were supportive and receptive. I did some more reading on the topic from others in tech who felt similar reservations about these labels. And as it turns out, little words can mean a lot. Little words can affect the way people view and treat each other, and themselves— everything from creating an unspoken social caste system where "technical" people's time is prized over all others', to preventing "non-technical" people from wanting to write and deploy code to production (e.g. making changes to the marketing site).
And so, drawing from our past experiences at other companies, and discussing more intentionally the type of culture we do want to foster at Mem, I worked with the team to draft up an internal memo for how we'd like every Memer to see themselves, and each other. We're sharing this memo below, and hope it inspires you to reflect on the kind of default labels and categories that might exist in your own organization.
Everyone is a builder
At Mem, we value all the skills that a Memmer brings to the table. As such, we don't use the terms "non-technical" and "technical" to label people and functions.
At its core, "technical" oftentimes refers to a "technical skill that is an ability to perform certain specialized tasks within some domain". Which means coding is definitely a technical skill, but so is running analyses using Mixpanel, interviewing customers, writing/producing content to explain how to use Mem, or creating designs in Figma.
"Non-technical" skills often refer to "soft" skills such as communication, mentoring, conflict resolution and negotiation, diplomacy, and the like.
Over time, these terms have been co-opted by the tech industry to describe some roles (either strictly engineering roles, or ones that involve building the product like product management and design) as "technical", whereas roles that did not contribute to building the actual product were "non-technical". This has led to the terms also being used to commonly describe people and functions, such as a "startup looking for its first non-technical hire".
However, there are subtle problems with using "technical" and "non-technical" to refer to people and functions that can cause unintended consequences for a company's culture. Here are some examples:
It can lead to misguided engineering elitism of companies over-valuing engineering and product, and people in "non-technical" roles feeling like second-class citizens (e.g. outsized recognition for the engineer(s) who build and ship a feature, free lunches for engineers but not sales in some companies)
Labeling someone as non-technical can discourage them from learning technical skills and contributing in new and creative ways to the company. At worst, it can create a self-limiting identity that creates a fixed mindset over a growth mindset.
In 2021, anyone performing almost any role inside of a technology company can benefit from an understanding of code, and at Mem, we encourage anyone who wants to learn, to learn!
The converse is true: an engineer who's always been given feedback that they are "technical" (even in a positive way) may feel like they would never be a good people manager or a captivating presenter.
It can perpetuate a misunderstanding of other functions (e.g. marketing, data analysis, design) entail that just happen to not involve writing production code
It can create bias in the hiring process—describing someone as "not technical enough" is an easy and vague way out versus saying "the candidate had great communication skills but we would've liked to see more proficiency in TypeScript"
Instead of saying that a candidate was "not technical", we just describe what skill it was that they were lacking in
In other words, we believe that while skills can be described as technical or non-technical, people shouldn't be.
At Mem, we set a high hiring bar in both technical and non-technical skills and believe both are important to build a healthy, diverse company. We value people who are always looking to grow and improve, in both of those skill sets. We believe that everyone who joins should be proud of their role and that everyone has important contributions to make to Mem—whether that's coming up with creative ways to engage our community, shipping features, or cooking up the next great Tweet storm. For many of us, we do all of the above.
So instead of thinking of people in terms of "technical" or "non-technical", at Mem we'd like to think that everyone is a builder. It doesn't matter whether you're building up the codebase, the design system, relationships with our customers, or more efficient processes. While we may still use "technical" and "non-technical" to describe skill sets out of convenience, when it comes to your role and contributions, the sky's the limit.
Further reading
And many thanks to Jennifer Kim, April Wensel, and Dawn Parzych for their writing that helped inform this memo.
