A Guide To Managing Technical Teams

Summary

In this video, Dave Farley shares practical advice for leading technical teams. He emphasizes the importance of balancing technical expertise with effective leadership, allowing team members to work independently while providing guidance and support. Farley discusses the pitfalls of micromanagement and the value of fostering a collaborative environment. He also stresses the leader's role in facilitating communication, setting goals, and helping team members grow, while also addressing the necessity of making tough decisions and delivering difficult feedback with empathy.

Takeaways

• 🎯 Leading a technical team is a significant shift from individual technical work and requires a different set of skills.
• 🌟 The primary role of a team lead is to enable the team's effectiveness rather than making all technical decisions.
• 🏌️‍♂️ A good leader should act like a sports team captain, coordinating and amplifying the team's performance rather than dictating every move.
• 🚧 Micromanagement is detrimental to a team's performance and should be avoided to prevent becoming a bottleneck.
• 🤝 Fostering collaboration and communication is crucial for a cohesive and effective team.
• 🛠 Allowing team members to work in their own way supports their growth and can lead to better long-term outcomes.
• 👥 Encouraging autonomy in team members helps them learn from their mistakes and builds confidence in their decision-making abilities.
• 📈 Setting minimum standards is important, but allowing for some imperfection can be beneficial for team learning and growth.
• 🤔 The best leaders facilitate finding solutions rather than imposing their own ideas, promoting a culture of collective problem-solving.
• 🗣️ Providing regular, honest feedback is essential for team members to understand their performance and areas for improvement.
• 💔 When delivering bad news, it's important to focus on the individual receiving the news and offer support rather than dwelling on one's own feelings.

Q & A

What is the primary role of a team leader according to Dave Farley?

The primary role of a team leader is to make the team effective, similar to the captain of a sports team, by amplifying the performance of the team, coordinating efforts, and providing coaching and guidance.

Why is micromanagement a problem for inexperienced leaders?

Micromanagement is a problem for inexperienced leaders because it can lead to the leader becoming a bottleneck, slowing down the team, and stifling individual growth and innovation.

What is the concept of 'servant leader' mentioned by Dave Farley?

The concept of 'servant leader' suggests that leadership is about serving the team by removing barriers that prevent progress, rather than dictating how things should be done.

How does Dave Farley compare being a leader to hosting a party?

Dave Farley compares being a leader to hosting a party by stating that a leader's job is to invite people, ensure there are enough resources, make helpful introductions, and occasionally address disruptive behavior, much like a good host.

What is the 'communist anti-pattern' in software development?

The 'communist anti-pattern' is a form of micromanagement where technical leaders dictate specific solutions to problems rather than allowing team members to solve problems in their own way.

Why is it important for a team leader to allow team members to make their own mistakes?

Allowing team members to make their own mistakes is important because it fosters learning and growth. It helps them understand the consequences of their actions and develop problem-solving skills.

How does Dave Farley suggest a team leader should handle difficult conversations?

Dave Farley suggests that a team leader should handle difficult conversations by focusing on the individual's needs, being respectful and supportive, and offering help where appropriate, rather than focusing on their own feelings.

What is the role of a technical lead in terms of technical decisions?

A technical lead should not dictate every technical decision but should allow team members to work in their own way while supporting them in growing their skills and capabilities.

Why did Dave Farley's team decide to hire young, inexperienced developers alongside experienced experts?

The team decided to hire young, inexperienced developers alongside experienced experts to train them in their approach to development and to foster an environment where junior members could learn from more experienced team members.

What techniques does Dave Farley use to make consensus-based decisions?

Dave Farley adopts the consensus and tries to make it work even if he disagrees, allowing for quick progress and demonstrating the importance of teamwork and shared decision-making.

How does Dave Farley approach giving feedback to team members?

Dave Farley believes in giving feedback regularly and not waiting for formal review cycles. He emphasizes the importance of being open and honest, and providing guidance to help team members improve their performance.

Outlines

00:00

🚀 Transitioning to Team Leadership

The speaker discusses the feelings one might have when asked to lead a team, ranging from nervousness to excitement or vindication. The speaker, Dave Farley, introduces himself and his channel, Continuous Delivery, and acknowledges the sponsors. He highlights that leadership in a technical team is different from being a technical expert and emphasizes the importance of balancing technical skills with leadership qualities. He compares the role of a team lead to a sports team captain, whose job is to enhance the team's performance rather than to do all the work or dictate every detail. The key challenges for new leaders include allowing others to work in their own ways and avoiding micromanagement.

