LECTURE NOTES

Lead Dev London

Lead Dev London

Barbican, June 27-28 (2023)

Day 1

Ryan MacGillivray Supporting team members that aren’t seeking progression

How do you help team members who are happy where they are. In other words, how do we break the myth of constant promotion. What is the indidiual’s ambition, noting that this changes throughout our careers. Perhaps we’re prioritizing family or personal development for a season. At other times, taking lead on projects or mentoring at work take priority. Understanding that this modulates across our careers is one way we can get ahead of burnout.

One way we can meet folks where they are when they don’t want promotion is to explore their development path without linking it to promotion. This may require us to challenge the career path outlined at our company. When is it appropriate to encourage someone when they say they don’t want? Perhaps you can give examples of how these paths typically go and be open to hear their career aspirations. What you want isn’t important. It’s about what they want and how that aligns with role expectations at your company.

Alicia Collymore How to drive pace in your team

Productivity metrics can actually distract ICs when moving fast. What we care about instead is the value they are adding. How can we unlock pace on our teams without metrics?

We can prioritize:

Setting team defualts

  • what are you not willing to take risks on
  • put pace at the heart of your team
  • give lots of room for autonomy
  • be transparent by default (encourae public Slack channels)
  • hype your team up

Optimize team projects

  • keep projects very short (get value to your customer as soon as you can)
  • keep things simple
  • do the hard bits first (tackle all the unknowns early to drive down complexity)
  • work done should trump work started
  • regroup when things change (round up the team)

Encourage individual pace

  • hone in on their superpower
  • laser focus on value (80% on the value you are delivering, 20% professional dev)
  • beat deadlines (encourae thinking about the next value add at this juncture)
  • don’t stay stuck (no more than 30 mins; go find someone to pair with)
  • pain is expected; allow things breaking to be ok

What could go wrong?

  • Ensure you’re not putting too much pressure on your team. Regroup and reset expectations where needed.
  • Make sure we’re not dipping into poor code quality.
  • Keep an eye out for unhealthy competitiveness
  • Focus on value not speed

Understand your limits

  • What are you willing to be flexible with?
  • What are you not willing to compromise on?
  • What do you expect from your team?
  • Write these limits down and talk about them all the time. Cement this culture on your teams.

Olena Sovyn How we support making architecture decisions

Her firm formed a collective of adivsors along three principles. Someone from each domain area Rotate advisors in every 6 months. Didn’t position themselves as gatekeepers - merely positioned as advisors. The way it worked was engineers write tech spech, and the adivsors provide some resolution. This was based on a tech spec template. A practical guide to writing tech specs (the overflow) (article to read if you’re developing a tech spec teamplate)

Feedback could be

  • good to go
  • needs updates
  • not recommended
  • review not needed (changes will not impact more than one team)
  • escalated (need more context to make a decision)