Experiences of a Lead Developer

02 Oct 2010

It has been 3 years and a bit since I started leading software teams and recently I’ve been reflecting on my experiences since then.

I’ve lead 3 teams, all working on core and large products for the companies I’ve worked for. My current and 3rd team is in the midst of a rebirth and in many ways my 4th team.

No team is the same. What worked for one team does not work for the other. Each team has had different approaches to testing, coding standards and work ethics.

What I’d like to reflect upon is what I did, what worked, what didn’t work. I’m very much interested in what other lead devs do for their teams.

What does a lead developer / team lead do ?

I’m not going to define the role here, only to describe what I’ve had to do as a lead dev so far.

Facilitate standups and retrospectives. Watch out for standup smells

Act as a buffer between product ownership/ project management and the team.

Make the call on technical decisions. Have the technical architect hat handy.

Mentor developers. Enforce TDD, refactoring and clean code practices. I say enforce but not encourage. this is because I believe in these so strongly that I’m not willing let my team do anything else.

Build a team that learns not a team that expects me to tell them what to do. Do regular katas and demos of new tools/techniques we can use.  Do code reviews and refactoring exercises as a team, in front of a projector.

Keep the team focused. I’ve done this by having the team not work on anything else other than what our card wall says.

Know the product/ project thoroughly. Learn the quirks, know where everything is. Know the source, read the source to figure out what is going on.

Own the release process, do releases.

Do the grunt work. As a lead dev, I’ve spent an great deal of time on build and deployment scripts. Setting up source control and continuous integration with Teamcity

Staying out of the way. Leave  the majority of the work to the team. I expect to be pulled into meetings, asked to answer questions and deal with issues outside of the team. Part of this is good, as this takes away distractions from the rest of the team, but this also means that I can’t work on something continuously and see it to the end most of the time.  Let someone else in the team own the work.

Be there for the team, be prepared to answer questions all the time. This could be design decisions, having to explain the domain, or the history of why something was done in a certain way. This can be exhausting but it is necessary. 

Listen to the team chatter. Ask what is going on, when there is a discussion around code or a problem. Listen, observe and break into the conversation if needed.

Know the strengths and weaknesses of each team member. Know what they can do and what they cant do. Manage pair programming, some pairs may not be productive. This is necessary in the early stages of a team, but there will always be differences in skill levels.

What works.

I’ve covered a few of these above, but these the short list below is what I think every team needs.

Fostering a learning culture. The best teams I’ve had learned together and taught each other.

Strong discipline in the team.  Stick to what we’ve agreed as a team.

Having a programming god on the team. An expert, for example who knows NHibernate, MVC or can write a book on TDD, help with technical decisions, and tell you what you are doing is wrong. Someone who can go away and figure out the hard things and come back and present to the team.

Automate automate automate.

Have people with passion for what they do. Encourage this.

What doesn’t work.

Team members with an aversion to pair programming and sharing. No rock stars or heroes. Notice this early, don’t ignore it. This will fester and kill team morale.

Fear of code, and fear of breaking things. People shouldn’t be afraid to make mistakes. Mistakes are ok, we learn by breaking things. Give team members the power and confidence to change things.

Indiscipline. Nip it in the bud. Tell people when they are not following the rules and agreed practices. This is something I’ve learned the hard way.

Self organization without direction. Self organization needs a goal. A team suffers when they don’t have know what they are working towards.

Team democracy is not always good, a benevolent dictatorship works much better.

It’s the team, not the project.

An important lesson I’ve learnt is that, what matters is not the software we produce, it is what the team learns while writing all that code. The code we write is an expression of what we learn, and every new line of code is a new learning opportunity.

A good project, with quality code and a few bugs in production is a side effect of a good team, and this team is the most important asset a company has, and not the software that was produced.