A Guide To Managing Technical Teams

your boss comes up to you and says you did a great job on that last piece of work how do you feel about leading the team from now on depending on your personality your reaction is probably one of nervousness maybe some excitement or perhaps a feeling of vindication that at last your technical genius has been recognized so passing over the last one rather quickly whether you're a new team lead aspire to team leadership or just want some ideas to tell your current team lead how to do a better job here is some of my advice on being effective in leading technical teams hi i'm dave farley of continuous delivery welcome to my channel if you haven't been here before please do hit subscribe and if you enjoy the content hit like as well i'd like to begin by thanking our sponsors harness equal experts octopus and spec flow they're all helping us to build this channel and so please do help them in turn by checking out their links in the description below my latest book continuous delivery pipelines has just been released in hard copy form on amazon it's a practical guide that describes how to create and improve your deployment pipelines so check that out in the links below as well i'd like to begin this video with some caveats i've spent the majority of my career in hands-on usually close to the code technical leadership roles in one form or another so this is a fairly personal take on technical leadership rather than a deeply thought out or considered strategy more a collection of practical advice and tips based on my own personal experience and approach most of us who get asked to lead a team do so because we did a good job of the work itself in our case presumably a good job of software development that doesn't necessarily mean though that we're going to be good at leading a team it's a very different thing this entry into the job of leadership presents probably the first and one of the more challenging difficulties because we're asked presumably because of being good at doing something else it's natural to assume that doing more of that only better is the new job but being a team lead does not mean that you should make all of the technical decisions from now on it also doesn't mean that you are now either the best technical person or alternatively post technical in some way there's a balance to be struck here if we think about the role of team leadership from an organizational perspective rather than from our own personal perspective then the job is really to make the team effective i think of this rather like the captain of a sports team the job of the captain isn't to do all of the work the best captain isn't necessarily the best player it isn't the job of the captain to tell everyone else exactly where to run or when and where to kick the ball each player knows that stuff or at least their own version of it the captain's job is to make the decisions when the answer isn't too clear to amplify the performance of the team to coordinate the performance of the team maybe by being a good role model maybe by offering advice maybe setting broad goals or direction certainly coaching and guiding the team in improving specific skills one of the most difficult challenges and changes in focus for new leaders certainly that i experience and that i've seen in others is the difficulty of allowing other people to do work in ways that you wouldn't maybe even doing work that is worse than the work that you would do if you were doing it yourself however your goal as a team leader is to amplify the performance of the whole team if you try and micromanage what everyone else does you will become the constraint and slow the team down overall micromanagement is a big problem particularly for inexperienced leaders and managers i am a recreational sailor i once got a chance to sail across an ocean as part of a more experienced crew despite being junior inexperienced i am a basic skipper and so know my way around a boat nevertheless one of the much more experienced crew members let's call him joe started to micromanage me joe would tell me all the detail of even the most menial tasks tasks that i understood well he would take over if i did anything even slightly more than menial after a few days at sea one day i found myself looking at an untidy rope i found myself thinking somebody should tidy that rope up but i'm not going to do it because joe didn't tell me to now that is not me that's not the kind of person that i am that's not how i usually behave so i realized what i was doing and i went over and i tidied the rope later i noticed that joe went and tidied it again only this time to his preferred way of doing things my point is that this was bad on several fronts my role had become marginalized and joe had become the bottleneck for nearly everything that i did not great for either one of us better to focus on the outcomes was the rope tidy rather than the the mechanism had the rope been tidied in exactly joe's one true way the job of a leader is not to have all of the answers or if they're a good leader to enforce one way of doing things the job of a leader is to maximize the performance of the team and i know i've said that before there's a concept called servant leader the idea is that leadership is about serving the team i like this idea our job as leaders is to remove barriers that prevent the team from making good progress whatever those barriers might be i once thought read a post that i liked better being a leader is more like hosting a party your job is to invite people make sure that there are enough drinks and snacks for everyone make introductions that you think will be helpful and occasionally throw out the drunks i can't find the link to that great blog post to reference it so if you know it please do let me know in the comments so that i can provide proper attribution to the author the introduction part is definitely an important aspect of leadership i was once the tech lead for a large development hundreds of people split into many smaller teams i confess that i felt that most of my job was to act as a communications hub i found myself saying things like ah that team over there had that problem too you should go and talk to them or ah this team's tests are a bit flaky can you help them out please my job was to hold the kind of 30 000 foot perspective of the project so that i could spot things that people closer to the detail may miss and so foster collaboration where i could one of the other things that i did for this larger group was to improve the community communications in another way too i started a weekly newsletter on our project wiki and badgered team leads from the smaller teams to provide helpful suggestions important changes funny observations or just interesting thoughts it helps the wider team to begin to feel more like a team and improve the sense of ownership for people working on the project i've spoken a fair bit so far about mostly the human aspects of leadership and they are very important they are primarily what the job is about but as a technical lead what about the tech first the communist anti-pattern which i guess is just another version of micromanagement that is programming by remote control i see this all of the time it takes the form of formerly technical product owners telling development teams through the requirements process how to solve a particular problem rather than describing what the problem is that they're trying to solve i see it in architects who don't write code anymore but want to make sure that everyone else writes code in some ivory tower version of perfection and i see it in tech leads who try to dictate the specific details of design either before the work is done or afterwards through code review as i said earlier i think that to lead effectively you need to allow others to work in their way while at the same time helping them and supporting them in growing their skills and capabilities don't get me wrong this isn't easy we all have an ego and allowing people to do what you think is a worse job than you would do on some task is extremely difficult but i think it's often the right thing to do of course there are constraints you have to establish good minimum standards for work to protect against disasters or at least expensive failures but where the work is good enough but not perfect then it's probably better to let that go at least temporarily my point here is not that i think that quality is unimportant quite the reverse rather that you may be more effective in doing a high quality job long term by deferring the conversation people start from different places and learn at different rates if you try to force an advanced subtle design on someone who's just starting out they will at best miss the nuance at worst they'll become demoralized and wait for joe or you to tell them when to tidy the ropes and precisely how to do it they will lose confidence in their own ability to make decisions or at least abdicate that responsibility to you this is a really common failure that i see in teams all of the time people learn most strongly from making their own mistakes one way of helping people to learn is to allow them room to make some of those mistakes this is rather like teaching a child to ride a bike they simply won't learn if you hold on to the saddle all of the time at some point you have to let them go at some point they will fall over but that is what it takes to learn to balance and to ride a bike try to allow people to make mistakes but as safely as you can this is yet another reason why i value things like test driven development and pair programming quite so highly they both provide some support to help people to grow their understanding and in the case of pair programming to learn from one another i led a team who built a very high performance financial exchange we consciously hired young bright but inexperienced developers as well as experienced experts we consciously decided not to do much hiring of medium level experienced people in part the idea was that if we hired people that we knew and trusted and would then hire very smart junior people who we could train maybe brainwash to approach development our way we'd get a better outcome we did pair programming initially more junior members of the team were always paired with more experienced people once they had the basis of how we worked though and knew their way around some of some of the code we'd encourage them to pair with other juniors more experienced members would keep an eye out on their commits often usually the team lead would do that and they'd be there to help if juniors got stuck but largely we left them to explore a bit to make their own mistakes this helped them to grow as developers very quickly and i'm very proud of the fact that in that organization we helped several really excellent developers begin their career this way as i've already said it's not a team leads job to have all of the answers in my opinion the best team leads teach team members how to find their own answers but i don't mean to diminish the value of experience the very difficult task for a team leader is to allow themselves the freedom to apply their experience while at the same time allowing team members room to make their own decisions this is very difficult and very subjective and a narrow line to tread i am a very opinionated person as those who have worked with me will attest but i hope i aim to have strong opinions but hold them lightly i don't assume that i'm always correct one of the techniques that i use consciously is to make consensus-based decisions when working as part of a team i will adopt the consensus and try very hard to make it work even if i as the lead disagree with the choice however if there's no consensus or the decision is tied then my vote as team lead is the tiebreaker this does a few things first it means that we can make progress quickly we don't have to wait for everyone to agree second it gives me the freedom as an experienced member of the team to make my argument about why my idea is the best without forcing it on other people third it demonstrates something subtle and important we are a team and we make decisions together it's okay to challenge other people's thinking whatever their role this is about getting to the best ideas not about hierarchy or status and yes in my career as a tech lead we have often done things that i thought were bad ideas sometimes i was right but sometimes i wasn't my last point is about the sometimes difficult conversations that the dealing with the drunks part of hosting the party as a leader it's your responsibility to sometimes have difficult conversations with people in general my rule of thumb is to praise people in public and to critique them in private my own style is to try and be open and honest in both i'm english and so it's nearly as difficult for me to tell somebody that they're doing a good job as telling them that they're doing a bad job so i have to work a bit on both of these things but i do think it's important that you do both if someone is surprised in their performance review by bad news or good i feel i've done them a disservice i don't want to wait for some fixed review cycle to give them that feedback if it's my job to help them to do their best for the team then i need to help them to guide their performance all of the time not just during performance reviews this is the most important idea for me i've already touched on it but the job of a leader is not to tell people what to do but to help them to do what they can do in the service of the team to the best of their ability i have one more thing to say on giving bad news sometimes as a leader it may be your job to tell people really bad news their performance isn't good enough or maybe even that they've lost their job this is horrible for everybody concerned but it's more horrible for them than it is for you i have too often seen managers and leaders in this position focus primarily on how bad they feel having to impart this news how tough it was for them to make the decision or to give the bad news it's my view that if you find yourself in this position don't do that this is about them not about you however bad you feel about it focus on the practicalities give people time to process bad news be respectful be supportive offer whatever help you can and that is appropriate given the circumstances but don't spend time telling them how bad you feel if you really felt that bad you wouldn't give them the news in the first place so those are a few thoughts about being a team leader in a technical team i hope that you found some of them interesting let us know your suggestions for advice to team leaders in the comments below thank you very much for watching you

Channel: Continuous Delivery

Views: 109,534

Keywords: Managing Technical Teams, technical team managers, management guide, developer to manager, project management, leading software development teams, software development leads, technical lead job description, software development leaders, software developer advice, devops, Continuous Delivery, software engineering, software development, Dave Farley, leadership, management

Id: jMpCF0Z623s

Length: 17min 49sec (1069 seconds)

Published: Wed Jun 16 2021