I’m “in Tech” too!
Expanding our understanding of who makes up the “tech sector” is a feminist issue.
The reported ratio of men to women “in tech” is drastically uneven. But perhaps a bit misunderstood and miscalculated as well.
To illustrate what I mean, here’s a typical scenario I face whenever I attend a tech meet-up:
Male developer: “What do you?”
Me: “I am in tech as well.”
Male developer: “Oh, so you code?”
Me: “Not exactly. I’m a product partner at a small firm. I help my clients figure out what they want to build, prototype it, find the right developers to build it, and I manage it.”
Male developer: “So you are a consultant and a designer?”
Me: “Yes, but in tech.”
Male developer: “Well, you need to code to really be in tech.”
Me: “Well, I know enough code to design, build, manage, and sell. Is that not essential to building the right thing?”
Simply put, I’m tired of not being considered part of my community simply because I don’t fit the image of the archetypal technologist: a dude who is an “expert coder.” It’s bad enough that there aren’t enough female developers to begin with, but to be excluded from the tech community due to a narrow and fetishized concept of a web developer is saddening and frustrating. It also reveals a certain ignorance of how technology is built.
We have to change the way we think about what a career “in tech” means, such that the concept is more inclusive of a whole professional spectrum that includes UX/UI experts, designers, experience crafters, product managers, sales (which is more like teaching “technical literacy” these days), and marketing. All of these roles prop up, translate, create, and envision what technology can do for other sectors.
If we don’t expand our understanding of how technology is built, we risk devaluing other essential roles with different skills sets — many of which are filled by more equal parts men and women.
I won’t lie. I do know some code. Am I an expert Rubyist? No. Do I code in Python like a boss? No. But I can build out a great backlog and communicate with developers about the technical feasibility of a product I just prototyped. And I’d be damned if anybody tells me I do that poorly. You see, it’s a craft of its own: working with a non-technical business team to translate vision into product via prototyping requires certain consulting, empathy, and communication skills — skills that a developer might rightfully overlook whilst trying to learn the intricacies of something as challenging as Scala.
With software permeating every industry out there, I often work with non-technical business, marketing, or area experts who don’t know how to explain their vision to “techies.” Similarly, I also work with “techies” who don’t really know how to break down technology into bite-sized pieces that’s digestible for the non-technical individual. In fact, it is exactly that person — the ones typically fitting the image of the man behind the computer screen — who derives (unintentionally) some kind of power from people not understanding what he does.
The dude in a hoodie who hacks together a website using this mysterious thing called “code” has been placed on a pedestal because of the way technology has “disrupted” our lives — especially on a consumer level. It’s a fact of the world that most people are not technically literate, which is to say they do not possess detailed knowledge of how the internet works, an understanding of how software is built, or the capacity to begin even asking for help when it comes to issues of computing. There is a wide chasm of knowledge and understanding between “the coder” and everybody else. Because coding is inherently difficult and poorly understood by most, we assume that the coder is a rare person who is entirely responsible for the wonderful consumer technologies that we work with on a daily basis.
This often results in the extremely limited view of “tech workers” that unintentionally excludes many people who are equally necessary to creating good products, such as user experience experts, designers, interface crafters, product managers, and area experts (such as psychologists or consumer behavior scholars). Because so many people don’t know how technology is built, they rest their laurels on the coder.
As a woman, consultant, designer, and product manager, I’m often the only chick in a room full of developers. But when I leave that room to convene with my team of designers, I’m suddenly just another chick in a room full of women and men, with quite a few more minorities. It is no secret that there are more women in roles that are perceived as “ancillary” to the work of the coder. In the end though, all of these professionals are essential to building tech, and all are often equally hard to find.
If we keep discounting the value of all these other people because of our own technical illiteracy, the public will erroneously continue to hold the “coder in a hoodie” as the monolith of technological prowess, leaving out other pictures of what achievement and contribution can look like.
Saying we all need to code in order to share a piece of the “tech” success pie is not just an erroneous statement of what it means to be “useful” in tech. It harmfully excludes and devalues individuals who currently are in tech but in non-coding roles — many of whom are women. This view creates the uneven and mono-cultural work environment that Silicon Valley is grappling with today.
I would love to see more female coders someday, but I would also love to see a little more respect for the women in other roles who are in the room right now. We need to stop thinking that technology lives and dies by code alone. It will be mutant without correct design. Or it will just be the wrong thing without proper management.
Technology is more than code, just as the tech community is more than coders.
