A lead shouldn’t lead like lead.

I’ve been thinking a lot about what I’m going to do with my new role at CCP.  Most of these I’ve been able to do (or advocate strongly for) to some degree even as a non-Lead but they were never supported enough by the Leads and never took hold.

1. Training sessions.  These are vital for the health of the team in so many ways.  It exposes people to new ideas, stimulates discussion, and gets people thinking about things differently.  It also gets them contributing to the social aspect of the ‘team’ rather than just contributing files into a codebase.
2. Collective vision and self-tasking.  I was always most frustrated when I didn’t have a say in what I was working on.  True scrumming alleviates this, but even without scrum, team members need to decide what the team is going to be working on as a whole and what they are going to take on in particular.
3. Changing concepts/standards/practices.  Consistency in a codebase is great, but keeping a team motivated and passionate is more important, and will result in better code overall.  I think the current concepts/standards/practices should be consistent, but they need to change over time.  Developers change, and new ones join, and they have different opinions and better ideas.  You shouldn’t frustrate them by stifling superior ideas for the sake of consistency or resistance to change.
4. Community engagement.  I don’t think you can be an excellent developer in this day and age unless you are part of the coding community- force everyone to have a Stack Overflow account and come up with a blog bundle for the team.  And then have a ‘reading group’ every week or two to cover interesting concepts.
5. Move people around.  Never have your entire team sitting together permanently, and never embed a team member with a team permanently.  4-6 months at a time, and switch things up.  Expose your tool devs and TA’s to different groups, to get more context and develop more relationships, and then move them ‘back home’ to refine and refresh their skills.
6. Code Katas.  Another team-building exercise that can easily be factored into training sessions.  Also useful to cross-pollinate teams, so programmers from different teams can pair and compete against their buddies.

The key here is: change.  As a lead, you are your teams biggest enemy.  You have the power to grow your teammates and the team, and you have the power to frustrate teammates and stunt growth, more than anyone on the team (you have the most power on the team, and with great power…).  You need to make sure the team doesn’t stagnate, and the way you need to do that is by integrating mechanisms to guide change into your every day interactions.

And in a year, I’ll be able to look back at this post and evaluate how well I executed on what I wanted to do- and if something is ill advised I’ll be able to judge why I didn’t realize it.