Navigating the Journey from Developer to Tech Lead: Insights and Lessons

[Music] [Applause] 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 into that role and I think one of the

things that I wanted to also share with you as part of this talk are some of the things that I've learned sort of moving

into this role and talking to many other tech leads about their experiences moving into this role and some of the

challenges and lessons that they've learned along the way there are a few books out there and there are more and

more and this is a really positive thing for our industry but I think there's always something to learn from other

people um with experience um so I've worked with thoughtworks for 12 years and this meant

that I've LED quite a lot of different technical teams we a software consultancy who helped clients build

better software and we try to have a positive impact on the industry such as sharing ideas about continuous delivery

lean Enterprise and our tech radar which you can find out more about um our luminaries are Jim heith and Martin fer

and we're happy to talk more about this at our stand later today um personally my interest is

actually in building new sort of technical leaders and in this I've actually sort of published a couple of

books one which I'm very passionate about learning and hence about retrospectives but the other one is

about talking with tech leads which is a collection of interviews with about 35 different people in different stages

we'll be giving away five copies of this at our stand so come through have a chat to us and we'll happy be to talk more

about this however let's now talk about our time together we're going to be going on

to a journey and we're going to be having a look at three different phases about perhaps what some of you might

have about to be starting on or some of you have been through and are still continuing on we'll briefly look at what

life is like before becoming 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 the experiences of being the first time Tech

lead it's quite interesting because I think this is one of the most difficult sort of transition phases for anyone

first taking on a leadership role and then we'll have a look at what a season Tech lead might have learned through

over time so first life as a developer I still clearly remember my first time

before I was a tech lead my life was very much about sort of the terminal maybe you recognize this uh the place of

where I'd actually be working and it's it'd be a the code and the things that I actually be producing and so the the way

that I actually measured the value that I had was through the code that I wrote through the features and systems that I

built and I was really excited about delivering features I think I was kind of lucky enough to be involved I guess

in one of the early sort of agile projects very early on my career and I got a lot of kick out of actually

delivering functionality for the clients and seeing my software being used I think there's nothing more sort of

disturbing than sort of seeing your software go to waste and being put on a shelf and the interesting thing about

this phase as being a developer is that you kind of get really fast feedback about whether or not things are working

we get sort of you know to know whether or not things are broken immediately maybe our tests are broken maybe we get

sort of monitoring failures in production or we get sort of bug reports from users and you know in these days

okay there are sometimes some challenges we need to look at stack Overflow we need to go onto the internet we need to

talk to colleagues and think about these problems but these problems get solved relatively easy we can kind of think

about you know the the feedback cycle in terms of minutes hours maybe days and we get this the 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 is that you look at sort of wanting to solve more problems bigger problems more

interesting challenges you sort of build one system you get really excited about that you want to build a better system

and maybe you want actually 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 of which I'd be

actually writing for me my transition to being a tech lead was quite interesting as I was

coming back from a weeken abroad in Europe somewhere I got a call from our staffing uh sort of group at some point

and I was still at the airport I get this telephone call telling me I'm actually not going to go back to the

team that I was working on as a developer instead I'd be going back to a new team where I'd 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 what does a tech lead do I've only been a developer all

my time and yes I've worked with tech leads but I was really focused on the code that I wrote and the features that

I built rather than actually watching what the tech lead actually does it's interesting because we work with

probably tech leads all the time but we probably don't actually observe what they're actually

doing and so for me this was the whole transition from moving from being a developer to a firsttime 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 sort of trodden I knew I'd learned a lot and I knew that there was even more to learn the areas in which I

had sort of focused on I knew that there was 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 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 that there's a talk tomorrow about imposter

syndrome and the thing that I've learned over time looking at this is that and it's a bit cliche I know but life as my

first time te lead was a real emotional roller coaster there were days where I felt really good about myself where I

felt that would make some progress but there are other days where where I just didn't know what what to do I didn't

know if I was making the right choices I didn't know if I was saying the right things and you know I think I made a lot

of mistakes uh and I'm I apologize to my teams uh but I hope that they've also had a good time as part of it looking