05:01

🌟 Empowering Teams Over Micromanagement

Dave shares his personal experience with micromanagement during a sailing trip, illustrating how it can lead to team members becoming passive and waiting for instructions. He stresses that a leader's role is to focus on outcomes rather than methods, to serve the team by removing barriers, and to foster collaboration. He discusses his role as a tech lead for a large development team, acting as a communication hub to connect teams and share knowledge. Dave also talks about starting a weekly newsletter to improve community communication and build a sense of team ownership.

10:04

🛠️ Balancing Technical Expertise with Leadership

The paragraph discusses the anti-pattern of 'programming by remote control,' where leaders dictate solutions rather than defining problems. Dave argues for allowing team members to work in their own ways while supporting their growth. He shares an example of a team he led that hired inexperienced developers alongside experts, using pair programming to allow junior members to learn and grow. He emphasizes the importance of letting team members make mistakes safely and the value of practices like test-driven development and pair programming in supporting this.

15:05

🗣️ Navigating Difficult Conversations as a Leader

Dave talks about the responsibility of leaders to have difficult conversations, such as providing feedback or delivering bad news. He suggests praising people publicly and critiquing them privately. He shares his personal style of being open and honest and emphasizes the importance of providing feedback regularly, not just during performance reviews. Dave also discusses the approach to delivering bad news, advising leaders to focus on the individual receiving the news rather than their own feelings, and to offer support and practical help.

Keywords

💡Technical Leadership

Technical leadership refers to the role of guiding and overseeing technical teams, often involving a transition from hands-on technical work to a more strategic and managerial position. In the video, Dave Farley discusses his personal experience with technical leadership, emphasizing the shift from individual contributor to leading a team and the importance of balancing technical expertise with effective team management.

💡Micromanagement

Micromanagement is a management style where a manager closely controls every aspect of their team's work, often to the point of dictating the smallest details. The video script warns against micromanagement, illustrating it through the example of a sailor named Joe who controlled every task, leading to a team member feeling demotivated and waiting for instructions rather than taking initiative.

💡Servant Leadership

Servant leadership is a philosophy where leaders prioritize the needs of their team members, aiming to serve them and help them grow and succeed. In the context of the video, Dave Farley suggests that a leader's role is to remove barriers for the team and create an environment where they can thrive, aligning with the concept of servant leadership.

💡Team Amplification

Team amplification is the process of enhancing the collective performance of a team. The video emphasizes that a leader's goal is to amplify the performance of the entire team rather than focusing on individual tasks or personal technical prowess. This is exemplified by the analogy of a sports team captain who coordinates and supports the team rather than doing all the work.

💡Communication

Communication is key in leadership, as it involves sharing information, ideas, and feedback within the team. The script mentions Dave's role as a tech lead involved acting as a communication hub, facilitating connections between teams and fostering a collaborative environment.

💡Consensus Decision Making

Consensus decision making is a collaborative process where team members work together to reach a decision that everyone can support. The video describes how Dave adopts consensus-based decisions, allowing the team to make collective choices, even if he personally disagrees, unless there's a tie, where his vote serves as the tiebreaker.

💡Remote Control Programming

Remote control programming, also known as the communist anti-pattern, is a negative practice where non-developers dictate coding solutions to developers. The video script criticizes this approach, advocating for allowing team members to work in their own way while providing support for skill development.

💡Mistakes

Making mistakes is an integral part of learning and growth. The video script suggests that leaders should allow team members to make safe mistakes to learn and develop their skills, similar to teaching a child to ride a bike by allowing them to fall and learn balance.

💡Pair Programming

Pair programming is an agile software development technique where two programmers work together at one workstation. One programs, while the other observes and reviews. The video highlights pair programming as a method to support learning and skill development, especially for less experienced developers.

💡Performance Review

A performance review is a process where employees' work is evaluated, and feedback is given. The video script discusses the importance of providing regular feedback to team members, rather than waiting for formal performance reviews, to guide their performance and help them improve continuously.

💡Difficult Conversations

