Lead dev 2022 London: Day 2, part 2

The last post with my raw notes:

• Why mentoring selfishly is better than selflessly
• Using incidents to level-up your teams
• Career Changers: enabling the huge untapped potential in developers from different backgrounds
• Engineering a product for diverse markets
• Be the catalyst in a junior engineer’s career ❤️
• Key aspects of managing senior engineers ❤️
• Compassionate Refactoring ❤️❤️

Why mentoring selfishly is better than selflessly

John Apostol (@johnapost), Engineering Manager Handshake

John will talk about how his mentorship style has changed in the past 3 years. Focusing on how his own growth has been a boon in growing developers in his care.

Mentorship is something to do actively, it will not happen by itself on its own.

1. The mentee has to initiate the relationship, not to wait for the mentor to engage:
   • control
   • confidence
   • engagement
2. Mentees/mentor has to cross reporting lines: a junior person being mentored by a senior person from another reporting line would provide safety to the mentee (no wielded power relationship).

Becoming a manager, you have to be more purposeful. (The speaker resolved to find a mentor by himself, but in the end didn’t find the mentor very engaged.)

How to grow your skills beyond the teams you are leading? –> ADPList (a mentorship website: “Learn and grow with help from world-class mentors”)

Selfless mentor: mentorship is a gift of time. Selfish mentor: opportunities to pratice for yourself before trying on your own team (-> active learning).

Using incidents to level-up your teams

Lisa Karlin Curtis (@paprikati_eng), Product Engineer incident.io

This talk discusses the different things that individuals and teams can learn from incidents, and gives a few suggestions that’ll help you and your teams get the best value from the incidents that you have.

10 min talk

Accelerate your career by running towards “fires”. Big learnings all come from incidents, they broaden your horizons by making you looki inside blackboxes.

Incidents helps you design resilient systems (systems that failing gracefully). It makes you build observable systems (logs, metrics) ; you need empathy towards your future self.

Incidents are a chance to learn from the best. These people always show up on incidents, they have a lot of knowledge to share and to help fix the issue.

Make incidents accessible:

• Open up your communication channels so beginners can join and learn.
• Declare lots of incidents (not only when things get really bad, so you learn how to react) and broadcats what’s going on
• Encourage everyone to participate
• Show your working: great for everyone else in the team (e.g. use public Slack channel)
• Make the best debrief documents part of the onboarding
• Watch out for anyone playing the hero, taking away the opportunities for others to learn/practice

Career Changers: enabling the huge untapped potential in developers from different backgrounds

Marcus Gardiner (@marcusfgardiner), Technical lead Softwire

10 min talk

The hard part of career change is to desconstruct the image of yourself. Right now there is a war in hiring, we need to find people from alternative career background. What matters for innovation is gender, career path, industry background, not academic background and age.

For recruiting, we need to change to motivation instead of the ability to solve mathematical problems.

Do not manage “career changers” the same way you do with fresh computer science grads. They are very much subject to Impostor syndrome (as they didn’t write code at the age of 9). Its a career about asking questions, not about giving answers.

Engineering a product for diverse markets

Grygoriy Gonchar (@ggonchar), VP Engineering heycar

• i18n is just not translation, but adaptation to local market
• (pretty boring and too specific)

Be the catalyst in a junior engineer’s career

Amber Shand (@amberleetech), Frontend Engineer Cybsafe and Jessie Auguste (@_jessie_belle), Software Engineer Cybsafe

A career is a marathon, not a sprint. We often see rapid burnout in the industry. What preventative steps can we take as managers to ensure that Junior software engineers are not just surviving, but thriving?

(much more oriented toward including black women from different career path than the tiltle would suggest, so much more interresting)

attraction

How attractive is your company for juniors? People coming from coding bootcamps need you to overcome traditional thinking.

Techtalent charter show bootcamp graduates are more prepared for the role compared to CS grads.

Need to move beyond “need someone to fit within our culture”, we close ourselves to more diversity.

Leaders must create a culture to address cultural bias and racism.

onboarding

• Mentors: dependable, engaged, authentic, tuned into the needs of the mentee.
• Buddies: enhance well being, psychological safety and belonging. Creates a safe place where then can share concerns
• Sponsors: a leader within the company. Identifies and promote high performers inside the company. Endorse juniors (even informally)

