Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Confessions of a Tech Lead

79016924e98a29a496dc3470616cb783?s=47 ardliath
March 02, 2019

Confessions of a Tech Lead

My Confessions Of a Tech Lead talk from DDDNorth 2019

79016924e98a29a496dc3470616cb783?s=128

ardliath

March 02, 2019
Tweet

Transcript

  1. CONFESSIONS OF A TECH LEAD DDDNorth 2019 / January TechTalk

    TransUnion UK
  2. About Me ▪ Product Development Manager at TransUnion UK ▪

    Developer for 10 years ▪ Tech Lead for 3 years ▪ Regular Attendee of DDDNorth ▪ Inexperienced Speaker ▪ Cat enthusiast and Warhammer addict
  3. @ArdLiath Contacting Me

  4. The Purpose Of This Talk ▪ What is a Tech

    Lead? ▪ Why would you want to become one? ▪ Discussing what makes a good Tech Lead ▪ Understanding Business Value ▪ Systems and Processes ▪ People ▪ My 3 Rules to being a Tech Lead
  5. What is a Tech Lead? ▪ Responsible for a Software

    Development Team ▪ May include Line Management responsibilities ▪ Usually includes mentoring other team members (often not just developers) ▪ An “Expert and Active Developer” ▪ A figurehead and representative for the team across the wider business ▪ Responsible for Technical Excellence of the team’s work ▪ The glue of the team ▪ Involved in Recruitment and Appraisals
  6. Why be a Tech Lead? ▪ Enormous flexibility in how

    a team works ▪ Your outlook directly influences the culture of the team ▪ A huge sense of satisfaction when a team jells ▪ Celebrating the successes of the entire team, not just your own victories Myth Busting ▪ Being a Tech Lead DOES NOT mean you won’t get to write code! ▪ Being a Tech Lead does not automatically make you authority figure or a bad cop ▪ Having a job title does not make you right, and it does not make challenging debates any easier ▪ You don’t have to be the best at everything!
  7. You Don’t Have to Be The Best at Everything! ▪

    Part of working in any team is recognising that everyone has their own different strengths ▪ Insecure leaders try to prove that they are better at something than their team ▪ Strong leaders celebrate their colleagues’ strengths and aim to help them grow
  8. Imposter Syndrome For someone starting a Tech Lead role Imposter

    Syndrome is a very real feeling. Joining a new company in a new role with people is always hard, especially when people are looking to you for guidance. Your job is not to know everything, it’s to empower your colleagues so they can do their best work.
  9. Do you have to be a Developer? ▪ Most Tech

    Leads come from a Development background ▪ This, in my opinion, does not have to be the case! Let’s Think… Can you think of a type of engineer who focuses on quality, aims to be tactful when reviewing someone’s hard work, and has a knack for process and requirements?
  10. How to Become A Tech Lead? ▪ Apply (did I

    mention we’re hiring?) ▪ Tech Leads are often recruited from the pool of Go To Developers. This in my opinion is a mistake. Being a Tech Lead is a very different job to being an excellent developer. The engineer has to want to do something different. ▪ Interviews are often a shock for Developers (as are the first few months) as the world suddenly gets a lot wider. ▪ Read up on the wider Software Development Process. Not just scrum but Lean, DevOps, and other agile methods such as Kanban. ▪ Read books on people and teams, they’re not all as dull as they sound!
  11. A 30 MINUTE WINDOW INTO THE BIGGER PICTURE

  12. Business Value

  13. Running a Development Team is Very Expensive! ▪ 6 team

    members on an average salary of £40,000 costs a quarter of a million pounds per year just in salaries ▪ For your team to be profitable they have to earn about £10,000 per sprint just to cover your own salaries! ▪ This is why Product Owners prioritise backlogs to ensure that teams are always working on the most valuable pieces of work. ▪ As engineers we love to improve code and reduce technical debt. Having the responsibility of leadership means you often need to juggle the value/cost ratio ▪ Is it actually worth improving that deployment pipeline we use twice a year?
  14. Systems and Processes

  15. READ THIS BOOK! The Phoenix Project Gene Kim, Kevin Behr,

    George Spafford
  16. Systems Thinking ▪ It is important to understand that delivering

    a quality software solution depends on more than just writing good quality code ▪ Poor delivery systems can delay and fail even the most robust software Test Develop CAB Deploy Customer Customer
  17. Bottlenecks ▪ Every system has a bottleneck, this is not

    a problem. This is a scientific fact. ▪ Work can only ever progress through the system at the rate of the bottleneck Machine Shop Dispatch Desk Paint Booth Shipping 2 2 7 2
  18. Bottlenecks ▪ Making an improvement before the bottleneck will just

    result in more work being stacked up at the bottleneck Machine Shop Dispatch Desk Paint Booth Shipping 2 2 7 2 Machine Shop Dispatch Desk Paint Booth Shipping 1 2 8 2
  19. Bottlenecks ▪ Making an improvement after the bottleneck will only

    starve the latter stages for work Machine Shop Dispatch Desk Paint Booth Shipping 2 2 7 2 Machine Shop Dispatch Desk Paint Booth Shipping 2 2 7 0
  20. Bottlenecks ▪ Only by improving the capacity of the bottleneck

    can we improve the throughput of the entire system Machine Shop Dispatch Desk Paint Booth Shipping 2 2 7 2 Machine Shop Dispatch Desk Paint Booth Shipping 2 2 4 3
  21. And How Is This Relevant? ▪ Our team is a

    system for building software ▪ Where are the bottlenecks? Test Develop CAB Deploy Customer Customer
  22. Deploy Little, Deploy Often Deploying more frequently: ▪ Helps stakeholders

    see progress and visualise the end product ▪ Makes projects more profitable earlier on ▪ Allows people to finish work ▪ Reduces scope of change and makes testing easier https://medium.com/@mvwi
  23. Deploy Little, Deploy Often Deploying more frequently: ▪ Reduces upgrade

    gaps and makes deployments run more smoothly ▪ Ensures that development and test environments are inline with production at all times ▪ Makes teams more familiar with the process (and it’s risks) ▪ Reduces the risk of missing business deadlines https://medium.com/@mvwi
  24. Handovers and Empowerment ▪ Handovers cost knowledge and impede velocity

    ▪ Wherever possible teams should be empowered with the required skills to complete work Imagine you are building a new server and need to get network ports opened. To do this you need to: ▪ Raise a ticket with the service desk ▪ Who need manager approval ▪ And security approval ▪ And server owner approval By the time all this has happened the team has had to wait for four different groups.
  25. The Importance of Slack ▪ Back in the dark days

    managers used to believe that high resource utilisation produced high throughput. ▪ This was before The Theory of Constraints became widely accepted and people realised the costs of WIP and wait times. ▪ It is VITAL that your team members have slack in their working week to collaborate and innovate ▪ HOWEVER watch out for boredom. People want to feel productive and know that their work matters.
  26. People

  27. DISC Personality Profiles

  28. Safety and the 5 Dysfunctions of a Team ▪ Safety

    is about building an environment where people are not afraid to make mistakes ▪ If people are afraid to fail publicly then they will fail privately, and that can cause far more problems down the line! The 5 Dysfunctions of a Team Inattention to Results Avoidance of Accountability Lack of Commitment Fear of Conflict Absence of Trust
  29. Trust ▪ As a leader you cannot be aware of

    every technical line of code or design decision that each member makes ▪ Trying to do so slows down work and leaves team members feeling undervalued ▪ Trust your team implicitly ▪ Create space for open discussion
  30. Meetings ▪ As a leader you have the ability to

    schedule meetings for your team ▪ Resist the temptation! ▪ Scrum gives us a great structure of sprint ceremonies, use them to their full potential. ▪ If you’re calling a meeting, recognise what sort of a meeting it is and what outcomes you want Common Types of Meetings The FYI The Decision The Design Session The Troubleshoot
  31. Jelled Teams High Performing Teams: ▪ Are empowered to do

    the required work without assistance from other departments ▪ Are not afraid of making mistakes ▪ Take pride in their work, celebrate their successes, and make a cult of quality ▪ Are proud of each other’s achievements ▪ Have personalities ▪ Have a sense of identity
  32. Next Steps…

  33. Recommended Reading ▪ The Phoenix Project – Gene Kim, Kevin

    Behr, George Spafford ▪ Rolling Rocks Downhill – Clarke Ching ▪ The Goal – Eli Goldratt ▪ 5 Dysfunctions of a Team – Patrick Lenconi ▪ Agile Estimation and Planning – Mike Cohn ▪ Peopleware - Tom DeMarco, Timothy Lister
  34. 3 Rules of Being a Tech Lead 1. It’s always

    about the people! 2. Most process problems can be solved by releasing more frequently 3. If a piece of work is critical, don’t do it
  35. THANK YOU FOR LISTENING!