I was given the opportunity to attend the Lead Developer conference in London, which occurred on the 8th and 9th of June 2017 in the Queen Elizabeth Exhibition Centre in London. This was obviously exciting enough on its own, but it also coincided with the UK General Election, and the QEII Centre is situated right in the heart of Westminster, opposite the cathedral and behind the Supreme Court, just a stone’s throw from the Houses of Parliament.

Unfortunately, I didn’t get to see any exciting goings on while I was there, however one talk had to be cancelled because the person speaking worked for the government so was subject to ‘purdah’, a term that generated much googling and discussion in the conference slack group. Fortunately, the conference organisers had literally thought of everything including this, so there was a backup talk ready to replace it.

The Lead Developer conference is aimed towards tech leads and developers looking to improve their ‘soft skills’, however there were a few talks focusing on the technical side of being a developer. It was a good experience for me to see the skills I need to develop to progress my career apart from the more obvious, technical ones.

I wanted to recap the two talks I found most valuable, but you should definitely check out the links below for the full slides and videos of the whole two days!

How to talk to earthlings

This talk was by Adrian Howard and the video can be found here. This talk was predominantly about being a line manager and how to host one-to-ones to give and receive feedback, but it also had the comment that I think I took most to heart from the conference:

How often do you find yourself in a conversation with one or more people and somebody mentions something and now all you can think about is ‘Ah I have an anecdote related to this’ or maybe ‘I want to give my opinion on that!’. Now all you can think about is saying your piece, waiting patiently (or maybe not so patiently) for the smallest of pauses so you can interject.

Since I saw this talk it’s something I’m constantly aware of doing and actively trying to stop. It can be very hard, especially if you know you’ll get a laugh or get to be the centre of attention. We don’t truly have conversations unless both parties are actively trying to, we generally just take turns talking at each other.

‘The opposite of talking isn’t listening, it’s waiting’ - Fran Lebowitz

As a manager your customer is your employee, therefore you should strive to understand them in the same way you should understand your customer base.

Although the below is in the context of someone explaining a problem to their manager during a one-to-one, I think that everything could easily apply to any conversation—in the workplace or socially. As such, these are things that I’m actively trying to incorporate into my conversations.

The most important thing to do during a one-to-one is to listen. The second most important thing is to keep listening. People naturally talk in paragraphs, and these paragraphs will have natural pauses between them. When someone is talking and they come to one of these natural pauses don’t take it as an invitation to reply. If you do then you might miss out some valuable information about the issue they are describing. Let the person talk and only when you are sure they’ve finished should you say your piece. Merely being quiet doesn’t count as listening, it is very easy to paraphrase or reinterpret, accidentally or deliberately, what has been said so you should take efforts to ensure you understand them.

Ask reflective questions, this shows that you’ve paid attention and understood the issue, it allows you to dive deeper into any part of the issue you want more information on, and allows you to redirect the conversation back on topic if the topic has wandered. Briefly explaining back the issue will allow the other person to clarify any points you may have misunderstood, or just add general clarification.

‘Every clarification breeds new questions.’ - Arthur Bloch

When searching for solutions, it is important to frame the issue correctly, don’t ask ‘What would you do if …?’ questions, it’s hard to get meaningful answers from hypothetical problems. Instead, ask for stories. ‘Tell be about a day when this issue was particularly bad’. Being based in reality allows for greater understanding of the problem and can lead to further questioning such as whether that approach was the best.

It’s important to avoid leading questions as well. ‘Would x thing help next time?’ isn’t as good of a question as ‘What would help next time?’. Avoid questions with definitive answers, questions that provoke a story often provide much better answers.

Adrian summed up his talk in five points

  1. Shut up
  2. Stay quiet
  3. Reflect back
  4. Ask for stories
  5. Insights vs observations

Implementers, Solvers and Finders

The second talk I want to write about was called ‘Implementers, Solvers and Finders’ by Randall Koutnik a Senior UX Developer at Netflix. The main theme of the talk was ‘What is a Senior Developer?’. What words do we use when asked to describe a senior developer? Experienced? Opinionated? Expensive? These words aren’t a useful indicator of someone’s ability. Years of experience isn’t always a good indicator of ability if that person has never been given opportunities to, or never wanted to, stretch themselves. And being opinionated doesn’t make someone right, everyone in tech has at least once suffered from imposter syndrome, or even experienced (or observed) the opposite, the Dunning Kruger effect. We had a recent blog post about what criteria we have to differentiate between developer levels and while I think that is a good definition, Randall’s descriptions are a lot more simple and high levelled:

Junior => Implementer

A junior developer should be able to be given a solution and turn it into code.

Professional => Problem Solver

A professional developer should be able to be given a problem and turn it into a solution.

Senior => Problem Finder

A senior developer should be able to be given the context and be able to identify and prioritise problems

I really like this definition, its simple and easy to explain and I think it fits well with our own definitions.


Overall I really enjoyed this conference. If you are looking for a conference talking about the latest digital trends or technologies, this one isn’t for you. However if you’re a developer looking for something a bit different, something that will challenge some of your preconceived opinions of people or are about to take your first steps into management, then this conference is definitely worth considering.

If you want further information then check out their website where you’ll find all the slides from the talks as well as their youtube playlist which is constantly being added to and now includes most, if not all, of the talks. Look also at the sites for their previous conferences, London 2016 for videos of all the talks there, New York 2017 for slides of those talks, although I don’t know if videos are going to be made available for this one.