The fetishization of “technical”

One of my more controversial opinions on product management is that most PMs do not need to touch code, and in fact, usually shouldn’t.

Obviously, this doesn’t mean that Product Managers can’t use code in common tools of the trade. Testing APIs, running SQL queries and simply understanding how common languages and frameworks work are all important. Rather, when I say “touch code,” what I mean is contributing to the product code base. That is often an antipattern that pulls the PM away from their core job responsibilities.

Yet not only is the product management literature rife with technical jargon, but many (if not most) Product Manager job listings cite technical backgrounds as a requirement. Many companies would prefer to recruit people with a chemical engineering BS than a psychology BA. Not only is this extremely dumb on face, but it stems from a deep vein of insecurity in the tech industry about needing to appear “technical.”

There is a widespread fetishization of all things “technical” in many industries. Of course, technical expertise is extremely important in many specific areas – the most obvious being engineering. And in fields like the tech industry (and increasingly in many others), some level of technical understanding is pretty important for whatever you’re doing. You can’t sell or market a product whose technical function or purpose you utterly don’t understand. Yet deeply understanding a product need not also encompass the engineering chops to build it from the ground up. This is true whether you’re selling cars, pharmaceuticals, paper – or software.

Product Management is still a developing business function, and as such, there are types of PM roles where commiting new code might be appropriate. In particular, at very small companies, a developer might take on the role as de facto Product Manager in addition to his/her core job. I’ve seen certain Platform Manager roles (or PMs for developer products) where this person codes actively, though usually in the course of using their own product, and not in committing new code to it. After all, Product Managers at AWS probably code a lot! But that’s still quite different than contributing new feature functionality to the product.

A nasty habit I’ve seen in many beginning Product Managers is wanting to prove their “technical” chops to the engineering team they work with. Some do this by over-prescribing technical approaches in written product requirements. Others are eager to take on bugs or defects in the product and fix it themselves (for everyone to see!). Again, there might be team situations where this is an effective pattern (you can never say never); but in most, it’s not.

New PMs likely do not have a deep familiarity with the existing product code base, nor even necessarily the framework or language it’s written in. That being the case, a newcomer is far more likely to break something than to fix it. If not, and fixing defects is easy for a newcomer to do, then the product in question must still be very immature and small (and maybe poorly done to begin with). Instead, the Product Manager’s job is to understand and prioritize those bugs/defects for resolution by the engineering team, rather than to barge in and start fixing them personally.

On any mature enterprise product, by the way, the idea of a brand new Product Manager diving into production code and fixing bugs is pretty much unheard-of.

Who gets to be “technical?”

As Justin Gage pointed out in his excellent blog post, “the distinction between technical and non-technical is always made by those who are technical.” The person with that chemical engineering degree who now works with AWS is called “technical” because their degree has the word “engineering” in it, but the data scientist coding in R is not, because their degree says “psychology.” Nor is the digital marketer neck-deep in their ecommerce platform “technical,” and much less the HR professional who knows just how to recruit high-quality candidates.

To make things even weirder, the “technical” label often confers its status for life. I can’t count how many Directors, VPs and other tech executives I’ve met who haven’t written code in a decade or more, but are still considered “engineering” talent. (Side note – I once watched one of these guys interact with Jeff Lawson during the latter’s famous Twilio live demo, and it was hilarious.) Very few people who write code actually do so for most of their careers, since “non-technical” career paths are often more lucrative over time. Some developers simply burn out on it and want to do something different. Yet having a degree or old job title with the word “engineering” somewhere in it confers a tribal status for the rest of that person’s days.

Most jobs in the tech industry are not “technical” in the sense that they require formal engineering training. Product Management almost never is, and even many outstanding developers are self-taught. By screening out candidates without “technical-sounding” degrees, software companies rule out tons of people who would be very good at these jobs. Rather, screening for specific skills or experience – working with Javascript, understanding how cloud computing works, being able to explain modern software development processes, knowing how to work with software customers, and so on – would be more effective at determining who can do those jobs and who can’t.

In fact, I would go so far as to say that most companies would be better-off hiring new Product Managers with educational backgrounds in psychology, economics, philosophy, political science and even literature (just imagine the user stories!). The trick – for both employers and candidates with these backgrounds – is to pair them with the sufficiently “technical” baseline understanding of how software works. Fortunately, that is not terribly hard to obtain, but requires some savoir-faire.

A very, very large part of how the software industry works is through pattern-matching and mimicry. You’d be surprised how many companies model their job requirements from Google’s (right down to cut-and-paste jobs). This is how we’ve gotten to a place where “technical” gatekeeping intimidates and prevents many capable people from accessing the tech industry. The product management function is a perfect example.

Related posts:

[mc4wp_form id=”185″]

Standard