The top 5 things PMs should know about engineering
Guest post by Justin Gage, writer of Technically and growth at Retool
👋 Hey, Lenny here! Welcome to the ✨ bonus free edition ✨ of my weekly newsletter. Each week I tackle reader questions about building product, driving growth, working with humans, and anything else that’s stressing you out about work. If you’re not a subscriber, here’s what you missed this month:
Q: How do I become a more technical PM?
As you may know, I took a crack at this question a few months ago, and that post that turned out to be one of my all-time most popular posts. But considering how often I still get this question—clearly, questions remain. Also, with the rise of Web3, fintech, data infrastructure companies, and other deeply technical products, it’s only becoming more important for PMs to build their technical chops.
To help you develop those chops, I’ve pulled in Justin Gage, author of the fantastic Technically newsletter (fittingly described as “a place for not software engineers to learn about software engineering”), to share his highly actionable tips on becoming a more technical PM. In my previous post on the subject, I linked to Justin’s newsletter numerous times, and that’s because he’s especially talented at explaining deeply technical subjects clearly and directly. We’re super-lucky to have Justin share his wisdom with us. And if you want to go deeper, definitely subscribe to Technically.
The top 5 things PMs should know about engineering
by Justin Gage
There’s an old debate about how technically minded product managers should be. On the one hand, understanding your developers, their process, and their work is part and parcel of shipping products effectively. On the other hand, you don’t want to step on your engineers’ toes, and getting too deep into the codebase isn’t a great use of your time. One point we can all agree on, though: a strong technical knowledge foundation means a more effective PM. So in that spirit, this post will cover the top five technical things PMs should know.
If you don’t understand some of the ideas here, that’s fine! The more you work with engineers, the more comfortable you’ll get. And of course, every company is different; some companies hire only super-technical PMs, while others prefer generalists, or even design-focused ones. But no matter what, the more you understand, the better you’ll do.
Learn #1: Your company’s tech stack
What to know: What technologies your company’s app, site, and infrastructure use. For example, Technically.dev is built with React and Next.js, deployed on Vercel, and written in HTML, CSS, and JavaScript.
Why it matters: Choices of programming languages, frameworks, and infrastructure all come with important trade-offs that impact what might make a project something that could take a few hours, or a few weeks. If you’re using a NoSQL database, you can skip migrations when adding new features, but you might run into data quality issues. If parts of the stack are legacy, you may want to avoid projects that touch them. But perhaps more qualitatively, speaking the language of your engineers helps build trust and improves communication.
How to learn about it: Do as much snooping as you can, and then just ask your team.
First, look at your company’s GitHub repositories. You should be able to see what kinds of programming languages are in there, as well as any files or notes specific to what frameworks the app relies on. Here’s a screenshot of Supabase’s main repo, an open source Firebase competitor. Note how GitHub tells you what languages the code is in (on the bottom right):
Beyond languages, the structure of your team’s project might indicate what frameworks they’re using. If you see some files prepended with .next, your team is probably using NextJS. If you see “import { useState } from ‘React’ ” in any files, your team is probably using React. Reading through code files isn’t too fun and is not the best use of your time, but peeping at a few can at least give you some grounding.
After you’ve done your snooping work to impress them, just ask one of your developers.
Learn #2: Sensitive points in the codebase
What to know: Which pieces of the codebase—logical or procedural—are tangled, sensitive, or otherwise intransigent.
Why it matters: Knowing the hardest parts of the app to work on can help you plan more effectively and avoid project delays. If updating the marketing site copy takes a few days because Gatsby (a popular JS framework) requires a re-deploy to change content, you might de-prioritize that work in favor of something that you can move on quicker. There might not be much you can do about this as a PM, but it’s useful knowledge to have and can help you allocate resources more effectively.
How to learn about it: Talk to fellow PMs about projects that went surprisingly quickly or surprisingly slowly. A personal example: after doing some work on improving the onboarding experience, I was frustrated with how long things were taking. I eventually learned that the section of our codebase that dealt with onboarding was poorly organized and very difficult to test locally. That explained it! And of course, ask your engineers; they’ll know better than anyone.
Learn #3: Your build and deploy process
What to know: How your app gets built and deployed to your users, what’s manual and what’s automated, and how long it usually takes.
Why it matters: Writing code is only half the battle—you need to get it to your users by deploying the changes to production. Larger teams and more complex apps can have multi-day deployment processes that may delay projects and add to lead time. Knowing these pressure points can also help you more effectively batch features and understand what’s worth doing when.
A good example is how your company distributes cloud builds vs. on-premise builds. If it takes a while to get newer versions of your software to your on-premise customers, as a PM, you might try to batch a few features on a tighter timeline so that your team can bundle them together for a single release. For small updates like copy changes, you might feel comfortable doing them yourself if the release process is easy, but may time them along with another PM’s release if deploys take longer.
How to learn about it: Ask your developers, but you can also do some legwork before then by looking at pull requests (PRs) that have been merged and what the GitHub checks (or whatever else your version control system is) run for builds. Here’s an example from Supabase; it looks like the team is using Vercel to deploy the app, since the Vercel bot commented on the PR with links to deploy previews.
This is good to know—after doing some digging on Vercel, you might navigate to its site and learn that its product makes deploys quick and easy, usually sub-5 minutes. That information may come in handy later on when you’re wondering if you can get that copy change in before the deadline, or if asking your engineer for a quick change is going to be too bothersome. To find open PRs on your team’s repositories in GitHub, just navigate to the repository, click on the “Pull Requests” tab, and click on any one.
If your app also has customers that deploy it on-premise, you’ll want to get information on how upgrades work (do customers get them automatically? how often does the team recommend updating?), how far behind cloud they are, and how difficult one-off builds are.
Learn #4: How to contribute code
What to know: How to make code changes and open a PR, specifically for small, self-contained changes like updating copy or changing colors.
Why it matters: Great products have great copy, and you shouldn’t have to rely on your engineers to fix typos. Being able to make small changes yourself, be it copy or fixing an errant border radius (generally frontend stuff), will result in more polished products shipped faster. Don’t bite off more than you can chew, though; keeping the code you contribute to smaller copy- or design-related tweaks will win you points.
How to learn about it: As you get started, sit down with your favorite engineer on your team and ask them to walk you through how to contribute code. It’s going to look something like cloning your app’s repository locally, running it locally, making a fix and committing your changes, and then opening a PR in GitHub. You can even cheat and edit some code directly in GitHub, as long as it’s low-risk (like this markdown file):
Learning how to code is obviously beyond the scope of this post. Personally, I got my start by studying some slides from a Python class in college (that I wasn’t taking), brushed up with Codecademy, and then ended up building full-stack apps in my free time over the course of my career. If your goal is to be dangerous, focus on your team’s primary programming language and set a reasonable goal with a developer. Maybe it’s updating the copy on the website or something simple. The hardest part tends to not be the code itself but rather the process around the code, like handling version control and CI (continuous integration).
Learn #5: Technical basics 101
What to know: Outside of your company’s codebase, you need a basic understanding of how apps, data, and infrastructure work. Beyond being able to code, a conceptual understanding of what pieces come together to build applications is table stakes.
Why it matters: A lot of what your developers tell you will sound like complete nonsense without the right technical foundation. And whether you know how to code or not, you’ll want to know what your developer means when they say they can keep this feature to a “frontend change only.”
How to learn about it: There’s no teacher as valuable as experience. The reality is that knowing how to code—specifically, how to build apps that relate to your company’s stack—is the best way to be more technically literate. But that takes a long time, and simply isn’t for everyone! Thankfully, there are some shortcuts you can take in the meantime. A few that have worked for me:
1. Read engineering blogs
They’re sometimes surprisingly easy to understand, and can get you used to the terms engineers use daily. I like reading Segment’s, Slack’s, Netflix’s, and Stitch Fix’s. Teams usually write these for recruiting purposes—look at all the cool stuff we’ve built!—but they can still contain useful base knowledge. Much of being technically literate is understanding how software is used in practice, and these blogs are great for that.
2. Look up everything you don’t know
Technical writing and speak is built on layers and layers of concepts; you need to start from the bottom to understand the top. Search for terms you don’t understand rather than just glossing over them. There aren’t very many good central resources online for going from 0 to 1 in being technically literate, but many individual concepts have useful explainers. A nice example is Duo Security’s guide to SAML. Search enough and, with a discerning eye, you’ll find writing styles you like.
3. Find a developer friend on the outside
Chances are you’re friends with a developer outside your company; buy them a coffee! Come with some questions prepared. It’s usually unproductive to have them dump their knowledge on you, but a series of pointed questions around a particular topic can lead to a fruitful conversation. For example, when I’m writing newsletter issues, sometimes I’ll grab 30 minutes with an engineer friend to make sure I fully understand a topic I’m writing about. Doing your research beforehand to make sure you have good questions is the key.
Aside from these, though, subscribe to Technically—it’s made for exactly you :)
Thanks, Justin!
🔥 Featured job openings
Mynd: Product Manager, Buying Services (Remote-US)
OpenPhone: Senior Product Manager (Remote-US)
TaxBit: Product Lead (Seattle)
Orbiit: Director of Product Management (NYC)
Relish Works: Associate Product Manager (Remote-US)
OnFrontiers: UI/UX Designer (Remote-US)
OnFrontiers: Product Manager (Remote-US)
Panther: Product Manager (Core) (Remote-Global)
The.com: Software Engineer (SF)
Relive: Product Manager (Remote-EU)
GetSetUp: Product Lead, Discovery (Remote-Global)
Browse more open roles, or add your own, at Lenny’s Job Board.
How would you rate this week's newsletter? 🤔
Legend • Great • Good • OK • Meh
If you’re finding this newsletter valuable, consider sharing it with friends, or subscribing if you haven’t already.
Sincerely,
Lenny 👋
 | A guest post by
|
As a recovering IT engineer, technical project manager, director of corporate project management and no CEO, I can tell you that this question is THE ubiquitous leadership challenge.
There is the subject matter domain, and then there is the leadership domain. Knowing a lot of details in the subject matter domain risks the malady of micromanaging the details and thus failing in the leadership role to get project participants to take initiative and responsibility for their piece. Knowing too little of the subject matter domain risks being able to detect project problems early on, and to effectively lead and facilitate the solving of technically-complex issues and problems.
The idea situation is to focus on the leadership (the PM discipline skills and execution) while also owning subject matter mastery, but with the self-awareness of the risks for this... and apply the self-discipline to give the reins of decision-making control to the appropriate project resources... and only be there to coach and guide as needed.
There is a line where too little or too much subject matter expertise is a risk to the PM's capability to succeed. However, it is more important to be an excellent PM.