TalkFrom

The Geek's Guide to Leading Teams

Patrick Kua

Recorded at GOTO 2012

hi thanks for coming along to the talk
today it's about the geeks guide to
leading teams now what I find
interesting is that in our industry we
have a lot of people who can talk about
that sort of technical practices that we
as developers need to get good at doing
so we have books from refactoring we
have people who can teach us how to
write clean code we have a lot of things
to talk us about continuous integration
and now continuous delivery but what
about when we have to work with teams
and work with people so if you've been
working in industry for a while as a
developer most organizations you'll end
up working with a team and most likely
you'll end up in a leadership position
and what I want to share during this
presentation are really some of the
things that I've learned working with
lots of different teams and then moving
into a leadership position and some of
the skills and some of the things that
you need to think about to help you
prepare because there's nothing really
out there that can kind of help us so
before we kind of begin you probably
want to know well Who am I and a little
bit about my bracket my background is
well I'm a programmer at heart so most
of the time I work for a consultancy and
I work with projects delivering software
as part of my role I often end up as a
team lead and so I ended up helping big
teams kind of work and deliver projects
for clients at the same time I'm very
passionate about agile and I really am
enthused about the way that's kind of
working and as Linda mentioned I
recently published a book called the
retrospective handbook because for me
it's very essential to be learning and
understanding how we improve our
practices I've been working with teams
for about six to seven years as a team
lead and a lot of the stuff will talk
about these experiences that I've kind
of thought about over the time but if
you if you're kind of working in
different environments you might be
thinking about well why is it that we
need a team lead so why is it that we
perspective to lead a team now I think
about myself about when I first started
programming I joined a small group of
people I was actually the only developer
on the team so you end up with this sort
of one target and it's just you and
yourself perhaps you've been in a
situation like this before
and when you're thinking about what you
need to deliver it seems trivially easy
there's just this one thing and we end
up heading towards that target pretty
right now in most organizations today if
you think about Google that little
search box there's obviously a large
organization behind it and so we can't
really do things by ourselves anymore
these days because of the scale of the
things that we need to actually achieve
so we end up working with a much larger
team of some sort and we have to work in
these boundaries and we have to
understand what that is we still have
this goal that would like to achieve but
now we have a lot more people that we
need to think about so what happens is
well you know we kind of end up wanting
to head towards this target and
conceptually everyone should know where
this target is and is starting to head
in that same path now in reality what
kind of happens as you do start off with
this target and you start off with this
group of people and you kind of end up
starting on this path but maybe what
happens over time is that people kind of
end up going in different directions
who's been in a situation like this who
actually you know have worked on a
project that doesn't actually know what
they're there to do I've certainly been
in places like that where you know
you're there as a developer but you
don't really know what product and
perhaps the vision isn't so clear from
the product owner and so there's a lot
of confusion around it so it creates
chaos it creates anger and as a
developer I know this is that if I write
something and it doesn't get used I get
frustrated and it feels like a bit of a
waste so we all want to be kind of doing
really well so I think it's a really
important thing to think about
particularly being a tech lead and if
you don't think this really happens in
the real world I have a good friend
called Julian on Twitter and he had this
quote that I really love I had 10 guys
on my last project all of them had
opinions and all of them were expressed
in the codebase so if you think about
Conway's law in 10 different ways of
working you end up with 10 different
parts of the codebase and if somebody
new comes onto the project who wants to
change something else you're kind of
stuck and so for me I have a very simple
test for what is an effective technique
and it looks like this does the code
base look like it was written by a
single person so if you think about that
sort of a first picture where we thought
about one person and that target if you
opened up random parts of the codebase
does it
feel the same sort of passions are there
does it feel consistent and for me this
is one of the key responsibilities of
tech leaders to really help Shepherd
people towards that goal to help set
that vision that direction and to make
sure people end up going in that
direction and throughout this talk we'll
kind of talk about the different
elements it takes to get to that point
where it looks like a single person
wrote the code base now it doesn't
happen in reality but it's a nice simple
test to think about do we have
consistency in what we're actually doing
so the next question I really want to
answer is what does a good tech lead
focus on and for me there are kind of
three elements that I think about and as
a developer when you're moving into this
role there are two that maybe you kind
of have thought about but haven't given
a lot of time on so the three elements
that I'm kind of thinking about start
with be conveniently the first one is
obviously elements of programming what
makes a difference between a technical
leader and a team leader is that
somebody who is a tech lead has
experience in programming and still has
that experience and so they're an active
developer I'll talk about that a bit
more
the second element that we'll be talking
about is about the people dimension so
as a developer and I know this I've been
through this myself is that you if
you're focused on this small little area
of the code that you're currently
working on you're not really thinking
necessarily about the team the groups of
people that you're working with and the
well as the relationships between them
this is an element we'll focus on and
the second part and finally when I talk
about process it's a terrible word but
it's out of the P it's kind of really
thinking about how do the people and
programming sort of work together and if
I think about lifecycles of teams and
various things like that we're going to
be looking at well how does it work as a
team process so the first part is going
to be in flooring washes the programming
elements of what a technique needs to do
and the first question a lot of people
ask do effective technical leaders need
to still code and my answer to this is a
definite yes now the next question I
guess is well how much are they code if
you're sort of working with a large team
it's going to be a little bit hard to be
coding every day just like everyone else
so what's the right balance and I have a
bit of a rule of thumb that I have here
which is at least I think you need 30
percent of your time with a team writing
code so this means out of five day week
you need writing code at least one and a
half days out of that five week with the
rest of the team now why does this
actually make sense I think there's an
interesting article here it's called the
unspoken truth about managing geeks when
you look at the slides there's a link
here anyway
and basically this article or the author
of the article is kind of talking about
what is it that geeks kind of how do you
get along with deeds his perspective is
a little bit more in terms of the
context of products owners and business
and working with developers but in it he
writes this quote respect is the
currency of the realm so imagine
yourself on a development team working
with other developers and you know that
there's somebody over there who's not
really pulling their weight they kind of
surf the internet they might do their
own little side projects what do you do
you probably get really frustrated if
you've been in a situation like this you
kind of maybe they're not really helping
with you with you sort of develop
projects and actually write code that
helps but he goes on to say the amount
of respect an IT pro pays someone is a
measure of how tolerable that person is
when it comes to getting things done who
feels this way okay well when you think
about it for me it really wrong true
with how I seem to see how things work
if you know about our industry
technology changes all the time we are
hearing about new languages coming out
one coming out this afternoon at last
keynote and there's always new things to
learn and so we can't really be
exceptional at everything that we do
however we don't really like to work
with people who make our job harder so
if you have people who aren't
necessarily good or make your job a lot
harder it's it's very hard to understand
what that means and as a tech lead I
think it's very hard to make the right
decisions or to understand what the team
is going through unless you're actually
part and you're going through that
experience yourself so I think one of
the biggest things that you need to have
as a tech leaders
Paul with the developers and the rest of
the project and in order to do that I
feel that you actually need to be coding
with them so you need to understand what
the problems that they're experiencing
are you can't just listen to what people
experience it yourself at the same time
you also have to have a certain amount
of competence that you need to
demonstrate to the rest of the people
because if you're going to lead a team
they need to have confidence in your own
ability and therefore you need to be
able to demonstrate some of this so 30%
time you need to be coding with the team
so that can help build that respect and
that you are actually part of that team
as well the next principle I have for
leading development teams is really one
about consistency over cleverness so as
many as much as I like using the latest
tool the latest language that's really
great if you're a single developer but
when you're actually thinking about an
entire team and they're sort of one
direction that everyone's heading in
what I'm actually prioritizing is that
tech leaders actually consistency
because one of the problems that you
generally have in sort of software teams
is that you have a bit of a churn and
even if you don't have churn you might
end up with people with specialized
knowledge in different parts of the
codebase and so if you go back to that
whole principle of trying to understand
does the codebase look like it was
written by a single person
you're really aiming for consistency
rather than clever code that kind of
hides stuff away now one of the
interesting things is that when we talk
about consistency over cleverness people
who were actually trying to do clever
things are actually trying to do the
right thing this is the whole
retrospective prime directive they
really want to do and learn the latest
things and run or apply it and make
developers we get caught up in our
arguments over what is best and
unfortunately I don't think there is a
best thing in our sort of industry
there's always contextual best in terms
of you need to understand what is good
in your environment and what's suitable
and so in many teams that I've joined
there's often these debates tabs or
spaces no no no we need four spaces two
on the next line on the net or the one
before do we use
camelcase or underscore notation all of
these little arguments and you watch
refactoring battles go on in the code
base where people will check stuff out
refactor stuff check it back in and
really you know a lot of this stuff is a
bit of a waste of time
so my whole thing that I talk to people
about is that I think it's really
important that we have consistency over
cleverness because there are more
important topics to spend our time on
there are actually technically
challenging project problems that we
should be spending our sort of efforts
on exploring on investigating and trying
to come up with creative solutions
rather than arguing for our own personal
preference when it comes to programming
I also think there's an element to team
culture that we need to think about and
I'll talk about the people side a little
bit later but this is really about what
is the team culture around the
programming elements of how do people
treat the development aspects so for
instance one of the things I think about
when you need to build a team culture is
sort of thinking about a team charter of
how you work really and one of the
things that I kind of well these sets of
questions are the things that I kind of
think about when I think about how
healthy is a team when it comes to
technical prowess so one thing is how
long does the build stay broken so do we
have a healthy culture of anyone can
actually fix the build regardless of
whether they thought they checked it in
or do we get into entire arguments
around I didn't do that check-in it's
not my tests that work
what's that team culture around keeping
that build healthy and green hopefully
we all have builds the next thing is do
people avoid conflict so do people do
that whole check out refactor check in
rather than actually saying hey you know
I think we have a bit of a disagreement
about our approach to this can we
actually deal with it and have a
conversation about it so I think
conflict in teams is essential to
actually healthy teams I think there's a
bit of a you know picture perfect team
where everyone's smiling getting along
and actually I think that's a bit of a
dream I think it's healthy that teams
have conflicts what's important is as a
tech lead you need to facilitate them
through that conflict so you actually
get to a answer of
sort and I'll talk about the importance
of conflict and why that's that's useful
later the other thing is do people offer
new ideas I think as a as a lead one of
the things that I look for is really
creating an environment where people
feel that they can actually fail failure
is important Linda would have talked
about in her last talk where actually
the whole human mindset of learning and
trying something else is about failure
we need an opportunity to feel that we
are safe to fail and as much as I hate
being wrong in front of my team I'll be
one of the first people to actually say
hey I tried something I got it wrong and
we should move on and try something else
and I wonder how many people feel that
they could actually do this in their
teams right now
do people flag when they need help do
you have people who go off in a corner
for for a week
saying I don't know it'll be done 90%
done it's almost done and actually I
heard of a story about this recently
from some some ex colleagues of mine
they're working with a small company
where everyone's working teams of two to
three people and they had one person on
this team who had sort of broken away
and they were doing a new API for
integration and it was supposed to be
done in two weeks it's been six months
it's quite a while and each week people
are asking do you need help and has kind
of got into this a reinforcing cycle
where it's like no no I'm almost done I
don't need help I'm almost done and I
think one of the things that lead is
that you need to be able to help people
come out of stuff as humans we have
personal pride that's completely
understandable however we need to be
able to accept that we make mistakes and
we need to get through that so these are
some of the things that I think really
make a big difference to our programming
sense because other people have skills
that we don't have that we can tap into
to help solve the problems that we can't
necessarily by ourselves and so we need
to we need to know when we need to ask
for help finally do people feel okay to
admit that they're wrong and I think
there is a lot of stuff in developer
circles about developer pride
and so we think about this sort of
environment that you're you're sort of
fostering and thinking about whether or
not people can actually answer yes to
these questions the next thing I think
is a tech lead that you need to focus on
from a programming sense is a vision
who's heard of the XP practice the
metaphor okay it was one of the UH
XP Edition one it got dropped in the
second edition and for me it's actually
a really interesting thing because I
don't maybe necessarily understand as
much as Kent Beck does but for me I
think it's a really powerful thing is
that can you actually articulate why
your project or your software exists
what is the problem that that's trying
to solve and why is it important as a
developer I think we all get kicks out
of seeing the stuff that we create gets
used there's nothing more I don't know
disappointing than writing software that
gets thrown away or features that never
get used you kind of end up quite
frustrated because it feels like you've
spent a lot of effort to no avail and so
as a tech lead one of the things I think
about constantly is what is it that
people need to hear to help them
understand why they're here to do what
they need to do and if the answer is
actually you need to counsel your
project maybe that's a good thing I
think it's important that people have a
compelling vision and a purpose in
programming there are so many things
that shouldn't be sort of written that
can be done through manual sort of tasks
and manual process but we shouldn't be
writing software for and we should be
so for me the vision perspective is
really important to what we're doing as
programmers so let's move on to the
people aspect and and and here's kind of
where we need to stray away from maybe a
little bit more of the classical stuff
you hear in other talks one of the
things I think about is that there's
something about strength in diversity
one of the things I do with a lot of the
teams and the people that I work with is
I help people introduce this book called
the strengths find a book have many
people heard of this ok maybe wanted to
so for me it's really interesting
because this book premise is as people
we tend to focus or at least our sort of
education teaches us to focus on
weaknesses we can't have any weaknesses
you have to get be good at everything
unfortunately what they've found out
through a lot of research is that we're
much better if we focus on our strengths
so I mean we have weaknesses and we
should address them if they become sort
of problematic but we are much more
successful if we know our strengths and
which we focus on applying those
strengths and all the things that we do
so this book talks about I think it's 34
different signature themes that and they
come up with about five different
strengths so they talk about what are
your top five signature strengths that
kind of come through so I picked out a
few that maybe make sense to people in a
sort of software context so maybe one of
the things is intellection so maybe
you've worked with a developer like this
who likes to think about a problem very
deeply they'd like to research do a lot
of reading I'd like to think about the
problem very deeply they want to think
about what's the right thing and think
side you might have somebody who's an
achiever so somebody who just needs to
get stuff done somebody who wants to see
stuff out there and get stuff done
quickly and both of these things are
very important in different different
contexts of where we work in software
team so sometimes we do need to push
very quickly to get something out there
but sometimes we have those really
challenging problems that need a lot of
thought and one of the things that I
really appreciate being a tech lead is
that in a team of people you have a much
broader set of strengths than you do as
an individual and so understanding each
of the different strengths of each
person in your team makes you aware of
at least where when different tasks come
up what makes sense to actually apply in
different contexts so was really
powerful when you actually need to work
with business people who don't don't
like talking to technical people you
need somebody to win people over so that
they can open up to listening to why we
might need to address architectural
changes and why they might need to
invest in operational infrastructure or
monitoring or various things that
perhaps they don't really make sense and
so by understanding the people in your
team and the strengths that they have
you actually end up with a much stronger
sort of group overall than if you were
doing it individually so one of the
things that I think is is really
powerful in this book is that you can
sort of get everyone a copy of the book
and then work through them
with their strengths and help them talk
to each other about what their strengths
are if anything I think it also helps
everyone understand when everyone's like
working closely together on the ground
where each person is coming from I know
I've certainly been a lot less
frustrated by people who maybe need
ideation so that they're looking at the
latest and greatest things all the time
instead of actually getting stuff done
because that's you know one of the
things that they're very good at and you
know maybe when you're actually looking
at new areas to sort of in some some
sort of feature that you've never dealt
with before maybe they're the right
person to help look at what are the
different options out there that can
help us achieve that new goal so
different contexts different strengths
and if you don't believe me I think
there's some interesting statistics and
and research out there and one of the
things that I really appreciate working
at our company is we really value
diversity so I think pretty much for the
last six years have worked on a project
where there's at least been one one
female developer on a sort of project
and I know of a lot of people in our
industry who've never worked with a
female developer and I think it's really
interesting in that there's a paper here
that said that with three or more women
on the board they gained significant
performance advantage over those with
the fewest and if you look at the
statistics like in terms of actual
monetary return that's pretty amazing
this was a bit of an older paper but
there was a more recent one over the
past six years companies with at least
some so that means just one or more
female board representative outperformed
those with no women on the board and
equity on their board those with women
had 16% so that's a third more and I
think it's very interesting because once
again the sort of male-female thing it
is about diversity is about tapping into
things about the way that people think
differently the different skills are
they bring and there's a really good
book called the difference it's written
by Scott page who's a lecturer at the
University of Michigan that actually has
done a lot of research in terms of
proving and it's got amazing
mathematical formula about improving how
diversity makes sense he has this
formula and this isn't the mathematical
version but he talks about collective
accuracy equals the average accuracy
plus the diversity in that group who's
heard of the Netflix our challenge okay
maybe one or two so it's quite an old
thing now I think it started in 2006 but
Netflix is that I think everyone at
least knows the company because there's
a few speakers from there but they had a
competition where they basically wanted
to improve their recommendation
algorithm and so in 2006 they set out
this competition and Scott writes about
it in his book where the people that
could actually improve their
recommendation engine by 10% would win 1
million dollars pretty pretty cool huh
and what they did was that it had to be
by at least 10% and for each year where
people didn't achieve that they would
have a nominated prize of 50,000 people
could submit their sort of entries and
what was really interesting wasn't the
fact that they actually got to there 10%
improvement it was actually interesting
about how the teams and how they work
together in terms of winning the actual
outcome so in 2007 there were three
leading teams Belcore big chaos and
Belcore in big chaos which was actually
a joint union and all of them were doing
pretty well but it was a joint union
that was doing a little bit better than
everyone else
in 2009 one of the team so Belcore in
big chaos joined up with yet another
group and that became I have to write it
down because I can never remember
bellcore's pragmatic chaos in order to
improve their recommendation engine even
more and so they actually hit the 10% at
that point but at the same time they had
another competing team who hit 10 point
oh nine called the ensemble which was
also a group of different people who'd
competed and what was really interesting
is that the final winner was actually an
amalgamation of all the different people
that got together rather than the
individuals who started off and what's
fascinating about this is that it's
actually a little bit of a you know it's
a it's a real good example of this where
their solution improved overall because
they were able to integrate all the
different ways and different algorithms
that they had together in order to
improve their recommendation engine and
I'd really recommend this book for going
a little bit more detail about why
diversity matters so when you're
thinking about software and the problems
that we deal with as a tech leader it's
really important to value and appreciate
the diversity of the group that you have
and what what is really key is this the
small star that I have on the slide
which is you need that ability to
integrate so you need everyone to be
able to work together in order to tap
into this diversity there's no sense in
having a group of six people if all they
do is work by themselves all the time
because you're not actually integrating
all their solutions I think one of the
other things about people is that as
humans work we're sort of built into
this mode of working in small groups and
one of the things I think a lot of
companies do is send people out on trust
building activity days and I would
actually say don't do that
Trust isn't built in a day I've seen a
lot of teams we go away have a lot of
fun you know they do something outdoors
and as a group but at the end of the day
when they come back into their working
environment they're no better off
trusting each other and one of the sort
of secret things that I've learned over
time it's actually Trust is built very
incrementally so the things that you can
do to help sort of shape some of this
stuff is like you know make people to go
out to lunch together like don't force
them but create opportunities to go to
go and sit down to lunch together to
spend social time together I live in
London and one of the biggest things
there is actually making tea for each
other British people love their tea I'm
originally Australian so I had to get
into this whole tea making culture and
one of the things that they have in in
the mornings and the afternoons is that
have rounds of tea and so you're kind of
making tea for each other and you get to
know what each person has and just the
small token acts of actually doing these
things for each other is really
important we live kind of in a very gift
economy in terms of the way that we give
and receive trust is that if I do
something for you I build a lot of trust
in terms of you know reciprocation and
that's just kind of how we're actually
built so I think one of the key
takeaways I'd like you to think about is
if you really want teams to get together
don't think about big bang things think
about the small activities that happen
daily that help people grow stronger
relationships together
I think the next thing is a tech lead
that you need to think about from people
perspective is really thinking about how
do you grow the people on your team and
I really like this kind of model if you
think about when you're picking
something up new for the first time so
on the axis over there we have how
difficult is a challenge and on the
bottom axis we have this thing about
skill and ability and one of the things
about this kind of model is that if
we're given something too challenging
but we don't have the skills for we get
really nervous we get really like you
know we get the sweats we're thinking
about I'm not so sure I can do this I
get really anxious about this sort of
stuff at the same time if we're really
good at something and we're not given
anything stimulating and the challenge
is too easy for us we get bored and
there's this thing where we kind of flow
between these two sort of things and the
sweet spot that you kind of a thinking
about is this section in the middle
where you know we want something a
little bit above of our ability so that
we can actually grow and challenge us
but we don't want it too much because we
might get really stressed out at the
same time we don't really want to be at
this place here where we're kind of
bored and so when I'm thinking about
this sort of different tasks that need
to be done in all the different
development activities where skills lie
in our sort of collective group of
developers one of the things I'm
thinking about is how do I match up so
many skills and challenges so one of the
things I like doing is actually having
one-on-ones with people and asking
people about you know what are their
goals and what do they want to do and I
get a good sense about you know where
they currently sit to help understand
what are the things that are coming up
so one of the things that you can then
do is that you can give somebody a
challenge that's a little bit outside of
their current skill set and you can
support them in doing that sort of stuff
but one of the things you have to
realize with this model is that humans
learn and we get better at stuff which
is an amazing thing but what that means
back into this sort of thing so once we
get into that challenge we get into this
flow you feel that adrenaline hit from
solving something and get excited but
you know if we're given that task for
too long you know we might end up
getting bored so we always have this
constant battle that we're thinking
about is that
as we get challenged and we overcome
that we then face another thing where we
need something more challenging than
that to keep us engaged and so it's a
little bit of a cyclic thing that
becomes very hard to actually you sort
of think about and it's a constantly
evolving thing and the great thing about
this industry that we're in is that we
have lots of problems to solve so
there's lots of things for people to
think about and lots of opportunities to
grow the challenge is as a lead trying
to work with a team and help them
identify what makes sense for them and
how they can help support each other so
I'd recommend the flow book here which
is about the psychology of optimal
experience which talks about this model
the other thing that I think about a lot
with the people that I have is about how
do I maximize their potential and I have
this I I've recently sort of handed over
my tech lead responsibilities to another
developer of my team so I could go back
to just being a developer which is
wonderful and one of the models that I
wrote down for him was this one that we
talked about so when I'm thinking about
a person there's lots of different sort
of elements to them and one of the
things that I'm looking for is that I
need to really understand where their
skill sets lie so are they really great
that sort of JavaScript so they're
really great at I don't know database
type stuff are they really great at the
operations type stuff are they good for
the build management and sort of all of
that sort of stuff at the same time I
really want to understand their
strengths so what where are they
actually gonna are they a completer do
they need are they one of those people
that need to look for new things and
then what do they actually want to
achieve out of this project and then the
final thing is really about their
interests so what is it that they're
currently actively interested in web
services or various things like that and
so what I'm trying to do is really get a
profile about the team that I have and
look for where the sweet spot of overlap
is and so the only way that you can
really do this is actually by talking to
everyone on the team so you need to
understand them a bit more you want to
have an open dialogue about trying to
understand where that all kind of works
at the same time you need to think about
what things you could actually influence
so one of the things I think about is
that well with skills especially you can
help build a lot of skills with people
right so you can get external people who
have expertise
working with people and you can grow
that sort of stuff you can work if
you're an expert in a certain area you
can pair program with people and
transfer those skills and help people
grow that sort of stuff
that's something that you can actually
influence a lot you can also help sort
of shape goals a little bit maybe people
have their own sort of goals but if
people don't you can you know help
identify what is it that I feel
passionate about and maybe help them
with that you can't do that necessarily
as easily as with skills it's a little
bit smaller at the same time also about
interests so there are tasks in
development that we all need to kind of
do and it may not always be interesting
to people but you might be able to
explain to somebody why it's important
for success so you know it's great that
we actually wrote a new feature but
what's important is that getting live so
everyone has to take part in actually
getting our code shipped into production
because that's really important right
but maybe people don't like that so you
can help people understand the
importance of things but once again it's
a very small thing that you can
influence not as much as skills and
unfortunately you can't really do
anything about strengths so in the
strengths finder book it's the the kind
of just something that we're kind of
built with the things that we like you
can't really influence that so much but
the things that you can do you can help
support learning and have lots of
different activities for doing this sort
of stuff so some of the things that I
like doing with different people
obviously pair programming is a really
great thing if you're doing for the XP I
find it really a great way of learning
different techniques and things and
spreading stuff around the team who's
heard a brown bag sessions okay good but
so basically we have kind of lunchtime
sessions where somebody might do a talk
and on our current project we seem to be
doing one every fortnight and we rotate
everyone through it and everyone just
talks about their pet personal project -
what things that they're actually
passionate about and then I work with
them for to help support them in sort of
preparing their presentations and
talking to people about it I know that
some teams do like video or book clubs
so maybe you have a book and you're
reading a chapter a week and then you
get together and talk about well what
does it domain-driven design I have for
us in this sort of team context or
perhaps you watched like a a ten minute
info cue video
and then discuss how is that applicable
to what we have some of the things have
been experimenting with lately are
things like technical or spiked
showcases so we we maybe have heard
about showcases in an agile iterative
sense where we showcase here all the
different features in our sort of
product that we've built in this sort of
cycle but maybe one of the things that
we want to focus on is actually he's
talking about what are the different
things that we've learnt amongst
developers and spread that knowledge as
well and its really good when you're
working with a large team to do this
kind of spike showcase type stuff where
actually what you're showing is some of
the technical learnings and you're sort
of amplifying that to the rest of the
team at the same time I find technical
focused retrospective is quite useful
I've been in many a retrospective where
the developers dominate just because
they have a lot of people compared to
other roles and they end up talking
about things like we don't spend enough
time rotating through pairs or the build
has been broken a lot this this
iteration and so a technical focus
retrospective can actually help focus
everyone on learning stuff about the
codebase and what other people are
concerned about and it also may may lift
the rest of your retrospective so
they're actually kind of useful as well
and the other thing is whole team code
reviews so I don't know if anyone does
these but the way that I kind of conduct
them is that we have a room and then we
get people to pick out different parts
of the code base that I'd like to talk
about and then we project it up on the
screen and then we all kind of have a
bit of a go at it kind of thing and
because we have kind of collective code
ownership there's none of this you know
one person has ownership of this so
they're not really going to be really
defensive around this sort of part if we
before you inspect it and then we just
talk about what are the things we'd like
to improve around this sort of stuff and
then that kind of evolves in our sort of
iterative code standards so as we tackle
new problems we we detect these kind of
code smells we get everyone together in
room and we project it up and then we
agree what's the best way forward of
actually getting there so I think that's
a really useful thing about how we can
amplify some of these learnings sort of
activities the final thing about people
is that people it's really hard you know
it's very uncomfortable as a developer
having to think about these kind of
things and one of the hardest bits of
advice I've had to
people is really about beware the bad
apple and one of the things that I think
is is really contagious I think is that
we can be really hard on ourselves and
maybe you've worked with developers who
are like this who have a pet have a have
a pet peeve of some sort and all they do
is talk about it constantly
and maybe that starts to infect everyone
else in the project and there's an
interesting psychological paper called
bad is stronger than good that talks
about in order to offset sort of
negative kind of comments of something
you need ten positive reinforcement
things to offset one negative stuff so
one of the things that I sort of give
advice Tett leads when I'm sort of
coaching then when I'm working with them
is bare where the bad apple and there's
different ways of actually dealing with
this so you might actually help them
understand you know how they're saying
something is is the thing that's
actually affecting it or maybe they
don't actually feel like they're being
heard so you want to give them an
opportunity to do that so maybe you have
a way in the technical retrospective to
be able to talk about some of the
problems that they're actually seeing
what's important is that you don't let
somebody stew because that sort of stuff
can actually spread or the rest of the
team might end up isolating that person
which isn't good for anyone it's
uncomfortable for the other person
it's an comfortable for the team and we
need to be I'd actually deal with this
so I think one of the big bit best parts
of advice is that as a tech lead you
need to actually develop skills and sort
of conflict management and help people
find ways of airing the issues that they
have that are concerning them and then
find ways of overcoming that and if that
doesn't become if that's not a viable
solution you may end up needing to
recompose the team so finally I wanted
to kind of talk about the process side
a lot is is it okay to tell people what
to do we kind of work in this
collaborative space now there's a j'l
surf everyone's supposed to get along
but can I tell somebody what to do
and my advice to them is yes but only
sometimes if you're telling somebody
what to do all the time there's
definitely something wrong and there's
something called the situational
leadership model that's really useful
for understanding this
so they kind of talk about do you direct
people or do you support people and the
different combinations and you go
through this weird sort of cycle graph
backwards in terms of thinking about do
you do sort of directing or coaching
supporting or delegating and when you're
thinking about this one of the things
that their model kind of talks about is
you really once again need to understand
where somebody is at with the task and
the sort of skills of that person at the
time so one of the things they talk
about in this model is if you have low
competence but somebody's really
enthusiastic so a really good example is
if you have graduates straight from
university who don't have experience
they're normally really enthusiastic you
know they want program but they don't
really know how they want to learn all
this stuff but they just you know
they're they're on they're fresh on
their journey you might need to actually
be helping them and directing them a lot
more on the flip side you have somebody
who's been picking up a skill and you've
probably been through this yourself
where you've been doing something maybe
you've started unit testing but you're
not quite comfortable with it yet so
you're not really so sure of it so there
the term commitment kind of involves
both confidence and motivation so maybe
they're not so confident in their own
skills yet and part of this model is
then thinking about you need to actually
help coach that person in that situation
and then you kind of get on to more
competence but they're not really there
in terms of commitment so you know they
understand and they're pretty competent
and they they know that they're pretty
good but maybe they don't understand why
it's important and this is where you
might need to be supporting them in that
sort of sentence and then finally you
have high competence and high commitment
and that's basically something you can
just delegate to something so it's like
I trust you you can deal with this and I
don't have to worry about it
so that's kind of that sort of model the
other thing I think a lot a lot about is
about Tuckman's and it's a very old
model I think it comes from like 1970
but it's basically study about how do
how do teams form and one of the
comments that I've had from people
before is that I think people say that
actually you know what our team's being
together for a long time but I think one
of the things is that actually you have
one person join or you have one person
leave you have a new team you go
through this model again so when you
think about it a tea a group of people
get together they're definitely not a
team they're just starting to form and
then you start to get some conflict so
you get some disagreement you get some
arguing and then you get through if you
can get through this stage you get to
some sort of normalization and and these
two stages for me are really critical as
a tech lead to really support so you
want to be on an embrace conflict and
talk about issues openly but you need to
be able to get through that as well so
that you get to norming I've seen a lot
of places where people avoid conflict
and they end up in this kind of storming
phase and they never ever actually get
to agreeing on how do they work as a
group
if you've ever done sort of team
chattering or sort of project hardest
this is a really useful exercise to get
through this and if you can get through
that then you end up with a pretty high
performing team so you know people who
understand how each other works and
maybe once you finish a milestone you
end up a journey and I think this is
something that they added on to their
model which is really good and as its at
lead you want to celebrate this part
it's it's a little bit sad sometimes
because your team is kind of maybe
breaking up or somebody is leaving but
you really want to help support this and
what I really want to think about what I
really want you to think about is when
somebody does join or leave you can go
really drop dramatically from performing
team back into a forming team so all it
takes is one new person to join a team
and the whole dynamics will shift
somebody who is very loud or somebody
who's very quiet who doesn't fit in can
change the entire dynamics the same
thing if somebody moves will changes
positions a lot of that sort of stuff
can happen again so like a lot of these
models you kind of need to be thinking
about these constantly and seeing where
your team's at so small inspecting adapt
and see what things you might want to
try to to to help get to the next stage
and I really like this quote which is
essentially all models are wrong but
some are useful so one of the things for
instance that I think about here that
both of these models don't cover is what
happens if you're in a very chaotic
environment so you have eight different
people coming at the team all the time
demanding things get done how does that
actually affect some of this stuff and
both of those models don't really adjust
for some of that stuff so the the
biggest thing I want you guys to take
away is that all of these are
just models and sometimes they're right
sometimes they're wrong and it's really
thinking about what are the things that
you can do to help improve this sort of
stuff the other thing I think as a tech
lead you want to really think about is
the process about you and spending time
for yourself
I've watched a lot of team leads who end
up sort of in meetings all day who end
really get to spend time with the team
and if I do there may be programming but
one of the things I found a lot of value
in is actually making time for myself
so you can feel really inundated by all
the things that can happen and I think
one of the things that made it easy to
accept how to deal with this is actually
at the end of the day you can't deal
with everything you have to find time
when you need to spend thinking about
the team and so one of the things that I
think about is in my calendar week
really looking at ways that I can spend
time thinking about how is the team
doing how do how what are the smells and
I'm actually experiencing and what can
we actually do about it so I extracted
out a calendar a week out of my calendar
and this is kind of what I was kind of
thinking about here so I'm kind of a
morning person I'm from Brisbane so the
Sun gets up very early so I get up very
early as well so I like coming into work
a little bit earlier before everyone
else does I get through all my email
that I think I need to respond to where
I don't have to worry about it so and
then I try not to check too much email
throughout the day I then have all the
other activities that might happen and
then at the end of the day at least
twice a week I try to set aside some
planning time depending on what your
environments like I find sometimes
booking a room and just sitting in it by
myself with my laptop thinking about
stuff kind of is useful my project
managers does something similar to this
where he says it may look like I'm not
doing anything but I'm actually thinking
and it's really important because like
retrospectives we need a space to think
about how are we actually doing how do
we evaluate ourselves what are the
things that we're looking at it's so
easy to get caught up in the day-to-day
confusion and get reactionary that you
really need to set aside
time to prioritize the activities that
you're doing and work out what are the
things that are essential that you
should be doing that nobody else can do
versus anything else what are the things
that nobody else is thinking about that
you need to be thinking about and that
the elements are talked about are these
kind of things and then at the end of
the week I like to talk about sort of
our practices or try something new with
a team and think about that sort of
stuff what I really want you to take
away from this geeks guide to leading
teams is really thinking about these
dimensions above and beyond being a
developer I think those developer skills
are essential and are really important
to you being effective as a technical
leader but there are two other
dimensions in terms of the people and
process that make you so much more
effective as a technical leader and will
help you achieve a lot more so does
anyone have any questions okay well
thank you very much and I hope you