What I learnt at the Lead Developer London conference

In June 2018 I attended the Lead Developer conference in London. The conference is aimed at developers who aspire to become leaders or those who already have a leadership role and want to improve their knowledge in this area. I enjoyed the conference and it’s given me a lot of inspiration. Here are my main takeaways/learnings:

The team has the best solutions, the lead helps the team discover those solutions

This was a line from Dan Persa, one of the speakers at the conference. This neatly captures many of the sentiments expressed by the other presenters. Christian McCarrick spoke about the importance of delegation. As a lead you cannot make every decision. Sometimes you must let others come up with a solution. This has the added benefit of boosting skills within the team.

The lead must also keep the path clear for a team to find a solution and deal with any blockers. As Kevin Goldsmith explains sometimes to do this you have to make meetings more collaborative. This can be done through asking people to take on roles as facilitators and observers of meetings. An observer watches out for people interrupting each other and people who speak too much. Of course as the lead you need to make sure you are not dominating these meetings.

Set expectations both in terms of what you expect of others and what they should expect of you

Both Christian McCarrick and Kevin Goldsmith talked about the importance of setting expectations. Christian suggested writing a Manager README where as a lead you describe your communication style, how you approach 1:1s, how you deal with feedback and other things around how you approach management. You would also detail what you expect of the developers who you manage.

Kevin spoke about the importance of setting expectations in your first 1:1 with a developer. These expectations are something you should revisit every six months. He also discussed ways of getting your reports to open up in 1:1s. Sometimes this can involve going for a walk or just not saying anything. Kevin gave an amusing example of one of his reports at Spotify who was very unforthcoming until one day he just sat there in silence. This caused the other person to finally open up and share more freely.

Don’t start blaming when things go wrong

This topic was mostly covered by Nicholas Means when he recounted the story of the nuclear reactor meltdown on Three Mile Island. A number of the power plant’s employees made some bad decisions where if they’d taken the course of action they’d been trained to do, and was specified in the regulations, the meltdown would’ve been avoided. This would seem to be a simple case of people not doing their jobs properly.

But it turns out there were rational reasons for why these employees made the decisions they did. For example, the reactor control system’s user interface was flawed and sometimes gave incorrect information.

The story of Three Mile Island is not who destroyed it but what. When things go wrong we should assume the people involved had positive intent and we need to work from their reality. Sometimes by asking someone to tell their story we make people feel accountable without needing to assign blame. Finally, we should seek forward accountability not backwards. We should work out how to avoid the bad situation from occurring again rather than blaming what went before.

Make distributed teams feel like they’re part of a team

Dirkjan Bussink spoke about how Github manage widely distributed teams. His team encompassed developers from Europe, Africa and the USA. This talk was particularly pertinent for me at EVRYTHNG as we have a large team of developers based in Belarus as well as London.

Dirkjan explained it was important to have regular virtual water-cooler conversations where everyone in the team would join an online hangout and chit-chat. They also made sure they got together once a year for team-bonding and putting virtual faces to real faces. Key to the team was pushing discussions into Slack rather than developers in one office making decisions themselves. Finally, the lead needed to have regular 1:1s to ensure everyone was aligned with the goals of the team.

Make your calendar sacred and keep distractions to a minimum

Christian McCarrick raised a number of important points about scaling yourself as a leader. You should block time in your calendar for thinking and planning, not just for meetings. Say no when someone tries to book time that you’ve blocked for other things. I liked Christian’s line about “multi-tasking being an anti-pattern” and he went on to suggest disabling notifications on your computer and scheduling time for checking emails and Slack.

Conclusion

There was plenty to reflect on after the Lead Dev Conference. It’s highlighted areas where I can be better as a lead and given me ideas for improving the developers and teams I manage.