I used to think being a great product manager meant being the smartest person in the room. The one with the best ideas. The one who could jump into any hard problem, architect the solution, and move on to the next fire.

That's not wrong, exactly. It's just incomplete. And at a certain level, it becomes actively limiting.

I'm a senior product manager at Meta working on Quest and VR products. It's the hardest work I've done in my career, not because the technical problems are harder (though they are), but because the role itself requires a fundamental identity shift that nobody really prepares you for.

Let me explain.

The Conductor, Not the Soloist

The best frame I've found for senior IC work is this: I'm the conductor of an orchestra. Or maybe more accurately, since I was a drum major in high school, I'm leading a marching band.

The band is where the magic actually happens. I'm there to set context, frame up problems to be solved, synthesize information and communicate it effectively to the audience, and then get out of the way so the team can do their best work.

I set my expectations of quality really high. But it's the team that ultimately finds the answers, not me.

This sounds simple. It's not.

Because here's what they don't tell you about climbing to IC6: the skills that got you promoted become your biggest liability at the next level.

I built my identity around being the person who could jump into really hard spaces, solve problems, and move on. That's classic IC behavior: you're the hero who fixes things. You get promoted because you're reliable, responsive, and you ship.

But at IC6, being the hero actually hurts the team because it creates a bottleneck. If I'm the only one who can solve the hard problems, the organization can only move as fast as I can context-switch.

The "Why" Person

So what does conducting actually look like in practice?

It starts with being obsessive about "why." It's really easy to jump into what we're building (roadmap) or how it's going to work (design) or how we're going to build it (engineering). But it's critical to ground our thinking in the motivation - solving an actual problem for people in a way that grows our business.

This might be a strategy doc where we define the business context, product goals, target audience, problems to be solved, and solution approach. Or a PRD with context, goals, metrics, core concept, requirements, and milestones. But it should all have a clear throughline back to why we're building it.

The PM's superpower at this level isn't having the best ideas. It's keeping everyone anchored to the problem and strategy while the team figures out the solution.

The IC6 Paradox

Here's the uncomfortable part: senior ICs are expected to be working in highly ambiguous, complex problem spaces, aligning the org on major decisions, and delivering big results. AND you're expected to grow team health, improve cross-functional collaboration, and build community.

You need to operate at scale AND be able to zoom into critical details. The hardest part is knowing which mode to be in at any given moment.

I can't just take my hands off the wheel. If I let my team fail, it's just as much my fault as theirs. So sometimes I do need to jump way back in, sit with the team brainstorming solutions, test the latest builds, prioritize feedback, get really detailed on driving issues back on track.

It's an art and science knowing where to focus attention.

Deciding What Actually Matters

The framework I use comes down to four things:

1. Deep understanding of the product as an enthusiastic user of it
2. A clear take on our strategy: how we can win in the marketplace against competitors
3. A compelling vision of what executing on that strategy incredibly well would look like
4. Focus on the critical few things we need to get right

There are tons of things I could focus on. But ultimately very few of them probably matter in the end.

This is really hard for me personally because I'm an "inbox zero" kind of person who prides himself on being responsive to everything. But that's completely unrealistic and it's why I burn myself out if I try to keep up with everything.

Strategic focus isn't just about maximizing impact. It's also about survival and sustainability at the senior level.

Making Tradeoffs Visible

The hardest but most critical part of the job is saying no, not just to new ideas but to day-to-day requests for attention.

I care deeply about the product and want it to be successful. So turning things down feels wrong. When I do it well, I try to be really clear about priorities, not just saying "no, I can't do that," but starting with: "I think it's critically important that I get X, Y, and Z done for this product to be successful. You asking me to do this other thing is going to take away from my priorities. That's why I'm not prioritizing it."

At least then it opens up a conversation about whether their ask is more important than my priorities. It makes it less personal and more about the business.

You're not just saying no. You're trading priorities explicitly and making the cost visible. That's product leadership, not just time management.

The Convergence

Here's something nobody talks about: the higher you go as an IC, the more your role converges with management.

I used to be a PM manager before transitioning back to IC. There was a lot of overlap. The way I think about it now: as an IC, the majority of my impact comes from strategic decision making and product execution. As a manager, the majority of impact comes from team health development, cross-functional collaboration, and community building.

But both are important in both roles. At IC6, I need to scale through others more and more, so I have to lean heavily on team health building, XFN collaboration, and culture building.

In the end, my results really come through directing the work of others. Helping everyone around me do their best work is what's most important - and also the most rewarding work I've been able to do.

The irony is real: I'm not managing people directly, but I'm managing their focus.

What I Wish I'd Known Earlier

If I could go back and tell myself one thing when I first hit IC6, it would be this:

It's not about how many projects I deliver or reviews I lead or the quantity of things I'm working on. In fact, working on a lot of things is probably more of a weakness than a strength.

It's about the depth of decisions I drive, the depth of impact I make in a specific area, and the depth of collaboration I help unlock.

That's the real measure of senior IC work.

There's an uncomfortable truth buried in all of this: the identity that got you here - the problem-solver, the hero, the person who can do it all - has to die for you to operate at the next level.

You have to learn to get your dopamine hits from different sources. Not from personally solving the gnarly problem, but from watching your team solve it. Not from being responsive to everything, but from being strategic about where you engage. Not from the quantity of your output, but from the depth of your impact.

It's hard. I'm still learning. But I'm finding that the conductor role - when done well - is actually more rewarding than being the soloist ever was.

The music is better when everyone plays.

In this post:

• The Conductor's Paradox: What I Learned About Impact as a Senior PM
• The Conductor, Not the Soloist
• The "Why" Person
• The IC6 Paradox
• Deciding What Actually Matters
• Making Tradeoffs Visible
• The Convergence
• What I Wish I'd Known Earlier