When I moved from Monzo to Engine by Starling, I wanted to prove myself quickly. I’d felt the same pressure starting previous jobs: find something useful to do and get on with it.

The difficult part is knowing what’s useful before you understand why things work the way they do. It’s easy to notice a process that seems awkward. It takes longer to find out what happened the last time someone tried to change it.

Ask why it’s there

Reading old documentation, sitting with someone while they work, and asking questions in 1:1s all help. I’d start with the things that seem strange: who depends on this? What problem was it meant to solve? Does that problem still exist?

This is the point of Chesterton’s Fence: understand why something was put there before you remove it. The answer might confirm that it needs changing, but it might also reveal a constraint you hadn’t seen.

Work out what would help

If several people independently mention the same difficulty, that’s a useful place to look. It doesn’t tell you the solution yet, but it gives you something more to go on than your own first impression.

Some changes will be small enough to try early. Others will affect several teams or depend on decisions you don’t yet understand. Separating those helps you find useful work without committing everyone to a larger project too soon.

For a bigger change, write down what you think the problem is, what you’d like to do, and what you’re still unsure about. Share it with the people affected before getting too far into the implementation. It’s much easier for someone to point out a missing constraint at that stage.

I still want to get useful work done early in a new role. Asking enough questions to choose that work well is part of it.