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
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
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!
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
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.
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?
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!
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?
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
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
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
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
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
▪ 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.
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.
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
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
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
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
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