Provide oppotunities beyond adding code, from day 1. Use their fresh eyes, communicate their value from their perspective.

development

Initial tasks:

• pair programming sessions. See a variety of best practices and learn from different people. Use pomodoro method.
• quick wins: selection of work that builds knowledge of the product incrementally. Explain the value of this work
• balance upskilling learners VS delivering
• turn quick fix into a larger task (from bugfix to feature enhancement)
• help them find their interest, support junior to narrow their focus
• explain that most of the job is learning (which can be surprising for juniors)
• help them structure their goals (not just “being good in ReactJS”)
• value mindset over technical expertise
• informal learning is more difficult online than before the pandemic

retention

Prioritise psychological safety: make it really safe to fail (a “learning from failure “attitude). Include the junior to all events (incidents, meetings…).

We should be rewarding loyalty: design your promotion process with your top talent in mind. Make the process visible. There is no perfect strategy.

Key aspects of managing senior engineers

Katja Lotz, Engineering Manager Epidemic Sound

Katja has found that there are certain focus areas of your leadership that often provide value for senior engineers. These values include deciphering organizational complexity, nurturing the multiplier effect and providing opportunities.

10 min talk

Leadership often happens in background, with small incremental steps, not in bold moves.

Senior engineers (any engineer with a significant amont of experience, with successes and failures) still need management. They are very important, the backbone of the team perfomance.

Fundamentals: it all starts with trust. Every relationship is unique.

Senior engineer want a more pragmatic relationship, a partnership with their manager. We need to shift the focus of our interactions:

1. Nurture the multiplier effect: the ability to see the bigger picture, rather than concentrating around simple tasks. Leading by example, being open and vulnerable (making mistakes). Award all signs of being a multiplier.
2. Decipher organisational complexity: Understanding how the org functions under the hood. “how do I drive momentum?”, “who are the influceners”, “how are decisions made?”. Push them out of their scopes, help them have insights from outside
3. Provide opportunities: Help them identify their strengths and their goals. Create awareness around their career

Compassionate Refactoring

Clare Sudbery (@claresudbery), Technical Coach Sudbery Software Engineering Ltd

This talk is about kindness and forgiveness, and the paradox that the more you accept and handle bad code, the more likely it is that you will end up with good code.

refactoring

• what is it? M. Fowler: “make the code easier to understand, cheaper to modify”
  • not just code: how we work and interact
• what it isn’t?
  • rewrite from scratch
  • performance gains (avoid premature optimisation, makes code less readable)
  • improving the UX
  • adding new feature (you refactor to make it easier to add new features)
• why? Makes the coding more satisfying
• how to refactor?
  • refactor as you go (see TDD cycle)
  • move with tiny tiny steps
  • refactor the part of the code that will have the most impact

why it doesn’t happen

• external pressures: unrealistic deadlines by stakeholders
• impatience of the dev themselves
• seeking of perfection (idea of what good practice look like, and then: guild, shame, despair). Big bang refactor never works, everything stays broken, undeployable for a loooong time
• no self belief: “I don’t know what I’m doing”. You see something that looks broken, but you assume people who wrote it knew what they were doing
• a lack of compassion

how to make it happen: compassion

Compassion helps us mitigate all these problems.

Seek the well of Geek Joy.

Learn how to make the tiniest improvement that keep the test green.

• deadlines: ask for more time, question those deadline (most of them are arbitrary anyway)
  • better code buys us time, it’s worth investing that time.
  • in the knowledge industry, thinking is part of the job
  • on a broader view, the infinite todo list. Keep removing small things from the list (not treating it all at once)
• impatience. Compassion means forgiveness, sometimes we don’t do our best work, we are easily distracted. Forgive yourself and each other (and that’s ok not to do the best job every time)
• drive for perfection. Don’t embarras new comers by showing only perfection. We all are faillible, not geniuses. Embrace imperfection.
  • it’s okay to write bad code (raw material) because you can refactor it to make it beautiful (comparison with scupture)
• self belief: show compassion to yourself. Everyone feels the same in fact. Use refactoring to understand the code you are reading. The smaller steps, the smaller risk you take.
• seeking joy. Identify what is enjoyable for you and find ways to do it