The Lead Developer UK conference - part one

Last week, on 8th & 9th June, a few of us attended The Lead Developer UK conference in London. Meri Williams, who was the conference chair, together with the rest of the staff, did a wonderful job getting a lineup full of bright, engaging speakers. It was an extremely inspiring event, filled with great talks and useful advice that we want to now incorporate into our workflows. Here’s an attempt to write down what I personally found most useful from each of the talks - however, this does not do the justice to the work that all the speakers have put into their presentations - I strongly recommend watching them when videos become available (will update this post so please check back).

Photo of uSwitchers at the conference From left, sitting: Jamie, Aleksander, Viktor, Tomasz, Fell and Tom standing

The Constant Life of a Tech Lead - Patrick Kua

In the opening talk of the conference, Patrick shared valuable learnings acquired over years of consulting - he’s a veteran at ThoughtWorks and spent last 13 years working with clients across the globe. In his experience, any number of problems with product delivery occur regardless of company’s size, number of teams they have or countries they work in. He introduced the idea of ‘constants’ that are always proving to be a challenge: tech, people, system.

When thinking about tech, Patrick urges developers to think of programming languages as tools, and to favour learning patterns and principles that will outlast the actual technology.

When talking about people, Kua believes it’s important to recognise what makes us unique. Diversity is what gives us strength. Successful people often focus on their strengths and use them to their advantage instead of just trying to overcome their weaknesses. This was one of many times where the conference talks touched upon how a tech lead’s role has the capacity to multiply the output of a team, by removing blockers and building capabilities within the team.

Finally, the system: process management, and making sure you are able to prioritise and delegate when appropriate is an important skill to have. Patrick referred to the Eisenhower Matrix, pictured below, as a guideline to follow.

Eisenhower box Image credit:

In addition to that, Patrick encourages tech leads to not fall victim to a single loop of Action -> Result; instead consider that problems may exist within our understanding of the problem itself. This double loop learning is easily exercised by carrying out retrospectives.

Double loop learning

Picture: Double Loop Learning

It was a fantastic opening to a conference that really set the overarching theme of the next two days: diversity, communication, and learning about yourself and the people who surround you.

Things You Wish You Shared With Your Team Before They Agreed on That Deadline - Dominika Rogala

How long is a year? A month? A week? Right off the bat, Dominika shatters the illusion of having more time than we think by asking when was the last time you had eight uninterrupted hours of productive time at work? All the things we need to do need to be accounted for in task estimation: research, documentation and context switching.

Dominika pointed out that December 24th is always the day Christmas is celebrated on (at least in Poland, where she is from!), and that’s because when it comes to this holiday, time can’t be something you compromise on. In work, you can choose other priorities to adjust how you deliver: quality or cost.

This talk made it clear that you can’t just think about actual work when it comes to estimates, but also all the things that happen in between. There are traps, such as thinking “I’ll just do it in the meantime” or not accounting for context switching when estimating work.

Time, traps, priorities: as leaders, are we sharing this information and providing context to our team? If they understand this from the start, they can concentrate their efforts in the right areas.

How to Talk to Earthlings? - Adrian Howard

Adrian shared a lot of interesting insight about his approach to talking to colleagues. He suggests we learn from all the research that has been done to improve UX interviews. After all, that’s also a process that involves communicating with people. The part that resonated with me the most was his insistence on asking for stories. When it comes to user testing, we know people are bad at thinking about the future, so we draw from the past instead. Rather than asking leading questions such as “Would you use an app to help you book holidays?” you ask about experiences, “What was the best holiday you’ve had? What made it great?”; when it comes to your 1on1 with a colleague, you could ask “What was the most productive team you worked on?”.

Adrian’s basic rules to communicating with your team are: Shut up. Stay quiet. Reflect back. Ask for Stories. Insights versus Observations.

Insights versus Observations was a particularly interesting rule. It’s easy to mix observations (what people say and do) and insights (conclusions we draw from the actions). It’s best to make a note of and learn from both.

When it comes to the actual conversation, listening is an extremely difficult skill; don’t just wait for a gap to interject with a response. Stay quiet. The other person will often continue the point they’re trying to make. Also, responding with phrases and words the other person has just used can show them you understand what they are trying to communicating, e.g. “So what you’re saying is...”.

Ask vs. Guess Culture Communication - Katherine Wu

Katherine explained the difference between ‘Ask’ and ‘Guess’ cultures. The former has a communication style that’s more direct; the latter favours subtlety and putting out feelers. There’s no right or wrong, and we all fall somewhere on the spectrum between these two. It’s important to recognise that, and it will help you communicate with someone who may have the opposite style to yourself. The tips Katherine shared:

For “Ask”:

  • Make a guess culture friend
  • Listen more closely, for the things people don’t actually say
  • Simply apologise if you realise you’ve misinterpreted something

For “Guess”:

  • People might be unaware of “the rules” (if someone offers you tea, and you refuse, that might mean you still want tea - but you’re politely refusing, at least once)
  • Resist the urge to soften a “no”

Time to Focus on Your Goals - Maria Gutierrez

Maria’s talk was one of many that inspired me to take direct action. She spoke about ways of making sure you have the time to remember what your goals are, and ensuring that what you do aligns with them. She takes one day a year to review her personal development such as what are the goals for next 12 months and why are they important. You can look at profiles of people you admire to get some inspiration; better yet, set up lunches with people who you look up to and nurture a diverse network.

