Menu

Posts tagged “leadership”

The game you’ve never heard of that taught me a better way to build alignment

In South Africa we call this game (where the goal is to keep the rally going as long as possible) “Beach Ball” so I immediately got it. And despite my aversion to “Here’s what X taught me about B2B Sales” posts this one actually got to me. Because Gabrielle is right. The communication goal—especially in big corporations—is not to win, it’s to keep talking until you have a better way forward:

In tennis, you win by hitting shots your opponent can’t return. In Frescobol, you win by setting up your partner to succeed. One earns you points. The other builds momentum. When you default to tennis, every hard conversation becomes a match to win. You come in armed with tactics—rebuttals, logic, bulletproof clarity. But the more you prepare to win, the more you risk breaking the rhythm that makes change possible. Frescobol invites a different question: “What would I say differently if my goal were to extend the rally, not win the point?”

Source: The game you’ve never heard of that taught me a better way to build alignment

Here is how I approach starting a new job

Elena Verna has some really good tips for ramping up in a new job in this post:

If you over-index on action, you’ll likely misfire because you’re missing context. But if you over-index on just learning, you’ll create anxiety and unmet expectations around you. It’s a tough balance to strike. Assuming you are learning at max velocity, here is how I deal with ‘take action’ part: start with protecting what’s already working, move onto quick wins, go after big bets, and finish with the strategy.

I am inclined to move the strategy piece up (see my post about product strategy) and work on that before “big bets” so that you can build confidence that you know what the product is, who the users are, and how it makes money. Small quibbles about the order of things aside, I agree with all the details!

Source: Here is how I approach starting a new job

You cannot survive poor management

Yes, amen to this.

As a manager, be honest to your executives and your reports. Given enough people in your team, there is no tactical decision that will make your engineers work faster. Your only real option is to admit early that your deadline is untenable, and replan by reducing features, or extending deadlines. Whipping your engineers to work harder has never worked, and will ruin their trust in you forever.

Source: You cannot survive poor management

New advice for aspiring managers

Great advice here for new managers in this wild time we find ourselves in. In general:

Whereas the previous focus of managers was to rapidly hire and scale their teams, today’s focus is on expanding impact. This is because in today’s macroeconomic environment, output is key. In the eyes of a 2025 company, the more that you can do with fewer people, the better. There are very few additional people to go around, so the focus is on how you can help your team do more with less.

James focuses specifically on EMs, but the advice definitely applies to PMs too, so check out his post if this is you!

New advice for aspiring managers

How to provide feedback on documents.

This is great advice on providing feedback on docs. This especially resonated:

Before starting, remember that the goal of providing feedback on a document is to help the author. Optimizing for anything else, even if it’s a worthy cause, discourages authors from sharing their future writing. If you prioritize something other than helping the author, you are discouraging them from sharing future work.

How to provide feedback on documents.

Product Management: The Good, the Hard, and How to Know If It's Right for You

An engineer recently sent me some questions about the Product Management role. I took a long time to respond because I saw it as a great opportunity to reflect on the role and what it means to me. I decided to share my answers below, in case it’s useful for anyone else!

What did you like the most about your job as a PM? (I say past tense because Director can be different)

The joy of shipping, and shepherding products and features from ideas all the way through execution and user feedback and continuous iteration.

To me, the PM role is a people job. How do we get people to work together to do amazing work? How do we get the best ideas out, how do we make them real? How do we build things that people genuinely enjoy using, and don’t mind paying for? How can we understand how our products make people feel, and how can we make that better?

If you’re able to get into a product loop that does that over and over, it’s the best job in the world. You get to understand complex user, business, and technical needs, make sense of it all, and support a team of people to get useful products into the world. And then you get to talk to the people who use those products about how to make them even better.

Daniel Pink says we are all motivated by 3 things: autonomy (self-directed work), mastery (getting better at stuff), and purpose (serving a greater vision). At the best of times, I can’t think of another job that combines those 3 things as thoroughly as Product Management does.

What is the one aspect of the role that makes you from time to time (but consistently) say “I don’t think I want to do this any longer”? Or “I need a break from this”?

When we get caught up in the human tendency to forget about what we’re trying to do (that purpose from the previous question), and focus on our own needs instead. When I interact with teams and people who find their identity in their work to such an extent that it overshadows how cool it is that we get to do this stuff together. In short: when internal politics take over.