Difficult conversations refer to challenging discussions, often involving criticism or bad news. The video script advises leaders on how to handle such conversations, emphasizing empathy and focusing on the recipient's needs rather than the leader's discomfort when delivering bad news.

Highlights

Personal reactions to being asked to lead a team can range from nervousness to excitement or vindication.

Leading a technical team effectively requires a shift in focus from individual technical work to team coordination and performance.

The role of a team lead is not to make all technical decisions but to ensure the team's effectiveness.

A team lead should act like a sports team captain, making decisions when the answer isn't clear and amplifying team performance.

Micromanagement is a common issue for new leaders and can slow down the team.

Leaders should allow others to work in ways they wouldn't, even if it means the work is not as good as they would do themselves.

The concept of a 'servant leader' is introduced, where leadership is about serving the team.

Leaders should focus on outcomes rather than enforcing a single way of doing things.

The importance of allowing team members to make their own mistakes and learn from them is emphasized.

Pair programming and test-driven development are highlighted as methods to support team growth and learning.

The leader's role includes acting as a communication hub and fostering collaboration across the team.

The 'communist anti-pattern' of programming by remote control is criticized as a form of micromanagement.

Leaders should establish good minimum standards for work but allow room for team members to grow and make their own decisions.

The importance of consensus-based decision-making in a team is discussed, with the leader's role in breaking ties.

The leader should help team members find their own answers rather than always providing the solutions.

Difficult conversations are a part of leadership, and leaders should focus on the individual receiving bad news, not their own feelings.

The leader's job is to help team members perform to the best of their ability in service of the team.

Transcripts

your boss comes up to you

and says you did a great job on that

last piece of work

how do you feel about leading the team

from now on

depending on your personality your

reaction is probably one of

nervousness maybe some excitement or

perhaps a feeling of vindication that at

last your technical genius has been

recognized

so passing over the last one rather

quickly whether you're a new team lead

aspire to team leadership or just want

some ideas to tell your current team

lead how to do a better job

here is some of my advice on being

effective in leading technical teams

hi i'm dave farley of continuous

delivery welcome to my channel if you

haven't been here before

please do hit subscribe and if you enjoy

the content hit like

as well i'd like to begin by thanking

our sponsors

harness equal experts octopus

and spec flow they're all helping us to

build this channel

and so please do help them in turn by

checking out their links in the

description below

my latest book continuous delivery

pipelines has just been released in hard

copy form on amazon

it's a practical guide that describes

how to create and improve your

deployment pipelines

so check that out in the links below as

well

i'd like to begin this video with some

caveats

i've spent the majority of my career in

hands-on

usually close to the code technical

leadership roles in one form or another

so this is a

fairly personal take on technical

leadership

rather than a deeply thought out or

considered strategy

more a collection of practical advice

and tips

based on my own personal experience and

approach

most of us who get asked to lead a team

do so because we did a good job of the

work itself

in our case presumably a good job of

software development

that doesn't necessarily mean though

that we're going to be good at leading a

team

it's a very different thing this entry

into the job of leadership presents

probably the first and one of the more

challenging difficulties

because we're asked presumably because

of being good at doing something else

it's natural to assume that doing more

of that

only better is the new job but being a

team lead

does not mean that you should make all

of the technical decisions from now on

it also doesn't mean that you are now

either

the best technical person or

alternatively

post technical in some way there's a

balance to be struck here

if we think about the role of team

leadership from an organizational

perspective rather than from our own

personal perspective

then the job is really to make the team

effective

i think of this rather like the captain

of a sports team

the job of the captain isn't to do all

of the work

the best captain isn't necessarily the

best player

it isn't the job of the captain to tell

everyone else exactly where

to run or when and where to kick the

ball

each player knows that stuff or at least

their own version of it

the captain's job is to make the

decisions when the answer isn't too

clear

to amplify the performance of the team

to coordinate the performance of the

team

maybe by being a good role model maybe

by offering advice

maybe setting broad goals or direction

certainly coaching and guiding the team

in improving specific skills

one of the most difficult challenges

and changes in focus for new leaders

certainly that i experience and that

i've seen in others

is the difficulty of allowing other

people

to do work in ways that you wouldn't

maybe even doing work that is worse than

the work that you would do if you were

doing it yourself

however your goal as a team leader is to

amplify the performance of the whole

team

if you try and micromanage what everyone

else does

