Technical Leadership: A Task Has an Assignee. The Commitment Belongs to the Team.

Ammar Najjar · Posted on October 31, 2026 · 4 min readleadership

AI-generated image

I recently saw two pieces of work sit untouched for almost two weeks even though both had clear deadlines.

Nothing unusual had happened to the work itself. The requirements had not changed, no external dependency was blocking progress, and the team had enough information to start. The developer most closely associated with the work was simply unavailable for part of that time.

At first, this looked like a capacity problem. Someone was absent, so the work slipped. But the longer I thought about it, the more the absence seemed to expose something else. My reading was that we had treated the commitment as if it could only move with the person assigned to the work.

Seeing the Problem Is Not Enough

This is easy to miss because most of the time the model works. A story is assigned, the developer works on it, and the team sees progress. The weakness appears only when something interrupts the expected path: sickness, competing production work, an underestimated task, or a dependency that suddenly takes longer than planned.

I now separate two things that used to blur together. The first is implementation ownership, which the assignee holds: understanding the problem deeply, moving the work forward, and making the day-to-day decisions. The second is team awareness: noticing when important work is no longer progressing toward its deadline. That awareness matters, but if it belongs abstractly to everyone, nobody may feel responsible for turning it into a decision.

A Shared Point of Reassessment

A third responsibility appears when the current delivery plan stops being viable: someone needs to make sure that awareness turns into a decision.

I have started to treat a risk to a deadline as a shared trigger for reassessing the delivery plan. When time-sensitive work stops moving, the team should reconsider whether the current delivery plan is still credible. That is the same move I described for treating a late constraint as a test of the decision: new information arrives, and instead of letting momentum decide, the team checks it against the criteria that produced the current plan. Here the criterion is simply time, and the reassessment belongs in the normal flow of planning and daily coordination, especially when the original owner cannot continue.

AI-generated image

The useful signal is not that someone is absent. It is that the team can see important work approaching a deadline without anyone deciding whether the delivery plan needs to change. The gap appears when everyone can see the risk, but nobody owns the decision about what to do with it.

Waiting Should Be a Decision

The response does not always have to be reassignment. Moving work between developers has costs. Context needs to be rebuilt, unfinished reasoning needs to be transferred, and interrupting another piece of work may create a larger problem. Sometimes waiting is still the right choice.

The team should be able to say: we know this work is paused, we know the deadline, we considered the options, and given the trade-offs we intentionally accept the risk. That is very different from discovering later that everybody assumed the original assignee would eventually return and continue. It is the same move Lencioni makes in The Five Dysfunctions of a Team when he writes that in dysfunctional teams decisions get made and then quietly undermined, postponed, or relitigated: commitment is real only when someone is willing to carry the decision forward, even when it is not the option they preferred.

The Question I Now Ask

A small practice I find useful is to make one question explicit whenever time-sensitive work stops moving:

Who owns the decision about what happens to this work now?

That should be a named person, whether that is the tech lead or someone else the team explicitly assigns for that item. They do not necessarily need to implement the work. It is the same ownership instinct I wrote about before, just applied to a deadline instead of a decision: who should own the context behind a decision. Here the question is narrower. Their responsibility is to make sure the team consciously chooses between waiting, reassigning, reducing scope, moving another commitment, or renegotiating the date before time makes the choice for them. Changes outside the team’s authority need agreement from whoever owns the affected priority or commitment.

When someone on your team becomes unavailable, what mechanism prevents their important work from quietly becoming unavailable too?