Hey!

Welcome back to another week of musings.

I hope you had a great weekend! We spent time with my wife at the ballpark and at Chase Center watching the Valkyries!

Was this forwarded to you? You can subscribe here!

Things I enjoyed in the past week

• The normal work of creating reliability is another great post by Lorin around reliability space in software engineering.
• Adding a team was the wrong strategic decision. A good read on how strategy fails, and why adoption can't be forced.

Over the last couple of weeks, I've been taking a hard look at everything on my to-do list.

Part of that exercise has been understanding what I need to prioritize to keep growing in my career, and what "the next level" actually looks like in practice.

I've been lucky to have conversations with people who are already operating at that next stage. Being able to ask them how they spend their time, what they optimize for, and what they had to let go of has been very helpful.

One theme keeps coming up for me: I'm still holding on to tasks that I should have delegated a while ago.

In some cases, I haven't pushed hard enough to hand them off. In other cases, I haven't even started the conversation with the right team. The work keeps moving because I keep doing it, but that doesn't mean I should.

What makes this tricky is that some of these tasks became part of my identity at work.

I know how to do them. People associate me with them. I probably built some of the systems around them. So letting go can feel like giving away part of what makes me useful.

But that feeling is not the same thing as reality.

In reality, some of these tasks are no longer the best use of my time. They belong with someone else. Or they should be owned by another team from the start, with me helping shape the direction rather than carrying the execution myself.

That is the shift I'm trying to get better at.

As we grow in our roles, I think this happens a lot. We get good at certain work, we get known for it, and eventually we outgrow it. Sometimes we even get bored with it. So we start looking around the organization for new problems to solve.

That can be healthy, but it also creates a decision point: are we moving toward the kind of role we want, or are we just collecting more work because it is familiar and comfortable?

I've also been talking with people about how the staff engineer role is different in nature from the software engineer role.

At a high level, software engineering often has a clearer structure: tickets, systems, code, and delivery. Staff roles usually become less structured. The job shifts more toward influence, shaping direction, connecting teams, and helping other groups achieve their goals.

Not everyone wants that shift, and I think that's completely ok.

I've met people who are bored in their current role, but don't actually want the staff engineer path because it would mean spending less time coding and more time influencing. They don't want their work to become more abstract, and that is a valid preference.

It also makes me think about why some companies create multiple growth archetypes for engineers. A company like Meta having a "coding machine" archetype makes sense to me. It acknowledges that engineers can create value in different ways, and that growth should not require everyone to become the same kind of leader.

I think there will always be a Venn diagram between:

• What I like to do
• What my team needs
• What the company needs

The hard part is not making that tension disappear. The hard part is being honest about which circle you're optimizing for at any given moment.

If you're spending most of your time on work you enjoy, that's fine, but it might not move you toward the role you say you want.

If you're spending most of your time on what the company needs, that might accelerate growth, but it can also move you away from the kind of day-to-day work you actually enjoy.

The key, at least for me, is to go into those trade-offs with eyes wide open.

Careers tend to reward intention more than hope. It's better to be deliberate about the work you're choosing, the work you're holding on to, and the work you're ready to let go of.

That's the part I'm trying to practice now: not just doing the work I can do, but making room for the work I should be doing next.

Your turn!

Have you ever held on to work longer than you should have because it felt tied to your identity? Or have you had to let go of a part of your role to grow into the next one? Let me know by replying to this email.

Happy coding!