you will become the constraint and slow

the team down

overall micromanagement is a big

problem particularly for inexperienced

leaders and managers

i am a recreational sailor i once got a

chance

to sail across an ocean as part of a

more experienced crew

despite being junior inexperienced i am

a basic skipper and so know my way

around a boat nevertheless one of the

much more experienced crew members

let's call him joe started to

micromanage me

joe would tell me all the detail of even

the most menial tasks tasks that i

understood well

he would take over if i did anything

even slightly more than menial

after a few days at sea one day i found

myself

looking at an untidy rope i found myself

thinking

somebody should tidy that rope up but

i'm not going to do it because joe

didn't tell me to

now that is not me that's not the kind

of person that i

am that's not how i usually behave

so i realized what i was doing and i

went over and i tidied the rope

later i noticed that joe went and tidied

it again

only this time to his preferred way of

doing things

my point is that this was bad on several

fronts

my role had become marginalized and joe

had become the bottleneck for nearly

everything that i did

not great for either one of us

better to focus on the outcomes was the

rope tidy

rather than the the mechanism had the

rope been tidied in exactly joe's one

true way

the job of a leader is not to have all

of the answers

or if they're a good leader to enforce

one way of doing things

the job of a leader is to maximize the

performance of the team and i know i've

said that before

there's a concept called servant leader

the idea is that leadership is about

serving the team

i like this idea our job as leaders is

to remove barriers that prevent the team

from making

good progress whatever those barriers

might be

i once thought read a post that i liked

better

being a leader is more like hosting a

party

your job is to invite people make sure

that there are enough drinks and snacks

for everyone

make introductions that you think will

be helpful and occasionally throw out

the drunks

i can't find the link to that great blog

post to reference it

so if you know it please do let me know

in the comments so that i can

provide proper attribution to the author

the introduction part is definitely an

important aspect of leadership

i was once the tech lead for a large

development hundreds of people split

into many

smaller teams i confess that i felt that

most of my job was to act as a

communications hub

i found myself saying things like ah

that team over there had that problem

too

you should go and talk to them or ah

this team's tests are a bit flaky can

you help them out please

my job was to hold the kind of 30 000

foot perspective of the project so that

i could spot

things that people closer to the detail

may miss

and so foster collaboration where i

could

one of the other things that i did for

this larger group was to improve the

community communications in another way

too

i started a weekly newsletter on our

project wiki

and badgered team leads from the smaller

teams to provide helpful suggestions

important changes funny observations or

just interesting thoughts

it helps the wider team to begin to feel

more like a team

and improve the sense of ownership for

people working on the project i've

spoken a fair bit

so far about mostly the human aspects of

leadership

and they are very important they are

primarily what the job is about

but as a technical lead what about the

tech

first the communist anti-pattern which i

guess is just another

version of micromanagement that is

programming by remote control i

see this all of the time it takes the

form of formerly technical product

owners telling development teams through

the requirements process how to solve a

particular problem

rather than describing what the problem

is that they're trying to solve

i see it in architects who don't write

code anymore but want to make sure that

everyone else writes code in some ivory

tower version of perfection

and i see it in tech leads who try to

dictate

the specific details of design either

before the work is done or afterwards

through code review

as i said earlier i think that to lead

effectively

you need to allow others to work in

their way

while at the same time helping them and

supporting them in growing their skills

and capabilities

don't get me wrong this isn't easy we

all have an ego

and allowing people to do what you think

is a worse job than you would do on some

task is extremely difficult

but i think it's often the right thing

to do

of course there are constraints you have

to establish

good minimum standards for work to

protect against disasters or at least

expensive failures

but where the work is good enough but

not perfect

then it's probably better to let that go

at least

temporarily my point here

is not that i think that quality is

unimportant

quite the reverse rather that you may be

more effective

in doing a high quality job long term

by deferring the conversation people

start

from different places and learn at

different rates

if you try to force an advanced subtle

design on someone

who's just starting out they will at

best miss the nuance

at worst they'll become demoralized and

wait for joe

or you to tell them when to tidy the

ropes and precisely how to do it

they will lose confidence in their own

ability to make decisions

or at least abdicate that responsibility

to you

this is a really common failure that i

see in teams

all of the time people learn most

strongly

from making their own mistakes one way

of helping people to learn

is to allow them room to make some of

