Enough with the technicalities

git reset

Related Posts

I use the word “technical” a lot. 

It’s an unthinking habit — a practical delineation of my minimum course requirements (two “technicals” a semester) as an undergrad in the College of Engineering, a convenient encapsulation of what I’ve devoted the last few years to studying and a serviceable descriptor for the future career I intend on pursuing. It’s also a parasitic term that disoriented me when I received a critique from a fellow EECS peer in the first month of my freshman year who commented, “Your resume isn’t technical enough.” 

I quickly discovered that this scale of “how technical are you” is, in other words, a measuring contest of how many programming languages, softwares and technologies you can work with. Though the exclusivity of the word wasn’t evident to me at the time, the stark division between “technical” and “nontechnical” has fabricated a hierarchy of skills to acquire.

As my friends and I began applying to internships, I became more and more appalled when hearing my peers introduce themselves as “nontechnical”, apparently resigning themselves to an identity lacking in value rather than promoting their unique knowledge areas. Many of them would downplay any difficulty they were experiencing in their classes when among their “technical” peers, fearful of tainting optics of their intelligence. On the other hand, my peers who were studying engineering generally lusted after the most “technical” fields like artificial intelligence and machine learning, which also happened to correlate with the highest paying opportunities in the area. The rigor of “technical” classes seemed like an adequate justification to discredit any hardship in “nontechnical” classes and create a “we vs. they” mentality on campus.

This dichotomy of “technical” vs “nontechnical” perpetuates a slew of mischaracterizations. First, not everyone dreams of being an engineer! The decision to pursue classes or careers in fields that aren’t hard sciences must not invalidate the work. Mastery is required in every craft, and to superimpose an ideal of intelligence as one solely available in a “technical” field is absolutely ridiculous. Second, why do these need to be mutually exclusive? Intellectual desires that coalesce knowledge over both technical and nontechnical fields are not inherently any more or less valuable than intellectual desires in a single field. 

In computer science there’s a concept called a “reduction”, which posits that if we are able to reduce (or simplify) problem A to a problem B, then solving problem B inductively proves that problem A is solvable too. While reductions are effective as the basis of computational theory, the far too common practice of reducing a multifaceted challenge to a tangible “technical” problem increasingly drives the dismissal of political, economic, and social realities that are paramount in framing the challenge. This misconception — that the hardest part of solving any problem is creating a technically-sound product — is undeservedly used to justify the consequent obfuscation of “nontechnical” complexities, like who the product is serving and not serving, and any societal implications.

And this is exactly what is happening at most Silicon Valley tech companies. In allowing the “technicality” of any problem to reign center stage instead of the hybridization of multiple types of knowledge, polarization and insularity in tech workplaces have only increased. The inequality in treatment of those who are “technical” vs “nontechnical” isn’t just culturally pervasive, but unfortunately also reinforced in amenities and pay structures. Despite programming applications of their own and working on data analytics in a number of different softwares and systems, the vast majority of business and marketing interns I interacted with at work were paid significantly less due to their “nontechnical” roles. 

This manufactured “technical vs. nontechnical” system of classification paints two disparate worlds: one with engineers working on hard product problems like developing software while nontechnical employees… exist? Take one look at the valuations of most technology startups in the Bay Area, whose inflated value (ascribed to the creation, not distribution, of technical products) exactly conveys the group that is perceived as most worthy of celebration despite absolutely no net company profitability. Sales, operations, marketing and distribution are trivialized as professions, while the conceit in creating “technical” products is normalized. 

Every day, I revel in scrolling through beautiful and brilliant pieces of engineering on ProductHunt, a platform with thousands of technology ideas and implementations. It’s clear that there are no shortage of ideas in this day and age — “technical” products are everywhere, but without the proper distribution channels, strategy, pricing models and operation details that “nontechnical” employees offer, a product remains yet another post and will fail to materialize into a business. Scaling technical infrastructure is futile without the work it takes to reach and maintain active customers. I mean, the very first version of Twitter was born out of a hackathon project and finished in a few months.

Somewhere on our path to assign binary labels to everything and everyone, we’ve lost specificity and nuance. It’s time to start promoting more inclusive language in companies, in classes, among peers. Let’s cut the crap, yeah?

Divya Nekkanti writes the Friday column on tech, design and entrepreneurship. Contact her at [email protected].