Staff engineers shift from solving problems to shaping systems

Estimated reading time: 5 minutes

Key takeaways:

• Find the research gap between the problem everyone’s discussing and the problem actually worth solving.
• The right solution is rarely the smallest change.
• For staff engineers, the highest-leverage work makes you unnecessary, not indispensable.

---

About six months after joining Monzo, I gave a technical presentation. It was on BigQuery optimization: making queries faster, cheaper, and more efficient. It was useful work, and the improvements are still in place today. Afterwards, over a drink, one of our directors asked me a simple question.

“How do you think that went?”

If I’m honest, I wasn’t excited by it. Not because the work wasn’t good, but because the talk didn’t feel like me.

As we chatted, he asked about my background. Before technology I was a classically trained musician, then I completed a Master’s and PhD before moving into industry. What struck me was that none of the skills that had defined those parts of my career had shown up in the presentation.

I’d become very good at solving technical problems. What I’d stopped doing was questioning whether they were the right problems in the first place.

Looking back, I think this is one of the least talked about transitions in an engineering career. Early on, you’re rewarded for writing better code, building better systems, and finding better solutions.

As you become more senior, your impact comes from something different: seeing systems clearly enough to identify the problems nobody else has articulated yet.

Over the last few years I’ve tried to make that way of thinking more deliberate. Through conversations with staff engineers, principals, and engineering leaders, and by reflecting on projects that had the biggest organizational impact, I found myself coming back to the same four moves.

1. Find the research gap

One project started with a deceptively simple question: how much time do we actually spend handling a customer’s problem?

Everyone had an answer. None of them agreed.

Different reports produced different numbers, teams debated whose definition was “correct,” and every unexpected result triggered another investigation. The obvious conclusion was that we needed a better metric.

However, after talking to engineering, product, and operations, it became clear that the metric wasn’t the real problem. We weren’t actually measuring customer handling time at all. We were measuring a collection of proxies and heuristics that attempted to infer it. That distinction changed everything.

The visible problem was an inaccurate metric. The underlying issue was that the system had no reliable way to know the thing we were trying to measure.

I’ve started thinking of these moments as research gaps: the difference between the problem everyone is discussing and the problem that’s actually worth solving.

The simplest questions often uncover them:

• What are we really measuring?
• Why does the system work like this?
• What assumption have we stopped questioning?

2. Have conviction about the right solution

Once we understood the real problem, there were plenty of incremental fixes available.

We could improve the heuristics. Add more rules. Tune the existing models. Instead we asked a different question.

Why are we trying to reconstruct the truth afterwards?

If handling time genuinely mattered to forecasting, planning, and operational decisions, shouldn’t it be something the system knew directly? That completely reframed the project.

Rather than building a better calculation, we redesigned the underlying system so it generated the information at source. The metric became a property of the platform instead of something inferred later in the data warehouse.

The technical solution was more ambitious. It also solved the actual problem.

I’ve found this pattern appears surprisingly often. If you’re repeatedly reconstructing reality after the fact, it may be worth asking whether the thing you care about should exist inside the product itself. The right solution is rarely the smallest change.

3. Design for belief, not just correctness

Having the right answer doesn’t mean anyone will use it.

Some of the most valuable work on that project wasn’t technical. It was architectural reviews, discussions with product teams, prototypes, validation, and deliberately inviting people to challenge the proposal.

Slowly, something changed. It stopped being my idea. It became our direction.

I’ve come to think of alignment as another design problem. Every stakeholder sees the system through a different lens, and good technical leadership is often about connecting those perspectives rather than persuading people your solution is correct.

The goal isn’t winning an argument. It’s creating enough shared understanding that people begin advocating for the idea when you’re no longer in the room.

4. Make yourself unnecessary

The biggest lesson came after the project was delivered. Initially, success looked like building the new system. Eventually, success became something else entirely.

Other teams started asking the same questions on unrelated projects”

• What are we actually measuring?
• Where should the source of truth live?
• Why are we inferring this instead of generating it?

The approach had spread further than the implementation. That’s when I realized the real product wasn’t the metric. It was a different way of thinking.

One of my favorite quotes at Monzo is: “The best mentor I ever had didn’t even know I was their mentee.”

People don’t just copy your solutions. They copy how you approach ambiguity, how you respond to challenges, and the questions you choose to ask.

The highest leverage work isn’t making yourself indispensable. It’s creating systems, and people, that continue improving without you.

The shift that matters

For a long time I thought creativity and engineering were different skills. I don’t anymore.

As a musician, I learned to look for patterns, structure, and variation. During my PhD I learned to form hypotheses and question assumptions. Those turned out to be exactly the skills I needed most as my engineering career progressed.

The transition wasn’t from technical to non-technical work but rather from solving problems to shaping systems.

Technical excellence will always matter, but the engineers who create the biggest organizational impact aren’t simply the best problem solvers.

They’re the people who notice that everyone has been solving the wrong problem. That’s the playbook I’ve found myself returning to:

• Find the research gap.
• Have conviction about the right solution.
• Design for belief, not just correctness.
• Build something that continues to create value without you.

If your impact depends on you being there, it probably won’t scale.