PM 101: Working with Engineers
13 June 2021 ‧ 8 min read
In the “PM 101” series I am sharing some PM basics that I wish I had known when I first started as a product manager. In this article, I share a few best practices to better collaborate with engineers.
In addition to designers, engineers are the people that product managers interact with the most on their teams. In fact, there are usually many more engineers on product teams than people from any other function, so it is paramount for product managers to effectively collaborate with them.
Working with engineers might be easier or more difficult for you, depending on whether you have a technical background or not. However, I believe that these tips below are useful regardless of how technical you are:
- Respect the maker schedule
- Understand the development process and your role in it
- Get to know the system architecture
- Understand complexity drivers
- Treat them as partners
- Learn about technical debt
More details on each of these points in the following.
1. Respect the maker schedule
One of the classic pieces of Silicon Valley lore is Paul Graham's post Maker's Schedule, Manager's Schedule. It describes how managers are often on a schedule that's driven by back-to-back appointments, whereas makers often need big chunks of uninterrupted time in order to productively “make” things. Meetings in the middle of one of those chunks of “make” time are a disaster because they mean the maker can't get anything useful done before or after. Engineers are a prime example of makers as per this definition.
Product managers, for better or worse, often run largely on the manager schedule. The key reason for this is that alignment of various stakeholders and their perspectives is one of the key responsibilities of the product manager role. Especially in big organizations, product managers often spend a lot of energy on listening to and addressing concerns from leadership and stakeholders from other functions.
As discussed in Paul Graham's post, these two schedules are fundamentally at odds with each other. Someone on the manager schedule will often carelessly schedule a disruptive meeting with someone on a maker schedule, simply because the time slot was one that happened to be free. As a product manager, you should be more mindful than that about your engineers' time. After all, these kinds of disruptions will slow down your team, and in the end, make it less effective. Instead, talk with your engineers and figure out how you can give them the maximum amount of uninterrupted time. Some ways to achieve that could be to schedule meetings in the morning or at the end of the day, combining several short meetings into one longer one, or skipping some meetings altogether in favor of asynchronous communication.
The maker schedule should also be taken into account for communication outside of meetings. A tap on the shoulder or an instant message at the wrong time can be really disruptive to an engineer who's tackling a tough problem. Instead, see if you can grab them when they're free, or use a less intrusive communication channel. It also helps to clarify up front what channels you will use when there is really something so urgent that you want them to drop whatever they're currently working on (like a critical bug in production).
2. Understand the development process and your role in it
In most companies, product managers play a critical role in the development process. While engineers do the majority of the delivery (by means of actually writing the code), product managers are often involved in almost every step of the way. Their responsibilities may involve writing specs, tasks, or acceptance criteria, reviewing and testing work products, or configuring various aspects of the product.
The previous paragraph included a lot of “mights” and “mays”. The reason for that is that the product manager's role in the development process varies enormously from company to company. Here are a few examples of the potential differences. The actual delivery process might be different: some companies use Scrum, some Kanban, some waterfall, some their own custom process. The role of the product manager might be more hands-on, where the PM is expected to break down the work into individual tasks and manage the execution of the project, or hands-off, where a tech lead among the engineers takes on that work. There might be dedicated functions for QA, release management, and operations, or that work might fall on the rest of the team, in which case the product manager will likely have to pick up some of the work.
From all of the above, it follows that as a new product manager, you will have to speak with your engineers about your role in the process. This discussion should cover not just the tasks and artifacts (work outputs) expected of the product manager, but also quality criteria. Some teams might have those formalized (for example, a “definition of ready”, outlining how a task needs to be defined before it is considered “ready for development”). Even if such formalized definitions don't exist, engineers will likely be able to describe their needs and/or show examples of what good artifacts look like.
3. Get to know the system architecture
As a product manager, you very likely won't have to get involved in depth in technical and architectural decisions. It helps tremendously, though, to understand technical trade-offs that the engineers on your team are making. One of the fundamental pieces of information that is required to understand such trade-offs is the overall architecture of the system. You won't have to know every individual component by name, but having an overall idea of the architecture is helpful.
Getting to know the system architecture has several advantages. The perhaps most impactful one is that you will be able to speak the engineers’ language. Referring to concepts from the engineers’ world in their own words helps build trust, make yourself understood, and understand technical tradeoffs. All of these are critical to success as a product manager.
The best way to build that understanding is having an engineer who's been with the company for a while walk you through. Here are some questions that might guide a discussion like that:
- What are the most important components of the overall system architecture that I should know?
- Where do the major pieces of business logic reside (in which service(s) in the backend, in the client,…)?
- What are the major technologies and frameworks we use?
- How is our product instrumented (event and error logging)? How can I access that information? What is the process to add new events?
- What aspects of the product can be configured without changing / deploying / releasing code? How?
- Do we have infrastructure in place for A/B testing? If so, how are A/B tests set up, configured, and concluded?
- Are there any major technical constraints or design assumptions that fundamentally limit what we can easily build?
4. Understand complexity drivers
In order to really effectively work with engineers, you will need to get a feeling for what level of technical complexity different ideas have. In the beginning, this can be quite a daunting task, especially if you don't have a technical background. It is therefore crucial to develop a trusting relationship with at least one experienced engineer who can help you quickly assess complexity.
Understanding drivers of technical complexity has several advantages: Firstly, it speeds up the process, if you have a rough understanding of complexity and can apply that to ideas as they come up without having to cycle through engineering. It also reduces the risk of you overcommitting to tasks that the team is unable to deliver due to high complexity. Lastly, it can help with generating alternative ideas with lower complexity—if you aren’t aware of the complexity in the first place, you might not be aware that alternative solutions might be beneficial before talking to an engineer.
5. Treat them as partners
In the best product teams, the various disciplines work together as a team to discover, design and develop the best possible solutions for their customers’ problems. This requires a true partnership between the product disciplines and engineering. Treating engineers as “code monkeys” who just deliver the genius solutions that product managers and designers have come up with won’t get you there.
You need this partnership to develop great products because these products combine the product manager’s understanding of what’s valuable to the customer with the designer’s understanding of what’s usable and the engineer’s understanding of what is technically feasible. Only a tight collaboration between this product trifecta will lead to the solution that optimally balances the various concerns.
Treating engineers as partners means involving them very early in the process. Naturally, the discovery phases of any newly developed product or experience are heavier on the product manager and designer, and the later delivery phases heavier on the engineers. That shouldn’t mean that engineers only get involved once the solution idea is already somewhat well-defined. To the contrary: jointly building up context about the problem space and ideating solution ideas together ensures that both engineering concerns (e.g., about complexity) are taken into account right from the start, but also that engineers can contribute their ideas (e.g., in terms of technological trends and new possibilities that could help solve the problem in ways that were previously infeasible).
Involving engineers early on has the additional benefit of instilling a product mindset in engineers, where they build up empathy for users and the customers and understand the problems they are solving. If engineers are just delivering software “to spec”, they can only strive to stick to that spec as closely as possible. For detail decisions that come up, they will have to either go back to product managers and designers or just go with what is easiest or makes most sense from a technical perspective. If they have more context and understanding about the customer problems they are solving, they are able to make better detail decisions by taking into account what will best solve those problems.
It is worth noting that some engineers can be reluctant to engage early on in the process. There are several reasons for that: these engineers might be more motivated by technical excellence and craftspersonship than by solving customer problems, they might feel pressure to be maximizing their time in front of a keyboard, coding, or they might want to minimize context switching between work that's currently in development and work that's in the discovery phase. Of course, different reasons might need different ways of addressing them. In any case, as a product manager, it is often advisable to start small, perhaps by inviting engineers to solution brainstorming sessions. It can also be helpful to find one or two engineers that are already more product minded, and start involving them a bit more deeply, to demonstrate the benefits of a deeper understanding of customer problems to the rest of the team.
6. Learn about technical debt
Technical debt can sometimes feel like the perennial bane of product managers' existence. When development work slows to a crawl, or when things that should be easy become infeasible, then often technical debt is the reason.
Technical debt is a term that describes that less-than-perfect implementations of past features slow down future features by increasing complexity or requiring additional rework. The analogy to financial debt is that once the debt is taken on, it has to be paid back over time, even with added interest. The repayment in the case of technical debt comes in the form of increased effort for future features (interest) or even major refactoring to get rid of technical debt (principal repayment).
There are different types of technical debt. I like to differentiate between deliberate and accidental tech debt. Deliberate tech debt is taken on in order to speed up getting a product shipped. This kind of debt often comes in the form of cut corners, shortcuts, and suboptimal technical solutions for the sake of delivery speed. This kind of technical debt is akin to a mortgage: debt deliberately taken on to afford something you couldn't otherwise afford. Over time, you will need to pay it down, or the interest payments will crush you. Accidental tech debt, on the other hand, is the kind of debt that develops over the normal course of shipping multiple versions of a product, even though each individual feature was soundly architected. The reason for accidental tech debt is the iterative nature of product development. If you had perfect information about how the product will evolve, you would never produce accidental tech debt. Accidental tech debt is more like credit card debt, where you will regularly need to make payments to keep the debt from piling up—and if you have neglected your payments for a while, you might not be able to afford any new features anymore until you've spent some time paying down the debt.
As a product manager, you should talk with your engineers about the technical debt they encounter, and make sure they have some capacity to pay down accidental tech debt. You should also be mindful about deliberate tech debt: it is okay to take it on occasionally, where it allows you to validate more quickly, but piling up such tech debt without ever paying it back is unsustainable.
How well you collaborate with engineers is what often determines your effectiveness as a product manager. Especially if you don't have a technical background, it is therefore crucial to quickly make some allies among the engineers you work with. Having such allies will help you navigate the challenges and pitfalls in all your relationships with engineers.
I hope you found this article useful. If you did, feel free to follow me on Twitter where I share thoughts and articles on product management and leadership.