Summary: The Lead Developer Conference 2019

Tue, Jul 2, 2019

Read in 24 minutes

This is a blog post containing my summary of all the talks and recordings from the Lead Developer conference held in London in 2019.

I recently attended the Lead Developer conference in rainy London. Despite the weather, the conference was great — well organised, inclusive, brilliant people, interesting and professional presentations, and a grand venue (Barbican). In this blog I will present my summary of all the conference talks. But firstly, well done to Meri Williams (organiser and host) and White October Events for orchestrating such an outstanding conference! You can follow The Lead Developer on twitter to keep up to date with other events that might be taking place near you. The highlights video can be found here.

Processing all the content from 2 days worth of talks can be a bit overwhelming. Therefore, I decided to write this summary not only for personal use but also for anyone else who may find it useful or who simply wants a quick reference to some of the content for the conference.

This summary consists of all 2 days and 27 talks, numbered accordingly. For each talk I structure the content as follows:

Before I start, I just want to say thanks to my company Simplesurance for providing me with the opportunity to attend this event — especially since I required a visa to get there! We are hiring in Berlin so check out our open positions and in particular, I am currently looking for a frontend engineer for my team.


1. Navigating team friction

Lara Hogan | recording



Lara’s talk set the stage for other speakers to come. The quality of the talk was very high and the topic was one which many could relate to. 4 out of the Tuckman’s 5 stages of team development formed the basis of the talk, namely: forming, storming, norming, and performing. During the storming phase, fear or doubt can lead Amygdala hijacking where the brain tells the prefrontal cortex to go on standby, leading to lack of concentration and focus in the team and tasks at hand.

Lara discusses how to take care of your team during this stage by identifying the level that each person in the team requires for their 6 basic needs (BICEPS) to be met. The 6 basic needs (BICEPS) are:

Providing feedback is also discussed and Lara presents a feedback equation which entails:

2. I can’t do that for you Dave

Asim Hussain | recording

**Books: **None — but Asim is thinking of writing one ;)


Asim presented the current state of AI in JavaScript. He presented examples of how AI is currently being used in JavaScript, several of which can be found here. This is an exciting area especially since the tensorflow JavaScript library exists and makes it possible to easily develop and train machine learning models in JavaScript, and deploy it to the browser or on Node.js.

3. Engage teams to achieve high performance

José Caldeira | recording


José’s presentation was about how we can achieve high performance when teams and goals are constantly changing. He presented 5 engagement points to achieve this, namely:

  1. Goal — set a goal that is bold and simple to understand.
  2. Constraints — define constraints so as to embrace what you cannot change.
  3. Principle — identify what principles are important for the goal (e.g. autonomy, speed, etc.).
  4. Pitch — promote your goal in a way that energises others.
  5. Storytelling — Be empathetic when motivating the goal. Don’t lie but make the truth sound even more exciting.

Last year when he attended the Lead Developer conference he set a goal to present at this year’s one, which he did by using the techniques he spoke about in his talk — well done!

4. Bottoms up with OKRs

Whitney O’Banner | recording


OKRs (Objectives and Key Results) is a framework for defining and tracking objectives and their outcomes. Whitney got the audience’s attention with her talk on OKRs. This was because she was promoting it even though in recent times OKRs have received a bad reputation. Whitney provides 3 bold tips to follow when starting with OKRs, namely:

  1. Skip individual OKRs — rather focus on tasks
  2. Ignore metrics — these are just guesses, for the most part, rather focus on outcomes.
  3. Avoid cascading goals — rather allow for the initiative to be taken from the bottom.

Overall, Whitney promotes a bottom-up approach with OKRs since this leads to innovation.

5. The developer’s conundrum: what on earth does it mean to build AI software?

Ronald Ashri | recording


What I liked about Ronald’s talk is that he provided a lot of scientific evidence to back up his question: What does it mean to build AI software? This is because AI, by definition, is a science. A lot of companies say “we want AI”, but what does it really mean? Ronald explains that it’s about building software which delegates decision-making to machines.

The talk is scoped around the context of data-driven AI vs model-driven AI, which you can read more about here — data-driven AI discovers the model based on data collected whereas model-driven AI attempts to capture knowledge through explicit representation and rules.

Ronald spoke about the components of a SMART framework, namely:

Using agent-based theory, Ronald discusses the different types of agents:

According to Ronal, we should stop asking the questions “Is this software real AI?” because it’s impossible to answer. I highly recommend watching this talk if you want to, plan on building, or being involved in any AI software development.

6. Guiding self-organising teams

Rebecca Hill | recording


“People come first” — this is the main point of Rebecca’s talk and is a key prerequisite for enabling teams to self-organise. Rebecca provides a couple of tips for managers to help achieve self-organising teams, namely:

Self-organising teams are great and can provide a lot of drive and innovation.

