The False Binary: Silicon Valley's Obsession With Being Technical
Technical ability is a spectrum, but Silicon Valley turns it into a status marker—and mistakes the label for mastery.
Note from 2026: I wrote this before I’d ever set foot in San Francisco. Funnily enough, I picked SoMa for the opening after Googling a common San Francisco location (I needed somewhere for the fictional startup event to happen).
Re-reading this now, the technical/non-technical distinction lands a little differently in an AI-shaped world. Still, I think the piece’s main question holds: when we call someone “technical,” what are we actually trying to say?
Picture a crowded startup event in San Francisco’s SoMa district. MacBooks line the tables, their surfaces plastered with so many stickers they’re practically laminated. Ambitious twentysomethings in oversized hoodies and Patagonia vests weave through the crowd, engaged in an intricate social dance. Watch closely as conversations splinter into two camps, divided by Silicon Valley’s social sorting hat: “Are you technical?”
Some founders casually affirm “yeah, I’m technical” between sips of kombucha and name-drops of their Y Combinator batch (“Oh, you’re W23? I’m S24!” [awkward fistbump]). Others choke on their drinks and frantically tout their product management experience, desperately trying to position themselves as “somewhat-technical” (which really means non-technical). Finally, a few admit they can’t code, knowing their honesty will diminish their status in the room.
In Silicon Valley, we routinely collapse the spectrum of technical ability into a single bit: 0 or 1, “technical” or “non-technical.” Technical founders can code, engineer, and build products. Non-technical ones cannot. While convenient shorthand, this binary creates a hierarchy and misleads entrepreneurs to think coding is the primary, if not only, skill needed to build successful companies. While being technical is undeniably valuable and categories are useful, we need to remember that technical ability is a spectrum and only one of many skills necessary for achieving startup success.
Having spent most of my life not knowing how to code, I experienced the technical/non-technical divide firsthand. For eighteen years, I viewed code editors as magical tools reserved for math whizzes and logic puzzle enthusiasts. My eyes would glaze over whenever I heard someone talk about “composition over inheritance” or “client-side state management.” I came to Yale to study the humanities, but during the COVID-19 pandemic, I started coding for fun and couldn’t stop. Eventually, I mustered the courage to call myself “technical.”
After my transition, I was shocked by how non-technical founders viewed me differently. Dropping the T-word was like a cheat code. At mixers, founders would excitedly ask questions and make offers (most were terrible in hindsight, but appreciated regardless). They would say they’re hunting for a “technical co-founder,” whatever that means, and for most, even an inexperienced undergrad who barely knows how to center a div in CSS would do. They didn’t know how to assess technical talent, and they were so starved for it that they just didn’t care. It became clear they were chasing a label rather than pursuing someone with mastery: mention “I study computer science” or “Stanford” and they’d go feral.
I don’t blame them for following well-intentioned advice. Prestigious startup incubators like Y Combinator constantly preach that you need a technical co-founder. While I’m sure the advice is well-taken for Silicon Valley’s elite, I’m unsure if they know what reality is like on the ground for us mere mortals: Patagonia-vested MBAs prowl around campus, desperately hoping to catch a smelly CS major who can tell the difference between an API and an IPA.
Granted, most of what I said applies to naive first-time founders, not experienced ones. The veterans know better than to think someone is “technical” just because they made a shitty MERN todo app that crashes every time you add more than 3 items to it. Still, the patterns are concerning, especially because there are far more first-time founders than veterans. The question “Are you technical?” has devolved into a crude checkbox rather than a meaningful assessment of capabilities. It’s like asking writers “Can you write?” Of course they can, but that completely misses their command of language, their grasp of structure, and their ability to move readers. This superficial approach to evaluating talent undermines genuine technical excellence and leads to many suboptimal first hires.
After crossing the technical threshold, I decided to continue my coding journey and revealed more uncomfortable truths about technical mastery. I became intimately familiar with those technologies that had once made my eyes glaze over, and I felt powerful. I was no longer afraid of “event-driven architecture with asynchronous message queues” or “using dependency injection for better inversion of control.” I also noticed that I eliminated naive approaches, understood technical limitations, and had a more pragmatic and iterative approach to problem-solving. The shift wasn’t just in skills. It was in mindset.
While you might expect me to downplay the divide between technical and non-technical people, my experiences suggest the opposite. The startup world’s emphasis on technical expertise isn’t just hype. Learning to code revolutionized how I perceived and solved problems, and it continued to as I got better. My concern is not that we differentiate between technical and non-technical people, but that we get complacent and don’t differentiate enough past that arbitrary threshold. The gap between a junior developer building a basic CRUD app and a senior engineer architecting scalable systems is enormous. Even among seasoned engineers, there are huge discrepancies in code readability and maintainability. Yet in our current paradigm, all of them are simply labeled “technical.”
I remember confronting technical complacency after I met some extremely hyped-up technical founders. I was excited to bring up new frameworks I learned and ask them about their favorite technologies, but they’d always deflect and change the subject. Clearly, they were all one-tricks who only knew specific outdated tech stacks. One guy wasn’t even technical. I discovered all his websites were made with the same website builder. When I asked him about it, he said he was “more of a Steve Jobs kind of guy.” To be clear, there are still a lot of technical founders out there who enjoy talking about code. But there are also a lot of technical founders who don’t and coast on their antiquated 2013-era knowledge. We focus so much on crossing the chasm from non-technical to technical that we forget how wide the gulf can be between technical practitioners themselves.
Although I’ve seen some technical founders become complacent with their abilities, I’ve seen even more non-technical founders become obsessed with learning to code at all costs. While everyone has different motivations for learning to code, it’s clear that the term “non-technical” does not help the startup world’s unhealthy obsession with becoming technical.
I am personally sympathetic to the non-technicals. There is no way around it: “non-technical” carries a negative, if not shameful, connotation. The term is defined solely by what someone cannot do rather than what they can do. “Non-technical” does not mean “business-oriented” or “better at sales.” It means to have a subset of the capabilities of a technical person. It reflects a brutal reality of startups that I mostly agree with: technical people can learn business more easily than business people can become technical, so all else being equal, they will be prioritized.
But even if true, the branding of “non-technical” is unmistakably damaging. It gets under your skin. It makes you want to learn to code even when you’re 35 and married with children, in a way that “business-oriented” just doesn’t. While technical talent is undoubtedly game-changing, framing the technical question as “Can you code or not code?” creates a dangerous tunnel vision. Novice entrepreneurs often believe that coding is the only barrier to building a successful business. In reality, the most significant challenge isn’t technical development. It’s sales. Unfortunately, I’ve watched countless non-technical founders obsess over learning to code rather than finding customers for their business, leading their ventures to implode after building something that nobody wants.
Within startup circles, there’s a nifty strategy that avoids this headache: sell before you build, and secure your customers before investing in development. This minimizes the risk of expensive development that might build something nobody wants. Once you’ve validated your idea (and perhaps secured initial funding), acquiring or outsourcing technical talent becomes much easier.
Although I love being technical, the truth is that I’m inclined to agree with this strategy for most non-technical founders. If you’re not technical now, forcing yourself to become technical might not be the best use of your time. The path to technical proficiency is long, and your energy might be better spent developing your business in other ways. A founder who can consistently close sales and deeply understand customer needs will always be more successful than a mediocre programmer who builds products no one wants.
In this world of zeros and ones, the startup ecosystem’s obsession with technical ability has led us to oversimplify and overemphasize technical expertise. While being technical has advantages, the binary classification of technical ability hides the truth that early-stage startups live or die by building and selling. We should stop asking the equivalent of “Can you build or not build?” and start asking “Can you build or sell?” The real question isn’t whether someone can code, but whether they can create value through development, sales, or both. In today’s landscape, where technology is increasingly accessible, perhaps the most valuable technical skill of all is knowing when to code and when to connect with customers.