Leadership Philosophy (Part 1)

I've been a tech lead for several years now, and I'm often asked (at interviews or general discussions) about my leadership philosophy. The running joke in places I've worked has always been that I run a tight ship - but this while true, can often be misleading.

It's true - my software projects have always met deadlines and always had some of the lowest bug per release rates of the places I've worked at. Some may jump to the conclusion that do this my dictacting the every move of my development team, which couldn't be further from the truth. Far from it, all the developers that have worked on my systems will readily tell you that they have enjoyed more individual freedom working under me than they did most anyone else.

How do I achieve this? Simple I focus on and create an extreme culture of accountability around the what, not the how. What I want is simple: robust maintainable software that conforms to spec (functional and performant) delivered on time. How individual developers achieve this is their concern, and while as lead I'm always willing to suggest ways to improve on quality and speed of an individual developer (hello vim..haha) I'm certainly not overly (or much at all) concerned with individual preferences. Focussing on HOW they deliver their code is micromanaging. Yes it is. Insisting on pair programming? Micromanaging. Insisting on TDD? Micromanaging. The worst thing about micromanaging (apart from the fact that everybody fucking hates it) is the fact that time spent focussing on the unimportant (the how) is time spent not policing and focussing on the important (what is actually being produced).

Look TDD is awesome  - I find it is especially useful in making me focus on requirements and not code when writing tests which is pivotal when writing quality tests. However, if a developer is giving me quality code with well written tests without using TDD, why on earth would I force them to use TDD?

It's important to differentiate things that constitute individual working styles/process and separate that from (and focus on) the work they produce. Try as little as possible NOT to dictate personal process - it's not just that it's not helpful, it's often counterproductive.

Now if a specific developer is failing to meet clearly defined team standards e.g unacceptable number of bugs introduced by said individual, failing to meet deadlines, failure to write proper tests, code not meeting specs (all things that you should be religiously tracking on your team) - Then and ONLY then should you sit down with said developer and go over their process insisting on changes that you feel would result in better software.