back also at the teams that I'd worked on before becoming a tet lead I realized that many of the Tet leads I worked with

had also made mistakes I managed to live through them but I also vowed never to make the same mistakes that they had had

and thus hopefully had a much more positive impact on the team that I had and the thing is about being a tech lead

is that you get to make make mistakes 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 that your your impact is Amplified no longer is it just the code that you're writing

or the systems that you build that are affected 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 and 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 firsttime tech lead it will be your safe haven you need your little quiet space

where you feel safe to to do something and feel accomplishment and writing code is often this Outlet you have to be very

careful though you don't fall in 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 um often in my experience talking to many tet leads

that people who make this sort of leave developer transition uh is that you're probably one of the more senior

developers or one of the considered best developers and the Temptation here is that as a tech lead uh that you might

want to make all the technical decisions and this is where you need to be really careful you don't really want to sort of

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 that you're having with the team that 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 would come in and reflect to everything that

would written you laugh but imagine this after two weeks so you as a developer all the

code you write being Rewritten you kind of get a sense that actually the thing that I'm developing isn't worth it

anymore and so maybe you start to lose motivation maybe you start to lose interest and as lead devs we need to be

aware of our own actions and the impact it has on others and what we communicate and their

value one of the next traps you need to think about is being aware that people are isn't somebody else's problem when

you work on a team everyone will go through a bad day everyone will maybe you know have a sleepless night things

will be going on outside of their team and as a developer you kind of get to ignore that you don't have to to solve

that problem but as a tech lead or a lead Dev you need to worry about this you want to be aware about the mood of

your team and make sure that you're aware about how that maybe starts to spread you know if somebody comes in

really angry and negative imagine what impact that's having on other people around you you don't necessarily you you

probably don't need to solve that problem but you probably need to be an emotional outlet for them and help them

through that you need to take 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 make assert their own sort of opinions you know this

fear of maybe wanting to stamp Authority on things and there's a gentle balance here 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 which

direction people are going in and this is where I see teams start to pull apart in different directions you'll have some

developers think oh this is the time that we get to play with you know new technology tools like Rea um or maybe

it's our time to sort of solve all this technical debt that we've been sort of building up over time other people

people will be sort of churning out features and our responsibility is to make sure that everyone's aligned rather

than sort of pulling in different directions and I guess this is where you know we also need to worry about how we

resolve arguments within the team our typical tabs vers spaces you know fights we need to be able to actually 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 to their preferred thing and check it back in imagine this going back and forth all the 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 uh but we need to be careful about how many we make and what that actually

means and so this brings us on I guess to our our sort of 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 uh having interviewed lots

of different tech leads in this sort of role is that the trans ition from being at first time setle 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 probably focused a lot more on your sort of technical skills but not really focused on all the other things

that you it will take time to build but are 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 we'll be very comfortable understanding whether our system actually is functioning or things

aren't functioning people will report errors and will work out if they're actually right or not your feedback as

this developer comes really fast comes in terms of these seconds and minutes or hours rather than thinking about you

know days or weeks potentially about people and the sort of systems and the thing is as we sort of make actions we

decide on things to do as as a lead Dev sometimes we're never really right if they're the right actions and this is

where things get really fuzzy you know it can be weeks until the consequences of what we do actually has some impact

and we're never really sure if it's still the right thing to do things get really hazy around did I communicate

enough to the team about where we're heading does everyone understand the end architecture of what we're actually

building are we moving in right direction or are we taking on too much debt these are not easy answers to

suddenly say yes or no these things change over time and they'll never ever be precise we'll get a sense of them but

we need to actually understand that this is a natural state of things we'll never really get that right answer about

whether or not things are perfect right now in a complex system such as involved with teams and organizations these

effects of when we decide to to act on things take a lot longer to manifest and a that we can fall into is acting too

rapidly and this is where maybe a system will sort of cycle back and forth and often it's sometimes better to actually

sort of wait and observe and monitor a system before we decide to act to work out whether or not we're actually

heading in the wrong direction or not so Monitor and look for feedback loops in this world of being hazy we'll never

really know if we're making the right things but maybe we get a sense of we're heading in the right direction and

