Hi, I’m Paula Muldoon – a staff software in multimodal GenAI at Zopa Bank in London.

Review season is over and if you’re like me, you’re having the usual existential crisis opportunity to understand what being a staff engineer is. It’s very clear that AI coding tools are transforming how we build software, so how does this change the role of a staff engineer?

Over the past ~10 years, we’ve come to an industry standard of the essentials of staff engineering. Claude summarises Will Larson and Tanya Reilly’s work as this:

A Staff Engineer is a senior individual contributor who leads through technical influence rather than management. As Will Larson describes, it’s leadership beyond the management track — setting technical direction, shaping strategy, and mentoring others. Tanya Reilly’s foreword reinforces this: the role demands broad organizational impact, not just deep expertise. – Sonnet 4.6

This definition of staff engineering, particularly the organisational impact, made a lot of sense before 2025. Staff engineers need to stop being hands-on with the code as the majority of their work and spend time teaching others, making strategy etc. I was fully on board with this – it’s probably not the best use of my time to spend a week implementing a feature that’s easy for me but a good growth opportunity for someone else, especially when there are more strategic goals to go after.

But if you think about it, org impact is a terrible metric. Do your customers care about your org? No, of course not. They care about whether your product works for them. But because writing code well has been a time sink, we’ve tried to make sure our most expensive engineers have spent time scaling others, because that was the most cost-effective use of their time.

AI software tools have changed that.

I’m not here to convince you of how AI software tools will change the industry. If you’re aware, you know, and if you don’t, go away, download Claude, and start playing with Opus 4.6. You’re going to have so much fun! (Don’t believe me? Listen to Kent Beck.)

That feature that would have taken me a week to build? It’s a day now. Analysing a system and coming up with a design? Minutes. Cost of change? Way lower than it used to be.

2026 is the year staff+ engineers need to get hands-on again.

Here’s why:

You need to recalibrate your tradeoff thinking

One of the things that makes you valuable is your ability to weigh tradeoffs, informed by years of experience of how software gets built. You go into a meeting with product leads and say “This set of features will take six months to build, but we can cut this one feature and have something almost as good in 3 months.” But what took six months in January 2025 takes one month in March 2026. There’s no way you can know that unless you have hands-on experience building with these tools.

Yes, you still need to scale the engineers around you, but they might be scaling you. Everybody is figuring out how to use these new tools and if you don’t figure it out, suddenly you’ll be recommending poor decisions to your org because you don’t understand how the world has changed.

(Side note: I’m continually amazed at how much more quickly we can build things now – not just because of the code generation, but because of the systems analysis. You don’t need a week of technical spiking and research any more to determine feasibility. You give Claude the context of the relevant systems and 20 minutes later you have your answer. I am fully aware that I haven’t gotten used to this speed, and I’m scared of deploying so much software so quickly, and I think I can move faster. That’s my personal challenge.)

You can move faster than anybody else with these tools.

Remember all that time spent as a senior engineer where coding was most of the job? You have deep technical and product expertise. You can use these tools to accelerate yourself to ship fast. Suddenly you spending your time mentoring and coaching other engineers feels a bit like getting a Kentucky Derby winner to coach yearlings instead of running the race. (OK, terrible metaphor since I think racehorses flame out after a couple years but you get the point.) You should be blazing the trail of how to accelerate everybody, and the best way of doing it is to learn it yourself and then to point to results.

Does it mean you don’t coach and mentor? No, but it’s not such a big part of your role for now. And crucially, there are early-career engineers who aren’t hampered by the past, who will be teaching YOU how to use Claude better. Have the humility to learn from them.

Org impact doesn’t matter. Customer impact does.

This is going to be controversial but I propose that we’ve been considering org impact as a proxy for customer impact. We assume that if a staff engineer is having org-wide impact, that translates into significant customer impact – but that’s not a given by any means. Customer impact is the only metric that matters. We’ve gotten very rigid about our definitions of staff engineer impact – ironically, as it’s actually tough to measure. It’s a lot easier to define and measure customer impact so why the hell aren’t we doing that? Org impact then just becomes an implementation detail under the hood. Sure you’ll still want to talk about it, but you shouldn’t be having conversations about how to have more org impact, you should be having conversations about how to have better customer impact, and sometimes that’s through org impact and sometimes it’s not.

This customer impact that you should be held accountable for – it should be big in scope – we’re not talking a few features here, we’re talking entire product suites, with uptime guarantees etc. And customer impact still means strategic thinking but your strategy has to be informed by your hands-on knowledge of the new software engineering landscape.

What about 2027?

I think it’s likely that staff engineering will change again in 2027. At some point the AI tooling will level off and staff engineers will recalibrate and go back to the more strategic/coaching role. I don’t know when that is, and I don’t know when the next big shift will come. But for now, you need to be at the forefront of the new technologies.

(Side note: depending on your company, you may prefer business impact over customer impact. One of the things I love about working for Zopa is that we genuinely do consider customer impact first. And we’re hiring, by the way, so come work with me!)

With thanks to the colleague who has been challenging my thinking on the staff engineer role!