those mistakes

this is rather like teaching a child to

ride a bike

they simply won't learn if you hold on

to the saddle all of the time

at some point you have to let them go at

some point

they will fall over but that is what it

takes to learn to balance and to ride a

bike

try to allow people to make mistakes but

as safely as you can

this is yet another reason why i value

things like

test driven development and pair

programming quite so highly

they both provide some support to help

people

to grow their understanding and in the

case of pair programming to learn from

one another

i led a team who built a very high

performance financial exchange we

consciously hired young bright but

inexperienced developers

as well as experienced experts we

consciously decided

not to do much hiring of medium level

experienced

people in part the idea was that if we

hired people that we knew and trusted

and would then hire very smart junior

people

who we could train maybe brainwash to

approach development our way

we'd get a better outcome we did

pair programming initially more junior

members of the team

were always paired with more experienced

people

once they had the basis of how we worked

though

and knew their way around some of some

of the code

we'd encourage them to pair with other

juniors

more experienced members would keep an

eye out on their commits

often usually the team lead

would do that and they'd be there to

help if juniors got stuck

but largely we left them to explore a

bit

to make their own mistakes this helped

them to grow as developers very quickly

and i'm very proud of the fact that in

that organization

we helped several really excellent

developers begin their career this way

as i've already said it's not a team

leads job to have all of the answers

in my opinion the best team leads teach

team members how to find their own

answers

but i don't mean to diminish the value

of experience

the very difficult task for a team

leader is to allow themselves the

freedom to apply their experience while

at the same time

allowing team members room to make their

own decisions

this is very difficult and very

subjective

and a narrow line to tread

i am a very opinionated person as those

who have worked with me will attest

but i hope i aim to have strong opinions

but hold them lightly

i don't assume that i'm always correct

one of the

techniques that i use consciously is to

make

consensus-based decisions when working

as part of a team

i will adopt the consensus and try very

hard to make it work

even if i as the lead disagree with the

choice however

if there's no consensus or the decision

is tied

then my vote as team lead is the

tiebreaker

this does a few things first it means

that we can make

progress quickly we don't have to wait

for everyone to agree

second it gives me the freedom as an

experienced member of the team

to make my argument about why my idea is

the best

without forcing it on other people

third it demonstrates something subtle

and important

we are a team and we make decisions

together

it's okay to challenge other people's

thinking whatever their role

this is about getting to the best ideas

not about hierarchy or status

and yes in my career as a tech lead

we have often done things that i thought

were bad ideas

sometimes i was right but sometimes i

wasn't

my last point is about the sometimes

difficult conversations that

the dealing with the drunks part of

hosting the party

as a leader it's your responsibility to

sometimes have difficult conversations

with people

in general my rule of thumb is to praise

people

in public and to critique them in

private

my own style is to try and be open and

honest in both

i'm english and so it's nearly as

difficult for me to tell somebody that

they're doing a good

job as telling them that they're doing a

bad job so i have to work a bit on both

of these things

but i do think it's important that you

do both

if someone is surprised in their

performance review

by bad news or good i feel i've done

them a disservice

i don't want to wait for some fixed

review cycle to give them that feedback

if it's my job to help them to do their

best for the team

then i need to help them to guide their

performance all of the time

not just during performance reviews this

is the most

important idea for me i've already

touched on it but the job of a leader is

not to tell people what to do

but to help them to do what they can do

in the service of the team to the best

of their ability

i have one more thing to say on giving

bad news

sometimes as a leader it may be your job

to tell people

really bad news their performance isn't

good enough or maybe even that they've

lost their job

this is horrible for everybody concerned

but it's more horrible for them than it

is for you

i have too often seen managers and

leaders in this position

focus primarily on how bad they feel

having to impart this news

how tough it was for them to make the

decision or to give the bad news it's my

view that if you find yourself in this

position don't do that

this is about them not about you however

bad you feel about it

focus on the practicalities give people

time to process bad news

be respectful be supportive offer

whatever help

you can and that is appropriate given

the circumstances

but don't spend time telling them how

bad you feel

if you really felt that bad you wouldn't

give them the news in the first place

so those are a few thoughts about being

a team leader in a technical team

i hope that you found some of them

interesting let us know your suggestions

for

advice to team leaders in the comments

below

thank you very much for watching

you