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.
3. The 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.
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).
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:
- 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.
- 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.
- 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.
