Every time I’ve stepped into a senior engineering leadership role (at Nested, at Moonpig where I was promoted to Director, and at Zopa), I’ve had to navigate the same tension. You were hired to make things better, and the organisation expects you to operate independently and solve problems from day one. But you also need to avoid making changes for the sake of making changes.
The skill isn’t patience for its own sake. It’s knowing when you have enough context to act decisively, and when you’re still filling in the picture.
The Listening Tour
In my first two weeks at any new role, I block out as much time as I can for one-on-ones. Not just with my direct reports, but with their direct reports, with product managers, with designers, with stakeholders outside engineering. I’m not looking for answers. I’m looking for patterns.
What do people complain about consistently? Where do they light up with energy? What have they been asking for that nobody’s delivered? The answers to these questions tell you more about the real state of the organisation than any architecture diagram or process document.
At Zopa, my listening tour surfaced something I wouldn’t have spotted from the outside: the engineering teams had strong technical skills but felt disconnected from the commercial outcomes of their work. That insight shaped my entire first-year strategy. I would never have found it by looking at the code.
Earning Trust Before Spending It
Trust is a currency, and you start with very little of it. People are watching to see what kind of leader you’ll be. Will you listen or dictate? Will you follow through or forget? Will you shield the team or throw them under the bus when things go wrong?
The small things matter enormously here. If someone raises a concern in a one-on-one, follow up on it, even if you can’t solve it. If you say you’ll look into something, look into it. These micro-commitments build the foundation for the bigger changes you’ll want to make later.
I’ve learned the hard way that spending trust you haven’t earned leads to resistance that’s almost impossible to overcome. At one point early in my career, I pushed for a process change in my second week. It was the right change; we implemented it six months later and everyone agreed it was an improvement. But pushing it too early created friction that took months to repair.
That said, earning trust doesn’t mean being passive. The organisation hired you at a senior level because they expect you to operate independently, identify problems, and solve them. If something is clearly broken and you can see the fix, waiting three months to act on it doesn’t make you thoughtful. It makes you slow. The distinction is between changing things because you’ve understood the problem and changing things because you want to put your stamp on the place.
What to Actually Do
So if you’re not making sweeping changes, what are you doing? Quite a lot, actually. You’re expected to be useful from week one, not observing from the sidelines until you’ve completed some arbitrary onboarding period.
Understand the delivery rhythm. How does work flow from idea to production? Where are the bottlenecks? You’re building a mental model that will inform every decision you make for the next year.
Map the people. Who are the informal leaders? Who’s frustrated and at risk of leaving? Who’s been overlooked for growth? Your engineering managers will have views on this, but form your own perspective too.
Learn the business. This is the one that catches most technical leaders off guard. You need to understand how the company makes money, what the competitive landscape looks like, and what keeps the CEO up at night. Your credibility as a leader depends on being able to connect engineering work to business outcomes.
Solve problems as you find them. You don’t need permission to be helpful. If a team is blocked on something you can unblock, do it. If a decision has been stuck in limbo because nobody wants to own it, own it. If a process is obviously causing pain and you can see a better approach, propose it. The point isn’t to hold back on everything. It’s to avoid the knee-jerk restructure or the grand strategy deck in week three.
Find quick wins that demonstrate judgement. Not just any visible improvement, but one that shows you’ve been listening and you understand what matters. Fixing a painful deploy process signals something different from rewriting the team charter. Both might be useful, but the first shows you’re paying attention to what slows people down every day.
Being Decisive Without Being Reckless
There’s a version of this advice that says “just listen for 90 days.” I don’t agree with that. You were hired to lead, and leadership means making decisions, not deferring them indefinitely.
The question to ask yourself before acting is simple: am I changing this because I understand the problem, or because it’s different from what I’m used to? If a process is slow because of a genuine bottleneck, fix it. If it’s slow because it’s unfamiliar to you, give it more time.
The things I’d act on quickly: team members who are clearly in the wrong role, a broken incident response process, a critical hire that’s been sitting unapproved for weeks. These are problems where delay has a real cost and where you have enough context to make a good call.
The things I’d wait on: reorganisations, technology strategy shifts, changes to the engineering culture. These require deeper understanding of the current state and carry much higher costs if you get them wrong. I’ve seen leaders come in and immediately restructure around a model that worked at their previous company. It rarely translates cleanly. Every organisation has its own context, constraints, and culture.
What I Wish Someone Had Told Me
Your first 90 days set the tone for everything that follows. The relationships you build, the trust you earn, and the understanding you develop in this period will determine whether your bigger initiatives succeed or stall.
But equally important: you were hired to make a difference, and people are watching to see whether you can. Nobody wants a leader who spends three months “listening” and has nothing to show for it. The organisation expects you to operate independently, to identify problems without being told about them, and to solve them without waiting for permission.
The balance is this: listen carefully, act decisively, and know the difference between a change that needs context and a problem that just needs someone willing to own it.