LeadDev London 2024 (Day 1)
In what is fast becoming an annual tradition I recently switched on my Slack out-of-office, packed up a bag with plenty of room left for some conference swag, and got on the train to the Barbican for LeadDev London 2024 (see my review of 2022 day 1 and day 2, and 2023 day 1 and day 2). As with last year, this is a one-track conference focused on leadership and engineering management, with a separate one-track conference at the same time, StaffPlus, focused on Staff+ engineers. I only have a ticket to LeadDev, so I only got to see those talks.
As in previous years the event was held at the Barbican in central London. The main event space remains excellent, with good acoustics and sightlines for all 1000+ attendees. Last year I complained about the state of the toilets, and while the existing toilets are still there and haven’t been renovated there was a temporary set of additional toilets which were much better. The quality and speed of the food remains excellent, although I was a bit short-changed at lunch on the second day so needed to have a second dessert to ensure I had enough energy for the final set of talks (#FirstWorldProblems).
There was an expanded set of activities during all the breaks, but these were very popular and the terrible acoustics meant it was challenging to get close enough to even hear what was happening, let alone contribute. This fact was acknowledged by the host Meri Williams at the end of the conference, where the bombshell news that LeadDev will be leaving the Barbican after nine years was dropped. The venue for next year will be the InterContinental at the O2. Hopefully, this will solve the acoustic issues with the activities and they will have better toilets. Apparently, the move is to allow the conference to expand, so fingers crossed it keeps the lovely sense of community and doesn’t become a faceless megaconf (e.g. QCon). Time will tell, and even though the new location nearly doubles the commute time for me it’s highly likely I’ll be attending again.
One addition to the schedule compared to last year was a set of three “micro workshops”, which ran for 80 minutes at the same time as one block of talks. With three workshops, each running twice, there was plenty of opportunity to find a workshop that interested you and didn’t clash with talks you were keen on. As I attended the workshop on the second day I’ll cover it in the second part of this write-up.
In general, the quality of the talks was excellent, and even the first-time speakers did a great job of hiding their nerves and putting on a polished presentation despite speaking to over 1,000 people. I’m secretly glad that my talk was not among the 24 selected from 700+ proposals as I’d likely turn into an unintelligible pile of jelly if I had to walk on that stage, so kudos to everyone who presented. As usual, there was a good range of topics that are likely to be relevant to a wide range of leaders, and they mostly avoided sales pitches, with the notable exception of the Vercel talk on day 2 which I felt badly misjudged the room. It was also interesting that there was a lot of scepticism of Generative AI both on stage and in the audience, apart from a couple of talks (one of which was the Vercel talk). It’s good to see that is LeadDev is not getting carried away on the Gen-AI hype train.
What follows is a summary of my notes from each talk. I believe you can buy digital passes to catch up on the talks, or they are usually put onto YouTube after a few months.
Embracing engineering’s place at the forefront of business
This was an interesting talk by the CTO at Compare The Market about the overlap between technology and business. Half the executive team at CTM come from a tech background. Being a technology leader is morphing into business leadership as a tech person can learn about business, but you can’t give a business person 20 years of experience in technology.
She described how the number one priority for the business was a migration to GitLab. This is obviously a very technology-focused project, but all the executives (including non-technical execs, like the CFO) were on board with it being the top priority for the business because a good story had been told about why it was good for the business, and the future changes it would allow.
She closed with a message that people should prepare to lead, but even as a technologist, that role might not be directly in tech.
How do you deliver a feature on the biggest stage in the world?
This was a bit of an odd talk for LeadDev. It focused on the technology needed to display video at the Las Vegas Sphere, which is a giant dome with the world’s largest video screen. It’s certainly interesting technology, and it looks cool - but the talk was pitched halfway between a tech demo, and a talk about the organisation that helped it happen. As a result, it didn’t really succeed at either.
Engineering leadership in 2024 and beyond: Skating where the puck is going when the ice is melting
In this session the results of The LeadDev Engineering Leadership Report 2024 were discussed. The tech landscape has been complicated over the last few years, with waves of layoffs. Apparently, 7% of companies had both layoffs and hiring increases in the last year, and 71% of engineering leaders have seen the scope of their work increase. The main takeaway was that leaders should be “skating to where the puck is going, not where it has been”. The landscape is changing so fast, being left behind is a real concern.
Tech debt as innovation, reframing this forever problem as an opportunity
This was a great talk from a really engaging speaker. Tech debt is a natural byproduct of the software development lifecycle, but tech debt has a marketing problem. Tech debt doesn’t come from nowhere - systems that we are advocating for now, will become tech debt.
Bruce defined tech debt as the delta between a system’s current state and its ideal state. It is not business decisions you don’t agree with, or strategy misalignment. It’s not normal bugs and software errors, or even just bad code. It’s also not inherited code, systems or tools - just because you didn’t write it, doesn’t make it tech debt.
His recommendations for dealing with it include…
- Be specific - what debt exactly are we talking about?
- Make the debt visible, perhaps through metrics or reports that show where the debt is.
- Be proactive - neglect is not a strategy.
Leaders change. Teams change. Business priorities change and technologies change.
Lies that people tell themselves about tech debt include:
- Legacy code == tech debt (just because it’s old doesn’t automatically make it tech debt.)
- Having debt zero as a goal.
- Debt reduction work is only for junior folks, or as part of on-boarding.
- There’s nothing we can do.
We should manage technical debt so we can say yes to the business more.
From overload to oasis: Creating more time for the cool stuff
Cool stuff is relative, and changes over time. Share work that you consider not be cool to create space to do what you do consider cool, and because your boring is someone’s cool.
Managing across timezones; A retrospective
I found this talk decidedly “meh”. Timezones can be a real pain to manage across, but it’s not a particularly complicated issue.
The main points from this talk were:
- Block out “golden hours” - when everyone is online. You won’t always use the slot, but you want it available in case you do need it.
- Experiment with your processes.
- Use async processes as much as possible - wikis, blogs, ADRs, messages in public channels.
- Embrace timezones, and use them to reduce out of hours on call
Building for the new developer
This was a very academic talk, with a much more rigorous evidence base than usual. Unfortunately, I found it a bit unclear and unfocused, and I think it tried to cover too much given the timeslot for the talk.
When we join a new company we look for signals about what success means in that organisation. We use our biases and preconceptions about what a success requires in a field to decide who is brilliant - our biases and preconceptions can be wrong!
There was quite a lot about the AI Skill Threat and how it interactives with a thriving culture, and a contest culture in an organisation.
A learning culture drives up productivity.
Demystifying neurodiversity in tech with nostalgic video games
This talk had amazing slides with a classic video game vibe. Unfortunately, the video game theme didn’t seem to apply to anything other than the slides, which felt like a bit of a missed opportunity.
They said that 53% of people technology are neurodivergent, but only 3% are disclosed. To help people work better small accommodations make the world of difference. And don’t be afraid to make suggestions - neurotypical people can make good suggestions too.
Try to take advantage of people with a different point of view, and a different way of thinking - dissent opens the mind. Be careful though, because unresolved conflict leads to a disengaged team and lower productivity.
Only 1 in 4 people is diagnosed as a child, so they are often learning what works best for them. Some people produce a “user guide” or a “working with me manual” which describes how they like to work and helps to avoid conflict.
How to use technology radars to make transparent tech decisions
Most people question a technology choice when they join a company.
To create tech radar:
- Get leadership buy-in.
- Document all technology choices, including retroactively.
- Use human-centered design to make the radar easier to use.
- Build a culture of documenting technology choices.
You should use the tech radar to question established technology choices.
Building a tech radar is easy, but building a culture of documenting decisions is hard. It takes time to embed that in a company culture.
Delivery metrics - the good, the bad and the utterly ridiculous
This talk was about measuring the performance of software teams, although it didn’t include as many examples as I had expected based on the title. Jennifer talked about the importance of distinguishing between measuring “What are we building?” vs “How are we building it?”. One key measure she mentioned was the “goal ratio”. This is based on the fact that we know the sprint goal, and we know the work in the sprint. The ratio of work that is goal related against total work in the sprint is the “goal ratio”.
Measure for change
Measuring and improving are two different things. If we want to improve we must change the way we measure. We should measure for change, not for control. To drive change it is important to involve your team, tie data to decisions, and always follow up on actions.
Quantitative data is easy to measure, but usually, it’s not clear how to improve. Qualitative data is much harder to measure, but makes it much clearer how to improve.
Software is made by humans, for humans, and disregarding the feedback from the humans (developers) making the software only gives you half the picture. Developer productivity is complex - quantitative data is rigid, and you can only measure what you think to measure.
Developers know where the problems are, so just ask them. You can correlate sentiment with data from your build tool.
This was a talk from a conference sponsor (DX) so it was clearly a talk that was justifying their product, but it was not that obvious, and Laura focused on the problem rather than how their tool helps to solve it.
Data science demystified
This was a strange talk. As the title implies, it was a basic overview of what Data Science is and how a Data Science team works, so the talk did what it set out to achieve. I’m just not sure why, and I’m not sure who in the audience wouldn’t know what Data Science is.
You are here: The story of the Barbican
As was the case with the previous two LeadDev London’s that I’ve attended the first day was closed by Nickolas Means, who is a brilliant storyteller. In previous years he has talked about Fukushima, the Boeing 737 Max and Three Mile Island. In a change of pace this year he didn’t talk about a disaster, but about the history of the Barbican. He started by dropping the bombshell that this would be the final year of LeadDev at the Barbican (although the new venue wasn’t revealed until the end of day two), and then worked his way from the end of World War II through the design, planning and building process to the present day. I will always recommend Nickolas’ talks, although in this case it’s probably more interesting if you have a connection to the Barbican. The general management theme he drew at the end was a bit tacked on, and not as immediately relevant as in his previous disaster talks.
Comments