On the 11th and 12th of June, at the iconic Barbican in London, LeadDev hosted the 2024 edition of the conference. I had the pleasure to attend this year as an activity host, facilitating a table talk discussion on the topic of "how to interpret engineering data in a holistic way".
I intend to (time permitting) dedicate a separate blog post to the insights and learnings from that discussion. in this post, I want to share some of the highlights from the talks I attended.
The complete agenda for the event can be found here. LeadDev will release the recordings of the talks in the coming weeks, so I encourage you to check them out if you are interested in the topics.
How do you deliver a feature on the biggest stage in the world?
By Josh McNamee
Josh was being quite literal on his talk title. He works at Disguise, the company behind the software that powered the visuals in the U2 concert at the Las Vegas Sphere.
He highlighted how, in the media industry, everything usually comes together at the last minute. Deadlines are very strict (since the event will happen on a set date!) and communication across teams is key. Bugs are usually discovered very late, and the team needs to be able to triage, track and resolve them quickly.
Although not an in-depth technical talk, Josh shared some of the challenges they faced (like the video being too big to fit the server's hard-drives, or how to project on a sphere without distortion) and how, by working on a close-knit team around the clock (Josh's team was split across two timezones, and one team would pick up from where the other team left off), they were able to deliver it on time.
Engineering leadership in 2024 and beyond
By Lena Reinhard and Scott Carey
This talk was a dive into the LeadDev 2024 Engineering Leadership Report.
For the report, they surveyed 1100+ engineering leaders in the US and Europe to understand how their roles are changing and what these changes mean for the industry at large, especially in this time of (apparent) uncertainty, lay-offs, and remote work.
The survey focused on three main areas:
- Leading in organisations
- how have organisations changed? what do reporting structures look like now?
- Being or Becoming a leader in 2024
- are companies hiring more or less managers? what/how has the engineering manager/leader role changed?
- Industry trends and outlooks
- basically how AI and ML are changing organisations
The five key takeaways from the report were:
- 35% of engineering leaders are working longer hours than before. 7% are working less.
- 84% of engineering leaders had their roles changed in the last 12 months, with 63% having a wider scope than before.
- 44% of respondents had to deal with layoffs.
- Middle management was reduced/cut in 66% of organisations. This number jumps to 80% at large companies.
The report is quite comprehensive, and I encourage you to check it out if you are interested in the topic, following the link above.
You are here: The story of the Barbican
By Nickolas Means
As the title says, the story of the Barbican, the building that hosted LeadDev for the last few years. Ahead of the conference moving to the O2 next year, Nickolas wanted to share the history of the building, and how it came to be.
Although not directly related to engineering leadership, the talk goes through the variety of ways that the team responsible for the Barbican project had to adapt, reshape, change, work with constraints, and find creative solutions to the ever-changing requirements and challenges they faced.
Watch it on Youtube when it becomes available. It's great.
The boss's shoes don't fit: and other surprises of leadership
By Inna Weiner
Inna started her talk by asking the audience if anyone ever thought something like "if only i were in my manager's shoes, I would...". She was there, and, now that she is the boss, she found out that things are not always as easy as they seem.
She shared five lessons/rules she learned on her journey to become the manager:
1. Speak less
It's likely that, as a leader, you are not the person with the most context. However, your words are amplified via a "megaphone". You are the boss at the end of the day.
Any question can be a call to action; any comment may be taken as a decision.
What's the alternative? Listen more.
Not only what's being said, but what's implied, who's speaking and who's not, non-verbal clues, etc.
What if you really need to say something? You don't want to be seen as an "absent manager", so you should definitely participate. You also need to report to your own manager, and they may ask deep questions; you need to know those tiny details.
Which leads to the next rule...
Speak more
Which is kinda conflicting with rule one. However, Inna frames it as a way for you to be more curious. Asking questions, clarifications, explaining your reasoning process and why you are saying or asking something.
You are in meetings that most people are not. Sharing the context that you have is important. Be generous with your knowledge.
5:1 rule: the feedback rule
The ideal positive-to-negative feedback ratio (based on Emily Heaphy and Marcial Losada 2004 research).
Be a storyteller: Framing matters
Accomplishments don't speak for themselves. It's on the manager to share and tell the stories about the success of their teams. "doing the quiet work" won't get noticed.
You should also consider carefully who's the audience of a given message. It's unlikely that your manager cares about the deep details of your project, but rather what's the impact and how it relates to the business.
Celebrate: make it fun!
It's on the leader to celebrate the wins and the team's activities. A few ideas she shared:
- Thank people!
- Prizes, bonuses, awards (not necessarily monetary)
- Credit is infinite (you can give it to everyone)
uncertainty of change
by Jitesh Gosai
What do the Luddite Riot of 1779, Sears' flight to online, Blockbuster's delay in acquiring Netflix and Nokia selling its business to Microsoft have in common?
With the above examples, Jitesh started his talk on the uncertainty of change, my favourite of the whole event.
He goes about stating the obvious: change is constant. Some are small, you just carry on. Some really disrupt your life. You can't know from the "change" itself, so that brings the uncertainty. What changes will be small? What changes will be big?
Certainty is comfortable, uncertainty is not. And that is wired in our biology, a survival mechanism. Change puts us in a state of high alert, which can be either excitement or fear. The difference between one and the other is, usually, in the story we tell ourselves.
Jitesh then explains a bit about the brain, the amygdala, and how it can trigger a fight, flight, freeze, or fawn (submission) response. Individuals usually protest, leave, do nothing, or just go along with changes. These reactions map to each of the fear responses.
And those are good. It enables us to get here. However, our brain is not able to differentiate between a bear and a change in my team's ways of working.
One factor he shared is that change doesn't come out of nowhere. By being more aware of the environment, you can control the impact of uncertainty. You can become more aware by being humble, curious, and empathetic.
Next, he talked about the Cynefin framework, which separates complicated things from complex things. A complicated thing can be known, and some people know about it. Car mechanics and Programming are complicated, but you can find a good mechanic or programmer. Complex things are never fully knowable. Modern code is built on top of tooling, and other tooling, and libraries, and system, and that makes Software complex.
Whenever we make changes, it makes it hard to predict how the system will behave. That's uncertainty. That's the reason behind tests. We add tests to affirm, with some degree of certainty, that the software works and behaves as expected.
As software becomes more complex, we need to develop new ways of testing. He shares some possible strategies to make software less complex:
- Test less: if you have fewer tests, you have less code to manage, less code to understand, and less code to maintain. However, that increases uncertainty: is my software working as expected?
- Add more tests: tests are a way to affirm that the software works as expected. However, the more tests you add, the more complex the system becomes.
- Add more testers: more people, more communication lines, more complexity.
- Maybe more automated tests? well, they are also code, and you will also need to understand it, etc. Which makes it more complex.
For him, one of the problems with current testing is that it's framed as a "bug-catching" tool: you test all combinations and all things together and hope to catch any bug that may be there. He proposes a reframing: what if we take tests as a way to reduce uncertainty?
Instead of asking how to do more testing, we ask how to reduce the uncertainty on our system. All environments are different and unique to your organisation, and there's unlikely to find a one-size-fits-all solution or even best practices. Engineering teams need to find it themselves.
There is some guidance we can use though, and that's where the cynefin framework helps. It tells us to probe, sense, and respond. you probe to better understand what we know; assess what we could do, and respond based on what we now know. That's curiosity, humility, and empathy.
I found myself nodding a lot during this talk. I have often been in engineering teams where the number of tests written was used as a metric for quality, or where team members spent a lot of time preparing on setup or ci to run a test that is not really reducing uncertainty. I'll ommentdefinitely be thinking more about this as I write tests in the future.
LeadDev is not only a great conference, but also a community of like-minded people that are always willing to share their experiences and learnings. I really recommend you to check out their events and talks if you are interested, and maybe join their Slack.