How to Amass Engineering Knowledge as a Product Manager

For about the past two years, I’ve been a product manager at Kaggle where I work on our public data platform as well as (more recently) our Google Cloud Platform integrations team. Lately I’ve had the opportunity to do quite a bit of reflection on my career thanks in part to having a mentee (being a mentor is awesome!). The other day she asked me how I “amassed as much engineering knowledge as I have”. (She asks great questions!) I shared my answer on Twitter and, you know what, I want to blog more so I’m sharing it here, too.

Anyway, I had to spend a few days thinking about how to respond in a sage, mentor-ly way because it hasn’t been something I was necessarily intentional about (my interest in software development is more of a curiosity, probably). At the same time, I definitely had a couple of motivators for accumulating engineering knowledge.

Product managers spend their days influencing without authority. Understanding and sympathizing with your engineering coworkers can help with this.
Apart from the website about goldfish I made when I was 12, I don’t already have a background in computer science or software development. I could elaborate on why exactly I include this, but I’ll save that for another time.

After thinking about her question for a bit and jotting down my thoughts in my favorite note-taking app, Sublime Text, here’s what I came up with:

1. Invest time to learn what it takes to describe architecture and key services at a high level

This is a good idea for two reasons. First, this information should be readily accessible in some form–take advantage of it! Just ask for the documentation for it or, if necessary, schedule a chat with the owner engineer. Second, this will be one of the highest leverage ways to successfully gauge feasibility of new features. This has saved me a number of times from needing to bother our tech leads.

To give an example, when our tech lead was on paternity leave last Northern hemisphere fall, I took over managing our engineering team. Early on, we began experiencing a lot of instability with one of our services. I took the time then to review all of the available architecture and desgin docs (and even a 1hr recorded onboarding video!). From this I was able to draft a design doc proposing specific changes which were ultimately implemented (with a lot of input from my coworkers, of course!).

2. Read engineering design docs for fun, especially requirements and alternatives considered

It’s fun, I promise! This is a lot like #2, but it’s more about understanding the process, context, and conversation that happens around engineering designs. Plus understanding what’s important and why to your coworkers is a great way to empathize with them. And of course, it can also ensure you’re up-to-date on things like database schema changes, new services, etc. that might help you answer questions or inspire product ideas in the future. It’s helped me in this way a number of times!

3. Ask SWEs you work with for more technical details than you may actually need

See, these are all so easy! Even if it’s out of pure curiosity that I ask for additional technical details, doing so is a great way to test my knowledge and show my coworkers I care about understanding the problems they’re solving. I’ve found that my developer coworkers are always more than happy to share.

4. Have (and sometimes use!) a development environment like your coworkers'

Doing this might be relatively minor and is probably not necessary in all (or maybe most) cases, but it’s given me a lot of appreciation for how much our team invests in developer productivity and dev tooling. I like knowing how to make minor changes and deploy them. And my coworkers that helped me out liked seeing me contribute to our codebase and were super happy to help. I set up the server-side C# code that creates the CSVs we use for Meta Kaggle, Kaggle’s public dataset about … Kaggle.

…

And so there’s what I’ve come up with to answer my coworker’s question. I’m still learning, but these are nonetheless some things that have helped me do my job better (and enjoy it more). The common thread my pieces of advice share, I think, is that they exhibit care for my coworkers, the things they work on, and how they make decisions.

My final piece of meta advice from here is to demonstrate that you’re listening and working on improving your engineering knowledge. The more you make product decisions with the things you learned through the help of your coworkers as input, the more people will come to trust you. And in turn, they’ll share more with you. It’s a really rewarding cycle.

Be curious. Be empathetic.

–