A lot of the common wisdom in the technology world differentiates between those who are technical and those who aren’t technical. I think that distinction ends up being pretty meaningless, for the following reasons:
Full Disclaimer: I’m a Data Scientist and have been writing Python code for 4 years. I’m no expert, but I’m squarely technical and I’m still writing this.
Silicon Valley and the broader technology world (until recently at least) have thrived on their uniqueness. The fact that Google is not Bank of America – immortalized with ridiculous artifacts like play slides and massage sessions – is a strong part of how the company defines its culture, and what draws top notch engineering talent to its ranks (2x market effective salaries help too). Technology is shaped as much by what it isn’t as by what it is.
Engineers do the exact same thing.The distinction between technical and non-technical is always made by those who are technical, seeking to separate themselves as an independent entity from those who aren’t like them. It’s basic human nature that’s very much in line with how we evolved as tribes. A designer who (inexplicably) doesn’t know how to use Sketch would never refer to themselves as non-technical without prompt.
What exactly does technical mean? In the way it’s currently used, it most often refers to either:
This distinction is silly. What about being able to write code makes you technical? Is dragging things around in Photoshop technical? If it’s not, why is it so valuable and scarce? If you think like a Computer Scientist but have no interest in using some other dude’s syntax, you’re not technical? What exactly is it about being able to type words in an artificial language that is so important?
(The answer is obviously that you can practically create things. But more on that later.)
Very few people write code for their entire careers, because:
The more senior in your career you get, the more general your responsibilities become.
Writing code or building bridges (literal ones, you crazy networkers) is not a career: it’s a job.
Starting salaries for technical people are usually much higher than, well, anything else. But at some point you hit a wall, because writing code is only so valuable. To hit that next meaningful salary increase, you need to diversify your skillset. That can end up meaning you become an Architect, but usually means becoming a manager. And a great manager is a great manager, not a great developer.
The trajectory for non-technical people is usually much more natural. The skills that you learn at each stage of your journey as a product manager are directly relevant to your next career steps. Moving up in product will always require learning new skills, but never totally ignoring the type of work that got you where you are.
Technical people can do many things that non-technical people can’t, and that’s often the source of some of the separation inherent in the term. The implication is that to “get stuff done” you’re eventually going to need to write and use software, and if you can’t do that you’re not on the same level as those who can.
There’s obviously merit to being able to do your own work (more on this later), but I think this is vastly overrated. The overwhelming majority of employees at any company with more than 100 of them will not be engineers. A mature company has a VP of Sales, Design, Product, Growth, Marketing, Legal, Social, and Branding; but only one VP of Engineering. There are technical people sprinkled throughout these departments (sometimes), but companies somehow manage to get by without having all their employees being engineers.
Finally, think of the iconic companies and CEOs that have defined the technology world over the past few decades. How many of those founders were technical? In your experience, are the most impressive and successful people you know the ones who can code?
Plenty of great CEOs can’t write good code or any code at all. They find a great CTO, because part of what makes them great CEOs in the first place is their ability to understand and recruit great people. Oh, and that’s part of what makes a great CTO too.
All of this being said, being technical is obviously crucial to a complete operation. You need engineers to build software products and maintain them. A company full of salespeople isn’t a company (it’s a bank). But I think where being technical really starts to give you an edge is specifically when you’re not technical. My view of technicality is that it’s augmentative – it can give you an edge and a boost at roles where it’s not typically appreciated.
Which of these people would you rather hire?
The second option (all other things equal) is always the better one, even if they don’t write code. That’s because being technical is just a means to an end, and that end is getting things done in a better way. That’s why I’d usefully define technical as such:
Being technical should mean that you have a set of skills that enable you to be really good at your job without constantly relying on others.
The difference between a product manager and a product manager who can write SQL is huge: it’s the difference between writing your own queries and having to rely on an analyst to write them (think of all the experimentation that would happen if you could explore data yourself!). But a social media manager who can use her own sentiment analysis tools has that same edge. Within the specific subdomain of your job, being technical is totally subjective. Being a product manager who can write SQL queries is infinitely more useful than being a product manager who can write low level C++ code.
Instead of asking if someone can write code, we should be asking whether they have the drive and personality to learn and understand the tools necessary to make them independently successful. Remember that Sketch to a designer is the same as SQL to a product manager: it’s just a tool. The fact that one of them is considered “coding” and one is irrelevant.
This new definition of technical is also meaningful because it’s accessible. Technicality as a mindset is accessible because you can learn it – if you’re a designer, spend your nights learning Sketch. If you’re a social media manager, spend your nights understanding what sentiment is. When your technicality is domain specific, you can realistically focus on acquiring it.
Personally, I find the most utility in my Data Science background as a guide for thought. Working on a Growth team, I’m able to think in a sophisticated way of how to use data to ask interesting questions, understand what not having a data warehouse means for our operational capabilities, and realistically assess how difficult certain queries might be. As I grow in my career, I think these bigger picture skills will end up mattering a lot more than my SQL writing (I prefer Pandas anyway).
Product manager job listings usually require some sort of programming experience: not because they’re expecting you to write code, but because to interact with and manage engineers requires an understanding of what they do and how they do it. But being an engineer for 2 years after college isn’t going to give you razor-sharp estimates on product build times. Engineering is a mindset, and you might just be able to build that mindset without editing someone else’s code at a bank for 2 years.
In the end, having experience writing code is most valuable as a conceptual undertaking – it gives you the knowledge of what code is, and what realistically can be done by whom. If we start defining technical by outcomes like these instead of your practical ability to scan Stack Overflow, we might just understand personal dynamics better.