I left Guild recently and moved to Cedar, a fintech, as a Staff Engineer. Going through the process of onboarding as a Staff Engineer marks my second Staff+ role. And as I've gotten up to speed, a few insights have popped up and solidified. Joining a new company is always a good time to re-evaluate and consider conclusions you made and see how they stack up against other parts of the world. And this is no different. It's especially interesting as this is the first time in my career where I'm joining a new company as a Staff+ engineering. So I wanted to put together some quick thoughts.

1. Staff Engineering is about taking up space

It's not a nice to have. It is in fact the literal job. Making yourself smaller to support others will only work so much. Not just as a matter of exerting power, but as an ability for you to actually help other people as well. Part of what people are paying you for is your ability to demand other people's attention to and to spend it well.

I made the mistake of assuming the best way to be an "equitable" staff engineer was to be as respectful of everyone else's time and decision making as possible. This often meant getting pushed out of conversations, framing opinions too weakly to get picked up, and not maximizing my impact. While I still think it's important to listen and engage other people's voices, having an opinion and making decisions about how they company (and teams) operate are important parts of the role.

2. Making lots of incremental progress is more valuable than making a bit of huge progress

This is a counterintuitive one, but given the timescales (and AI), I think it makes way more sense. At bigger companies narrative (both at the internal and external level) become way more important. Incremental progress is narrative building because it sends a message that "we're doing lots of things!" Delivering one thing particularly well, especially at firms with lots going on has diminishing returns and might even be counterproductive.

I initially thought that taking a single project through to the end was important. It's certainly how I operated at Guild. However, after seeing the results there, and getting a chance to see how Staff+ engineers operate at Cedar, I'm seeing now that leaving tendrils for other people to pick up is an excellent way to spread influence, guide the company in positive directions, and make a positive impact. While finishing a thing is incredibly satisfying, having multiple irons in the fire is probably the best way to operate at a bigger firm.

Being a Staff Engineer is about breadth as much as depth. That means starting the tendrils for 4 different things that get picked up and carried forward is actually much more valuable than diving on one thing deeply (unless that one thing can unblock or unlock a lot of people). This is a hard skill to learn especially as a software engineering when finishing things feels so important.

3. Your value directly relates to how well you further and cut against "The Big Narrative" — and the expectation is that you do both

I think this is part of the agreement that a lot of Staffs (especially ones who are exceptionally strong engineers) struggle the most with. I know I have at various points, and I'm not the strongest engineer. You both have to have an opinion about "the big thing" and also a critique of that thing that will subtly move the org forward while still reinforcing it. Right now that's AI, but it could also be a big migration, an opinion about serverless, or a belief about org structure. I've noticed a lot of people try to divide this into two camps, either fully agreeing/assimilating or fully disagreeing. I don't think this is the case. Especially with the role of the Staff, the goal is to both further the primary narrative (set by leadership) and also to influence it positively. It's impossible to do both unless you have agreeing and conflicting positions.

The nuance is that conflicting positions need to be tailored to the correct goal. Completely disagreeing with the direction is about as useful as completely agreeing (with the added friction of being completely unfun). The challenge is to be able to hold both of these thoughts simultaneously. AI has certainly been the case with this. Being "anti-AI" (I'm honestly not sure what that means in the context of engineering) isn't useful anymore, but you also don't have to be a primary cheerleader to make an impact. Finding the best way to be informed, engaged, and figuring out how to critique and shape strategy is also incredibly useful.

4. Ergonomics are the Heart of All of This

The biggest challenge I've had as a Staff (or Staff+) engineer is thinking about ergonomics in the context of getting things done. Even though I truly love UX it's hard for me to get in the mindset of making things easier for other developers. Often I'm completely focused on the problem in front and thinking about a slight tweak that would make life more efficient for other developers.

It's the "Staff" part of Staff engineering and it's a skill I'm still in the process of building. Because you're leading with influence, making something "good" is often not a useful barometer for how well it gets picked up. The ergonomics (how easy it is to hit the ground running) will often determine if a tendril gets picked up by another developer and carried forward.

5. AI Complicates All of This

AI trades coherence for speed. LLMs trade coherence for speed. Which is, incredibly interesting. It's a fact that enables a great many things, regardless of what you think about it. And it draws to question how much coherence is important when it comes to certain areas of product management and software engineering. From a writing perspective, where the point of writing is coherence, that tradeoff is poor. Writing something incoherent has minimal value.

From an engineering perspective, if you can make that tradeoff in ways where you can increase cycles with direct goals to improve coherence (or at least enforce it), that tradeoff can be incredibly beneficial. But, ironically, one of the primary goals of Staff Engineering is coherence at the org level, which means that being a staff gets much harder with all of these tools, because you have many more actions going out in many more different directions that you have to make decisions about how to pick up or drop. And those actions are getting less coherent.

Silicon Valley, and software startups generally, have always prized speed over coherence, but there were reasonable limits on those tradeoffs (the humans who had to produce the code and the complexity of the state machines which could auto generate it). But that's mostly disappeared, and we're currently in the process of figuring out what if any hard limits there are. In a practical sense that makes picking what threads to carry forward, and how to influence people on those threads much harder.