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:

• Speaker/s | slides (if available)| recording
• Books: Link to book recommendations mentioned in the presentation (if applicable)
• Summary: Personal summary

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.

DAY 1

1. Navigating team friction

Lara Hogan | recording

Books:

• Resilient Management — Lara Hogan: Lara launched her book at the conference and for the lucky few who preordered they got their copy signed.

Summary:

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:

• Belonging
• Improvement/​Progress
• Choice
• Equality/​Fairness
• Predictability
• Status

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

• Observation (objective feedback)
• Impact (customised impact of behaviour)
• Question or request (an action which can rectify the behaviour)

2. I can’t do that for you Dave

Asim Hussain | recording

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

Summary:

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

Summary:

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

Summary:

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

Summary:

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:

• Entity — has only attributes
• Object — has attributes and capabilities
• Agent — has attributes, capabilities, and goals

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

• Passive agent — requires that goals are assigned to it
• Proactive agent — takes measures to optimize achieving the goal
• Autonomous agent — able to generate its own goals

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

Summary:

“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:

• Trust the team
• Document everything
• If you failed at something, understand where it went wrong (also — use feature flagging!)
• Listen to everyone in the team
• Don’t forget to challenge the high performers
• Be positive and authentically celebrate success
• Be kind to yourself

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

7. ¹²⁄₁₀, Excellent doggo: the power of positive transformation

Heidi Waterhouse | recording

Books:

• Making Work Visible: Exposing Time Theft to Optimize Work & Flow — Dominica DeGrandis
• Drive — Daniel H. Pink

Summary:

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:

• Define clear goals
• Respect other’s goals
• Break goals down into smaller goals
• Offer rewards

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

Summary:

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

Summary:

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:

• A richer network
• Resilience
• Better preparedness

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

Books:

• Difficult Conversations: How to Discuss What Matters Most — Douglas Stone, Bruce Patton, Sheila Heen
• Thanks for the Feedback: The Science and Art of Receiving Feedback Well — Douglas Stone and Shiela Heen

Summary:

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

Summary:

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:

• People what to showcase their soft skills alongside their technical skills — provide them with an opportunity to do this.
• People what the human connection — completing some online assessment is not interesting and doesn’t appeal to people.
• Take-home tests are not inclusive — some people have to care for others outside of work and cannot additionally find time for these tests.
• Your job listing is as important as the process — be transparent.
• Challenge the status quo of how things are done.

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

Brian Scanlan | recording

Summary:

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

• Each person is on-call for one week at a time.
• Escalations go to the on-call manager who is pre-defined.
• Everyone on call get’s a flat-fee in addition to their salary, regardless of if they had to respond to something or not.
• Individuals are required to take rest and cannot be on call more than agreed upon.
• Reduce or rather “kill” low-value alarms.
• During office hours the actual team is responsible for the system but outside off hours, the virtual team takes over.

Most importantly, humans > computers — look after them.

13. Give 10%, get 110%

Kate Beard | recording

Books:

• Drive — Daniel H. Pink

Summary:

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:

• A structure should be defined so that everyone is aware of how it works.
• Communication is important, in terms of sharing what will be done or what has been done.
• Trust needs to be given so that there is a sense of responsible freedom.

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

Books:

• How to win friends and influence people — Dave Carnegie
• You can negotiate anything — Herb Cohan

Summary:

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:

• Networking — think of it as “making friends”
• Self-promotion — think of it as “telling stories”
• Negotiation — think of it as “cooperation”

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

DAY 2

15. Flavours of technical leadership

Pat Kua | recording

Books:

• Continuous Integration — Paul M. Duvall

Summary:

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?

• “Leadership is the ability to lead”, “The act of leading a group of people” — Anyone can be a leader, all it takes is a single action.
• The act of leading people in a technical context.
• Turn yourself from a maker to a multiplier.
• A multiplier has more impact.

Where do people demonstrate technical leadership?

• Trident model of career development (technical leader, individual contributor, management).
• Formal or Informal (not accountable, a lot more flexible).
• Broader impact.
• Depth (deep specialties and expertise).

How do people demonstrate technical leadership?

• 4 flavours of 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

Summary:

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:

• Understand your own bias.
• Inclusion is not just HR’s responsibility.
• It’s not only about the numbers.
• Hire underrepresented people.
• Be kind to others.

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

Summary:

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

Summary:

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:

• Benefits are not ping-pong tables because people are interested in the people they will work with and their possibilities to learn.
• The best indicator of a candidate, who would fit in well, is someone who worked in a similar environment.
• Define a performance profile.
• Hire diverse leadership positions.
• Define the hiring process according to what candidate will do.
• An example of a task for a candidate instead of the coding challenge could be a code review.
• Have reviews of technical challenges be blind reviewed to eliminate bias.

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

Summary:

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:

• React Native
• Flutter
• Xamarin

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

Summary:

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:

• Have security advocates on the team who can support and educate others on security concepts and practices.
• Create an environment where mistakes can be made, learned from and not used for shaming.
• Have security reviews where anyone can attend.
• Practice scenarios. Check out Tabletops by badthingsdaily to get a daily scenario which can be used for practice.

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

Summary:

“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

Summary:

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:

• Define the criteria for a frontend framework.
• The Spike Process: this is where you build a production-ready prototype app with sprints and a report card in the end (based on the frontend framework criteria).
• Each person working on this would be an “owner” of a particular framework.

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

Summary:

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

Summary:

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:

• 1–1 are super important! These were done weekly.
• Weekly team standups which addressed the following topics: new faces, helps, interesting, and events.
• Lunch and learn where the team joins for lunch and someone presents/teaches something.
• Monthly retro’s using Postfacto — a tool for facilitating retros for remote teams.
• Quarterly Off-Sites with a full agenda.
• One of the teachings which Paula provide was based on Google’s Project Aristotle, where the focus was on psychological safety. The key points being: Active listening, mindful communication, and resilience.
• Celebrate successes.

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

• The remote team on another continent didn’t feel totally include.
• Slack channels created silos.
• Book club failed, due to the fact that not everyone had the time to read the books.

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

Summary:

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:

• Quality, Security, and Privacy should be taken into account for the technical solution from day 1.
• Be clear about trade-offs in the technical design.
• The team is the heart of the company: Hire with purpose and don’t lower the bar; look out for burnout; don’t have a “hero” attitude on the team — it should be a team effort.
• Open/transparent communication is important.

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

Summary:

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

Summary:

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.

Conclusions

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.