Interim tech leads have a weird job. You’re supposed to lead, but you’re also temporary. You have authority, but you’re an outsider. The team knows you’ll leave, and that changes everything.
Here’s what actually works.
First week: listen more than you talk
You don’t know why things are the way they are. That architectural decision that looks insane? There’s probably a reason — a deadline, a constraint, a team member who left. Before you change anything, understand the history.
Ask questions like “what’s the biggest thing slowing you down?” rather than “why are you doing it this way?” One builds trust, the other puts people on the defensive.
The decision log is your best friend
Teams get stuck when nobody decides. Interim leads often get hired precisely because decisions aren’t happening — whether that’s conflict avoidance, unclear ownership, or a vacuum from someone leaving.
Start a decision log. Dead simple: date, decision, rationale. Put it somewhere visible. Update it publicly. This does three things:
- Forces decisions to actually happen
- Prevents the same debates from recurring
- Helps whoever replaces you understand why things are the way they are
The log isn’t bureaucracy — it’s the main artifact you’ll leave behind.
Prefer reversible over perfect
As an interim, you shouldn’t be making big architectural bets. You won’t be around to see them through, and the team will be stuck with your choices.
Instead: feature flags, staged rollouts, abstractions that can be swapped later. If you must make a big call, document the hell out of it and make sure someone permanent owns the follow-through.
Watch for decision debt
Some teams have a backlog of decisions nobody wants to make. Should we migrate to the new API? Do we support that legacy client? Who owns the flaky test suite?
These aren’t technical problems — they’re ownership problems. Your job isn’t to make all these calls, but to make sure someone does. Often that means putting a name and a date next to an open question.
Keep the metrics simple
You don’t need a dashboard. You need to know:
- Are we shipping? (lead time)
- Is what we ship stable? (change failure rate)
- Are we drowning in support? (incident load)
If these are getting worse, dig in. If they’re stable or improving, don’t add process just to look busy.
The embedded program problem
If you’re leading firmware or embedded work, you’re dealing with two timelines: hardware and software. They rarely align.
The trick is planning software work that can progress independently — dev boards, simulators, test harnesses. When the PCB slips (it will slip), the firmware team shouldn’t be blocked. Track hardware lead times and have alternates for critical components. A sensor that goes end-of-life three months in will ruin your schedule if you don’t have a backup.
When you leave
A good interim makes themselves unnecessary. That means:
- The decision log is up to date
- Someone permanent owns ongoing decisions
- The team isn’t dependent on you being in every meeting
The worst outcome is leaving a team that can’t function without you. If you did your job right, they’ll barely notice you’re gone.
XIThing does interim technical leadership for IoT, energy, and cloud teams. Get in touch if your delivery is stuck.
