When you’re a senior-level engineer (i.e., focused on being impactful in a single team), it’s hard to tell how far you are from being Staff+ in impact. Here are a few questions I ask folks around heuristics that can indicate when you’re near or at a Staff+ level. Does it…

From what I’ve seen, Staff+ engineers are usually heavily involved in a team/squad, or are squadless. If you’re newly squadless (and want to stay that way), it can feel really lonely given the drop in close collaboration with peers. Having gone through that adjustment years ago, I wanted to share…

Non-Staff Engineers are typically pulled into a project once an initiative already has-buy in and needs to be technically detailed for execution. Staff+ engineers are often brought in before that. But to answer the question, we should understand the phases of a new initiative and see how our Staff+ archetypes…

As a Staff+ engineer that opens up opportunities for Senior+ engineers to lead, it can be hard to know when to step in (ideally without stepping on toes) versus letting folks fail. I imagine managers, in the context of situational leadership, have the same challenge: knowing when to move someone…

This post assumes you’re working in an environment with heavy use of chat applications. If the majority of your team collaborates in person, this advice is not applicable. Pros: Exposes you to numerous discussions, allowing you to piece together macro context that translates into shipping more correct software and architectural…

A coworker asked me this question and I thought my answer could be helpful to others struggling with the same ambiguity (though biased to the Spotify environment). When you’re leading multi-team projects as more of an architect, is the only way to code to do “snacking” (i.e., low-impact, low-effort work…

I haven’t seen it written about much publicly, but I deeply connect with and often use the Spotify Staff+ engineering archetypes when framing advice. I’ll share my summarized interpretation, since I tend to refer to these archetypes in other posts. Business Partner: (think “product engineer”) an engineer that understands the…

I see a lot of engineers struggle with phrasing their impact in promotion packets. I think the same problem could manifest itself in 1:1 when managing up, but that’s out of scope for this post. Here’s the usual way I’ve coached others to phrase their impact (to great success in…

I have this habit of asking product managers questions about whether or not customers will need a particular feature in the future. Product managers are at the forefront of customer needs; I believe engineers need to see what they see in order to make sure our technical decisions are informed…