I’ve created teams from scratch and been brought in or promoted to lead existing teams. I’ve made a few mistakes, especially when starting, and I hope sharing them with you will help you to help your team faster.
When I started out, I often started a new team with a quick speech. And in that speech I made the mistake of assuming all responsibility for the failure of the team.
I thought I was a softening the risk and encouraging them to try new things, but it had the opposite effect. I was actually taking away responsibility. It limited everyone’s investment because in being responsible for failure, I also became responsible for success. So folk were afraid to try new things and some had to be cajoled and re-motivated.
Now I try and make sure everyone recognises it’s a team effort, and whilst I have responsibilities in addition to the rest of the team, we are all responsible for success or failure, and we all have a voice in ensuring that.
If you’re a leader, be Opinionated, show a strong direction. And initially it doesn’t even have to be strategic. After all, you won’t know the domain on your first day.
So be opinionated about what you want most from the team. Make green builds a mantra, and dress up as a dinosaur to enforce it if you have to. Make everyone care about code consistency. Make everyone care about the quality of each other’s code.
And give them space for improvement.
And then provide as clear a path as you can. Requirements and strategy are always muddy and subject to change, so find waypoints and keep the team focused on them, knowing that you’re working on what the next waypoints are, and are available to anyone who asks.
Be a team player
Never ask your team to do something you wouldn’t do. If they have to stay in late, try to be there. If you want them talking to other teams, and visiting other countries, be with them to introduce them, and bootstrap those relationships.
Every team, every architecture, and every sprint needs a structure. A scaffold to support the work. Understand what those structures are and align them where you can. After all, the structure of a team is reflected in the structure of the code.
Make sure everyone understands the structures and why they exist the way they do. Understanding the justification means they have a context to suggest improvement, and hopefully won’t retread old ground unless the context changes.
Teams thrive or fail in their social interaction. As a lead, your job is to ensure the social and personal wellbeing of the team so they are as effective as they can be.
You don’t have to get drunk every night, but regular social pulses, whether a team lunch or a morning together away from the office, help to reset everyone’s view of each other and understand some of what’s going on under the surface that helps everyone relate to each other, even the shy, quiet one.