The Lead Developer UK conference - part two

Summary of day one can be found here.

Fail Fast, Fail Smart, Succeed - Kevin Goldsmith

Second day of the conference started off with a presentation on failures - and how important they are to successes. Kevin presented the idea of minimizing the blast radius. Small explosions are OK as they propel you in the right direction as you learn from them and improve. He recalled IBM having multiple teams working on the same problems just so that they fail in parallel.
From his most recent experience, Kevin told us about Spotify Now, a promising feature in the online music streaming platform, which was developed in secret. When it was finally tested with a small sample of users, it performed great. Unfortunately, due to the fact that testing was so limited, the team missed the fact that there was another change being tested at the same time that affected the outcome of the results. What they thought was a great success actually had a negative impact on their bottom line. It’s preferable to have small, continuous releases from which you learn and improve over time.

Minimize the cost of a failure; once something is in your production code, you have to support it forever.

We're Agile, We Don't Do Documentation - Birgitta Boeckeler

As agile manifesto states: Working software over comprehensive documentation.

But it also says “while there is value in the items on the right, we value the items on the left more”, and Birgitta explained her perception of values of documentation, what is the right amount and how to do it.

A lot of the suggested practices involved drawings; have a limited amount of space where you share a high-level overview of your application and parts within. The space constraint helps you get rid of too much detail, but also surfaces complexity and provides the team with shared understanding.

When it comes to the usual problem of keeping documentation up to date, Birgitta suggests just having as little of it as you can get away with, but keeping it visible by including it in tech catch ups or other rituals.

Building and Scaling a Distributed and Inclusive Team - Mathias Meyer

This was a rare glimpse deep into the inner workings of a remote company.

First of all, Mathias recognised the value of going remote: you can hire from all over the world, helping you grow the diversity of your team. Being remote also means you have to spend extra effort on being inclusive and transparent. It was interesting to see how the open source roots of the employees translated to how they work. GitHub repositories and issues are used for almost everything at Travis CI; aside from the code, documentation (both technical and non-technical, e.g. onboarding processes) and even discussion around company values live on GitHub for everyone to see and participate in.

Mathias acknowledged that having a distributed team does incur a tax on communication, and it’s easy to misinterpret tone and nuance in writing (something to look out for). His team still jumps into voice/video chats and meets up in person to try and combat that.

Big Rewrite Strikes Again - Sabrina Leandro

Sabrina guided us through the steps to follow when trying to get rid of legacy projects and propose a rewrite. First of all, you need to have a clear business case, and it can’t just be an experiment in technology. Sell it to the team and stakeholders and make the pain visible (i.e., explain how difficult it is to extend or modify current system).
Following that, prototype (speaks to what we’ve learnt earlier about learning and failing fast) and iterate. It’s probably easier to build the greenfield project and maintain the legacy application side by side, letting the new version take over the critical features until the old application can be killed. This idea is often called Strangler pattern. Cut features to move faster. Question to consider when choosing how to prioritise: If we were starting over, what would we build today, knowing what we know now?

During the project, make sure you make the progress visible and don’t forget to celebrate successes!

Finally, to ensure you don’t need to repeat the cycle, refactor on a regular basis. Delete unused code, unused features and unused products.

Continuous A11y - Automate the Hell Out of It - Patrik Karisch

This was one of the more practical talks of the event, providing something you can apply into work straight away. Patrik explained the ideas behind accessibility and the benefits, which include of course making the site easier for users with assistive technologies, as well as the SEO value and even the legal need to make your product accessible.

A11ym - Accessibility Machine is a tool that you can add into your continuous integration to help you automatically test your product.It provides clear output in form of a report that points out things you can action.

Mentoring Junior Engineers @ Slack HQ - Carly Robinson

Carly’s story is seriously impressive - she’s gone from being an actress her whole life to learning how to code and getting her foot in the industry with a job at Slack (to speaking at Lead Dev conference!) in a drastically short timespan.

She recognised the perks of the environment at Slack that allowed her to succeed:

  • Mentorship - having the support to grow as an engineer.
  • Ownership - being responsible for valuable production features; having stretch assignments that take you out of your comfort zone.
  • Feedback - frequent communication and opportunity to self-reflect.
  • Clear expectations and accountability - transparency about what is expected from the role, with regular meetings to discuss the goals (which need to be measurable).

Carly made a move from one tough industry to another, but self-determination (she spent a lot of time in bootcamps and training programmes) and continuously asking for direction on how to improve made her successful.

