LeadDev London 2024 (Day 2)
This is the second part of my write up of the LeadDev London 2024 conference. To read my thoughts on the talks from day 1, and my overall impression of the conference please read my previous post. As with that post this is just the summary of my notes, so will give you a flavour of the talks. This should help you decide if you want to pay for a digital pass to access the videos, or if enough time has passed to look them up on YouTube or the LeadDev site.
In the afternoon I attended a workshop by a couple of Google engineers on DORA. I’ve watched the recording of the talks I missed, so I’ve included my thoughts on those below. My write-up of the workshop is at the end of this post.
And with that out of the way, on with the talks…
Build great engineering teams and have a positive social impact
Germán Bencci and Seraphine Young
This was a talk about the Code Your Future charity. They do digital skills training for refugees and disadvantaged people. There was no leadership takeaway from this talk, but one fact that I was not aware of is that 1 in 78 people in the world is forcibly displaced. This is an awful lot higher than I would have guessed.
While the talk was fine, and the charity is certainly worthy they didn’t really have an “ask” at the end of the talk. I would have been ok with them asking for donations, but they didn’t do that, or talk about how you could get involved. I left the talk feeling glad that a charity like this exists, but not with a sense of how I could help.
Revolutionizing engineer growth: The tech-powered blueprint for careers clarity at ASOS
Gareth Waterhouse and Ed Collins
This talk was a case study about introducing a careers model as ASOS, the online clothing seller. It wasn’t clear what an engineer needed to do to get promoted, and they were getting low scores in employee satisfaction surveys. They also knew they had to support “squiggly” careers, where people move back and forth between different crafts as their career progresses.
They produced a set of conversation starters with versions for managers and engineers on how to approach career meetings, and what questions to ask. They also produced documentation that covered “What does good look like?”. It also included “How should <role> think and act?”, and “What should <role> do?”. They also produced a website where you could use sliders to measure yourself against different competencies, and then it produced a radar to highlight your strengths and weaknesses.
Making smart investments: A framework for maximizing your ROI in technical decisions
Everyone makes technical decisions. Some are big decisions, some are small - but everyone makes them. Even if you want your team to make decisions, you have to give them guidance. Is how you define gain the same as your team or your manager? Bias affects how you see gains, and overlook costs so try to be impartial.
Katerina then presented a model for how to make technical decisions
- Potential. Try to use metrics to identify the gains.
- Risks. Identify constraints and uncertainties. Do we have the money and resources for this project?
- Involvement. Who needs to support the project? Get their buy-in.
- Skills. Do you or your team have the right skills?
- Motivation. How excited are the team?
Risks + Involvement + Skills = Cost
Potential + Motivation = Gain
Iterate to greatness: Building high performance, AI-native engineering teams
This was a blatant pitch for Vercel, which in itself is not a bad thing, but it was so overblown that it just seemed like a puff-piece of AI hype. There was an interesting section in the middle of the talk about testing AI models and using data to improve and guide the training. One of the key points seemed to be that Vercel made it incredibly quick to deploy, on the order of seconds to deploy a new AI model. There was no talk about actually implementing functionality, it was just AI can do everything for you. Avoid.
Beyond the hype: Practical steps to establishing and scaling your data & ML team
In the age of AI dominating everything (see the previous talk!) this was a talk advocating for “traditional” machine learning and data analytics not to be forgotten. Ellissa works for a company that are trying to balance electrical grid supply and demand, which is important with an increasing share of green sources. They do this by turning large industrial appliances on and off.
The value proposition was established using a spreadsheet, and then they gradually evolved their data strategy by automating the many data requests Ellissa’s team were getting.
The Post Office Scandal: What we can learn from its process and human failures
This talk was a summary of the Horizon IT scandal, which caused more than 900 subpostmasters to be wrongly convicted of theft or fraud due to problems with the IT system. This was an excellent talk about the potential real-world dangers of an IT system. In 2000 it was decided that UK courts should assume that computers were working as intended, the same as they do with traffic lights and speed cameras. Anyone who knows how many bugs there are in computer software will find this terrifying…
The key message from this talk was that we should give our teams the right skills to do their jobs. We should listen to users and teams, and not bury our heads in the sand about potential problems. We should also trust people over systems, but verify to ensure our trust is well placed. And finally, we should be humble about our software.
The boss’s shoes don’t fit: And other surprises of leadership
This was a talk about the early stages of becoming a manager.
- Speak less - you are likely not the most knowledgeable person in the room. Also, as a manager, your words will be amplified 10x. Listen more - if you avoid micromanagement you can become an absent manager, so be engaged and pay attention.
- Speak more, but differently - explain the way you are thinking, and explain why something is important. Be curious.
Diffuse the situation if necessary. You’re in other meetings, so be generous with the knowledge this gives you.
Connect the dots. - 5:1 ratio of positive to negative feedback. (There’s a lot on this in other talks and books, but I’m not convinced it’s a good thing to follow.)
- Be a good storyteller - accomplishments don’t speak for themselves.
- Celebrate! Credit is infinite.
Uncertainty of change
This talk is worth watching for the slides alone. They zoom and slide over the screen, connecting one screen to the next in a very slick way. The talk started with some examples of people or companies who resisted change - the Luddites (who resisted textile machinery), Sears (who failed to adapt to online shopping), Blockbuster (who had the chance to buy Netflix and didn’t), and Nokia (who were sold to Microsoft and still failed to remain relevant).
Jitesh then moved on to talking about the psychology of change, and how people resist big change because it’s hard to predict, but small changes offer more certainty. They talked about our fight, flight, freeze and faun (i.e. submission) instincts, and how we can’t tell the difference between a change in a team’s ways of working and a bear.
They then moved on to the difference between complex and complicated. Complex systems are unknowable due to emergent behaviours, while complicated systems are difficult to follow and understand, but are ultimately knowable. They described how modern software is complex, not complicated.
Testing gives us certainty about how systems perform and should be focused on reducing uncertainty, not catching bugs.
Managing the marathon: Leading teams through lengthy migration projects
Migration projects are a staple of software development teams. They are coming for you whether you like it or not. To lead your teams through such a project you should focus on a story that will influence the outcome, and educate your stakeholders.
Highlight milestones as part of your storytelling:
- Landmarks in the development
- Capabilities that demonstrate new features
- Integration milestones.
Become a better storyteller to engage, motivate and inspire your team.
The software bug all stars - and what we can learn from them
This was a quick run-through of some of the times software bugs have had a significant, even life-threatening impact. The cost of operational software failures in 2020 in the US was $1.5 trillion.
The Mars Climate Orbiter was lost after orbit insertion around Mars. The probe cost $327 million dollars, without taking into account the cost of the rocket. The probe was lost because it entered orbit 57 km above Mars, rather than 150km. Lockheed Martin were responsible for the orbiter, while NASA JPL looked after the ground systems. Lockheed used imperial units while NASA used metric (pounds of force vs Newtons) - they are a factor of 4.5 out.
The ground team realised there was a problem while doing testing as the probe was approaching Mars. They alerted management, but management ignored them as they didn’t follow the right channels. The issue was only found a few days before Mars arrival, so there was no time for the proper channels. The result was the probe was lost.
If you have a function like int getTotalAmount() how do you know what the type of the amount is? You need to try and avoid the need
for implicit information, perhaps by using a MonetaryValue type.
The Therac-25 was a radiation treatment device which had a race condition that resulted in three people dying from a radiation overdose. The manufacturer claimed it couldn’t happen, even after it did. The race condition occurred when entering data too quickly. It took two years for the issue to occur because people had to learn and get quicker at using the system.
Be humble and don’t dismiss that it might not be you. Don’t just display error messages - display options and information so the user can make an informed decision about how to proceed.
Date handling is a huge source of bugs:
- The Microsoft Zune stopped working on 31st December 2008 because 2008 was a leap year, and it only handled 365 days per year.
- On the 1st of January 2012 Apple iOS alarm clocks didn’t work. This bug was caused by the fact that 1st January was in week 52 of 2011.
- An F-22 Raptor fighter jet crashed when it flew over the date terminator because the software couldn’t handle the date going backwards.
How to set goals with people who don’t want to set goals
This talk didn’t really match the title. It was Alicia’s process for working with her reports to set goals, but didn’t address how to get people who don’t want to set goals to engage with the process. Still, it sounded like a good process that some people might want to try out.
The first step is to do a brain dump of ideas:
- Think big - do you want to be a CTO?
- Think small
- Include personal life.
- Have they received any recent feedback?
Next, map each item to a timeline of short, medium and long-term. Then draw a line between items that depend on each other.
Finally, you need to shape the ideas and make them more specific so they fit your company’s goal framework (e.g. SMART, OKRs, etc).
Managing Engineering Teams in the Era of AI
While I’ve been pretty negative in my write-up of AI talks, this one was good as it was a clear case study of how they actually added AI to their product, and the issues they faced.
Chris recommended experimenting early so that when you want to add AI to your product the team is ready with the right skills and knowledge. The team was used to delivering features quickly, but AI needed a different pace. In particular, the unpredictability of AI meant a lot more time was needed to handle edge cases than was expected. They also learnt that minor changes in prompts made little difference to users, but took up a lot of development time.
If you’re not part of the solution, you’re part of the problem
This was a great talk, but difficult to take notes from. The idea is that being good is not enough, you have to drive change. Fixing other people’s mistakes is not a sustainable solution - you have to help people get better.
Mentorship + sponsorship
As is often the case with the final talks, this one was also hard to take notes from. When growing in our careers it can be hard to feel progress, mentors and sponsors can help both to grow your career, but also feel like you are growing.
Lara talked about the difference between coaching, sponsorship and mentorship.
- Mentorship is great when you want help onboarding, or need unblocking.
- Coaching is the best tool for internal growth.
- Sponsorship helps you to find more opportunities.
To find a sponsor…
- Do great work!
- Find someone who knows your work.
- Know how you want to grow.
Look for people who will help you grow!
The engineering leader’s playbook: A hands-on guide to DORA
This was the 80-minute micro-workshop I attended on the Wednesday afternoon. The two Googlers, Finn and Rob, who were running the session did a good job talking about DORA and some of the findings as well as facilitating a discuss between the 30 or so people who were there.
The question being tackled was “How do you optimise value delivery from investment in tech and technologists?” They highlighted that DORA is not just the metrics most people know about, but it also looks at how the capabilities of a team predict their performance. Performance means both in terms of the reliability of their software delivery, but also how the well-being of their team members predicts organisational performance.
The key DORA metrics are:
- Lead time for change
- Deployment frequency
- Change fail rate
- Failed deployment recovery time
Teams that have a climate for learning have fast feedback cycles and make small changes.
They also talked about what change strategies work. Communities of practice and bottom-up or grassroots changes work well. Training centres, centres of excellence and big bang changes don’t work.
You can take the DORA QuickCheck to get an overview of where your team sits, and DORA Conversations is an interesting way to spark conversations on how to improve.
Comments