Great engineers leave when they are no longer excited by an opportunity.
These engineers are in demand, they have other companies constantly knocking on their doors, pitching them exciting opportunities, as well as money, in an attempt to convince them to leave.
Given that cutthroat environment, how do we, as product managers, contribute to a strong engineering culture? Why should we care enough to make that our responsibility?
Great product managers want to work with great engineers, but not every engineer knows what it means to work with a product manager. Company cultures can change what the role of product management is and can dictate the power dynamic between product and engineering in amazing ways.
Additionally, there are some product managers out there who don’t understand why it’s important to foster a constructive relationship with engineering.
Misconceptions of the role of product management
Many engineers that I’ve met have been skeptical of the real value that product managers bring to a team. Rightfully so, since many of them have not had productive relationships with their PM’s.
Ask an engineer who’s worked with a bad PM, or has not had a productive relationship with an otherwise capable PM, and they’ll tell you that their PM…
- Slowed things down through unnecessary processes, meetings, ceremonies, etc.
- Advocated for onerous levels of documentation and testing, or overlooked them entirely
- Made frequent attempts to map their work with tedious metrics, overlooking the value that they created
- Pushed their team towards building things that were not perceived as being valuable
Bad product management can be a key contributor to an engineering culture that drives top performers away.
Engineers are the single most important resource that a tech company has to leverage, and designing crappy products is a fantastic way to waste their time.
Why engineers stay or leave
At a previous job, a senior product manager would often insist
Engineers just want to build, they don’t care about impact
This is a common refrain by those who are skeptical of the value of focusing on outcomes. “Engineers don’t want to hear all this talk about the outcomes we’re achieving, they just want to work on interesting tech.”
In a talk that he gave which inspired me to pen this article, John Cutler, Product Advocate at Amplitude, spoke to the reasons that engineers stay. In his talk, John said that truly great engineers care deeply about making a difference through their efforts, but that most organizations are not set up in such a way that those engineers can feel their impact.
Without a notion of the impact their work is making, all engineers have to work on is how interesting the tech is. Inevitably, most smart and curious engineers’ desire to work on new tech will outstrip the rate that any product will adopt those technologies. There are strategies that you can use to adopt new technologies faster and such — hackathons, for instance, but that’s for another article.
Product Managers are user cheerleaders…
Consider what I believe to be an underrated and undersold role of product management — optimizing for excitement. It’s our job to make sure that we’re pitching projects that are enticing to our engineering team.
Now, I’m not saying that we need to make every project sound sexy, because not every project is. Every project needs to sound important within the context of your company’s mission. Revamping a login page might not sound exciting, but improving access to your product by an order of magnitude (and all of the ancillary benefits that come with it) might sound more exciting.
Product managers can help their companies by focusing on what users are feeling, because great engineers are motivated by users in pain.
The key factor here is the focus on outcomes. Great products are built on all of the little, non-sexy things that users never notice. Nobody is going to go home telling their friends and family about how sexy your login experience is, or how quickly your pages load, but those things are essential to your teams’ success.
The way to get teams to really care about whatever work is most important to users. In my experience, engineers have an unyielding desire to save people from bad tech or instances where there isn’t any tech to solve a given problem. The trouble, though, is that getting in the heads of users is a full-time job. Enter the Product Manager.
Product managers can help their companies by focusing on what users are feeling because great engineers are motivated by users in pain. Spending time in the field, on the phone, and otherwise getting to know users and their habits is an essential role of product managers who want their engineers to feel the why of what they’re building.
…and measurement maestros
On top of that, Product Managers need to carry the battle standard of measurement as an indicator of success. The metrics you use need to be those that tell the story of what your users are feeling, whether their problems are being solved or not.
Many PM’s, including yours truly, rush to the “let’s measure everything” approach. This is certainly better than not measuring anything, but it can be confusing. The common big board of metrics, in its least useful form, is a puzzling hodgepodge of metrics, like an episode of Game of Thrones with so many characters that you can’t keep the story straight.
One way to attack this problem of metric overwhelm is a concept that Josh Elman popularized called “The Only Metric that Matters”. It involves picking a keystone metric that measures the number of users performing some key action in a particular time frame. For example, Airbnb’s OMtM is:
Number of users that book 4 trips in a year
You can see how this metric tells a story in and of itself. The Only Metric that Matters is a great grounding presence in an infrastructure of many different measures. It makes it harder for us data-driven PM’s to bend our component metrics to tell biased stories.
Great PM’s get engineers involved in the conversation
Back in the day, PM’s were often given the moniker CEO of a product. I think that’s an outdated notion.
Great PM’s coordinate. They gather and synthesize data, opinions, and skillsets.
Engineers can often feel ambushed by PM’s who don’t keep them properly in the loop about future work. With all of our responsibilities, it’s all too easy for a PM to unilaterally write tickets that engineers see for the first time when they are asked to start working. This phenomenon, which I call “throwing tickets over the wall”, is a harmful innovation antipattern.
Instead, great product managers have engineering involved in the ideation and prioritization discussion from day 1. Day 0 even.
For early-stage projects, I turn to the Three Amigos, a group that is generally comprised of a team’s PM, engineering lead, and designer. When possible, QA representation is often also a good idea. This group’s job is to vet early-stage product ideas and conduct experiments to assess the potential risks of those ideas.
Later-stage projects often benefit from Story Time, wherein the engineering team is invited to partake in a session where large projects are broken down into smaller component stories with well-written acceptance criteria. This is best conducted as a series of short, opt-in meetings throughout the week, where engineers can decide whether they’re going to attend based on the topics to be discussed. It’s very important to have Design representation to clarify requirements from wireframes, and QA representation to gain an understanding of the context around functionality and propose appropriate testing.
There are other techniques out there that can help to get people involved. a 3–5 day Design Sprint can help to flesh out some of the early questions around a product that can cripple momentum. Brainstorming can be a great way to ensure that a diverse set of perspectives are considered with regards to the requirements for a particular project, or the roadmap for a product.
Great PM’s get everyone involved.