I don’t resent this tendency any more, to be honest. I used to, but not any more. This is normal human behavior—I am not immune to it, no one is. We want to feel heard, we want to feel useful, we want to be seen as competent and smart. But I now recognize very quickly when a discussion about a project or a product becomes about self-preservation vs. what is best for the team and the product and its users, and I am allergic to it. It makes everything more stressful. It requires having to “read between the lines” every minute of the day. It slows everything down. It makes everyone grumpy and wary of each other. It is poison to healthy teams and products, and it affects me deeply (too much).

I deal with it by losing myself in side projects, and spending deliberate time with the work people who don’t succumb to that behavior.

How do you advise me if I were considering either an EM or PM role to decide on which is more suitable to try out first?

I think the best starting point is to reflect on where you naturally find energy, especially when things get hard. Do you find satisfaction in crafting elegant systems and seeing the architecture click into place? Or do you come alive when you hear someone articulate a pain point and you can immediately imagine a better experience? Do you find yourself trying to optimize team throughput and code quality, or do you have an interest in clarifying ambiguity, getting people to work together happily and effectively, and shaping decisions through influence rather than control?

PMs and EMs both lead, but in different ways. Engineering Managers lead through technical insight, mentorship, and a responsibility for the velocity, health, and growth of the team. Their scope is often constrained by the product strategy/roadmap and what’s possible technically, and their main outcome is helping the team build the right thing in the right way.

Product Managers lead through context, clarity, and storytelling. They untangle complex ambiguity, and they create clarity when everyone sees the world differently (which happens on every project…). Their main outcomes are making sense out of too many chaotic inputs, aligning everyone on the problem to be solved (and how to solve it), and keeping the team connected to each other and customers.

Career advice in 2025

If you’re currently in the job market I highly recommend this post by Will Larson:

If you pull all those things together, you’re essentially in a market where profit and pace are fixed, and you have to figure out how you personally want to optimize between people, prestige and learning. Whereas a few years ago, I think these variables were much more decoupled, that is not what I hear from folks today, even if their jobs were quite cozy a few years ago.

It’s a sobering—and imo necessary—read, even for folks who are not currently look for a new job.

"Ack, think, act"—building trust as a product manager

Many (oh my word, so many) years ago I wrote that I thought “fairness” is the most important characteristic of a good Product Manager. I still stand by that, but I had another thought recently about a related characteristic that forms the other side of that coin.

Jakob Nielsen’s 30+ year old usability heuristics remain true to this day, but it’s not just relevant to UI/UX. In particularly I think “Visibility of System Status” is one of the most important skills a PM can internalize. The principles states:

The design should always keep users informed about what is going on, through appropriate feedback within a reasonable amount of time.

When users know the current system status, they learn the outcome of their prior interactions and determine next steps. Predictable interactions create trust in the product as well as the brand.

A PM can do nothing without trust. And to build trust in an organization, applying “visibility of system status” thinking is the #1 way to gain (and keep) that trust. That means a PM needs to:

  1. Ack: Acknowledge comments or questions as soon as reasonably possible (within hours, not days), even if it’s just to say, “I saw this and will get back to you.”
  2. Think: Respond to the original comment/question—with ultimate clarity—in a timeframe that balances thoughtfulness and pragmatism (days, not weeks).
  3. Act: Follow through on any commitments / next steps with regular proactive updates (for as long as it takes).

Note that the order is important here as well. Don’t Ack only after you’ve taken the time to Think. Don’t Act before you Think. That seems obvious, but I’m sure we recognize the wrong order all around us (and in ourselves!) all the time.

This all might sound hard, but once you’re in the rhythm of this cycle, it becomes second nature. “Ack, think, act” becomes just the way you go through your day. I think this is something we should all aspire to more in product (and probably beyond).

What to do about time goblins

Once we’ve got a plan and that plan is locked we’re in this rare and special place where the things that will pull us off-course haven’t happened yet.

— Raw Signal Group, What to do about time goblins

Managing Up

Michael Lopp has a great post about “managing up”, including how problematic that term is:

To me, “Managing Up” has that “your boss’s job is more important than yours” feel, which pisses me off. Your boss’s job isn’t more important than yours; it’s different.

He goes on to share some great advice for what to share with your manager, and when. For instance, when to share something immediately:

Unexpected developments. A situation appears in front of you, a non-threatening one but unexpected. Strange. Something is up, but you can’t discern the backstory story or the intent. It is unfamiliar. Tell your manager. Now. Just a brief note. A heads up. It’s probably nothing—it usually is—but there is a chance your manager’s context plus your suspicions equals additional clarity.