Lead dev 2022 London: Day 1 - part 1

avatar
Durée de lecture : 10 minutes
Cet article fait partie de la série Lead Dev London 2022
conferences • culture • orga • english • management
Voir sur twitter

You’ll find here the 1st part of my quick note taken during the LeadDev London 2022 conference:

  • Navigating the Chaos of Scaling ❤️
  • Keeping your codebase fun at scale
  • Outputs vs Outcomes: Driving and Defining Quality in Software Development
  • How to bring accessibility into your teams
  • CSS: Cascading Support Systems
  • What Dashboards Don’t Tell You ❤️
  • Scale, Scale, Scale! (Lessons from an engineering recruitment drive)

(other parts will follow in the coming days)

Vitor Reis, Director of Engineering • Delivery Hero

How can you understand if your team is producing great outcomes? Understanding the difference between high-performing versus average and low-performing teams is vital for success in a fast-paced environment. For this to be sustainable in the long run, you need to have the right people at the job.

Fictional story about a dev’s journey:

  • start small engineer in a small team
  • then business understands how to grow: more product lines, new teams created (lead dev)
    • priotities: hiring, understanding new features
  • MVP disaster, pivoting thanks to agile practices
  • company is growing, more teams hiring, more lead devs
    • one lead dev is leaving: difficult to replace
    • no more oOo, no more feedback
  • -> manages several teams, growing teams (need to gain trust)
  • when company is market leader: end of scaling process
    • leading several teams with lead dev for each team
    • different levels of seniority between the teams

How to succeed?

  1. be self aware
    • most important skill to be succesfull in your career
    • knowing when you’re wrong (stop doing the same things again and again)
    • look for answers, need to make judgments: it’s all about perspectives
    • what is performance (individual, team)?
    • most of the time, we are not the 1st person to ask some questions: document yourself, read, connect to communities (such as Lead Dev)
    • books to read:
      • The making of a manager, Julie Zhuo
      • Radical candor, Kim Scott
  2. Be replacable
    • do not be irreplacable, or you won’t be able to change role
    • don’t do too many roles at once
    • when you start adding people, people get nervous
      • “are they taking my job?”
      • “what if they are not good?”
      • “what if they are better than me?”
      • –> can be counter-productive
    • if you want to grow, you have to give away your job every couple month
  3. Focus on communication
    • in the beginning, people know each other, they know the processes, the goals of the company, how success looks like
    • -> then, everthing becomes a struggle
    • start writing: writing is thinking
      • writing helps you think
      • very good investment in the long run
    • need to over-communicate, everywhere, with everyone
  4. Be efficient with your time
    • “tell me how you spend your time, i will tell you what your priorities really are”
    • reflect on your time: ask yourself that question (see point 1, “be self-aware”)
      • how can I be more efficient?
      • what would happen if I don’t join this meeting?
      • what do I do in my calendar that someone in my team could do better?
        • –> if you can’t find this, start training someone, hire someone…
    • how to get better at time management?
      1. anticipation
        • best performing teams are teams with a routine, no surprise, everything was anticipated
          • address the root causes, stabilize things
      2. be careful with overstaffing
        • (see mythical man month, Fred Brooks)
        • more people have to align, more conflicts to solve, this takes time
      3. poor organisation design: if you spend more time in meetings, you have a organisation issue

Chaos is part of the journey. Let it happen, it is normal, keep moving and enjoy the ride. Lots of opportunities to be self-aware, learn new roles, learn how to be replacable.

Keeping your codebase fun at scale

Raul Chedrese (@RaulChedrese), Principal Engineer • 7shifts

In this talk you’ll learn techniques for creating a compelling technical vision, sharing that vision, and creating buy-in as well as developing an incremental plan for reaching that vision.

Principal enginner: how to ensure that every dev has a fun experience? Whats is a “fun codebase”? Different for every team.

