It is twenty past one on a Sunday morning and I am finishing a synchronisation task that is not mine. It was assigned three weeks ago, it is on the board for Monday's demo, and it is about seventy percent done. I will have it working by three, I will merge it myself, and on Monday the demo will go fine and nobody will mention it.

That was the second time that month. I am twenty-three, I have been leading a small automation team for the better part of a year, and I have convinced myself that this is what commitment looks like from the front.

The mistake was not the weekend. The weekend was a symptom. The mistake was the theory behind it, which I had never said out loud, and which was wrong in a way that took me a year to see.

The theory I actually held

If you had asked me what motivates engineers, I would have given you a reasonable-sounding answer about interesting problems and autonomy. But the theory I was running was simpler than that, and it went like this: the lead cares the most, works the hardest, and talks about the product with real enthusiasm — and the team catches it.

Nobody taught me that. I inferred it from myself. I had been motivated exactly that way as an engineer: put me next to a hard problem and someone visibly excited about it and I would work through a Saturday for the pleasure of it. So I generalised from a sample of one, and my management technique, stated honestly, was: be the most committed person in the room and wait.

For about three weeks at a time, it looks like it is working.

What the team actually did

Then it stops working, and the version of events I told myself was that the team was not committed.

It was not true, or it was true in the uninteresting sense that people who are not engaged do not stay late. Nobody on that team was lazy. What was actually happening had a mechanism, and the mechanism was me.

A task is at seventy percent on Thursday. The demo is Monday. I take it. The demo goes fine. The following sprint, the same task shape comes around, and it is at sixty percent on Thursday — because last time, at seventy percent on Thursday, nothing happened. Nothing bad, and nothing good. The date arrived and was met by someone else.

I had made myself the buffer between the team and every consequence of missing a date. A commitment that somebody else absorbs is not a commitment. It is a suggestion.

The code I wrote at one in the morning

Here is roughly the shape of what I wrote that Sunday. It reconciles the state of provisioned deployments in one product with the workflow layer in the other, by reading changes since a watermark and publishing them onto an exchange.

# 01:20 on a Sunday, in the demo branch by 03:00, and mine forever.
foreach ($item in Get-VraResource -Type 'Deployment' -Since $watermark) {
    $payload = @{
        id    = $item.id
        state = $item.state
        at    = (Get-Date).ToString('o')
    }

    Publish-AmqpMessage -Exchange 'sync.deployments' `
        -RoutingKey "deployment.$($item.state.ToLower())" `
        -Body ($payload | ConvertTo-Json -Compress)

    # Advanced per item, so a mid-loop failure re-publishes everything after
    # the last success. Found that out in March, in production, on a Tuesday.
    Set-Watermark -Name 'vra-deployments' -Value $item.updatedAt
}

There are three things wrong with that loop and only one of them is the watermark. The second is that it had no test and no note explaining the ordering assumption, because it was written at one in the morning by someone who was going to remember. The third is the one that mattered: it belonged to an engineer who was now further behind than when the sprint started, and who had learned nothing from the hardest two hours in it.

I did that, in small pieces, for a year.

What it cost, itemised

Nobody else grew, and the bus factor was one. I did not set out to hoard the interesting work. I hoarded it anyway, because the parts that were late on a Thursday were always the hard parts. By the end of the year the ownership table looked like this, and I had written it one late night at a time:

component                        primary owner   others who had touched it
AMQP sync between the two tiers  me              nobody
request lifecycle extensions     me              one person, once
SOAP integration to billing      me              nobody
the migration runbook            me              nobody
scheduled reporting              engineer 3      me

Read the right-hand column as a list of the conversations I never had.

Everyone above me got a false reading. The team hit its dates. So there was no case for more people, no case for cutting scope, and no reason for anyone to look closely at how the automation work was staffed. The picture of my team that existed one level up was assembled partly out of my Saturdays, and I was the only person who knew that. When I eventually did raise it, I had a year of evidence that the team could do this, and I had produced all of it myself.

I stopped doing my own job. This is the expensive one and it took me longest to see. What I was there to do was collect the client's use cases, work out which manual steps could be automated and in what order, define the procedure the tool would follow, and clear the blockers in front of four other people. That work has no visible deadline. It is the first thing that gets compressed. When I spent Thursday night finishing someone's task, the requirements for the next phase got written in forty minutes on Friday morning, and two of them were wrong, and being wrong about requirements costs more than any task on that board.

The most expensive thing I did was not the extra work. It was the work I quietly stopped doing in order to do the extra work.

The conversations I had not had

I never asked any of them what they wanted. That sentence is the whole post, really. I assumed my motivations were the general case, and so there was nothing to ask about.

What I found out later, in three separate conversations that I should have had in the first month:

One of them wanted to be in the room with the client — designing the migration, arguing about what the sequence should be — and not scripting the result of a decision someone else had made. One of them was tired of PowerShell glue and wanted to be on the Node and Angular side of the internal tool, which is the part I found least interesting and had therefore treated as a reward rather than as somebody's career. One of them had spent three weeks on something that was never demoed and never mentioned again, and had drawn the obvious conclusion about whether it mattered.

Not one of those three is improved by watching me work a weekend. Two of them are made actively worse by it, because the work I was taking was the work they wanted.

The part that is genuinely embarrassing

I was finishing a master's in IT project management at the time. I could draw you a responsibility matrix. If I had drawn one for my own team, honestly, I would have been accountable for everything and responsible for most of it, and that is not a matrix, it is a diagnosis. I had the vocabulary for my own failure and never applied it to the thing in front of me, because the theory felt like management and my weekends felt like character.

What I am changing

I am three weeks into this, so treat it as intent rather than as results.

Let things be late, visibly. This is much harder than it sounds and it is the whole of it. A date that slips with a reason attached is information everybody can act on — the client, the people above me, the person who missed it. A date I rescued at three in the morning is a rumour. Last week a task shipped four days late for the first time and the Monday conversation was uncomfortable and more useful than anything I did last year.

Hand over the hardest piece, not the safest one. I used to delegate what I was confident would go fine. The sync bridge now has a second owner who is finding out how bad the watermark logic is, which is a better use of my knowledge than the knowledge being mine.

Ask, roughly monthly, what each of them wants to be doing in six months. Then actually route work that way where I can. This costs me nothing and I cannot explain why it took me a year.

Do my own job first. Requirements, the plan, the blockers. When I unblock someone now I write down what the blocker was, because half of them repeat and the note is worth more than my being available.

The sentence I would have needed

I do not know yet whether the four things above work. I know what the other thing did.

I was not a committed lead with an uncommitted team. I was a lead who had made commitment unnecessary, one Sunday at a time, and then read the result as a fact about other people. Being twenty-three is not the reason. The reason is that I mistook my own motivation for a management strategy, and my own effort for the thing that produces effort in other people. It does not. Mostly it just produces a lead who is tired and a team that has learned the deadline is not real.