A toast to those that do nothing

Published: 05 Mar 25 12:18 UTC

The various roles I've held in my career have largely been technical.

For me, the metric of success has always been whether I can execute some task using some technical knowledge. Across my roles, proficiency has been doing some complex statistical analysis or writing some code that involves working around some constraint(s).

In those roles, delivering value means some technical deliverable, some tangible artefact. I've derived some degree of pride from being able deliver these things.

While that's fine and well, anyone that's worked in an organisation of any meaningful complexity (headcount, reporting lines, diverse capabilities) will realise that most of what gets done isn't driven by technical knowledge or the ability to "do a thing", but instead, non-technical capability.

In particular, the ability to influence and get along with others.

I am confused about delivery leads

In the past, I've always been bemused by roles such as "delivery lead" or "scrum master" or these IT-adjacent roles that seem to not do any actual IT work.

From my limited perspective, these roles seem to pay a lot without having to do any of the code-monkey stuff that takes many years to become remotely good at.

There is definitely some level of resentment at being managed/told what to do by someone that doesn't know what it is I do exactly (or can't do the task themselves).

I usually hand-waved these concerns away as jealousy, thinking that delivery leads are like good managers - if they are doing their job well, you don't really notice it.

While this might have been true in the past, it's only very recently that I've come to experience what an effective delivery lead looks like.

The effective delivery lead

Based on a Google search, a delivery lead

helps guide their team to complete projects successfully and on time.

In the past, I've worked on teams (with a delivery lead) that achieved precisely none of these things across a great many projects.

Is that purely a failure of the delivery lead? Probably not. Complexity exists. It's hard to foresee technical issues or working with other teams that suck.

But if a delivery lead isn't really technical, how can they guide their teams? How can they influence such things if they don't have as good a grasp as the developers who are responsible for delivering the solution?

Hint: it has nothing to do with programming or even managing the team.

Very recently, I've worked with and observed delivery leads who have been able to guide their team to complete projects successfully.

The best tool they have, which is far better than programming chops, is influence.

I've found that people and teams like or owe said delivery lead favours, which they leverage, usually to make things go faster for your own team. Things get unblocked. Work that is "highly critical" but is vague and uncertain suddenly gets put in a backlog for next month.

You might have to do a favour for another team from time to time, but that is certainly better than constantly being crushed (which I have also experienced).

If I'm being churlish, I might argue that a delivery lead should be proactive and teams shouldn't have to ask a delivery lead to do things for them.

But just as developers need clear requirements to deliver a solution, delivery leads also need clear problems to solve, especially if they're spending personal influence that is hard to gain and too easy to spend.

So people that do nothing actually do the most?

Sort of. They help the people that do things, do more things, more quickly.

I'm not sure if this "reactive, in other team's faces" form of delivery lead is best practice. But it's been a lot more effective than other delivery leads I've worked on.

The delivery leads I worked with previously weren't particularly effective. I surmise that since they didn't take this approach, they were less effective.

In their defence, this might have been down to organisational factors out of their control (bad leadership, toxic culture, engrained behaviours). But equally, they might also just have been shit.

Back