frontend

Lessons From Coaching: Getting Tech Teams to Play as a Unit

Thoughts from the intersection of code, craft, people, and progress.

Managing devs isn’t that different from managing footballers.

A collection of talented individuals does not automatically become an effective team, in sport or software. People need clear roles, useful feedback and enough trust to say when something is not working before it appears on the scoreboard.

The useful question behind “Lessons From Coaching: Getting Tech Teams to Play as a Unit” is what changes in the work afterwards. A sound idea should improve a real decision, not only give us a neat phrase for describing it.

What makes this interesting is not the fashionable part. It is the effect on the person doing the work after the initial excitement has worn off.

Make the work easier to do well

The leadership part is rarely the grand speech. It is the ordinary environment around the work: whether people can ask an awkward question, whether priorities stay still long enough to act on them, and whether useful effort is noticed.

My practical test is simple: after a conversation, does the other person have more clarity and more agency? Good leadership should not make the leader look essential. It should help the team make sound decisions without waiting for permission at every turn.

Leadership is not having every answer. It is making better answers possible.

Trust is built in small, repeatable moments. Say what matters, make space for challenge, and follow through when somebody takes the risk of being honest.

I do not always manage it perfectly. The aim is to make the better choice easier to recognise the next time it appears.