I’m a Non-Technical PM. Should I Learn to Code?

7 min readOct 17, 2019

One question I hear a lot from junior product managers and folks looking to move into PM from another field is, “I’m not technical; should I learn to code?”.

Only you can answer that question for yourself, but my tl;dr is: if you’re asking, the answer is no.

Should I learn to code?

Sure, if you’re interested in learning to code. It’s a great skill to have. But if you’re asking “Should I learn to code for the sole purpose of getting a job as a PM?”, I’d say a flat no. Here’s why:

You don’t need to code. There may be some PM roles that require you to code yourself or to understand other people’s code, but they are in the minority (and they’re mostly TPM roles). If you’re not interested in learning to code, there’s a good chance you wouldn’t enjoy — or excel at — those roles.
It’s not gonna stick. If you’re only learning because you think you have to, it probably won’t stick. You don’t learn to code once and then call it done. You have to use it, and learn new languages and frameworks as they become popular. If you’re not into the idea of coding, ask yourself: is it really worth the time commitment to acquire a temporary skill?
You could do more harm than good. Let’s say you got hired, maybe at a startup, and they want to draw on those coding skills. Junior engineers put a lot of hours, pairing time, and practice into becoming productive at their roles. If your actual job is being the PM, you’re not putting in that time. Even if you’re just reviewing code and asking questions, there will be a lot that you don’t understand, and you might well waste the engineers’ time.
It will take time away from improving your core skills. This is a matter of prioritization, which as a PM is your bread and butter. If you’re really not sure if you should learn to code, put it through your prioritization process. What other skills could you improve? Plot them on an impact vs effort matrix. If you still think learning to code is the most important, do it. Otherwise, focus on your highest priorities for professional development.

What should I do instead?

Great question! One of the drivers for learning to code seems to be the idea that engineers will respect you more. I wonder if this is driven by hiring managers or recruiters. I frequently see in PM job recs some version of “technical chops; you need to command the respect of engineers”. I can’t say exactly what the “technical chops” are that those companies seek, but I find this a little baffling, and frankly a little insulting to engineers.

Engineers are completely capable of respecting other people’s skills. Just like everyone else, engineers can recognize and appreciate your skills, even though they are in a different field. In fact, in many cases you will work with engineers who appreciate your skills precisely because they don’t share them. You’re bringing something to the team that would be missing otherwise. That’s way more valuable than being able to parse an array like you learned in boot camp.

That said, you’re working in a technical industry and you will need some of those “technical chops”. It’s great to know the basics of computer science (and I really do mean the basics). You should know enough to be able to understand:

How a particular solution might serve your product, and why it’s preferable to other options;
How a bug might be affecting your users;
Potential unintended technical consequences of your decisions;
How to make prioritization decisions given the technical trade offs.

You don’t have to understand those things all on your own; you can always ask your engineering team to explain the details or the edge cases. In my experience, they’ll be happy to do so.

Here are a few ways you can build a trusting, effective relationship with engineers:

Be honest and humble. You don’t know how to code. Be up front about it. Ask for clarification if you don’t understand (and especially for simple things like acronyms — we all forget we’re using obscure terms from time to time). People won’t respect you for pretending to know stuff you don’t.
Get to know your team, and let them get to know you. This is so bleeding obvious, but somehow we are still in a place where many organizations treat engineers as some weird species of cave dwellers who can only speak in binary. You don’t have to become best friends with your coworkers, but hanging out over lunch and learning more about your team as people will go way farther in building trust and respect than trying to acquire a little of a skill that they’ve mastered.
Have a good grasp of logic. Computers are built on logic; you don’t have to understand coding syntax to be able to understand the logic of what’s happening under the hood. There are lots of ways to get better at logic, including reading philosophy, playing kids’ coding games, and doing puzzles. (Check out the resources at the end for specific suggestions.)
Understand the specific technologies you’re working with. If your team is building an API, understand that API and its endpoints. Look at the output of the API, and understand the flows of data. If your team is using machine learning or other AI technologies, dive into those technologies. You might not understand the details of the neural net, but you should understand at a high level how it works, what the technical challenges could be, and why it solves your problem. There are plenty of articles and resources that will help you to understand specific technologies in enough depth to do your job (check out the resources section at the end of the post for some examples).
Hold up your end. It’s more important to be stellar at your job than to be mediocre at someone else’s. Understand what your team needs and how you’re contributing, and then do that job as well as you possibly can. Take feedback (and give quality feedback, too). Strive to be better at what you do. This, more than any technical proficiency, will build trust with your team.

