There’s a temptation when you step into a new leadership role to make your mark early: reorganise the team, introduce a new process, and signal that change has arrived. I’ve learned to resist that temptation.
Pace matters in a short-term or interim role, but action without understanding is just noise. It’s the last thing a team in transition needs.
Start with the humans, not the systems
Most technical leaders default to the technology: auditing the architecture, reading the code, or understanding the deployment pipeline. I do that but my first priority is the people. Not “the team” as a collective, but the individuals: what motivates them, what they feel proud of, and what they’d change.
I have one-on-ones with everyone who’ll give me the time. I ask what they wish they were working on, what gets in their way, and what the team is better at than anyone realises. Things that come up in multiple conversations get written down. In my experience, this is the fastest way to understand where the real opportunities are.
Map the real operating model
Every organisation has two operating models: the official one and the actual one.
The official one is documented: ceremonies, structures, processes. The actual one lives in Slack threads, in the engineer who quietly fixes things before they become incidents, or in the understanding between a product manager and a tech lead that eliminates three meetings.
I spend time mapping how work actually gets done because you can’t improve what you don’t understand.
One thing I look for: who do people go to when they’re stuck? That’s a load-bearing person and they’re someone I need to know early.
Understand what “good work” means here
Every team I’ve worked with is trying to do good work; nobody shows up each day to do a bad job. The problem is that the many definitions of “good work” are not symmetrical.
Engineers optimise for technical quality, product optimises for metrics moved and the rest of the business optimises for revenue, cost, and survival. When they’re pulling in different directions without a shared understanding of what value actually means, you end up with people who are busy but not effective.
Early on I pay attention to whether the team can articulate the why behind what they’re building. If an engineer tells me they’re building something “because product asked for it,” that’s a signal that something in the connection between the work and the outcome has broken down. Fixing that makes everything else faster.
What I’m not doing - and why that matters
In my experience, the leaders who cause the most damage in new roles are the ones who move fast on the wrong things. Changes made before you’ve earned trust tend not to stick and they consume the goodwill you need to make the changes that actually matter.
In the first weeks I’m not reorganising the team, introducing a new framework, or telling anyone their architecture is wrong, even when I have a view.
Early on, I need two things: a clear point of view on the highest-value opportunities, and enough trust with people that when I do act, it feels like something we’re doing together.
When 30 days is a luxury
Everything above assumes time. In an interim or fractional engagement the sequence necessarily compresses.
I can’t spend a month in observation mode when there’s a team that needs direction and a set of critical deliverables.
The main difference is that I compress and parallelise. The listening still happens but it happens alongside early decisions, not before them. My first one-on-ones are discovery conversations and the moments where I can start establishing how I work and what I expect.
I also make my decision-making visible early through clear, unambiguous ownership of something that matters - even a small thing.
I still need to understand before I optimise and earn trust before I can lead change. The difference is I have to do it faster, more openly, and while also delivering.
Thinking about how to bring more effective technical leadership into your organisation? Let’s talk. Contact me