I have never led a team I owned. Eight engagements since 2018, most of them teams of five to twenty people who were already working together before I turned up and who carried on after I left. Nobody reports to me. I cannot reassign anyone, I do not run their reviews, and I have no say in what happens to them next quarter.
That is the normal condition of contract work, and it changes what leadership has to mean. Everything I might want to influence has to be earned in weeks, from outside, by someone the team has no obligation to listen to.
Credibility is the only currency you arrive with
A permanent lead can be wrong for a while and still be the lead. I cannot. The first architectural opinion I offer at a new client is also the audition for every one after it, so being genuinely useful in the deep end is not a nice-to-have. Architecture, reliability, trade-offs, debugging under pressure: that is where an outsider earns the right to be listened to on anything else.
It also sets a limit worth respecting. Turning up and rewriting somebody's conventions in week one is not leadership, it is vandalism with good intentions. Their patterns usually exist for a reason, even when the reason is old.
Adapting to a team's rituals is not a compromise
I join whatever rhythm the team already has rather than importing my own. Partly that is manners. Mostly it is that a team's ceremonies encode a lot of what it has already learned, and an outsider changing them early is guessing.
So I onboard by asking far more questions than feels comfortable, which needs somebody with context available to answer them. That is the one thing I ask for on day one, and the engagements where I got it were consistently the ones where I was useful fastest.
Disagreeing without authority
I cannot end an argument by outranking anyone, which turns out to be a good constraint. What I can do is make the trade-off explicit, say plainly which option I would take and why, and then let the person who owns that call make it. Product scope goes to the product owner. Technical direction goes to whoever holds technical responsibility. Then we commit and move on.
The commit half is where contractors quietly fail. When a decision goes against you, the temptation is a half-effort implementation that leaves the argument visible in the code, so that when it goes wrong everyone can see who was right. That is not disagreement, it is sabotage on a delay. If I build it, I build it properly, including the version I argued against.
Ownership when you are the outsider
When something slips or breaks, the easiest move is to find a culprit, and the fact that I am leaving in a few months makes it easier still. The more useful question is what I could have prevented: what I did not clarify, what risk I skipped past, what I assumed everyone already knew because it was obvious to me.
That matters more in the sectors I work in. In government and healthcare, the expensive failure is not a bug, it is a problem nobody wanted to raise until it was too late to fix cheaply. A team that hides mistakes from the contractor is a team where the contractor made hiding them the sensible option.
The bar does not move
High standards on testing, observability, security and maintainability are not separable from caring about the people who inherit the code. I will not be there when it breaks at two in the morning; someone else will. Softening a standard to avoid a difficult conversation just moves the cost onto them, after I have gone.
So the bar stays. How I hold people to it, as a guest in their team, is the part I am still working on.