What if it goes wrong?

OK, that’s our happy path. But maybe you’re in a situation where you’ve had feedback that you’re not technical enough, or you’ve made a poor decision because you didn’t understand the technical implications. What can you do? Here are a few suggestions, in increasing order of severity.

Ask questions about the feedback. Understand as best you can exactly where you went wrong, or where you’re perceived as deficient. That will help you figure out whether and how you can address it.
Ask for guidance from your team. Your engineering team is your greatest resource when understanding the tech they’re building, so they should be your first port of call.
Study up. If you realize that there’s a particular area you just don’t understand, find resources that will help you learn about it. Let your team know what you’re doing; that way they’ll know you’re addressing the issue, and they might be able to offer support. Remember, you don’t need to do a coding boot camp or go back to school — there are lots of ways to address gaps in your knowledge.
Talk to your manager about professional development. Maybe the requirements of your role have changed, or your company has introduced new tech that you’re struggling with. Your manager should be able to help you identify more robust professional development opportunities.
Find a new role. It might be that this isn’t the team for you. If they are demanding a higher level of technical knowledge than you have, or are likely to acquire, maybe it’s just not a good fit. That doesn’t make you a bad PM, and it doesn’t make them a bad team. Maybe they should have hired a TPM. Maybe their culture is super technical and they’re not prepared to accommodate someone like you. If you’ve tried all your other strategies, it might be time to start looking for a job that will work out better for you. Remember: lots of us are non-technical PMs. There are roles out there for you!

Product Management is, at its core, a generalist discipline. We come from all kinds of backgrounds, some more technical than others, and that’s a good thing. Embrace your skillset, keep working to get better at it, and go where your skills fill a need.

Resources

Computer Science

Khan Academy has courses in the basics of computer science, including algorithms, cryptography, and internet protocols.
Online learning platforms like EdX and Coursera offer courses in computer science fundamentals, many of them free or accessible via a free trial.
If a book is more your thing, you might want to check out some basic networking books like Introduction to Networking: How the Internet Works or books from the For Dummies series. I can’t remember the name of the networking intro book I read way back in my career, but I’m so glad I bought it!

Specific Technologies

EdX and Coursera are good places to look for online courses introducing specific tech. It’s worth looking for courses that are designed for managers and executives, as these won’t assume you have a technical background.
StackOverflow is a great resource if you have specific questions about a technical detail.
Quora is helpful for less-technical or higher-level questions.
Business publications (Forbes, Harvard Business Review), tech sites (TechCrunch, Gizmodo, BoingBoing, Wired) and news organizations (newspapers, The Conversation) will often have articles that offer background on specific technologies. For example, check out this HBR article on the AI powered org, or The Conversation’s article on blockchain tokens.
Podcasts! There are so many. Like this episode of Zigzag that explains crypto. Here’s a list of tech podcasts from The Muse, or search wherever you get your podcasts!

Logic

One of my favorite books of all time is Daniel Dennett’s Intuition Pumps and Other Tools for Thinking. There’s a section on computers, if you want to skip the more philosophical stuff!
Check out Dennett’s RodRego register machine simulation.
There are lots of programming games designed for kids that are great for improving your logic. My son has Code Master and we love playing it together.
If you want to go further, Stanford’s Open Learning Initiative has a Logic & Proofs course.

Many thanks to Matt LeMay for giving feedback on this piece.