What is NOT fun then?

  • no clear path between monolith and micro services
  • simple common tasks now take days to complete (use to take minutes)

Successful code base tend to become less fun to work with.

3 steps to fun:

  1. understand the dev experience
    • How do you know your codebase is fun? Just ask the devs! Run surveys every 3 months. (rate front codebase, backend codebase etc…)
    • Also ask more open questions (ex, “what could we do to improve our experience?”).
  2. form a vision
    • pain points, requests, company goals -> vision
    • ex:
      • fast dev feedback
      • strong foundational tools
      • fast consistent self contained archi
    • over communicate
  3. iterate towards the vision
    • prioritize, pick 1 thing and work only on it before starting something else
      • reduces the risk of the “never ending project”
    • start with the smallest one (the smaller, the better)
    • track progress (at the team level)

Don’t forget to have fun!

Outputs vs Outcomes: Driving and Defining Quality in Software Development

Gabby Llanillo (@gabs820), QA Engineer II and Quality Lead • Riot Games

In this talk, Gabby will cover the value she added as a quality owner on her own game development teams and how aligning with her team early in the process to define what “good” looks like, significantly improves both the quality of the games and the relationship with the players.

(Gabby got covid, talk from a video)

Warning: Entire carre spend in QA in video game industry.

Started in QA for i18n of Dragon Quest 11. Not a very collaborative approach with the Japan dev teams. i18n done after dev.

The last of us part 2, i18n was done along the dev with multi-langual devs. QA could suggest things: a nice/cool creative aspect of the job. Work was split up about points of contact (know who is responsible). Great attention to details (hyper realistic game, lots of expectations from the players).

Having the context helps QA to do their job.

Takeways @last of us:

  • rotate people around to avoid tunnel vision (not too often though)
  • when you loose point of contacts, you lose context
    • -> maintaining documentation is key

Quality ownership for GaaS (Games as a Service):

  • validating stories (in and out)
  • write test plans
  • triage/escaladate bugs/issues
  • risk assessment (should we fix this bug or not?)

Takeaways @riot:

  • quality if owned by the entire team (not only the QA)
  • embody the experience of the users
  • many different ways to define quality (even inclusion)

How to bring accessibility into your teams

Laveena Ramchandani (@Laveena_18), Test manager digital & data-science • Easyjet

This talk focuses on accessibility testing and how it is vital especially when your product is a user facing application. We need to be socially aware as a team and build quality towards our product with making it more accessible.

(accessibility = a11y)

  1. Some background
    • Tim Bernes Lee quote about people and the web
    • a lot of people have disability and are working (numbers are in millions)
    • 1/12 men is colorblind
    • wrong examples that led to lawsuits: Netflix, Amazon, Dominos’ pizza, Nike, Parwood Entertainment…
      • focus on AAA WCAG
    • without disability, tech make things easier. With disability, it make things possible
    • it should be in project from the very start, not an afterthought
  2. why a11y is important?
    • massive community
    • business: smart decision (avoid law suits)
    • drives innovation
    • enhances your brand
    • extends market research
    • minimizes law risks
  3. Benefits (from thinking it ahead of time)
    • goal 1: wider audience
    • goal 2: increases usability, become a market lead
    • goal 3: satisfies legal requirements
    • goal 4: improves maintenance and efficiency
      • do not lose customers by inplementing traps for them (they will go to the competitors)
  4. How to bring a11y to the team?
    • raise awareness: talk about it, make nice slides
    • work on what you want to convey
    • speak to teams & individuals: what do they think about the subject?
    • research to suggest options
    • –> create a report for the Product
  5. Coaching your team
    • become an advocate for a11y
    • back your point with studies, research
    • need to convince people
    • how to know people understood it? need for discussions with all the teams, find blockers, talk about it, gather their opinions
  6. when/how to do a11y testing?
    • make research of the matter
    • as it is a frontend app, you have to take a11y into account
    • it starts from the design/planning phase