7. 1210, Excellent doggo: the power of positive transformation

Heidi Waterhouse | recording



Heidi’s talk highlighted that if you make it rewarding to do the right thing, people will do the right thing more often. She compared this to training dogs :) As simple as it might sound, there is a lot behind this. The following suggestions were made, to change the behaviour of someone:

Understanding what motivates someone requires understanding what makes someone feel rewarded. This can be different for every person. What makes you feel rewarded?

8. The reality of testing in an artificial world

Angie Jones | recording


Angie spoke about the challenges of testing AI software and highlighted the importance of testing AI software. Testing scenarios where machine learning determines some outcome (e.g. Clothing likes and dislikes, Netflix recommendations, and ad recommendations) is challenging because there is no exact predictable outcome to test against. Nevertheless, as machines make more decisions for us, it becomes even more important that this software is tested.

Angie concludes that there is a need for thoughtful and critical tests and the future is here and we should test it!

9. A team in ten minutes

Steve Williams | recording


Steve is a member of The Royal National Lifeboat Institution (RNLI). In his talk, he compared several similarities between building a team for a critical mission at the RNLI to building any other team that needs to respond to critical situations.

The main point is to extend the training to run exercises which simulate real word critical situations. This helps foster a team where each person knows they can rely on the other team members, especially when in a critical situation. Doing this can build teams that have:

Check out Dave Snowden’s Cynefin Framework for more details of this. In summary, Steve says that we should all build “crews”.

10. Level up: developing developers

Melinda Seckington | slides | recording



Melinda compared developing developers to video game design. She shared 10 lessons with us:

  1. Don’t overload newcomers — have an onboarding checklist or trello-like template of tasks for newcomers.
  2. Support and guide — make a mentor available for newcomers.
  3. Make it clear what to focus on — it can be overwhelming in the beginning, so set goals.
  4. Provided direct feedback — See the book recommendations.
  5. Provide time and space to reflect — Have retrospectives on a personal level.
  6. Provide opportunities to try out new skill sets — Personal budget and training opportunities.
  7. Acknowledge growth — Review and adjust salary yearly.
  8. Expose competencies — Use this to provide a framework for feedback.
  9. Allow people to choose their path — don’t be so fixated on specific roles and allow people to generalise or specialize.
  10. Visualize what progress looks like — as an example, Melinda showed the spreadsheet which they used to map out the skills and progress of developers.

To sum it all up, as managers, developers are our users so we need to provide good user experience, according to Melinda.

11. What I learned about hiring diverse teams from conducting a fully-anonymous recruitment process

Bethan Vincent | recording


Most of us what to have diverse teams, especially since it can help foster creativity and innovation. If you don’t believe that, have a look at all the academic papers on this topic. However, according to Bethan, managers like to hire people like them. Therefore, management needs to be diverse if you want to have diverse teams.

Bethan provides some tips on how to adjust your interview process to attract a more diverse range of applicants:

12. Volunteers, not conscripts: fixing out-of-hours-on-call

Brian Scanlan | recording


Brian spoke about how they set up virtual teams of volunteers to handle on-call situations. Some of the suggestions were:

Most importantly, humans > computers — look after them.

13. Give 10%, get 110%

Kate Beard | recording



This was a first-time talk for Kate and I must say, she did a really good job — sounded like a seasoned pro! The main topic of the talk was about how to help developers develop quicker by providing time at work for developers to do “non-work-related” software development. In Kate’s case, this was 10% and the time could be used so that developers can develop themselves and learn in a way that works best for them. For some, this could be side-projects, open source projects, preparing for meetups or talks, or simply doing courses.

However, getting this approved in a company or getting it started requires some action:

Providing the opportunity for developers to grow has positive outcomes for developers such as intrinsic motivation, autonomy, and satisfaction. Think about how you could do this at your company.

14. Eiffel’s Tower

Nickolas Means | recording



Apparently, Nickolas has told great stories at previous conferences and this was no exception. Nickolas told us the story of the Eiffel Tower and how Gustav Eiffel navigated the political scene in France at the time to be awarded the project to build this famous landmark. I won’t go into the story — you can read about that here (it’s a Wikipedia link) or watch Nickolas’ recording.

Apart from Nicholas’ telling of the story, what I liked is how he applied the lessons learned from Gustav Eiffel’s political dealings to the working environment we find ourselves in. Every organisation is political and we should not be afraid of taking part in these politics because it could lead to something great. One way is to change your perception of certain “politically orientated” words, such as:

I highly recommend watching this talk for its entertainment but also its educational value.


15. Flavours of technical leadership

Pat Kua | recording



Pat kicked off day two with a talk about different technical leadership flavours. Every leader has their own style and you need to invest in finding your own flavour. The talk was divided into 3 main sections, namely:

What is technical leadership?

Where do people demonstrate technical leadership?

