An attendees summary of LeadDev London 2024
TL;DR — On 11th and 12th June 2024, LeadDev hosted a 2-day conference for Technology leaders at the iconic Barbican stage and I was one of the 1300+ attendees at this conference. The conference covered a range of topics and this blog is my attempt to summarize all of the talks which I attended.
The details…
To start with, in case this is the first time you are coming across LeadDev, I strongly suggest checking out…
In their own words…
LeadDev is a community of software engineering leaders that come together to learn and get inspired on all things team, tech, process, and personal development. They have been organizing leadership conferences in the US and Europe for over 9 years.
LeadDev in numbers is best represented by these infographics…
With that context in mind, let’s jump right into the two days!
Day 1
Welcome to LeadDev London 2024
(By Meri Williams & Marcus Gardiner)
Meri kicked us off again… for the 9th year of LeadDev!
We had a packed audience at the Barbican — full of engineering leaders…
After an understanding of the logistics and the scale of this conference, one key focus for this year was to help facilitate connections between fellow engineering leads — that attendees can potentially connect over time as peers, mentors, sponsors, etc. Marcus, the co-host, shared his experience about how he found it difficult 2 years ago to interact with others when he attended LeadDev and also, some practical steps that the organizers have taken to overcome it.
The organizers created 10 different ways to help connect — this felt like a unique experience this conference created. Kudos to the organizers for that!
Keynote: Embracing engineering’s place at the forefront of business
(By Renee Hunt)
Renee plays the role of a CTO — it was inspiring to understand how she recently got promoted from the ‘Head of Engineering’ to a CTO. She kicked off the talk by mentioning that her talk was going to be the ‘lead’ part of the conference. She referenced how we are in the middle of the fifth ‘technology shift’, by first highlighting the 4 big shifts —
Renee talked about how COVID-19 created a huge boost for companies all over to expedite their digital transformation.
One interesting anecdote that Renee shared was how in her company (Compare the Market); the CEO, COO, CTO, and CFO were all from technology backgrounds! Fascinating, eh?
Renee urged all engineering managers to grow their business/domain acumen. Because it’s a significantly easier for someone with an engineering background to grow the business acumen v/s the other way around! This was a good call to action, imho!
How do you deliver a feature on the biggest stage in the world?
(By Josh McNamee)
Josh talked about his experience of building software behind playing on a massive spherical screen in Vegas for a U2 concert.
(Reference — https://www.digitaltrends.com/home-theater/u2-sphere-las-vegas-tech/)
The problem statement that Josh talked about on a high level is how the incoming video was too big to store and stream and additionally, all the intricacies of playing a rectangular video on a spherical screen.
Through multiple engineering brainstorming sessions and feedback loops, they were able to resolve these complex requirements. Though we didn’t get into too much detail about the ‘how’, it left the audience with a realization of how important it is to break down complex problems into small, simpler problem statements so it’s easier to achieve them. The final output looked pretty impressive —
For anyone interested in learning more, I came across this very well-written article about this —
Engineering Leadership in 2024 and Beyond: Skating where the puck is going when the ice is melting
(By Lena Reinhard & Scott Carey)
Scott started talking about what’s going on in the industry in 2024 and how it impacts us! Some key questions that Scott and Lena have focussed on are as follows -
- How have organizations changed in the last 24 months with all the external factors going on?
- What’s it like to be an engineering lead in 2024?
- What are the industry trends and outlooks?
- Any practical recommendations?
The data were from 1100 responses from engineers to CTOs, with responses from the US, UK, and EU.
From the detailed report, here are the 5 key takeaways —
This one was one of those talks where there were some fantastic infographics shared along with personal anecdotes. But instead of sharing a bunch of pictures, here is the link to the detailed report —
On a lighter note, Lena taught us a cool German phrase that is so relevant in our industry so I had to share…
The engineering leader’s playbook: A hands-on guide to DORA
(By Finn Toner & Rob Edwards)
The objective is ‘Better software delivery’ using DORA (https://dora.dev/).
The key question is “How can your org optimize value delivery from investment in technology and technologists?’
Also, we talked about checking out Accelerate https://getdx.com/blog/accelerate-metrics/). There is a book called Accelerate worth reading that walks through the Accelerate metrics in detail.
At the core, these are 4 DORA measurements —
Based on the ‘State of DevOps Report’ from 2023 (full report available here — https://cloud.google.com/devops/state-of-devops/), these benchmarks make a team ‘Elite’ to have -
- Lead time for change -> Less than 1 day
- Deployment frequency -> On Demand
- Change failure rate -> 5%
- Failed deployment recovery time -> Less than 1 hour
Google also gives some interesting categorizations to teams based on their experience (source — https://cloud.google.com/blog/products/devops-sre/using-the-four-keys-to-measure-your-devops-performance) —
DORA’s research applies behavioral science methodology to uncover the predictive pathways that connect ways of working, via software delivery performance, to organizational goals and individual well-being. This is the current core model —
There is also a v2 version of this core model that is being discussed here (https://github.com/dora-team/dora.dev/discussions/582) —
Based on the DX surveys, there is a natural clustering of teams in 3 categories
- User centricity
- Software delivery performance
- Operational performance
The performance predictions based on this are pretty interesting to observe (apologies for the complicated infographics but it has some interesting findings!)
TL;DR — be a ‘user-centric’ team, and not a ‘feature-driven’ team!
Next, we also focussed on how functional documentation is and a logical diagram of how documentation plays a role —
One interesting learning to visualize the performance of the team and organization across the 4 DORA metrics. One open-source project to explore to create a dashboard around this is https://github.com/dora-team/fourkeys (Note that this project is currently not maintained)
Action point — Do a self-assessment using…
Also, worth checking out the white paper called “Designing Cloud Teams How to Build a Better Cloud Center of Excellence” by Google here —
https://services.google.com/fh/files/misc/designing_cloud_teams.pdf
Finally, in the spirit of keeping up with the LLM hype, you can also ask DORA anything in natural language at
Demystifying neurodiversity in tech with nostalgic video games
(By Parul Singh)
The talk started with talking about how IKEA used words against numbers because the founder of IKEA was AHDH and dyslexic.
Fact —
We covered the neurodiversity movement and how it has become somewhat rigid and Parul offered a new perspective that can be more flexible, and more sustainable!
Some tips —
- Instead of asking to ‘try harder’, ask to ‘try different’
- Small accommodations can make a world of difference
- Neurotypicals make good suggestions
Some tips —
- We think in multiple directions, seek information, and consider all sides of the issue
- Steps to deal with conflict: Validate → Educate → Mitigate
How to use technology radars to make transparent tech decisions
(By Andra Blaj)
We started by how we, as engineering leaders, question some technology choices and decisions, especially when we join new teams and organizations.
Some questions that we struggle with as leaders are
- How do you easily grasp a dense technology landscape and understand the what of certain technology decisions?
- How do you document those decisions in a centralized and open place?
Answer — The Technology Radar!
Here is an example from Thoughworks
A sneak peek of the Tech Radar from Thoughtwork’s article above —
As an organization, Andra suggested that we should build our technology radar. Here is a helpful open source to visualize this — https://github.com/zalando/tech-radar
Recommendation — update your technology radar every 6 months!
The good
- Valuable and fun conversations
- Onboarding & hiring
- Alignment
- Tech stack skills coverage
- Strengths and vulnerabilities
Lessons learned
- Building a technology radar is straightforward
- Building a culture of documenting technology decisions takes time
- Encourage technology conversations regularly and openly. Document the ‘why’ very well
Finally, a good resource to be aware of is the community health toolkit available here —
Delivery metrics — the good, the bad, and the utterly ridiculous
(By Jennifer Mackown)
The objective for Jennifer has been to ‘Design smart delivery metrics’ — a DORA dashboard was a good starting point but the graphs by themselves didn’t mean much.
Two questions that Jennifer wanted to focus on 1) What are we building? and 2) How are we building it?
She did a brief walkthrough of her journey with those two angles. The key takeaway for me from this talk was not to create over-reliance on DORA but instead; question the ‘what’ and the ‘how’ and iterate through the metrics to find as well as fine-tune mechanisms to capture it. This was a strong message IMHO because plenty of organizations end up using DORA because ‘Google said so!’
Measure for change
(By Laura Tacho)
Given all the focus on DX in the last couple of years, the question is ‘Is developer productivity improving’?
Measuring and improving are not the same thing. Measure for change.
Pfizer is a GOOD example where there has been a material change in DX!
Companies like Pfizer have done a great job with 3 key things —
- Involve your team
- Tie data to decisions
- Always follow up
Qualitative v/s Quantitative v/s both? The answer is BOTH!
One tip — to understand the developer experience, capture ‘Priority and ‘Sentiment’ next to each other and then, relate the sentiment with the functional workflows — the sentiment comes from Qualitative questions and the workflow comes from Quantitative pipelines. This intermingling is extremely powerful!
“Can we capture ‘In the moment’ feedback from engineers” — instead of being periodic pulse surveys, moving to ‘in the moment’ surveys is very beneficial. Plaid is a GOOD example of doing this! This is an interesting article related to this
Data science demystified
(By Grishma Jena)
We started with two key data-related questions —
How much data was produced in 2023?
~120 zettabytesWhat’s a common data science pipeline?
Question -> Wrangle -> Clean -> Explore -> Pre-process -> Model -> Validate -> tell a story -> Actionable sight
And so, Grishma started talking through the pipeline, especially focussed on the model building —
You first start with feature engineering. you then choose a model, decide if it’s supervised or not, and tune parameters and then, split the data into training and test data. Be careful not to overfit! Finally, Evaluate the model using the test data.
Some examples of machine learning approaches include—
- Classification (supervised)
- Regression (supervised)
- Clustering (unsupervised)
- Anomaly detection (unsupervised)
- Reinforcement learning (unsupervised)
Data storytelling — Tell a compelling story with data using characters, setting, conflict, and resolution! But it’s important to consider ethics and responsibility in Data Science.
Here are some best practices shared while thinking about data science, both from a data & infrastructure angle as well as from a culture angle —
You are here: The story of the Barbican
(By Nickolas Means)
The last scheduled talk of day 1 was by Nik — who is an amazing story-teller and shared multiple stories from different industries in LeadDev before.
This year, Nik shared the story of the venue we were in, which is the Barbican — and it was a fascinating story! While the story didn’t have direct relevance to engineering leadership, the talk was very appropriate, IMHO, for two key reasons -
- The audience had got a lot of good content and were Maxx-ed up for the day so, any new engineering leadership content would have pushed some of us to feel like a stack overflow! :D
- Nic was very efficient in connecting the story of architecture, resiliency, and uncertain times when the Barbican was being built to how engineering leaders should think about problems/opportunities in today’s markets
If there was one ‘inspiring’ talk that I had to recommend from day 1 to folks reading this article, I would suggest folks go and check out this one on YouTube, once available.
PS — Day 1 ended with a fascinating panel discussion on the topic of ‘The next twelve months of AI — how they are optimizing for effectiveness, and motivating teams” with 4 CTOs! The CTOs part of the panel were
- Meri WIlliam (CTO, Pleo)
- Rafe Colburn (CTPO, Depop)
- Rebecca Salsbury (CTO, The Financial Times)
- Rob Zuber (CTO, CircleCI).
Many good points were discussed on this panel to be effectively summarised but all I will say is it gave a very broad and differing perspective of how companies across different domains are thinking about AI both to accelerate internal productivity and also, a user-facing product suite. What a beautiful way of wrapping up today 1!
Day 2
Revolutionizing engineer growth: The tech-powered blueprint for careers clarity at ASOS
(By Gareth Waterhouse & Ed Collins)
The focus of this talk was threefold, namely —
- Strategies for navigating constructive career conversations — both for yourself and others
- Effective frameworks and resources for constructing competency frameworks
- Understanding which platform of delivery is most effective for a career framework
They started this journey when one of the survey questions had a lower percentage for the question — “I have good opportunities to learn and grow at ASOS”
Podcast recommendation — https://www.amazingif.com/listen/
Some of the steps that they took as they went through the journey
- They introduced the concept of ‘Career Conversation Careers’
2. They created a flow-chart of the promotion process — to give more visibility about how individuals can
3. Create two different roles at the mid-management level —
a) Agile Delivery Manager (People management + Delivery management)
b) Engineering Manager (People management)
4. They created a competency matrix for engineering managers by doing external research. They used three companies as references because they had good external blogs about their engineering manager roles —
a) Farewill (People focussed)
b) SkyScanner (Technical/People focussed)
c) Spotify (Delivery/People focussed)
5. Uploaded this on Github and created a web UI on top of that as an in-house solution.
This is how it all comes together —
They created a tech radar based on your competency matrix which helps with meaningful career conversations.
Three key takeaways —
Making smart investments: A framework for maximizing your ROI in technical decisions
(By Katerina Iliakopoulou)
Fact — Regardless of how junior or senior you are, how many years of experience you have, and what tech stack you work in…
This talk focussed on finding the story behind decisions!
Story #1 — deciding on a high-risk project with unknown returns
Story #2 — deciding when to outsource to a vendor
ROI = (Gain from investment — Cost from investment) / Cost from Investment x 100
But how does one define ‘Gain’? Do we have any unknown biases?
Five key factors to consider —
We went through in detail all these 5 factors — specifically focussed on understanding how to measure it.
Finally, putting the ROI formula and the 5 key factors together, this is where Katerina reached that one should keep in mind —
Iterate to greatness: Building high-performance, AI-native engineering teams
(By Jared Palmer)
Jared talked about how Vercel has re-architected their teams to be AI-native. We started with the definition of ‘software 2.0’
To prepare teams to be ready for ‘software 2.0', these are the steps that Jared walked through — starting from evals!
Side note — Vercel created an AI SDK so that developers have an abstraction layer on top of multiple core foundational models across OpenAI, Anthropic, Meta, etc.
You can create squads/workstreams/teams based on different components of this flywheel to focus on that specific part of the puzzle — to be able to build ahead!
Beyond the hype: Practical steps to establishing and scaling your data & ML team
(By Ellissa Verseput)
Great question to ask —
The problem that Ellissa focussed on was a critical daily forecasting process that was in the hands of ONE colleague and Excel! This might have been okay as a PoC or during the start-up phase, but not during the scale-up phase and so, she went through multiple rounds to improve this.
Round 1 — some challenges
- Mini team (team of 1!)
- No data infrastructure
- Loads of data ‘buzz’ but no strategy
Elissa recommended about creating a data team with two outcomes 1) forecasting and 2) insights. Additionally, she put together a strategic architecture for the future data platform.
Next question — do we build? buy? They went with ‘buy’ with Databricks
Some takeaways from ‘round 1’
- Hire for crucial missing skills
- Buy and not build the data infra
- Choose 1–2 use cases and prove value!
Round 2 — some challenges
- Thinking about top-down demand
- Getting all business users onboard
- Unable to work on all ML projects and lead the team
- Maturing the data platform architecture
Elissa focussed on growing the team — going from 2 ‘analytics engineers’ to 2 ML engineers, 2 analytics engineers, 1 product manager with Elissa being the team lead
The data platform architecture matured as a result of all the focus —
Some takeaways from ‘round 2’
- Manage your top-down data demand
- First-time data manager — delegate!
Round 3 — some challenges
- Growth pain
- Growing the team from 7 to 14
- How to best structure the data team(s)
- Scaling analytics
Book recommendation — https://teamtopologies.com/
Ellisa kept the e2e solution provider approach as is, but started moving to enabling other teams (read self-service!). For example, data-savvy business users, analytics engineers, machine learning engineers, and data engineers.
Some takeaways from ‘round 3’
- In hindsight, pivot faster towards enabling other teams rather than keeping ownership of the e2e workflow
- Learn from the community
- Experiment!
The post office scandal: What we can learn from its process and human failures
(By Hywel Carver)
Problem statement — How do post offices get visibility about stock levels and do the coordination?
Originally, The Post Office’s system was built in 1999 by Fujitsu, and the system was called ‘Horizon’. It was a distributed system based on architectural principles as of 1999. The root cause of the post office scandal was a buggy system, while the problem was that the post office trusted the buggy system as against the humans.
Bizzare law & logic —
Most surprisingly — some individuals knew there were gaps and security loopholes but they refused to allow this on a cost and time basis!
Some takeaways that the Post office has taken away from the scandal —
- Psychological safety
- Open about production logs
- Close contact with users
Some learnings that we, as engineering leaders, should take out of this —
The boss’s shoes don’t fit: And other surprises of leadership
(By Inna Weiner)
Inna talked about how she got promoted to become ‘big boss’ and when she attended her first team meeting, she left the meeting feeling very happy and satisfied but, instead, she got this feedback from the team…
That was a big surprise for Inna and so, she went through her journey to learn a few lessons that she realized over time
Five lessons that she learned —
- Speak less — likely, you are not the most knowledgeable person in the room. Your words are amplified via a ‘megaphone’. Instead, listen more (verbal as well as non-verbal)
- Speak more (but differently) — explain the way you are thinking. Explain why it’s important to you and the company. Be curious. Diffuse the situation. Share information by connecting the dots.
- 5:1 rule — ideal positive-to-negative feedback ratio (according to a 2004 Emily Heaphy and Marcial Losada research). As you become more serious, this becomes even more important
- Be a storyteller — accomplishments don’t talk about themselves. Framing matters
- Celebrate!
Uncertainty of change
(By Jitesh Gosai)
Jitesh started by going through 4 examples of change and how different companies approached it —
Our brain reacts to change in a very certain way — either via excitement, v/s fear. If it’s fear, it’s usually Flight-Fight-Freeze-Faun response.
To co-relate the 4 examples and how our brain reacts, here is a good visual
Jitesh shared about the Cynefin framework for decision-making and how it can be used in a complex, complicated, and constrainted world!
This is the basis of the framework —
Managing the marathon: Leading teams through lengthy migration projects
(By Lawrence Taylor)
Lawrence shared his journey in Bloomberg for a migration story using the story-telling concepts of 1) Who? 2) What? 3) How?
Who?
Stakeholders — the team, manager, their manager, product managers, sales managers…. the list goes on!
Patrons → People who are paying for the project!
Consumers -> People who are going to be eventual users of the tool/product as well as the engineers who will have to maintain, test and deploy the code
Builder → People who are building the tool/product currently
What?
Size → How big is the system that we are migrating
Time → How long will this take?
Impact → What will be bottom line impact of this migration?
How?
The unique challenge is that the system already exists and so, it should be easy, right?
The way Lawrence broke down the milestones was as follows —
- Integration points
- Capabilities
Additionally, they defined some metrics with the ‘role’ of a ticker watch — to celebrate, gamify, and motivate
The combination of milestones & metrics helped Lawrence and the team share their stories effectively!
The software bug all stars — and what we can learn from them
(By Christian Seifert)
Example 1: The focus of this example was about the Mars Climate Orbiter issue — the root cause of which was a software bug!
The root-cause analysis began. It was learned that different teams work on different subsystems. Lockheed Martin and MASA JPL were the two key teams working on this. The root cause was… Lockheed Martin used imperial units (Pounds of Force), while NASA used SI units (Newton)!
The ground team realized something was wrong — but management chose to ignore them!
Lessons learned —
- In your API design/contract, make things as explicit as possible
- Trust your team and do not ignore their observations
Example 2: The focus of this example is about three people who died from an overdose during radiation therapy (Therac-25) — the root cause of which was ALSO a software bug!
The root-cause analysis began. They learned that there was a race condition when entering data. The puzzling part was that this race condition bubbled up only after 2 years. That is because the speed of the operator improved over time and that led
The software failed because there was 1 developer… who was also responsible for QA!
Lessons learned —
- Be humble and don’t dismiss the fact that it might be you!
- Every developer is biased — build technical and organizational safeguards (eg linters, automated tests, CI pipelines, etc)
- Don’t show cryptic error m
Example 3a: Microsoft Zune. Microsoft’s reaction to the iPod. 31st Dec 2008 — the device stopped working.
The root-cause analysis began. And the picture below shows the reason (hint hint — 2008 was a leap year!)
Example 3b: Lockheed Martin. Crash of the F-22 Raptor in the middle of the Pacific Ocean.
The root-cause analysis began. The F-22 crashed when it crossed the international date line
Lessons learned -
- Use & understand proven tools, frameworks, and libraries for date and time handling
How to set goals with people who don’t want to set goals
(By Alicia Collymore)
Alicia talks through her process to help people set goals, especially for reluctant individuals.
- Brain dumping — set the scene for them. Think big, think small. Include personal life. Use past conversations.
- Mapping — pick one by one and talk through them. Create a timeline and connect the sticky notes
- Shaping — pick 2–3 sticky notes together. Use the SMART technique or OKRs. Keep asking ‘how’, ‘how’, and ‘how’. Make it Actionable!
- Review and revisit — what have we accomplished, what didn’t fit? what can we add to the backlog? what should we pick up next?
- Outcomes — what 3 legit goals, career direction, personal aspirations, backlog of goals?
Here is one example of how Alicia suggested shaping →
Managing Engineering Teams in the Era of AI
(By Chris Class)
Chris talks about incident.io’s journey towards using AI. It started with a hackathon in a pub!
Some high-level steps that Chris and the team took are as follows —
- Start experiments soon
- Favour short iterations
- Promote rapid knowledge sharing
- Expect and embrace a longer learning curve
More details on here —
If you’re not part of the solution, you’re part of the problem
(By Alessandro Canessa)
Alessandro shared a personal story about how he overcame a toxic work environment. It was very difficult to capture some key highlights from that talk because it was more of a story to absorb rather than be able to make an efficient summary!
Mentorship + sponsorship
(By Lara Hogan)
Some key qualities of mentorship include —
- Honesty
- Flexibility
- Reciprocity
- Active listening
- Mutual respect
- Personal connection
- Shared values
This visual is super helpful in highlighting the difference between Mentorship and Sponsorship!
Finding a sponsor includes a bunch of steps —
- Do great work
- Find someone who knows your work
- Know how you want to grow
This is a good resource to use —
(Source — https://wherewithall.com/resources/Manager-Voltron-Bingo.pdf)
And with that, we had a wrap! All the videos will be available from 19 June onwards here https://leaddev.com/leaddev-london-2024/videos.
My closing thoughts
This was the third time that I attended LeadDev (previous ones were in 2020 and 2022) and every time I attended, I realized how inclusive and inspired I felt being part of this conference and this community.
I would recommend anyone who is on the technology leadership and management journey to attend this conference — ranging from tech leads to middle managers/directors to ‘heads of’/CTOs.
While this article covered only the talks section of the conference, there were multiple ‘non-talk’ events going on ranging from table talks, speed coaching, networking events, solution swaps, and more that I thoroughly enjoyed being part of. And for that, huge kudos to Meri, Marcus, and all the organizers!
Three asks if you are still reading this —
- Whilst this was a sincere effort from me to summarize everything I could; I might have misunderstood/mistyped something. In case you spot that, please feel free to let me know and I will be happy to edit & update
- If you found this summary helpful, please feel free to add some claps and share it with your network. The objective here is to share the learnings across the community
- Finally, feel free to connect with me on LinkedIn — my LinkedIn profile is https://www.linkedin.com/in/kaushikchaubal/
