… you ask discreetly, feeling slightly embarrassed to admit you don’t know something in the tech world’s overachiever culture. Hopefully you can take a class or two to cover the basics and help you have some more productive conversations with your engineers.
The reality is you should flip the order: Have conversations with the engineers and then take classes if helpful. What if you assumed that rather than judging you, your colleagues would love the opportunity to help you and share their knowledge?
Start by grabbing coffee (real or virtual) with one or more of your engineer buddies on the team and asking them A LOT of questions. Go to someone who has a good understanding of the system and can explain technical concepts in plain English – the fact that they’re good at it is usually an indication that they also enjoy it.
- No trying to look smart.
- No self-imposed limits on the questions you ask – your goal is to learn, not to impress (see previous rule). No, your buddy is not going to think you’re dumb – just that you’re not an engineer (duh).
What should you ask?
- Ask them to explain to you the overall architecture of the system. What are the key parts? Is there a client? A server? What are the key components of each? How do they communicate? How is data stored and retrieved? What are the key technologies used and what are they used for? Are there platform components – parts of the system that service multiple applications or use cases?
- Take the most common use cases and see how they flow through the system. What happens when a user does X? Which components are involved? How does data flow back and forth? What processes operate in the background?
- Ask why the system was designed the way it was. How else could it have been designed? What are the tradeoffs? Which use cases become simple as a result of the architecture choices, and which are more complex? What are the performance bottlenecks? Tradeoffs are often made to simplify the most common use cases, speed up development, or to satisfy performance requirements; you want to really understand those.
- Which part of the system is your team responsible for? How does it interact with the areas of responsibility of other teams in the org? If non-obvious, why does it make sense to divide responsibilities this way from a system standpoint?
- Pick a few features on the roadmap. Try to understand which components they touch and what needs to be added / changed for the feature to exist. What are the trivial parts in the implementation and what are the complex parts? Why?
- Google all the technical terms later to learn more.
You may not cover this in one coffee chat (unless you want to end up a jittery mess), but once you get a basic understanding of these issues you can be much more targeted in the classes you take or the materials you read. PMs too often start by going down a rabbit hole of learning coding or machine learning algorithms, which isn’t a bad thing, just not the most useful place to start.
Technical knowledge can help you credibly question estimates, discuss how to modify requirements to align with goals and timelines, or define thoughtful requirements that result in flexible systems that don’t need to be rewritten every quarter. However, the knowledge required revolves more around overall architecture, information flow, performance, responsiveness etc. than around writing code or understanding the nuances of one algorithm vs. the other (data science is a lot of trial and error anyway).
You’ll know you’re on the right track when you ask an engineer just the right question and they (sometimes reluctantly) say, “that’s a good point…”.