How do people demonstrate technical leadership?

  1. Knowledge cultivator: Help other people learn by building a learning environment. This leader also improves their own knowledge by teaching others. “If you can’t explain it simply, then you don’t understand it enough” and “If you really want to understand something well, explain it” — (Feynman technique)
  2. Advocate: Someone who understands the problem domain, helps provide solution and tools. Listening to pain points and doing something about them. Draws upon powerful questions i.e. open-ended questions. Get buy-in for the solution therefore networking is required.
  3. Connector: Companies are a network with different types of smaller network. Sponsor someone, invest in social capital, lend your privilege. Reputation score is important (experience, knowledge, likable)
  4. Storyteller: Can inspire others with a vision.

What is your technical leadership flavour?

As a side note to the conenctor leadership flavour: this reminded me of some social network analysis centrality measures which are used to identify influential people in a network graph. One of the most interesting ones is the betweeness centrality which identifies the amount of influence a person (node) has over the flow of information in a graph. This could be useful to identify the right people to connect with or to connect others with, which is useful for the connector leader. I wrote my masters thesis on along the lines of social network analysis, relating to a trust model and here are some articles of mine if you want to go down that rabbit hole.

16. Inclusion starts with an I

Dora Militaru | recording


Dora filled in for one of the speakers who couldn’t make it. Her talk was about inclusion and here are a couple of the points she mentioned about improving inclusion:

This is an important talk for those interested in improving inclusion at their company.

17. Business as usual: how to stop drowning and learn to swim

Jonathan Scott | recording


This was Jonathan’s first tech talk and he did a good job telling us how to deal with BAU (Business As Usual) tasks, which are tasks that are required to keep everything running as usual (e.g. maintenance tasks). He defined 3 actions to help with BAU:

  1. Documentation — Ensure good quality documentation so that these tasks can be accomplished by those who have no experience with the system.
  2. Simplification — Keep an eye out for opportunities to simplify things in the system.
  3. Automation — Identify parts of the system that can be automated and potentially reduce manual work.

Jonathan also recommended hiring a “tech support engineer”. This is someone who would basically automate themselves out of this position and transition into a new role. For example, this could be a good opportunity for a beginner and it would help unblock the team.

18. Behind the scenes of an effective and inclusive hiring process

Ola Sitarska | recording


Ola gave a great talk on how the hiring process can be adapted to make it more effective and inclusive. Here are some points which she made:

I’m sure some of these points could be useful or at least worth trying out in your hiring process.

19. Mobile development in 2019: native versus cross-platform

Miriam Busch | recording


Miriam gave a talk on the state of mobile development in 2019. This topic was of interest to me, having done development in this area in recent years. The main question was: is it better to do native development or cross-platform development of mobile applications. As always, the answer was “it depends”.

Native mobile development involves the development of Android apps using Java or Kotlin and iOS apps using Objective-C or Swift. The is little to no code sharing between these apps but they are often considered to be more performant.

Cross-Platform mobile development involves the development of both Android and iOS apps with a single framework. This allows one, for the most part, to have a single implementation of the app which is then compiled for iOS and Android. These are not hybrid apps, which are normally web apps running in the web view component of a native Android or iOS app. In contrast, cross-platform apps render to native app components and the main thing that differentiates them is where this rendering takes place.

Several cross-platform frameworks are:

So, it depends on the feature. Understanding the feature will help you select the best approach, which could even be a combination of native and cross-platform development.

My personal experience is with React Native and at Simplesurance, using ReactJS and React Native we were able to share a lot of code between 3 platforms, namely web, iOS, and Android for our digital insurance broker app in Germany called Schutzklick-Makler. How we achieved that is explained in my react-shared boilerplate project. (Sorry for hijacking this summary — I couldn’t resist :D)

P.S. Miriam made brilliant summary notes of talks in real-time which have been very helpful for me while writing this blog. You can check them out on her twitter feed. Thanks a lot for that Miriam!

20. Building security culture on infrastructure teams

Franklin Hu | slides | recording


Franklin gave a good talk about how to create a security culture in the team. He specifically focused on infrastructure teams but agrees that security is everyone’s job. Here are some notes about how to go about building a security culture:

I managed to get my hands on the security edition of the Increment magazine which Franklin brought with from his company — Stripe. I recommend checking it out.

21. Why we should be scared of Shor’s algorithm right now

James Birnie | recording


“RSA encrypted traffic is safe now but NOT in the future!”. This is the outcome of James’ talk and a scary but realistic one it is. James talked about the progress being made in quantum computing and how it can be used together with Shor’s algorithm to crack public key cryptography (e.g. RSA).

