LeadDev London 2023 (Day 1)
Recently I was lucky enough to attend Lead Dev London for a second time (see my review of 2022 day 1 and day 2). As with last year, this is a one-track conference focused on leadership and engineering management. Unlike last year LeadDev was also running a separate one-track conference at the same time, StaffPlus, focused on Staff+ engineers. As I didn’t have a ticket to that, I didn’t attend any of those talks but it was great to see LeadDev expanding and I’ll be considering StaffPlus next year.
The event took place at the same location, the Barbican in central London. The auditorium is a lovely space, with excellent sight lines from everywhere and good acoustics. The spaces outside are pretty tired looking, and in particular, the toilets were terrible. For a 1000+ person conference, this took the shine off attending. The food provided was good, and the logistics of the lunch rush were handled well. This year the networking mixer was held downstairs in the sponsor’s hall, whereas last year it was upstairs in the breakout space. I felt the sponsor stalls got in the way rather, and prevented people from mixing. I think the addition of something to help people mix would help break people out of their company groups - whether it’s a kind of speed dating system or something a bit more low-key, just handing people a beer and leaving them to it doesn’t work.
On stage, things were generally slick, with Meri Williams MCing again. The conference suffered from a few technical issues, with clickers repeatedly not working, a few microphone issues and some issues with videos playing without sound. Some issues are understandable, but it was a bit disappointing that they hadn’t been ironed out by day two.
Compared to last year the conference has added several activities in the gaps between conference sessions. These included live coaching, table talks and AMAs with LeadDev staff. I only tried attending a table talk, and it was too noisy to properly engage in, which was a real shame. To help navigate all the activities two new “experience hosts” were added (Jessie Belle and Amber Shand, who were presenters last year). They added a great feeling of energy to the proceedings, but having three people on stage at the end of each session of talks was a bit slow, and most people just want to get up and stretch their legs. Hopefully, LeadDev will find a better way to promote the extra activities. Even just having Meri at the start and Jessie and/or Amber and the end of each session would have made things run more smoothly.
Those a minor niggles though, and I hope to be attending again next year. Anyway, onto my summary of some of the talks. LeadDev will put the videos online at some point, but as I write this they are only available to people with tickets.
Managing at the threshold: Examining our principles in a moment of change
In 2002 Google removed engineering managers and switched to a much flatter org structure. This lasted for a few months, and a few years later in 2009 Google published Project Oxygen which describes what they had learned about engineering management.
For years it was accepted that the most senior engineer in the room would be your manager, but engineering management is a skill in its own right.
After COVID-19 there was a period of change known as “The Great Resignation”, which was people taking control of their careers.
A Liminal Space is a space between states. It is space where we change. If you are in a Liminal Space nobody is going to tell you want to do. If you don’t have a process you can trust, you have principles you can follow. Stay true to those.
- Notice
- Think
- Persuade
- Proceed
Compassionate on-call
Flexibility
You shouldn’t have to stop to go on call.
Autonomy
Anyone on call has to be able to fix their own pain.
Support
Anyone on call must have support they can use.
Pager Load
The foundation of sustainable on-call.
Red 2.0: Transforming a game company
Colin Walder
This was a talk about the process of changing a games company after the disastrous launch of Cyberpunk 2077, which was riddled with bugs and poorly received, even after the team had worked a significant amount of crunch time on it.
Unfortunately, this was a pretty bad talk. There was some talk of how the teams were restructured, but not in enough detail to be useful to others. There was some talk about how they adopted agile processes, but this was not a talk about agile, so lacked details - and how many people other than games companies are not already using agile?
This talk might have been interesting if it was after the release of the Cyberpunk expansions that is coming later this year, so they could compare the development process and reception to both, but since it’s not been released yet there is not much to compare yet.
What do you mean there’s no onboarding plan for engineering managers?
Starting a new position is hard, and starting as an engineering manager is doubly hard because as a manager you will have people immediately looking to you for guidance, inspiration and support, despite being new to the company.
The key factors for a good onboarding plan are creating a sense of belonging, and delivering a sense of accomplishment. It should prepare people for their new role, and connect them to the culture.
Things that should not be part of the plan are making technical contributions, and making big changes.
New employees should own their own onboarding, so they are in charge of the pace and content.
Code is poetry
Maintaining a clean code base can have a huge impact on team performance. It will help you to:
- find bugs early
- add features quicker
Try to encourage strategic programming over tactical programming. Schedule time for spike sessions before you tackle a big project, because the first idea might not be the best. Recognise strategic programming with rewards.
All code should look like one person wrote it, so normalise nit-picking - but be kind!
Why onboarding to a company’s legacy codebase sucks, and how to make it work for your team
When onboarding you need to learn a number of things…
About the code/system:
- how does it fit together?
- what are the domain objects?
About working with the code:
- deployment procedures
- how to test
But you need to remember that people are human! Memory retention is an issue, and it’s hard to learn new things.
Treat every code review as a mini onboarding to that part of the code. Start small, and expand the scope strategically. Choose tasks that will build confidence in the codebase - tasks that require learning a small number of new things.
Tech debt reduction can be a good first task. Upgrades need little knowledge.
Learn about the frameworks used, as well as the implementation.
Making the move to manager: Common pitfalls for new engineering leaders
Jacqueline Pan and Marlena Lui
It’s ok to say “I’d don’t know” - be yourself!
Know where your time is best spent, and at what level you need to know the details.
“I’m happy where I am” - Supporting team members that aren’t seeking progression
There is a myth of constant promotion.
The practice of an art isn’t to make a living, it’s to make your soul grow
– Kurt Vonnegut
Recognise cycles of ambition in your reports, and try to support them when they are ambitious and when they aren’t. Try to create a sense of development - grow in their role, not just move up.
Don’t deprioritise these people.
How to drive pace in your team
Pace is value delivered at speed.
Set some defaults:
- what are you willing to compromise on?
- what are you not willing to risk?
Give lots of room for autonomy, and be transparent by default.
Create some hype! Get people excited about the value they will bring. Keep projects very short, and keep them simple - use tried and tested technology. Aim to do the hard bits first, and remember that work done is more important than work started.
Be laser-focused on value. We’re not here for fun, we’re here to make money!
Aim to beat deadlines - where can you get the best value for the time left over?
Pain is expected, and that’s ok - but try to give people on-call a break!
There are risks with being this focused on value:
- too much pressure
- poor code quality (so aim to make active tradeoffs)
- unhealthy competition
- not everyone is fast in the same way
How we support making architectural decisions
This was a description of their current process for making architectural decisions. They have seven members of Technical Design Architecture Advisors. They have different domain knowledge, and they rotate members regularly. They aim to be advisors, not gatekeepers.
This article from Stack Overflow was recommended as it describes how to write a technical design document, and gives a good structure to start with.
Once a change has been proposed they spend 3-4 days gathering further details, and 3-4 days discussing them in the group before making a decision. The possible outcomes are:
- Sponsored - they approve this change.
- Needs update - the proposal needs more work.
- Not recommended - they aren’t gatekeepers, so can’t say no, but they suggest not to do this change.
- Review not needed - this is an area they don’t cover.
- Escalated - for some reason, this needs to be looked at by senior management.
Where we’re going wrong with developer productivity
- Productivity is the stuff that is hard.
- Productivity is never stopping.
- Productivity is lonely.
- we need to work together!
- Brittle productivity.
- productive if nothing goes wrong.
vs
- Resilliant productivity
- when something goes wrong, it delivers.
Thriving means:
- Agency
- Learning Culture
- Motivation & Self Efficacy
- Support & Belonging
Good managers blame processes not people.
Good productivity is adaptive and sustainable.
Engineering A More Equitable Hiring Process
Equity = treated differently to enable the same outcome.
Tolerance = You are allowed to be here.
Inclusion = We want you to be here.
Avoid pedigree bias - where they went to school or worked.
Decouple assessments - clarity of speech and explanation vs just communication.
How to effectively “Spike” a complex technical project
First, understand the problem, then understand the technical landscape.
Don’t…
- write clean code
- solve for everything
- take all the time in the world
After the spike…
- what’s new?
- what’s being modified?
- what do we need to discuss?
“Those with knowledge don’t predict. Those who predict don’t have knowledge.”
The 9.1 magnitude meltdown at Fukushima
Nickolas gave the closing talk to day one of LeadDev last year, and this talk was equally excellent. It’s impossible to take notes for, but do watch it if you can find it online.
Comments