Manage up

When I talk to devs about “thinking like a PM,” I hear many variations of:

• “This is all well and good, but I don’t get to make decisions like that.”
• “This won’t work because I have a bad relationship with my manager.”
• “I tried this, but then our CEO swooped in a blew up the whole roadmap last week.”

A vital part of Product Management is finding aligment between a ton of people in your organization. Many of those people are above you on the org chart. Thus, “managing up” to your manager / CEO / client is part of the job. Developers have to do this too.

At the bottom of this post, there are several practical tips for how to do this.

We were part way through a complex Feature A. After that we planned to work on an important tech debt project that would make our next big Feature B a lot easier. Managers called an urgent meeting to say, “We need Feature B right now. Drop everything.” Conventional wisdom gave us good reasons to push back and say, “not yet,” or even, “no.” And so we did.

We got frustrated, and framed the conversation as management vs. developers. We invited a negotiation. Or perhaps an argument. Managers argued to get stuff done for customers ASAP. They advocated for the success of the business. So to negotiate against them sounded like an argument to…. not get stuff done? To neglect customer needs? To advocate against the success of the business?

Trust devolved. Private text threads erupted. Blame was cast, feelings hurt, resignations considered. Management felt the need to micromanage. After all, there are a bunch of highly paid people arguing on the side of “don’t get stuff done.” Management rode developers, questioned every decision, scheduled extra meetings, and commandeered the roadmap. It sucked.

One of our smartest devs had a great insight: talk about tradeoffs. Instead of, “No, that’s a bad idea,” they found ways to say, “Interesting! We can do that. But here are the tradeoffs if we do.”

This is subtle, but brilliant. This maneuver moved developers to the same side of the table as management, sitting across from the problem at hand. We negotiated with the problem, not with each other. We were on the same team. Devs provided crucial information to inform this negotiation. They reframed their work as an investment in the company's success. Devs appealed to company goals in this negotiation. Managers love that.

Here are some practical tips for how to do this:

Managers / executives hate to hear “no.” “No” is a show stopper. It sours the mood. It sows seeds of resentment and distrust that lead to micromanagement hell. Improv performers attest to the power of saying, “Yes, and…” The phrase has evolved into a way of life for creative collaborators. Don’t kill the vibes by saying “no” to your collaborators. Say “yes, and...” then volley the conversation forward to something even better.

For example:

• “Yes, that is an exciting new feature request. And we think it will take months to build. What would we remove from the roadmap to fit it in?”
• “Yes, we could completely change the UX of this feature we just finished. And here’s what it would cost for us to do that: 4 weeks of work, and a huge hit to morale.”
• “Yes, we could not work on tech debt this year. We agree we could move faster in the short run. And here are the long term consequence of that...”

People like options. When these kinds of conversations come up, give your managers a set of options. Explain the tradeoffs of each. It’s all tradeoffs. But express an opinion. Tell them which you prefer.

Always write down decisions. I make a "Decision Log" table in most documents I create. Write down every important decision and every meaningful ambiguity that requires a decision. Write down the decision, the rationale, who made the decision, and when.

Good documentation answers questions. The decision log creates alignment. It gives everyone a public record to see, “how did we get here?” But this is also a powerful way to cover your ass. You have something to point at to say, “We actually decided with you 2 months ago that we weren’t going to do that. We can reverse that decision you made. But here’s what it will cost us.”

Developer hours are an expensive investment. So invest in the right stuff. Reframe the conversation into a discussion about which investments are best. This is a powerful way to sit on the same side of the table as management. I talked about this at length in my post about Tech Debt.

These tips works better if you’re a good communicator. Communication is the absolute most important non-technical skill you can develop. Do not underestimate it. I wrote a whole post about Communication