Mandy Brown nails it, once again:
One of the principles I come back to over and over is adrienne maree brown’s invitation to move at the speed of trust. That is, whenever attempting any effort with other people, prioritize building trust and respect for each other over and above any other goal. The trust forms the foundation from which the work can grow.
Michał Poczwardowski shares a good reminder about how to set expectations well in our teams:
The biggest partner in crime for missed expectations is unclear communication, which means that the antidote is clear communication. Follow these steps to make sure that expectations are clear:
- Be realistic about the future. Overconfidence will build up expectations. If there are a lot of uncertainties, state clearly what is certain and what is uncertain.
- Point out what you don’t know. Give as much context as you can. If you leave too many unaddressed gaps, people will fill these gaps with their own projections of which you have no control over.
Here’s a quick thought about ramping up on something new as a product manager.
If I don’t understand how something works in an organization, I do two things. I ask questions, and I draw boxes and arrows based on the answers. People sometimes make fun of me for this, but hear me when I say that nothing gets people aligned like a systems diagram they can disagree with.
B2C, B2B, Platform, Internal… the industry/product type doesn’t matter. Draw the flow of information through your product, get people to disagree, adjust until they agree. That’s the moment when you become a PM that can actually be helpful to the team and the business. You cannot improve the system until you understand it.
This is a good reminder about micro-management from Judd Antin. He says that maybe You’re Not Managing Enough (a big climbing analogy runs through the whole post):
As managers, we can be so afraid of micro-management that we risk moving into passive territory. We’re made to believe our main job is putting people in position to grow, and then going hands off to give them the space to do it. But that’s like encouraging a climber to take on a harder route, cheering them as they start while you check out TikTok instead of holding fast to the rope. To do their best, that climber needs an active belay from start to finish. It’s easy to try again when the rope caught you and you only fell a few feet. These are the most educational failures — it’s those big ones that you want to avoid.
There’s some practical advice in the post on the best ways to be more active and helpful in the right ways by providing clarity and making solid plans with your team.
I like this alternative approach to the old “disagree and commit” adage. That idea always struck me as a little passive aggressive (“sure, I’ll do this stupid thing you want me to do…”), whereas this seems like a more active, helpful approach:
It’s much healthier to “have concerns and commit.” Some decisions you can agree with, some you can disagree with, but most you should either just “have concerns about” or “be supportive of”. […] If you’re not sure of the answer but have concerns, you want to make sure that your feedback is deeply considered. You can tell your team that feedback was heard but ultimately the people with the most context made the call, which is how it should be.
It’s important to note that this type of culture is only possible if leaders agree to provide a lot of context on decisions (which not everyone wants to do):
As much as you have to be humble in your approach to engaging with decisions, healthy companies and leaders should provide you with enough information to be able to understand decisions in enough detail to have confidence in supporting the decision.
I recently did a first draft of my manager README and I end it with some books and newsletters that have shaped my thinking, and continue to do so. I thought it might be useful to a broader audience so I’m sharing it here as well. These are the books I keep right next to my desk, and the newsletters I open every time they arrive in my inbox.
I am skipping some obvious ones (like Lenny and Platformer) that everyone already subscribes to.
This is a really great post by Ben Werdmuller. On the surface it’s about Building Engineering, but it’s mostly about good leadership and how to build successful products. I very much agree with his conclusion:
The most interesting and successful organizations have an externally-focused human mission and an internal focus on treating their humans well. That’s the only way to build technology well: to empower the people who are doing it, with a focus on empathy and inclusion, and a mission that galvanizes its community to work together.
There’s some great advice throughout, so I recommend reading the whole thing!
Josephine Conneely shared some thoughts that might seem controversial in The Alignment Fallacy. The basic premise is that the need for full alignment within a team can sometimes hide some deeper problems within an organization:
The need for complete explicit agreements in organisations can reveal a culture which requires you to be on defense (a cover your a*s culture if you will). Alternatively, it can be driven by a culture which suffers from being too collaborative (it happens). Plans which require committee approval get delayed, often never quite leaving that committee discussion stage. Broad stakeholder alignment is a positive thing that should be strived for but there can be limits. High risk, high reward scenarios rarely get complete agreement up front. Instead, they require someone to step up and commit to pursuing that path.
I agree with this take in general, with some nuances I would add to the language. I see alignment as a communication outcome that should happen in any decision-making culture, whether it’s consensus-driven, command-and-control, collaborative, etc. I would say that the situation Josephine describes in the quote above is an issue with relying too heavily on a consensus decision-making style. Importantly, consensus doesn’t necessarily guarantee alignment. How many times have you walked out of a meeting where everyone agreed on a thing and then the next day you’re surprised because it feels like you agreed to a completely different thing?
So I would maybe tweak the language slightly and say the post is a warning against consensus cultures. Alignment is a separate step from the actual decision being made, and an important one. It aims to make sure everyone understands (1) what decision has been made, and (2) what the consequences/next steps of the decision are. That’s needed no matter what your decision-making culture is.
I wouldn’t want to work in an environment like this because even though delivery is a fun part of building product, I find that for most PMs it’s so much more fulfilling (and you usually get better results!) when they are part of strategy and discovery as well. That said, I’m now long enough into this product journey to recognize that as long as you have a team of people who love execution and are excellent at it, this is a completely valid way to build a company:
We changed this model with Brex 3.0. We killed our planning process, and now have One Roadmap for the entire company. I [Brex CEO] am the ultimate editor of everything that ships. We release 4 times a year, and each release has no more than 3 big themes. This forces me to choose what truly matters, allowing us to make a large, company-affecting investment in the few things that are step-function changes to the customer experience, and drop everything else.
Basecamp works in a similar way, and it works for them. I do appreciate that both companies are honest about how they work, so PMs know what they’re in for and what’s expected of them. The frustration only sets in if PMs think they have some autonomy over their work, and then slowly find out about the “shadow roadmap” they weren’t aware of. Just bring it all into the light, I say.
I know the concept of a Manager-README (a document where you explain to your team some of the ways you like to work) can be controversial, so I’ve avoided it up to now. But this week I got curious and read up on the pitfalls and how to avoid them. Then I took a stab at an outline and it was actually really helpful—even just for myself—to clarify some of my own views on product work. It starts like this:
The purpose of this document is to summarize some of the values and principles I try to adhere to at work. But we are human and this is a relationship not a contract, so I see it as a way to kick-start how we work together, not the end result.
I also recognize that documents like these can be abused by managers, so this is not a way for me to excuse any bad behaviors. If you see me doing something that is not reflective of these values, please call me out so that I can improve.
I then go into talking about my leadership style, product philosophy, communication preferences, decision-making, and feedback loops. I would love to hear if this type of outline is helpful to anyone, and if you have any feedback!