Implementers, Solvers, and Finders: Rethinking the Developer Career Path - Randall Koutnik

Career progression of software engineers often is described as eventually having to go into a management position. Randall shares a fascinating perspective on the growth within the role that he sees:

  • Solution Implementer given solutions
    produces code
  • Problem Solver given problems
    produces solutions
  • Problem finder given context
    discovers and prioritizes new problems

The way to help developers on this path is through involving them in discussions around problems and the wider context, otherwise they’ll get bored of just implementing someone else’s ideas.

Tech Hiring is Sometimes an F- Experience - Crystal Huff

Hiring is difficult. You need a process to eliminate as much bias as possible and make sure every candidate is treated equally. You need to make an effort to ensure your company culture is welcoming, and think about what it will be like to hire that first person that might be very different from you. Crystal encourages talking about it, reading and then talking some more.
As we’ve learnt throughout the last two days of talks, diversity is crucial for success. As is thinking about the questions you might want to ask your candidates, so that you don’t end up asking whether they’d eat kittens to get the job (an actual question from a process that wasn’t very well thought out).

Making the leap from execution to strategy - Sally Jenkinson

DA replacement talk for Jenny Duckett’s, who sadly was unavailable to do hers - despite having short notice to prepare, Sally delivered a captivating story of her progress from a designer to head of technology to now being self employed.

She points out that it’s OK to move to a more strategic role; it’s going to help you grow as a developer, too. Sally highlighted how thinking strategically helps you realise that not all problems need to have a technical solution. Her advice, when it comes to moving to more hand-off roles:

  • Gradually expand your responsibilities (unlike making the leap mentioned in the title).
  • Make new friends in different circles - once again stressing importance of mentorship.
  • Learn to communicate to different people in different ways; hinting at what we’ve learnt in previous talks, e..g Ask vs Guess culture.
  • Continue having side projects, regardless how silly.
  • Watch out for burn out; take time to reflect.

The Inclusive Leader: Tips for Developing Diverse Teams - Jill Wetzler

The message that resonated with me from Jill’s talk is that levelling up others is your job in leadership roles. You can achieve that by granting them trust, being aware of what makes them unique and their culture, making personal connections and advocacy, but not forgetting feedback.

Valuable lesson on feedback was a few questions Jill suggested to ask yourself before providing it:

  • Would i give the same feedback to someone of a different gender (or race, etc)?
  • Am I asking someone to be something they are not (i.e. asking an introvert to be more outspoken)?
  • Have I made a statement about who they are or "tend" to be? Remember, we should not judge on character.
  • What feedback should I be giving to others, too? If the advice is for someone to be more vocal, should others stay quiet?

Centralising the Right Things - Tom Booth

It was exciting to see uSwitch being represented by Tom on the big stage. He’s already covered a lot of the detail about the evolution of our infrastructure in a recent post "Evolving our infrastructure", and the talk gave a summary and a retrospective view.

Depending on your company size and culture, centralising might or might not be right. For uSwitch, there was a point where all of the control was given to the teams and individuals within them. While this had benefits in autonomy and helping us get better at DevOps, the downside as we grew bigger was that teams started to solve the same problems in slightly different places. However, by experiencing these problems first hand, centralising some of it felt right. And the values we hold dear, such as autonomy, still allow us to experiment and learn from each other. It’s important to continue learning and re-evaluating what is the right balance for the current size of your company.

Leading by Speaking - Lara Hogan

The final talk of the conference was very meta. Lara described how we have to give talks in public all the time, and people share similar fears when it comes to all of them. Daily standups, pitching project and, architecture reviews are all opportunities to speak up. And, as scary it might be, Lara suggested a few tips to make it easier.

  • Think about what you want to say. What is the message?
  • Delight yourself. Without distracting the audience, try and refer to amusing stories or keep something in view that helps you smile (Lara uses a picture of a sloth).
  • Practice and get feedback. Recruit a few colleagues or friends, and practice in front of them preferably people who are good at giving feedback).
  • Prepare for your environment. Wear comfortable clothes, spend a minute striking a power pose to energise yourself just before the talk.
  • Finally - celebrate after it’s done.

We all have something worth sharing and talking about.


I can safely say this is the greatest conference I’ve ever been to, and it has taught me a massive amount in an extremely short time span. I’ll do my best to review videos from the previous two years of conferences and continue to make notes on how to improve and level up myself and my team. Every speaker had valuable lessons to share and I’m looking forward to coming back!