that's okay I think one of the first things that you'll will sort of 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 looked to you originally to sort of answer all these questions about does this uh sort of or

is this function working or is this capability easy to do um you don't need to have all the answers and this is okay

you have a whole team to back you up the important thing is that you tap into the team and you work out how people can

actually contribute to this business people will ask you is this the best way of doing things or you

know when can we get this new sort of functionality built and developers will look to you to perhaps ask is this the

right architecture or tool that we should be using and you don't always have to sort of 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 place of being 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 that 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 sort of consequences of leading any group uh there's a

there's a really interesting Fable from es 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 countryman

kind of passes them and says you fools what is a 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 whom who said see that lazy youngster he lets his father walk

while he rides upset the boy got off and the man ordered um uh and the man got on the

donkey himself and they hadn't passed too far when they crossed two other women and they said to him shame on that

lazy L to let his poor little son trudge along confused the man decided to then pick up the boy and put it on the donkey

they soon reached uh the town and many people started to laugh and Jer at them the man stopped and asked what they were

scoffing at and they said aren't you ashamed for yourself for overloading this poor donkey you with you and your

hulking son they both got off and just and weren't quite sure what to do and they thought and thought and they

decided to actually pick up the donkey tie his legs together and tie him to a pole and carry him over the shoulder

they finally reached the market but then everyone was starting to laugh and wonder what was going on and in this

rackus the donkey kind of kicked and kicked and kind of slipped off but then fell into a river and

drowned it's a bit of a depressing tale I know 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 he can

but you also need to be understanding that you won't make everyone happy with the actions that you take

and this brings on to feeling of uh this role of loneliness so as a developer you're often surrounded by other

developers maybe you work in a sort of environment where you pair program and work very closely with people and that's

really 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 slight Outsider somebody in

your team might come Tor you and you know T 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 and 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 is that there are

probably other development teams around you where there are 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 in maybe a sort of anonymous fashion or a safe fashion where you can talk about

these things openly and the good thing is about people who work in sort of larger companies is that

you won't be the only development 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 can

probably support you as well so think about building maybe a tech Council within your own organization establish

your own sort of community of practice around lead developers and build your own support network it's really

important that you don't need to work out all these problem by yourself and find your own coach and your own mirror

to bounce these problems off you don't need to be alone as I mentioned before

non-technical areas are just as important and the thing is as a developer you'll probably have spent a

lot more time thinking about code design architecture working out 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 sort of thought a little bit more around

sort of architecture but we maybe 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 is a circle leadership skills the great

thing about the 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 if you want to get 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 maybe solving some of these things

because you don't get that sort of binary yes no things work problem but you know these areas are just as

important to develop so when you think about your own sort of personal experiences developing think about uh

where you invest your time and make sure it feels balanced in each of these three different

circles one of the uh important things that I've learned I guess about leadership and learning more about

leadership is really understanding that people are really complex I think when start thinking

about uh the teams that you're working on one of the easy things to do is start thinking in terms of the sort of 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 person is a bit more like

a snowflake each person has their own strengths and weaknesses their own

interests their own background about where they come from about what they've gone on as part of their journey and

where they're heading to and what they want to actually do and the biggest thing that I've learned about being a

lead Dev is actually thinking about how you tap into this how do you find out about these things and find their

interests about where their passions 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 in each person and learn

Lear to and 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're thinking about communication some people will prefer emails some people

will prefer being talked to everyone will have their own sort of mix and there'll never be a sort of right

mixture around them but the important thing is that you're spending time trying to really understand what each

snowflake is like and how you sort of develop that more importantly it's actually 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

things for each person on the team which brings us on to the not doing everything yourself so everyone will

have these different styles about what they'd 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 that I

need to keep sort of getting involved in all the hard places and and try to get involved and take action I need respect

from the team uh so I need to be seen writing code and you know I need to do all 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 uh to draw upon is the idea of the situational Leadership Model and this is

the idea that there are different ways of acting like leader depending on what skill uh 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 sort of directing behavior and we have kind of

four different actions that we might be able to take with the sort of team that we're actually working with we can sort

