Thoughts from The Lead Developer London 2018 conference

On 27th & 28th June I attended my first Lead Developer conference at the Barbican Centre in London. I had watched all of the previous year’s presentations so I had a good idea of what to expect – but of course, it completely exceeded my expectations!

The conference focuses on helping developers who have made – or are making – the transition into management, be it of one team or multiple teams. The talks were 30 minutes long, broken up with an occasional 10 minute technical lightning talk – a nice way to scratch that itch we no doubt all still have! There were also opportunities to talk to the speakers during “Office Hours” sessions, which was a really nice touch. I loved the format of the conference as there was only one talk at a time so you didn’t have to worry about missing anything. I wanted to write this blog post to share my thoughts about the conference and my notes/takeaways.

When attending conferences or training I find that I only really take notes if I feel the need to write something down. I’m not the kind of person who writes stuff for the sake of it – if I feel it won’t be of use I tend not to write anything at all. This means that sometimes I go away with just a page or two, and sometimes I hit the jackpot. And I certainly did that with the Lead Dev conference – by the end of the two days, I had typed 25 pages of notes as bullet points. There was live captioning throughout which worked an absolute treat – I was able to watch the presentation, then read the caption screen whilst touch-typing what had just been said and listening to what was happening next, all at the same time (trust me, it sounds more complicated than it actually was but it worked very well for me!)

After the conference I decided to take a break from the notes before coming back to digest them. In the meantime I read plenty of tweets from people who attended and one that I found really useful was from @GrahamKCook – It started to give me an idea of how to break my notes down into something more digestable. When I got round to it I wasn’t entirely sure the same process would work for me so I just started highlighting anything that jumped out at me, anything that still resonated even after a couple of weeks. This reduced my notes from 25 to 9 pages. I then printed these out and started marking every bullet point with two different categories: “key learnings” (L) and “actions” (A). “Learnings” would be things where I would have reacted with something like “good point”, “A-ha!” or “I agree with this”. Actions would be things where I would have reacted with something like “this is something I can do straight away” or “this is something I can use next time”.

Once I had that split, I reviewed the document again but this time concentrating on just the actions and looking for any similar themes/topics – for example, I found I was able to group the actions into topics such as Personal Development, Learning, Training & Team Development, or Technical Planning Techniques. I ended up with a split of “Do (straight away)” and “Use (next time)” for each of these. I also noted some questions for myself, such as “how do I go about doing this?” or “who can help with this?”. This helped me to understand the real and immediate next steps.

The whole process took around 5 hours across 2 afternoons and the result is below. I’m looking forward to being able to refer back to these repeatedly in the future and I’ll be interested to see if I can use this format for any other conferences I attend. Perhaps the structure will give you some ideas about how to review and digest your own notes!

Do [Personal Development]:

  • Ask for feedback for yourself, to establish a Feedback Culture (@danpersa)
  • Completely let go of programming – let go of the feeling that programming used to give, and find something else that will give that feeling (@mennovanslooten)
  • When preparing for change, work on yourself first:
    • Don’t do it all yourself – you can’t (@jenny_duckett)
    • Build your support network (@jenny_duckett, @cmccarrick)
    • Set yourself up to lead sustainably – give opportunity to take a step back and work out the direction of the team (@jenny_duckett)
  • Make yourself a priority once in a while. It’s not selfish – it’s necessary (@cmccarrick):
    • Exercise
    • Read every day
    • Speak up – take pride in what you do – send weekly email of individual and team accomplishments
    • Have confidence
    • Don’t let your weaknesses blind you – gather honest feedback

Do [Technical planning techniques]:

  • As an organization, we can discuss tasks prior to implementation (@alexhillphd)
  • Make the team’s work ownable:
    • Define a single clear goal, because focus is invaluable. Define essentials for deadline, extras, and dependencies. If there are other projects, define priorities. (@jenny_duckett)
    • Add context to user stories, use story kickoffs, run workshops (@jenny_duckett)
  • Talk about value – not size, not effort (@adrianh)
  • Book recommendation: User Story Mapping (@adrianh)
  • Ask: “What’s the simplest way to sustainably add and maintain user value?” (@froots101)

Do [Learning, training & team development]:

  • Support and grow individuals (@jenny_duckett):
    • Use every piece of work to help someone grow. Build in learning and development into normal workflow
    • Start with individual needs
  • Show your team where they fit in (@jenny_duckett):
    • Encourage your team to show off their work
    • Show the team how their work fits into the bigger picture

Use [Code review techniques]:

As a code reviewer, we can… (@alexhillphd):

  • Raise code by a grade or 2, no more
  • Use “we” instead of “you” – “what are the advantages of this approach” instead of “why did you do it this way?”
  • Give positive feedback – remember to say thank you

As an author, we can… (@alexhillphd):

  • Annotate our review first
  • Solicit feedback with specific questions

