I’m currently working on a small team within Honeycomb where we’re building an ambitious new feature. We’re excited—heck, the whole company is—and even our customers are knocking on our door.
The energy is there.
With all this excitement, I’ve been thinking about a risk that—if I’m not careful—could severely hinder my team’s ability to ship on time, celebrate success, and continue work after launch: burnout. I don’t see burnout mentioned often when the work of product management is discussed, but I believe it should be taken much more seriously.
What matters to me, as a PM
As the team PM, I’m accountable for delivering on our goals; for making sure we build the right thing and deliver it as close to ‘on schedule’ as possible. If I do this, it reflects positively on me, and is good for my career growth. But it also means I must navigate some really difficult incentives, because I’m tasked with balancing what is actually achievable versus what is ideal to ship. It’s reasonable for me to believe that my career progress rests on maximizing what is actually achievable to get it as close to the ideal as possible.
In fact, I could index entirely on customer value. As a PM, I stay very close to customers, field teams, and user feedback in order to continually refine my understanding of what will make the product most successful. I could continue to focus on that and decide it’s the responsibility of design and engineering to tell me when they are overwhelmed or feel like our commitments are risky. I know that’s fairly common practice in the industry. I could choose to focus only on the product, and assume others will tell me if our plans are at risk.
But personally, I think that way of working is a dereliction of my responsibilities, and a willful ignorance of product team power structures. I was an engineer for nine years before moving into product management. I’ve worked closely with some amazing designers. Because of that, I am all too familiar with how product team incentives result in pressure to continually say yes to new requirements, or commit to ambitious timelines based on an initial estimate that lacks crucial information. These incentives come from good motives—the desire to ship a useful thing to customers—but they lead to burnout if initial decisions are treated as unmodifiable contracts.
Unsustainable productivity isn’t a flex
Burnout—as I understand it and have personally experienced it—often stems from operating at your highest productivity for an unsustainable period of time. Productivity is easiest to maximize when you’re under stress, because your body responds to stress with fun chemicals like adrenaline (among many others) that help you focus and move faster. But a stress response is supposed to be a situationally reactive state, not a permanent state. We can handle occasional stress and it’s fine! We cannot, however, handle permanent conditions of stress. That is not fine. Among the many negative health outcomes, permanent or ongoing stress can lead to burnout.
Product managers—in my opinion—hold a lot of power to set the context of the teams they work on, including the context of how much stress team members operate under. We have that power because we are the ones accountable for requirements (how much work needs to be done) and timelines (when the work is due). If we use our power to push for expansive requirements, or to push for sticking to timelines that have become harder due to new information or scope creep, we are responsible for increasing the amount of stress our coworkers are under.
Now, I’m not naive. I don’t believe that the world we live in can be completely stress-free. I’m not here to suggest that stress is categorically negative and must always be avoided. But I hear about product teams where stress is considered normal way too often. People on those teams believe they have two options: stay on the team and deal with the stress, or find a new job/team that will hopefully be less stressful. My goal in this post is to suggest that as product managers, we are well-positioned to create a third option that’s better for everyone’s health: we can change the conditions to make work less stressful, so that team members can stick around without jeopardizing their health.
How I avoid burnout—for my team, not just for me
Here’s what I’m doing on my current project to work towards that option. I implemented these practices based on things I’ve done in the past that coworkers told me were helpful, and that I’ve seen other PMs (with similar goals) do.
Make ‘avoiding burnout’ an explicit goal
“I do not want this team to be a team that burns people out.”
I said this when the team formed, and I repeat it occasionally in other meetings. By making the goal explicit, I build psychological safety for my teammates to be aware of unsustainable productivity. We can have conversations much earlier if burnout feels like it’s creeping in. An added benefit of making this an explicit goal is that everyone can share in the goal, meaning it is not purely my job to monitor it.
Commit to actions that you’ll take to achieve this goal
Everyone who has worked in a corporate environment knows that even if you say the right things, that doesn’t mean the right actions will be taken. I believe that building trust with my team requires me to commit to actions so that they can see if my words are worth a shit. As a product manager, the things I commit to are:
- Willingness to revisit requirements to ensure that we are focused on the things that provide the most value to customers—and are truly necessary for success
- Willingness to fight for more time if timelines become unreasonable
- Willingness to revisit priorities and sequencing if more information leads us to reconsider our initial decisions
Each of these commitments is a recognition that I do have power to change what we’re working on and what we’re working towards. I may not always be successful (there are always external commitments and teams we’re working with), but trying to change things is necessary.
Treat my teammates as more important than the product
I don’t know if this is a given or if it’s super controversial, but this is another action I commit to. When we face a decision that will increase someone’s stress for a period, they have to be involved in the conversation and consent to the decision. And increased stress loads always require rest afterwards.
What this might look like in practice is that when we face a committed deadline (say, a launch date with marketing motions already in place) and a requirement with strong user value suddenly becomes more complex, I now face a situation where requirements + timeline = stress. This means I need to have direct conversations with the engineering manager and engineering lead to figure out if we have creative options. If not, the question is: do we think we can achieve the requirement? This is a big question, because saying “yes” means engineering must take on some level of stress as they work to hit a goal in a tight timeline.
If we agree there are no creative options, but the engineer does believe the requirement can be met within the timeline, the next question I ask is, “What do we need to shift to ensure there’s recovery time after we ship?” This often means bumping timelines for future releases, so that the post-launch period is a recovery period and the next release does not also require stress. This practice of consent and reorganization allows for us to continue to be ambitious, while (hopefully) not harming anyone on the team’s health or well-being.
Conclusion
I’ve experienced burnout in my career, and talked to many others who also have experienced this. A universal theme in these conversations is that burnout takes far longer to recover from than it does to fall into. Because of this, we should strive to build working environments that do not induce unnecessary stress, and we should treat sustained stress as a significant issue that should be addressed as quickly as possible.
I hope this post encourages other product managers to consider our power to affect working conditions on product teams. I’d love to hear from anyone who also considers this a responsibility of the role. Please feel free to reach out to me in Pollinators, our Slack community.
