Dan Fox bio photo

Dan Fox

Software developer interested in learning New Things and applying them in Real Life

Someone asked me recently what it is tat makes a good software team leader.  It’s  a really good question - I meet a lot of developers who might be architecturally brilliant, and can design the cleanest most maintainable code without breaking sweat.  Or they might have a particular knack for working with users - teasing those ever-elusive requirements out of their mind, understanding what they want to achieve with the software and transforming that into a set of requirements or tasks that a team of developers can work against.

Yet neither of these are an indication that the person in question will be a successful team leader.

Ultimately a team leader will be judged on whether they successfully delivered a project… was it on time?  On budget?  Bug-free? Maintainable?  Future-proof?  These are all contributors to what we mean by successful.

However this definition of a good team leader is easy in hindsight, but not so good during the development stage.  There is one particular skill that I look for in team leaders that I view as imperative for helping their team deliver software, and ultimately successful projects:

  1. A good team leader is not afraid of making decisions

  2. A great team leader makes good decisions

  3. The** best** team leaders make good decisions** when they need to be made**

Making a decision is difficult in software.  The impact of a wrong decision could have short or long term implications, financial or architectural.  But it’s very important that a team leader is capable of making decisions - decisions have to be made, one way or another.  It’s important too that the decisions are good ones!  Someone who consistently makes bad decisions isn’t going to be successful in the long term.

But the best have a special skill… delaying a decision so tat it is made precisely when it needs to be made.  There is no point in choosing a technology before evaluating the options… or choosing a technology just to do nothing with it for six months.  So as long as development isn’t impacted, why not wait before you make that decision?  Oh, and make it a good decision!