of maybe tell people what to do um maybe we need to actually sell them the task at hand um or maybe we need to actually

get involved in the problem solving with them or just purely delegate and depending on the sort of point in time

of where people are uh you need to take different actions around this so as a really good example is when we work with

graduates when we bring them in uh you know 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 had this enthusiasm motivation that maybe

more experienced people have lost along the way um and the thing that they lacking is really about the knowledge

and knowhow and so actually they're willing to be told what to do to a certain degree about being a little bit

more prescriptive and and giving them a bit more assistance about the task at hand whereas if you try to act this way

with maybe more experienced people uh it'll be really frustrating for them right because they'll have their

experiences and say actually I'm a you know I'm 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 U I was talking earlier before is that I've never done react and if somebody gave me a react

project I'd be quite happy for somebody to tell me here are the steps that I need to go through to actually set up

the react framework and these are the sort of places where I need to go through so even somebody who is seasoned

if they have a new skill being told what to do can help them along the way and the key with this kind of uh sort of

situational leadership framework is thinking about how you progress people through these different phases so as you

develop somebody's skill in a certain area you need to move away from sort of telling them what to do to maybe helping

them understand why it's important and then moving into sort of participating with them and we ideally want to get to

the point which is why this graph is a little bit backwards to the point where we can sort of delegate things so we

expand the bandwidth that we can create so we provide less sort of supporting behavior um or less directing behavior

and we 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 uh sort of talks about everyone has their own different styles and there

are many ways of being leader it's okay that you as a lead derve will be different about how somebody else

approaches their problems everyone has their own unique strengths as I mentioned and you need to probably spend

some time identifying how you approach things differently and your own personal strengths as

well I'll describe some of the I guess common patterns of which I see leaders acting out differently the first one is

kind of taking a coaching stance where good lead devs won't give people the answers straight away instead of sort of

telling people the answers we're asking questions to help people maybe connect the dots so if we think about Socratic

thinking and asking questions to lead people maybe to the answers they'll learn a lot more than simply being told

they'll go on 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 that you know that they have the skill and coaching is

maybe not the best way of actually bringing them out you might need to help them along the path so you might need to

sort of lay a few markers to help them come up with the sort of 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 new developers join your team and they talk about why is this system

like this and who put this framework in and why do we have all this technical debt it helps to sort of build the story

around where it comes from that there were constraints in the environment in which we worked in and what we actually

delivered this is channeling your inner sham and and helping people understand why things are the way they are and the

way that things got to today it doesn't mean you can't change it but at least helps you understand and appreciate

where things are because of the way things got to the final stance is thinking about

really 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 team uh sometimes being a champion means that we need to sort of rally the

troops and get them moving in the same direction you know particularly if there's sort of critical times around

maybe a production issue you know we need to get everyone focused on solving that problem rather than perhaps arguing

about maybe 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 understand and appreciate which are the ones that we feel most strongly with and

that we have the best skills in one of the secret things about being a lead Dev is something that I see a lot

of people never really tap into and the secret power is being out to say

no the biggest thing that will win you time is by saying no we won't do this it doesn't mean that you have to say no all

the time but in the sort of pleasure to sort of appease everyone uh 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 and 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 non-important 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 things and maybe this is traumatizing for people who are developers and not yet

lead devs but a real important lesson about why you might want to be a lead Dev is thinking about this greater

impact so I I shared my own personal story about moving on from wanting to right smaller features to systems to

wanting to have more impact and the empowering thing about this role is that instead of thinking about this sort of

myth of the 10 times developer is that if we actually focus on creating a a more productive environment for the team

in which we're working on if we make everybody on that team just that little bit more productive we can actually give

everyone a little bit of a power up and be that 10 times developer through the team that we're actually working

with we've looked at what life was like before being a tech lead we looked at the worries and the experience of maybe

the firsttime tech lead and the lessons learned through the more experienced and wiser Tech lead and now we've been on

this journey I'd like to reveal one final uh tip and that is the journey never ends hunger for knowledge and

continue to learn and you'll continue developing yourself as a tet lead and have greater impact in the

process thank you once again