Budget:

  • would you rather risk it?
  • there are free tools available
  • you want to reach more people (do not limit yourself on a specific market only)

What to include in the report?

  • areas tested
  • results
  • provide suggestions, that is helpful

Tools:

  • ARC toolkit
  • AXE
  • WAVE
  • Lighthouse
  • Remove styling and images
  • Screen readers (emulation of different color visions)

4 principle of accessible content:

  • perceivable
  • operable
  • understandable
  • …

Book: The design of everyday things

CSS: Cascading Support Systems

Phil Bennett (@phil_bennett), Senior Engineering Manager / Accountable Group Lead • Klarna

Phil will talk about how he has adapted basic principles like Solution-Focused Brief Therapy and applied them to be able to support my managers, and their reports dealing with empathy at scale.

10 min talk

Steve Job, Zuckerberg, Musk: successful, but psychopaths (lack of empathy).

Empathy is a superpower in leadership. It increases productivity, engagement. Difficult to scale empathy?

Solution focus brief therapy:

  • identify future perfects states, and imagine steps to go there
  • steps:
    1. what’s up?
    2. ask the miracle question: “if you work tomorrow and the pb is gone, how does it look like?”
    3. connect and give context
    4. solutions
    5. checking in
    6. most important: cascading to the whole organization

Result: all stress was trapped in the web of peoples’ connections, not only on his shoulders.

What Dashboards Don’t Tell You

Laura Tacho (@rhein_wein), VP Engineering & Engineering Leadership Coach • Laura Tacho Consulting

Learn how to spot vanity metrics in the wild, and learn what to measure instead, so you can create an environment where your engineers can excel. 10 min talk

Some metrics can lead to very different perceptions of what it means for different people. Performance and productivity are mutli-criteria . Self perception is very important.

–> Combine Self reported metrics AND automatics ones.

Dashboard are just tools of automation, they don’t deal with peoples’ perception.

See Godheart’s law: when a measure becomes a target, it ceaces to be a good measure.

How to go from Surveillance to empowering the team?

Teams want to be consulted about their performance, not informed.

Vanity metrics: metrics that look cool, but doen’t have meaning. (ex: nb of MR). Balance vanity metrics with tension. Ex, balance velocity with quality.

(see photo for 3 great research papers)

tools:

Results will be impossible to ignore, you’ll hear more sentences like this:

I feel like I can do my best work here

Scale, Scale, Scale! (Lessons from an engineering recruitment drive)

Jenny Sivapalan @jenny_sivapalan, Engineering Manager • accuRx

Expect to come out of this talk with a set of actionable items that you can own and make a difference in hiring into your team.

gone from 20 to 50 people in engineering team in 1 year

getting more candidates to apply

  • use external recruiters
    • mixed experience with them: communication breakdown, issue with internal scaling of their recruitment process
    • gives you insight about the market
  • grow the talent team (internal recruiters): more strategic
  • sourcing candidates
    • an unglamorous work
    • take time to write the good messages
    • be prepared to have a lot of “no”
  • referals, as a complement of others techniques
  • telling people who we are: promote us as an engineering team
    • write more blog posts from the team (every 6/8 week)

scale the recruitment process: creating a repeatable recruitment process

Goal:

  • an understandable process
  • a large team of confident interviewers
  • a faster process

Worked with an hiring manager, provide with questions, prompts and ended up in categorizing questions (wiki). Made some hiring process stages in parallel and not only in a sequence.

scaling the interview team

goal: have every engineer be able to conduct the interview.

  • run training sessions
    • run them through th exercices together
    • paired up exp/unexp people together
  • scale the hiring manager team

setting candidates up for success

let the candidates know the details of the interview:

  • public page about every step of it
  • put salaries on job description

reflections

Hiring is a continuous effort at scale. You have to get help from hiring teams.

Some tips:

  • draw candidates into apply
  • scalable / consistent interview format
  • give a genuine great experience for the candidate

Réactions