I will avoid all the details here but basically, on a large enough quantum computer, Shor’s algorithm can run in polynomial time to find an integer’s prime factors. Prime factorization is the fundamental idea of RSA encryption which therefore implies that it can be cracked by Shor’s algorithm. The key constraint at the moment is that you need a quantum computer with a sufficient number of qubits that could operate without succumbing to quantum noise and other quantum-decoherence phenomena [wiki-reference]. Check out Jame’s recording for more information about this.

22. Navigating front-end architecture like a Neopian

Julia Nguyen | recording


Julia talked about her experience in navigating the world of frontend frameworks and compared this to Neopians — those who play Neopets. I had no idea what Neopets are and it seems like this was after my time (feeling old) but I got the sense that quite a few people in the audience could relate. I don’t want to go into detail about Neopets here but in short, it’s a platform where you can look after a neopet and buy almost anything for them in a virtual world.

Selecting a frontend framework can be daunting but Julia provides some points on how to achieve this:

Here is a list of frontend criteria used by Julia:

Given the situation, it’s not always easy to assign a person to each framework to try and identify which one to use but nevertheless, the criteria and tips provided by Julia can be very helpful in the process of identifying which framework to use in your own projects.

23. How long is a piece of string: the key to solving the conundrum of software estimations

Jonathan Rigby | recording


This was Jonathan’s first talk and he wrote about his experience here if you are interested — well done btw! In this talk, he discussed the complex topic of providing software estimations. Ideally, he’d push for #NoEstimates but this is not really possible as estimates are at least required to some extent, to ensure realistic planning for software projects. Instead, Jonathan mentions that trust is important in giving estimations are here are 5 points that can facilitate trust:

  1. Keep commitments
  2. Be transparent
  3. Don’t overdo
  4. Show empathy
  5. Educate why estimations are so complex

Check out the recording of his talk for more details. One last important point to keep in mind — estimates are very important because they can impact peoples lives. Wrong estimations can lead to people working extra hard to achieve something which of course comes at the sacrifice of something else in their lives. Have respect for the time and well-being of others.

24. Silence isn’t golden, it’s deadly

Paula Kennedy | recording


Paula has a largely remote based team and during this talk, she discussed approaches which she took to try and include everyone and improve communication and collaboration among the team. It was triggered by a company-wide survey which indicated that her team did not feel well-aligned. To try and change this, Paula tried a couple of approaches, namely:

For the most part, these approaches worked. However, there are a few were a few things which didn’t work:

In summary, Paula encourages regular team health checks to identify the health of the team even if things seem fine — silence is not golden, it’s deadly.

25. Leading the team through a rapid growth

Joanna Chwastowska | recording


Joanna gave us some insight into the state of health care equipment and even in the leading hospitals, the equipment is still not as advanced as it should be. In her project at Google Deep Mind Health Stream, she had to scale up the team as the project grew and there are several lessons learned from that experience:

These are valuable tips for handling the rapid growth of the team and her talk is well worth watching.

26. Facilitation techniques 202

Neha Batra | recording


Neha gave a great talk on facilitation techniques. Having attended several workshops I noticed that I have seen a lot of these techniques in action and this talk provided a good summary for anyone who has to facilitate a workshop. On a high-level, here are some of Neha’s techniques for facilitation:

  1. Set the stage — create an agenda; prepare the room; sit and standup accordingly.
  2. Engage the group — group and individual work; ice-breakers such as each person mentioning something which no one knows about them.
  3. Include all personality-types — 3 people should speak before someone speaks again; take a break if discussions get heated; dot-voting.
  4. Finish with a bang — thumbs voting.

There were just too many good points to mention them all here so check out her recording if you want to find out about all the techniques in detail.

27. A button to pause time: how to live outside the clock

Sal Freudenberg & Clare Sudbery | recording


Sal and Clare lit up the stage for the final talk of the conference. They spoke about how they developed a time-machine for a 25-hour hackathon and won! The best part is that they were the team that focused the most on their well-being during the hackathon compared to others. They took time off to sleep, eat well, and stretch regularly and in the end proved that it’s not required to sacrifice your well-being to achieve great work — actually it’s encouraged not to. This might seem obvious but a lot of us don’t put enough emphasis on our well-being and overwork in order to achieve goals — either set by us or our employer.

Sal and Clare went on to motivate how important sleep is and how we are all different in this regard. To support this difference, companies should find a balance of providing flexible working hours but also create a highly structured environment to facilitate collaboration. Check out the recording for more info about Neurodiversity and the Spoon theory.


That sums up my summary! As you can see, there is a lot of content and I hope that you found something useful among all of it. All the speakers did a great job to prepare thoroughly for their talks and a lot of knowledge was shared — thanks to them!

Here are some other blogs about this conference which I came across, that might be of interest:

If you have any comments or corrections for the things which I have posted please feel free to leave them in the comments or contact me directly on Twitter.

Donovan Isherwood
Donovan_TC donovantc

Head of User Applications @Simplesurance

iconCreated using Figma