Maria also takes five minutes with her son every day to explain what they’ve learnt today to each other. By having to present these learnings in a non-technical way, she gets to reflect and think about the day, which helps acknowledge accomplishments.

5 Features of a Good API - Rob Allen

This was the first talk of the day that was a bit more technical. I thought this was a problem quite well discussed over the years, but Rob did not disappoint with his insights.

The five features are:

  • Malleability
  • Correctness
  • Error handling
  • Documentation
  • Security

Two highlights for me:

  • Keep full links in the objects you refer to, so that your API clients don’t need to have any hardcoded paths
  • Definition of an error response, it’s actually defined in RFC 7807. Example below:
   HTTP/1.1 403 Forbidden
   Content-Type: application/problem+json
   Content-Language: en

    "type": "",
    "title": "You do not have enough credit.",
    "detail": "Your current balance is 30, but that costs 50.",
    "instance": "/account/12345/msgs/abc",
    "balance": 30,
    "accounts": ["/account/12345",

Leadership Lessons from the Agile Manifesto - Anjuan Simmons

The first part of Anjuan’s talk is very entertaining reference to The Hero with A Thousand Faces, which outlines a universal motif of hero’s journey, comparing it to situation where a developer transforms into a tech lead. There’s a similar cycle for developers, where we accept a challenge, use a mentor’s advice and follow through, coming out at the other end richer with experience and become a mentor ourselves for the next hero.

The second part talks about the agile manifesto and how it applies to the role of a leader:

  • Individuals and interactions over processes and tools - recognise contributions, preserve dignity and value face-to-face communication.
  • Working software over comprehensive documentation - “working” always ships faster than “perfect.” Ship early and analyse findings.
  • Customer collaboration over contract negotiation - customers trust colleagues, not contracts. On the flip side, know when to let a bad customer go.
  • Responding to change over following a plan - don’t fear surprises, fear inflexibility.

The agile manifesto has been around for a long time, but it was great to have this fresh perspective on it — and remember not to just ignore the items on the right!

YOLO Releases Considered Harmful - Running An Effective Mobile Engineering Team - Cate Huston

While at the surface, this seemed like it could have been a fairly technical talk, Cate did a great job of highlighting themes that will resonate for just about any software engineering team. There were a lot of themes that are well worth considering when trying to build an effective team:

  • Predictable release cycles (you can’t roll back on an app store!)
  • User onboarding experience versus existing user experience
  • Using data to tell a story
  • Agree what success is and how to measure it
  • Accountable team

I thought that this last point was especially important. It’s difficult to create a culture of accountability. Make sure to own up to mistakes and show that it’s ok to make them. “Healthy teams are made of healthy people.”

Forty-Two Months of Microservices. Stairway to Heaven or Highway to Hell? - Sander Hoogendoorn

I would describe this talk as a good summary of the last few years of discussion around microservices. Sander covers all the issues with monoliths and presents the alternative with microservice-oriented architecture. Among the benefits, he lists the ability to choose the most appropriate language for each part of the system, continuous integration, independent deployments and also highlights the importance of having your architecture written down in the form of code. This allows you to rebuild quickly and understand everything that is needed to run the application.

Better: Fearless Feedback for Software Teams - Erika Carlson

As difficult as it is to choose, I think this was my personal favourite of the entire conference. I wasn’t alone; many speakers that followed Erika referred to what she had to say.

People are bad at feedback — both receiving and giving it — and it is a difficult skill to master. It matters as it’s one of the simplest way of avoiding problems, but it’s challenging because it requires openness, maturity, self-awareness, courage, vulnerability, confidence and trust — that’s quite a list!

I encourage you to watch the video of the talk when it’s published, but here’s a short version of Erika’s Feedback 101:

  1. Listen actively. Pay attention to your body language, confirm understanding especially when receiving constructive feedback.
  2. Say thank you. When it comes to both positive and constructive feedback, don’t diminish what you’ve done; don’t get defensive if it isn’t something you expected to hear.
  3. Respond (later). Emotions go away; decide how you feel and how you want to respond after letting yourself cool down.
  4. Assume the best. “Feedback is a gift for the purpose of helping you grow.”
  5. Be specific. Name actions and behaviours.
  6. Let it land. Feedback needs to be direct and unmitigated.
  7. Be collaborative. Ask before giving feedback; find out how they’d like to receive it best.
  8. Avoid anti-patterns. Don’t attack character; focus on what they did, not who they are. Provide positive feedback in public and constructive in private.
  9. Lead by example. Good feedback culture starts with leadership; structure (1on1s, retrospectives, etc.) is a good scaffolding to build upon.
  10. Practice. Find a mentor or practice with a friend.

The Original Skunk Works - Nickolas Means

I was not familiar with Nick or any of his previous talks. So, when Meri, who introduced him, said we were in for a treat I had no idea what that meant. Nickolas turned out to be an amazing storyteller and captured the entire room’s attention with a fascinating journey of engineers who were building stealth planes. Great examples of hacks, prioritising users’ needs, favouring small, independent teams had a lot of value almost 100 years ago, and they are still very applicable today.


First day of the conference was great - summary of day two can be found here.