Use [Delegation techniques]:

  • Delegate effectively. Be clear and explicit. Set the scope – what is the problem they are trying to solve? What are the boundaries? Who else do you expect to be involved in doing the work? (@jenny_duckett)
  • Make yourself dispensable – know who you can hand over to as team lead, and help them prepare for this (@jenny_duckett)
  • Focus on your strengths and delegate your weaknesses (@cmccarrick)
  • Ask “how can this task get done?” instead of “how can I get this done?” (@cmccarrick)

Use [Learning, training & team development]:

  • “Turn up the good” – focus on the things that are working, and decide 1 action that will improve it by 1 notch (@pia_nilsson)
  • Help a Junior developer to gather evidence of changes as they make them, to help with future interviews/progression (@tara_ojo)
  • A supporter of junior developers… (@tara_ojo):
    • Invests time – teach them, transfer knowledge, spend time on good pair-programming
    • Asks open questions to get a better understanding of the junior developers’ understanding
    • Creates opportunities – discuss in 1:1’s, find ways to build on areas of interest
    • Gives specific and actionable feedback
  • Goal-setting (@mseckington):
    • Current role
      • What are the challenges of your role?
      • Which of your abilities, interests and/or values are you able to do in your role? Which would you like to do more of?
    • Current skills
      • Think about current skills and what they want/should get better at
    • Future
      • Think about what their ideal life and career would be
        • What does your ideal day look like?
  • Mentoring a future Lead (@KevinGoldsmith):
    • “What are the responsibilities of a Lead at our company?”
      • Split into “my responsibilities”, “your task” (pending my approval), “my tasks to delegate” (but you will inform me about when finished) & “your responsibilities”
        • What do I think this means?
        • Are you ready to take this on?
        • What do you need to learn how to do this and how can I help?

Use [Technical planning techniques]:

  • Instead of using story points, ask these questions (@adrianh):
  1. Can we take a story, and bin it?
  2. Can we take a story, and thin it?
  3. Can we take a story, and split it?

Use [On-boarding techniques]:

  • First 1:1
    • “Let’s discuss what we should expect from each other” (@KevinGoldsmith):
      • Develop a Joint Working Agreement
      • Brainstorm: each person writes down each thing they expect (10-15 mins)
        • Discuss each one
        • Does this make sense?
        • Do you agree/disagree?

Use [Team meetings]:

  • Make a decision in a team meeting (@KevinGoldsmith):
    • Polling (“I want your opinion, but I’m the one making the decision”) vs voting (“We’re making the decision together and I will support the group’s decision”)
      • Be very clear which you are doing
      • Tell people before they give their opinion
  • Collaborative team meeting agenda – works well for a team of 7-10 people (@KevinGoldsmith):
    • Shared Google doc
    • Everyone in the meeting adds their items (and estimate of the time needed) to the shared document at least 12 hours before the meeting
    • Meeting owner grooms the agenda before the meeting begins
    • A facilitator runs the meeting and keeps time
    • The person who added the item leads the discussion
  • Your positional authority will encourage others to conform to your opinion (@KevinGoldsmith):
    • Choose how and when to enter the conversation
  • Set expectations (@KevinGoldsmith):
    • “Are we making a decision or just talking?”

Finally, I pulled out five quotes from across the two days which I thought were the most important to me (by the way, this was really, really hard – I could easily have quoted every line from every talk!). I think they sum up one of the themes from the conference pretty well, which for me is “awareness” and “impact” –  make sure you you are aware of yourself and look after yourself, and be aware of the impact you are having (and can have) on others:

  • “If you don’t prioritize your life, someone else will” (@cmccarrick)
  • “When you let go of what you are, you become what you might be.” (@aliciatweet)
  • “Learn to love interruptions – there is no better way to know for sure that you’re going to help someone than if they interrupt you for help.” (@mennovanslooten)
  • “As leaders, you should be helping your team to figure out what’s next for them.” (@mseckington)
  • “As leads, we have the ability to both positively and negatively impact people’s lives.” (@KevinGoldsmith)

Related links

Dan Persa (@danpersa) – “First Steps as a Tech Lead”

Alexandra Hill (@alexhillphd) – “It’s Personal – The Art of Giving and Receiving Code Reviews Gracefully”

Pia Nilsson (@pia_nilsson) – “Knowing Me, Knowing You – Growing Teams to Continuously Deliver”

Menno van Slooten (@mennovanslooten) – How I Learned to Stop Worrying and Love Meetings

Jenny Duckett (@jenny_duckett) – Building Sustainable Teams to Handle Uncertainty

Christian McCarrick (@cmccarrick) – The Hardest Scaling Challenge of All: Yourself

Tara Ojo (@tara_ojo) –

Adrian Howard (@adrianh) – Points Don’t Mean Prizes

Alicia Liu (@aliciatweet) – Go Slow to Go Fast: Building Strong Foundations for Leadership

Melinda Seckington – Goal-setting Workshops for Managers (@mseckington)

Jim Newbery (@froots101) – How to Survive the Single Page App-ocalypse

Kevin Goldsmith (@KevinGoldsmith) – Using Agile Techniques To Build a More Inclusive Team