While there were many excellent sessions, I wanted to summarise a few to share more widely. This is a work in progress, I intend to add up to half a dozen highlights. You can see my original unedited notes for all sessions [[LeadDev London 2023-06|here]].
# Where we’re going wrong with developer productivity by Cat Hicks
Cat Hicks' presentation distinguishes between brittle and resilient productivity. Brittle productivity can easily break when issues arise, while resilient productivity is sustainable long-term, even in the face of challenges.
Using extensive quantitative and qualitative data from over 1000 developers and insights from many conversations, Cat found a strong link between developer productivity and factors such as agency, a learning culture, motivation, and a sense of support & belonging.
She warns against relentless work, as it leads engineers to skip reflective processes, harming individual growth and overall productivity. The research underscores the need for nurturing a thriving, resilient work environment for sustainable productivity.
> [!tip] Key takeaways
> - Brittle Productivity
> - Your org will look productive as long as **nothing goes wrong**
> - But when something goes wrong, it **breaks**
>- Resilient Productivity
> - Your productivity builds for the **long-term**
> - When something goes wrong, it **delivers**
>- There is a strong correlation between developer thriving and productivity. This means you can measure thriving and then try and do things to improve this, measure of thriving:
> - Agency
> - Learning culture
> - Motivation & self-efficacy
> - Support & belonging
> - If you never stop, the thing that engineers drop is reflective processes
> [!note] Further reading
> [Developer Thriving White Paper Series](https://www.pluralsight.com/resource-center/guides/developer-thriving-white-paper)
# Code is Poetry by Niranjan Uma Shankar
In his talk, Niranjan explained that our responsibility is to write readable, concise code that abstracts unnecessary complexity and can be easily understood. Well-written code sets a good example and promotes a culture of quality code. Similarly, clear and descriptive ticket descriptions and bug fix explanations are important.
![[Pasted image 20230627122411.jpg]]
> [!tip] Key takeaways
> - Tactical programming ends up with slowing velocity over time
> - Encourage the right mindset, continual shortcuts are expensive
> - Recognise and reward individuals who propose and build strategically
# How to drive pace in your team 🏃🏽♀️by Alicia Collymore
> Pace is value delivered at speed
> \- Alicia Collymore
In her talk, Alicia Collymore underscores the significance of speed and value in team dynamics. She proposes fostering autonomy, shortening projects, focusing on the hard tasks first, and using individuals' unique strengths. However, she warns about risks like excessive pressure, poor code quality, and overemphasising speed rather than value.
> [!info]
> Metrics can be useful but not strictly needed for the below takeaways.
> [!tip] Key takeaways - How to improve pace with teams
> - Put pace at the heart of your team
> - Discuss it with your team
> - Be transparent by default
> - Create some hype
> - Optimise your projects
> - Keep projects short, very short, inappropriately short.
> - Weeks, not months. Even with month-long projects, split them up and get value ASAP
> - Focus on finishing work, not starting work
> - Do hard things first
> - Regroup when something changes
> [!tip] Key takeaways - How to improve pace with individuals
> - Encourage their superpower
> - Not the same for everyone, and different people contribute to pace in different parts
> - Be laser focussed on value
> - Beat deadlines
> - If you finish early, don't fill the time, find the next bit of value
> - Don't *stay* stuck, e.g. 30-60m is ok as a learning process
> [!warning] What could go wrong?
> - Too much pressure
>- Poor code quality
>- Unhealthy competitiveness
>- Focus on speed rather than value
>- False sense of speed