What I wish I knew as a first time Tech Lead – Patrick Kua | The Lead Developer UK 2016On September 15, 2019 by Raul Dinwiddie
>>Good morning. I want to personally welcome
you to the Lead Developer Conference. I’m really excited about a conference like this
because when I think about my own journey as a tech lead, there was nothing like this
to help me enter that role. And I think one of the things that I want to share with you
as part of this talk are some of the things that I’ve learned moving into this role and
talking to many other tech leads about their experiences moving into this role and some
of the lessons and challenges they’ve learned along the way.
There are a few books out there and more and more, and this is a positive thing for our
industry. But I think there’s other things for people to learn through other experience.
I have worked with ThoughtWorks for 12 years and this means I’ve met quite a bit technical
teams. We’re a consultant. Sharing ideas about continuous delivery, lean enterprise, and
our tech creator, which you can find out more about. Luminary Jim Smith and Fowler, and
we’re happy to talk more about it later today. Personally my interest is in building new
sort of technical leaders. And in this I’ve actually published a couple of books. One
which I’m very passionate about learning and hence about retrospectives but the other one
is talking with tech leads, which is a collection of interviews with 35 different people in
different stages will be giving away five copies of this at our stand. So come by and
we’ll be happy to talk more about this. However, let’s not talk about our time together.
We’re going to be go on to a journey and we’re going to have a look at three different phases
about perhaps what some of you are about to be starting on or what some of you have been
through and still continuing on. We’ll briefly look at what life is like before coming a
tech lead. Maybe some of you are still developers looking at being a Lead Developer and what
it means to play this role. Well, maybe look at the shock and experiences of being the
first tech lead. It’s quite interesting because I think it’s one of the most difficult transition
phases for anyone first taking on a leadership role.
And then we’ll have a look at what a seasoned tech lead might have learned through over
time. So first as a developer. I clearly remember
my first time as a tech lead. My first terminal — maybe recognizes. The place working and
the thing about the code that I would be actually producing. The way I measured the value I
had was through the code I wrote. Through the features and systems that I built. And
I was really excited about delivering features. I was lucky enough to be involved in the agile
project very early on in my career, and I got a lot of kick out of actually delivering
functionality for the clients and seeing my interior being used. I think there’s nothing
more disturbing than seeing it go to waste and put on the shelf.
And the interesting thing about this phase as a developer is you get fast feedback about
whether things are working. We get to know whether or not things are broken immediately.
Maybe our tests are broken, maybe we get monitoring failures in production, or we get sort of
bug reports from users. In these days, okay. There are sometimes some challenges we need
to look at stack overflow, we need to go onto the Internet, talk to colleagues and think
about these problems. But these problems get solved relatively easy. We can kind of think
about, you know, the feedback cycle in terms of minutes, hours, maybe days. And we get
this sense of accomplishment that things are getting better and things are moving on.
And over time, I guess one of the things as a developer you want to solve more problems,
bigger problems, more interesting challenges. You sort of build one system, you get really
excited about it, you want to build another system. And maybe you want to have a bit more
of an impact. And, for me, it was really interesting because I think I started to think in terms
of building systems and not just the software, which I would be actually writing.
For me, my transition for being a tech lead was quite interesting. As I was coming a weekend
abroad in Europe somewhere, I got a call from my staffing while I was still at the airport.
I get a telephone call telling me I’m actually not going to be going back to the team I was
working with as a developer, instead I would be going back to a new team where I would
be acting as a tech lead. Exciting times. But then I started to think what does this
actually mean? What exactly is a tech lead? How do I know if I’m going to be a good tech
lead? I’ve only ever been a developer. Yes, I’ve worked with good tech leads, but I was
focused on the code I wrote rather than what the tech lead does. It’s interesting because
we work with tech leads all the time but we don’t observe what they’re actually doing.
And so, for me, this was the whole transition moving from being a developer to the first
time tech lead. And this was kind of scary. As a developer, I felt like over time I knew
what the path was. That it was well, well — I knew I had learned a lot and I knew there
was even more to learn. The areas that I had focused on, I knew there were lots of books
about, other conferences where I could learn about these ideas. But this tech lead thing,
it was fuzzy, it was unknown. I didn’t really know what I should be focusing on. I didn’t
know where I should sort of look to get advice. And I didn’t even know if I was going to be
doing a good job. I felt like an imposter. So it’s a good thing there’s a talk tomorrow
about endorsed syndrome. And the thing I learned over time doing this,
and it’s a bit clich�. There were days that I felt like I made progress and other days
I didn’t know what I was going to do. I didn’t know if I was making the right choices or
saying the right things. I think I made a lot of mistakes, and I apologize
to my team, but I also hope they had a good time as part of it. Looking back also at the
teams I had worked on before becoming a tech lead, I realized many of the tech leads I
worked with had also made mistakes. I managed to live through them but also vowed torch
make the same mistakes they had and thus hopefully make a more positive impact with the team
I had. And the thing about the tech lead is you get
to make, but you only get to make some number of mistakes. I guess one of the things that
you sort of learn as a tech lead is your impact is amplified. No longer is it the code you’re
writing or the systems that you build are effective if things go bad but actually it’s
the whole team and the environment in which you work.
I think one of the sort of first mistakes, it’s the easy trap to fall into is this idea
about writing code all the time. As a developer, you do this most of the time throughout the
day. You’re comfortable writing code. And as a first time tech lead, it will be your
safe haven. You need your quiet space where you feel safe to do something and you feel
accomplishment. And writing code is often an outlet. You have to be careful, though,
you don’t fall into this trap of writing code and leaving all the other responsibilities
behind. Because that’s one of the responsibilities of being a Lead Dev. You need to look beyond
the code you’re actually writing. Now, it’s quite often in my experience that
people who make this Lead Developer transition, is that you’re probably one of the more senior
developers or one of the considered best developers. And the temptation here as a tech lead that
you might want to make all the technical decisions and this is where you need to be really careful.
You don’t want to take all the really hard decisions on because you probably won’t have
all the information that your development team will have. More to that, you need to
think about the impact you’re having with the team you’re actually working with. If
you take on all the interesting challenges, then what is left for everyone else? Everyone
else should have some interesting problems to solve as well.
I worked with one tech lead very early on in my experience and that was kind of a traumatizing
one. We would write code and then overnight they want come in and refactor everything
we had written. You laugh but imagine after two weeks all the code you write being rewritten.
You get a sense that the thing I’m developing isn’t worth it anymore, so you start to lose
interest. And as a Lead Dev with we have to make sure
that what we’re doing with others communicate with their value.
One of the things we need to be aware about is being aware isn’t somebody else’s problem.
When work on a team, everyone will have a bad day. People will have a sleepless night,
things will be going on outside the team and as a developer, you ignore that. You don’t
have to solve that problem. But as a tech lead or Lead Dev, you need to worry about
this. You need to make sure the mood of your team and be aware of that and how that starts
to spread. Be aware someone angry and negative how that impacts the people around you. You
don’t need to solve that problem, but you need to be an emotional outlet to help them
through that. You need to being of care of some of these people problems.
And I guess one of the things that first time tech leads go through is this fear of wanting
to maybe assert their own sort of opinions. You know, maybe this fear of wanting to stamp
authority on things. And there’s a gentle balance for you to have. But there’s two extremes
and one of the worst extremes is actually not to do anything about it. To assume that
the team knows which direction people are going in. And this is the direction that I
see teams pull apart in different directions. Oh, this is the time that we get to play with
new technology or tools like react or build up this technical debt over time. Other people
are turning out features and our responsibility is to make sure everyone is lined instead
of pulling in different directions. And I guess this is where we also need to
worry about how we resolve arguments within the team. A typical tabs versus spaces fights.
We need to actually be able to help the team come to a consensus. And I kid you not. I’ve
been on many teams where you’ll have some developers check out code, automatically format
and check it back in. Imagine this going back and forth all the time and how much time that’s
wasting when they can solve more interesting problems with this energy.
So, yes, we can make mistakes. But we need to be careful about how many we make and what
that actually means. So this brings us on to a longer part about
what is it that a more experienced tech lead knows about after doing it for many times?
I think the really interesting thing for me having interviewed lots of different tech
leads in this role is that the transition for being a first time tech lead to a more
experienced one is a little bit easier than it is being a developer to being a Lead Dev
for the first time. As a Lead Dev, you’ve focused a lot more on your technical skills
but not really focused on all the other things that you will be able to take time to build
but just as important such as people and leadership skills.
So let’s have a look at what a wiser tech lead does.
The first thing is being comfortable that things will no longer be binary. So as a developer,
we’ll be very comfortable that our code will work or it doesn’t work. Or be very comfortable
understanding whether our system is actually functioning or things aren’t functioning.
People report errors and we’ll work out if they’re actually right or not. Your feedback
as this developer comes really fast. Comes in terms of the seconds and minutes or hours
rather than thinking about, you know, days or weeks potentially about people and their
sort of systems. And the thing is as we sort of make actions
we decide to do as a Lead Dev, sometimes we don’t know if they’re the right actions and
this is where things get really fuzzy. It can be weeks until the consequences of what
we do actually has some impact. And we’re never really sure if it’s the right thing
to do. Things get really hazy and do not communicate enough to the team of what we’re doing. Does
everyone understand the end architecture of what we’re build? Are we moving in the right
direction or taking on too much debt? These are simple answers to say yes or no. These
things change over time and never be precise. We’ll get a sense of them but we have to understand
that this is a natural state of things. We’ll never get that right answer about whether
things are perfect right now. In a complex system such as involved with
teams and organizations, these effects of when we decide to act on things, take a lot
longer to manifest. And a trap we can fall into is acting too rapidly. And this is where
a system will fall back and forth. And sometimes it’s better to wait and observe before we
decide to act to work out whether or not we’re heading in the right direction. So monitoring
feedback loops in the world of being hazy we’ll never know if we’re hitting on the right
things but we’ll get a sense if we’re moving in the right direction and that’s okay.
I think one of the first things that you’ll be expected to answer from lots of people
as a Lead Dev is having all the right answers. As maybe one of the best developers, people
probably look to you originally to sort of answer all of these questions about does this
sort of — or is this function working? Or is this capability easy to do? You don’t need
to have all the answers and this is okay. You have a whole team to back you pick up.
The important thing is that you tap into the team, and you can out how people can actually
contribute to this. Business people ask you is this the best way
of doing things? Or when can we get this new functionality built? And developers will look
to you is this the right architecture or tool that we should be using? And you don’t always
have to have an answer. It’s okay to sort of say, you know, I don’t know but let’s find
somebody or ask somebody who does. Let’s take some time out to actually discover what might
be the right answer because we don’t know. The side effect to this is that you expose
a little bit of vulnerability as well and vulnerability gives you a really strong face
of being a leader. It shows that you’re never perfect, we can never be perfect. But we can
actually help other people grow and learn as well.
Remember that we aren’t defined by the code that we write or the things that we built.
And as a result, we don’t have to have all the answers and that’s okay.
Third point here is thinking about you won’t be liked by everyone. And this is okay. The
interesting thing about this role is that you won’t make everybody happy. And it’s one
of the consequences of leading any group. There’s a really interesting fable which is
about the man, the boy, and the donkey. In this, the man and boy are walking a donkey
to the market to sell. As they walked by its side, a country man kind of passes them and
says “You fools. What is the donkey for but to ride upon?” So the man put the boy on the
donkey and on they went. Soon they passed another group of men. One
of them who said “See that lazy youngster? He let’s his father walk while he rides.”
Upset, the boy got off and the man got on the donkey himself. And they hadn’t passed
too far when they passed two other women and they said to him, shame on that lady to let
his poor little son trudge along. Confused, the man decided to then pick up the boy and
put on the donkey. The reached the town and many people began to laugh and dear at them.
The man asked what they were scoffing at. And they said aren’t you ashamed of yourself
overloading this donkey with you and this son. They both got off and there were quite
sure what to do, and they thought and thought. And they decided to actually pick up the donkey,
tie his legs together, tie him to a pole and carry them over their shoulder. They finally
reached the market but then everybody was starting to laugh and wondering what was going
on. And in this ruckus, the donkey kicked and kicked and slipped off but fell into a
river and drowned. It’s a bit of a depressing tale, I know.
[Laughter] But the consequences of this fable is that
if you want to please all, you will please none. And that’s the big lesson here. Is that
as a leader, your role is not to be liked by everyone. You need to make sure that you’re
trying to keep everyone as much happy as you can, but you also need to be understanding
that you won’t make everybody happy with the actions that you take.
And this brings onto feeling this role of loneliness. So as a developer, you’re often
surrounded by other developers. Maybe you work in sort of an environment where you pair
program and work very closely with people. And that’s an exciting environment because
when you have problems, you get to bounce things off with other people.
But when you become this sort of Lead Developer, you often end up in this role where you feel
like a slack outsider. Somebody in your team might come talk to you and, you know, talk
to you about something that’s quite personal. You can’t really share that with the rest
of the team, and you’re not really sure what to do with that. So you’re thinking about
taking on these problems by yourself, but you’re not really sure about how you deal
with that. The good thing is that there are probably
other development teams around you with other people in similar positions. Maybe not in
the same context but people who share the same concerns and problems that you might
have. And you can probably get together and maybe talk about these things and maybe sort
of anonymous fashion or safe fashion where you can talk about these things openly. And
the good thing is about people who work in larger companies is that you won’t be the
only teams with the only lead developers out there. You’ll probably have more people around
you as well. And the good thing about a conference like this is that there’s a whole bunch of
you here that could probably support you as well.
So think about building maybe a tech counsel within your organization. Establish a community
practice around lead developers and build your own support network. It’s really important
that you don’t need to work out all of these problems by yourself. And find your own coach
and mirror to bounce these problems off. You don’t need to be alone.
As I mentioned before, nontechnical areas are just as important. And the thing is as
a developer, you probably spend a lot more time thinking about code, design, architecture,
working about how to write clean code, and this kind of circle of skills is really easy,
and we can kind of spend more time developing that. Maybe we’ve thought a little bit more
to the architecture but we need to think about building systems and getting more awareness
about operational concerns or production concerns. But the circle that often takes the longest
is the circle of leadership skills. The great thing about this circle is that there’s a
lot of different books and resources out there. There’s lots of different training for different
types of things out there. If you want to get better at influencing, persuasion, better
at conflict resolution or setting a vision and communicating. There’s a lot more resources
out there. But it takes a lot longer to develop. You get less instant gratification from solving
these things because you don’t get a yes or no binary solve to the problem. But these
areas are just as important to develop. So when you think about your own personal experience
as developing, think about where you invest your time and make sure it feels balanced
in each of these three different circles. One of the important things that I’ve learned
about leadership and learning more about leadership is really understanding that people are really
complex. I think when you start thinking about the teams that you’re working on, one of the
easy things to do is start thinking in terms of there’s team members that you have and
sort of thinking, oh, yeah, I have a group of sort of developers or testers or different
people. And we start to think about them as sort of a collective group. Rather than thinking
of them as sort of a group of — and numbers, we really want to be thinking about each person
individually. And that each pattern is a bit more like a snowflake. Each person has their
own strengths and weaknesses, their own interest, their own background about where they come
from about what they’ve gone on as part of their journey and where they’re heading and
what they actually want to do. And the thing I’ve learned as a Lead Dev is
thinking about how you tap into this. How you find out about these things and find their
interest about where their fashions are and how you use them to sort of help the group
along as well. And this takes time. You need to have conversations
with people. Spend some time with each person and learn — find out what their interests
are. Learn their strengths and backgrounds. And there won’t be a single recipe that works
for everyone. When you think about communication, some people will prefer e-mails. Some people
will prefer being talked to. Everyone will have their own sort of mix, and they’ll never
be a right mix around. But the important thing is that you spend the time and trying to understand
what each is like. More importantly, it’s probably good for you
also to get some feedback from those people as well. Create a feedback culture and work
out if you’re actually doing the right thing for each person on the team. Which brings
us onto the not doing everything yourself. So everyone will have these different styles
about what they would like to do. And time management will probably be one of your most
critical skills to actually develop. As one of maybe the best developers, you might have
felt this pressure of I need to get involved in all the hard places and try to get involved
and take action. I need respect from the team, so I need to be seen writing code, and I need
to do all of these other things, but you have many other responsibilities to take care of
as well. So you can’t do everything yourself. One of my favorite tools around this to draw
upon is the idea of situation and leadership model. And this is the idea of acting like
a leader depending on what skill and sort of background people have and what things
need to actually happen. So there’s no one leadership mode that works for everyone. It
looks a little bit like this. So we have sort of supporting behavior and
directing behavior. And we have kind of four different actions that we might be able to
take with the team that we’re actually working with. We can maybe sort of tell people what
to do. Maybe we actually need to sell them the task at hand. Or maybe we need to actually
get involved in the problem solving with them or just purely delegate.
And depending on the point in time of where people are, you need to take different actions
around this. So a example is when we work with graduates, we bring them in. You generally
have this huge enthusiasm that comes from people fresh from university. They want to
change the world. They want to learn, and they have this enthusiasm motivation that
maybe more experienced people have lost along the way. And the thing that they’re lacking
is really about the knowledge and know how. And so actually they’re willing to be told
what to do to a certain degree about being a little bit more prescriptive and giving
a little bit more systems about the task at hand. Whereas if you try to act this way with
maybe more experienced people, it will be really frustrating for them; right? Because
they’ll have their experiences and say actually I’m a — an independent person, I know how
to do this. You don’t need to tell me what to do.
At the same time even experienced people will have new places where they need to be told
what to do as well. So as an example, I was talking earlier before I’ve never done React
and if someone gave me a React project, I would be happy for someone to tell me here
are the steps that I need to go through to set up the React framework and here are the
places that I need to go to. So even is someone who is seasoned if they
have a new skill, being told what to do could help them along the way. And the key of this
situation leadership framework is thinking about how you progress people through these
different phases. So as you develop a skill in a different area, you need to move away
from telling them what to do to maybe helping them understand why it’s important and then
move into participating with them. And we ideally want to get to the point, which is
why this graph is backwards, to delegate things so that we can contraband the bandwidth and
provide more supporting behavior and less directive behavior and support them in what
they actually need to do. And this brings us on I guess onto leadership
styles and this is one of my favorite sort of talks about everyone has their own different
styles. And there are many ways of being a leader. It’s okay that you as a Lead Dev will
be different about how somebody else approaches their problems. Everyone has their own unique
strengths as a mentioned. And you need to probably spend some time identifying how you
approach things differently and your observe personal strengths as well.
I’ll describe some of the I guess common patterns which I see. Leaders acting out differently.
The first one is kind of taking a stance where good Lead Devs won’t give people the answers
right away. Instead of telling people the answers, we’re asking questions to help people
maybe connect the dots. So if we think about thinking and lead people to thans, they’ll
learn a lot more than simply being told. They’ll go on to their own path of discovery and grow
as a result. Sometimes people need shepherding. So you’ll
have some people who maybe don’t know what to do, but you know that they have the skill.
And coaching maybe is not the best way of actually bringing them out. You might need
to help them along the path. You might need to lay a few markers to help them come up
with a big solution themselves or maybe the motivation around that as well.
And this is where you need to sort of channel your inner shaman perhaps. There are some
people that are much, much better at this than others. But it’s worth sort of building
up your storytelling ability. When you think about when lead developers join your team
and you think about why is this system like this? Who put this framework in? Why do we
have all of this technical debt? It helps build the story about where it comes from
that there are constraints isn’t the environment and what we actually delivered. And this is
channeling your inner shaman and helping people understand why things are the way they are.
At least it helps you understand and appreciate where are things because of the way the things
got to. The final stance is really thinking about
acting as a champion. So sometimes we need to give our team space. We need to protect
them from perhaps pressures, from external environments, and business people perhaps
coming in all the time and interrupting people all the time. We need to actually create some
space for that time. Sometimes being a champion means that we need to rally the troops and
get them moving in the same direction. Particularly if there are critical times maybe around a
production issue. We need to get everyone focused and solving that problem rather than
perhaps arguing about how you might solve that.
And there are many, many more stances that we can take as Lead Devs. The important thing
is that we need and appreciate which of the ones we will of more strongly with and we
have the best skills. One of the secret things about being a Lead
Dev is that something I see a lot of people never really tap into. And the secret power
is being able to say “no.” The biggest thing that will win you time is
by saying “No, we don’t do this” it doesn’t mean you have to say “no” all the time. But
in the pleasure to appease everyone, a Lead Dev will often take on too much and take on
too much and become overburdened with all the tasks they actually need to do. So the
biggest way that you can sort of manage this is actually by sort of telling people maybe
I don’t have the time right now or the team doesn’t have the time right now.
So manage your own time and your own team commitments, and it’s okay to say “no” because
you need to know about what your team is actually good at. Focus on where you add the most value
rather than on the things that you could potentially do. Don’t focus on the urgent and nonimportant
things. Make sure that you create time to actually spend time on the important but never
urgent things. And the only way that you can do this is actually by saying “no.”
Now, there’s lots of different and things maybe this is traumatizing for those who are
developers and not yet Lead Devs. But an important lesson of why you might want to be a Lead
Dev is thinking of the greater impact. So I shared my story of moving on to writing
smaller features to systems to wanting to have more impact. And the powerful thing about
this role is instead of thinking about this sort of myth of the ten times developer is
that if we actually focus on creating a more productive environment for the team in which
we’re working on, if we make everybody on that team just that little more productive,
we can actually give everybody a little bit of a power up and be that ten times developer
through that team that we’re actually working with.
We’ve looked at what life was like before being a tech lead. And the worries of being
a tech lead and the lessons learned of being a more experienced and wiser tech lead and
now being on this journey, and I would like to reveal one more tip. And that is the journey
never ends. Hunger for knowledge and continue to learn and you’ll continue to develop yourself
as a tech lead and have greater impact in the process.
Thank you once again. [Applause]