Leadership of Technical Teams
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Number of Parts | 132 | |
| Author | ||
| License | CC Attribution - NonCommercial - ShareAlike 3.0 Unported: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this | |
| Identifiers | 10.5446/44902 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
EuroPython 2018103 / 132
2
3
7
8
10
14
15
19
22
27
29
30
31
34
35
41
44
54
55
56
58
59
61
66
74
77
78
80
81
85
87
91
93
96
98
103
104
105
109
110
111
113
115
116
118
120
121
122
123
125
127
128
129
130
131
132
00:00
SoftwareProcess (computing)Design by contractCollaborationismDependent and independent variablesPerfect groupInsertion lossMountain passTwitterSource codeConvex hullMountain passStrategy gameMultiplication signSoftwareOnline helpLatent heatPerfect group2 (number)AreaProcess (computing)Projective planeCASE <Informatik>Self-organizationQuicksortState observerPlotterDirection (geometry)Decision theoryDiagramRevision controlPoint (geometry)Term (mathematics)BitAuthorizationOrder (biology)Computer-assisted translationStatement (computer science)Right angleTouchscreenPattern languageSlide ruleEuler anglesAssociative propertySphereRule of inferenceVideo gameLevel (video gaming)Cartesian coordinate systemDifferent (Kate Ryan album)Disk read-and-write headReading (process)1 (number)NumberGoodness of fitTable (information)Figurate numberConnected spaceScaling (geometry)Expert systemElectronic mailing listCodeDrop (liquid)CodeRoundness (object)InformationPlastikkarteFrequencyMeasurementGreatest elementData conversionTheory of relativityMathematicsWater vaporInteractive televisionStandard deviationProper mapSpacetimeSoftware developerSystem callVotingLattice (order)Parameter (computer programming)Extreme programmingProgrammierstilPhysical systemVirtual machineComputer programmingStructural loadLaptopData managementMereologyBit rateFerry CorstenProgrammer (hardware)Software engineeringShift operatorWhiteboardSign (mathematics)Context awarenessCombinational logicCuboidGame controllerArithmetic meanPRINCE2Mobile appMetropolitan area networkComplete metric spaceOperator (mathematics)Computer animation
Transcript: English(auto-generated)
00:05
It's a personal talk in that what what I want to what I want to show you is some of the observations that I've made over The years from the various teams that I've either been a member of and been led by someone else and those teams where where I've been Its leader it is a combination of things
00:21
I've seen done well and things I've done seen done very badly indeed And I'm going to give you no clue as to which is which and which were done by me Of course I can't control that one that way, so it's not going to work Excellent, right bit of introduction to myself that the weird signs on the right on these slides would have been my speaker
00:43
Notes if this was being done on my laptop So just ignore the yellow blobs, and I'll try and remember what I was going to say So just a little introduction about myself that will allow you to decide whether you want to bother staying for the rest of it That's a machine that I learned to program on back in 1981 which tells you a little something about how old I might be
01:01
I probably learnt everything I needed to know about programming on that machine I'm not sure I've learnt a great deal since to be perfectly honest That if you're old enough to recognize it was the logo of what was at the time one of the biggest employers in the UK and I joined ICI in
01:22
1990 as a young graduate engineer back in those days. I was an electrical engineer So the sort of projects I was running were building high voltage substations Refurbishing power stations, so some really sort of heavy-duty stuff I stayed with them for about 10 years in my career did all sorts of engineering projects
01:41
But gradually moved over to software systems and IT systems and eventually ended up doing the sort of stuff that I do today My final employer and my current employer is this fine looking gentleman here. I started working for myself in 2001
02:00
And as a freelance programmer developer, basically if anybody's willing to pay my day rate, I'll probably do it for them within reason And in that time I've worked for all sorts of organizations from housing associations to hedge funds to hospitals and everything in between But I want to tell you a couple of more things about myself
02:24
Firstly for 15 years and I've only just recently stopped I was a manager within the Scout Association So I wasn't the sort of leader that takes young people out camping I was one of the managers that those adults report to and and I did various roles in that
02:45
organization at various levels of seniority and the last one I've just stepped down from I had 1250 young people that I was responsible for and a team of about 250 adult volunteers
03:00
And then more recently and this is actually the reason I've stepped down from it This shiny new logo is the logo of the UK Python Association and that was formed back in 2017 and I'm now one of its trustees and we are gradually taking over the running of PyCon UK and looking to expand the sphere of what we do from within that charity as well
03:24
And I like that logo so much that I'm going to use it on here for when I don't want you to be Looking at the screen And I don't have any other better slides But why why do I want to tell you about the time I spent with scouts and and the time? I'm going to be spending with the UK Python Association and this brings me to my first point
03:44
I am a firm believer that leadership skills are just like any other skill. They can be learned They can be developed and they can be improved I've often heard it said that leaders are born not made and I Fundamentally and absolutely disagree with that statement
04:01
These are skills like any other and they must be practiced in order for them to improve The reason I took those roles in scouting was because when I started working for myself I was a little bit nervous that I would be losing the opportunity to do quite so much leadership and I went and looked for
04:20
An organization where I could do so voluntarily because I wanted to continue to develop those skills And That means anything to you if you're interested. I thoroughly recommend this book. It's it's very readable It's written a bit like a novel this the author was a world champion table tennis player
04:44
And he slowly realized that if he looked at the top 10 people in the world I can't remember the figures but a certain number of them came from the same town as him and when he looked a bit more Closely he realized actually they came within three streets of where he grew up And it was all to do with the level of coaching that was going on at the school and the club that he was a member
05:03
of And his book is all about Examples of where he's found exactly the same thing going on So this is all about the fact that any skill you care to mention Can be developed can be practiced and can be improved thoroughly recommend you go and
05:21
have a read of the book and My suggestion for anybody that's interested in developing their leadership skills Professionally is to find opportunities outside of work to go and try them out at first You'll be applying what you learn at work to what you're doing voluntarily But you'll be amazed how fast it turns around the other way in a volunteer organization
05:44
You're probably going to get promoted a lot more quickly And you'll have the chance to be operating at a far more senior level And I'm gonna have to do a sneak peek at what the next slide is because I haven't got my speaker notes right, okay What we're going to come and talk about this
06:01
What I want to talk about next the next point I want to let's say you are new into a leadership role of a Team there's lots of different ways in which that might have happened. You could have been promoted You could have been voted in depends on the organization But one of the things that I've seen in so many cases is that there is very often Somebody or more than one person who doesn't like the fact that you're in charge
06:25
Now it might because they wanted the role it might be just that they simply don't like you They might disagree with the direction you want to take things can be all sorts of reasons But it happens regularly In fact, my observation is it happens more often than it doesn't and that resentment is
06:43
Poisonous and it will kill a project if it's left unchecked And so as a new leader for me It has to be dealt with and dealt with early on and there are three strategies that I've seen work Firstly show them the love so find whoever this is
07:03
Flatter them ask them for help Find some problem that you tell them it might be true It might not that they are the only person that can fix for you find some problem that they have That you can fix for them, but show them the love win them round get them on your side
07:25
Second strategy pick a fight with them Find something where you know, they're going to disagree pick the fight and win it make sure they know you want it Make sure everybody else around them knows you want it make them very very nervous of picking a fight with you ever again
07:44
It's a slightly more dangerous strategy because if you lose that fight You're sunk and you're probably sunk for the term of your leadership But it can be very effective if you prepare the ground if properly you pick your fight carefully and you make damn sure you win it
08:01
And the third one is get rid of them now That's more difficult in some organizations in than in others some cases It's not even viable, but in a lot of cases It is actually the only way that's going to work now I call these three strategies schmooze them bruise them or lose them
08:22
But the real point I want to make is most of us will naturally have a tendency To one end or the other some people really don't like conflict and they would want to show them the love Other people relish the chance of a fight and that's where they'll go first The problem there is it can take a long time to deal with this problem if you've picked the wrong
08:46
strategy to start with so my advice is think these three through and Consider which is actually going to be the most effective which isn't necessarily the one that you're most comfortable with
09:03
Again, I'm gonna have to do a sneak peek right here we go Next thing I want to talk about is priorities How on earth do you go about deciding what your priorities are often when you take over a team from somebody else? You'll suddenly get hit with all the things that you didn't know about you probably walked in knowing
09:21
Some of the things that needed to be solved you'll find out the rest of them 30 minutes after you take the role on How do you go about sifting all this through well? I obviously can't answer the specifics for your team and your problem that you're dealing with today But what I can do is over the years I found that Most problems fall into one of those bubbles and so this little diagram is something I carry
09:46
Around in a little laminated a5 card in my bag, and I will regularly Daily scan that diagram and what I'm asking myself is Do I know what's going on in that bubble?
10:01
Do I trust the process by which that information is coming to me because if the answer to those two is no That is immediately a top priority as a leader I must know what's going on in each of those bubbles Because if I don't there could be problems that I don't even know about So first and foremost do I know what's going on do I trust the process by which I find out what's going on?
10:26
And it's only then can I run around there and work out? Okay, what are all the problems I've got and how do I deal with them now? I can't put them in priority for you But what I can do is to give you a little tool that I found Helps me and one or two others because I'm not the person that first came up with this
10:47
to decide how to go about that now one of the questions that often comes up at this point is In the sorts of work that most of us in this room do I suspect Should we carry on coding if we are the leader of a technical team?
11:03
Now you'll have heard me say previously. I'm a great believer in if you don't practice your skills won't improve So I'm going to say well Yes, if you want to continue to be able to code then you need to practice it and that means you need to keep on doing it, but
11:21
If you're the person in charge of a team when a problem comes along from one of those bubbles Who do you think it is that's going to have to drop everything and deal with it? Well, it's you so if the code that you're working on is so vital to the delivery of your project Then you're stuck when whatever this problem is hits
11:43
And so my advice here is always if you have the ability to do so Make sure your coding as the leader is something in the corner that can be dropped It doesn't have to be delivered tomorrow. It isn't vital for the next release. It can be dropped It can take a backseat and you can come back to it later
12:05
right Try to rattle through it because I'm conscious. We're a bit short of time I want to talk a little bit about leadership styles now again. This isn't my material You can look online and you'll find lists that look very similar to this But what they're trying to say is that there are various ways in which you can go about making decisions in your team
12:24
So at the top you've got dictatorial that is you're the leader you make the decisions Nobody else even gets a say and as we come down the list paternalistic is where yeah, you're in charge You'll listen to what everybody else has got to say, but you're the one that's going to make the decision in the end Consensual is where you will attempt to seek consensus and get everybody with you
12:45
But it's your call and you will make a call if you need to Democratic is where you have a voice and it's equal to everybody else's is you have no more and no less Voice on the team and then finally hands-off is where you don't even give yourself a vote
13:01
So your team makes the decisions you just oversee the process by which that's done now You'll see things written where they suggest that you should find your leadership style and learn to work with it absolute nonsense absolute utter nonsense Let me try to show you why I might think that here's what I think is a far more useful tool
13:22
So we've taken those styles and put them on the y-axis So you've got the dictator at the top and the hands-off observer down the bottom, but let's plot something else Let's plot the level of expertise now. This is a relative measure This is how expert are you as the leader? Compared with the people that you are leading
13:43
So on the left-hand side, we're saying you are a complete rookie You know virtually nothing compared to the experts around you and on the other side You're the expert they know virtually nothing and you are the one that holds all the knowledge
14:04
So the sweet spot of where we should be operating in as leaders is Somewhere in that green area the more, you know Relative to the people around you the more you should be dictating those decisions the less you know
14:23
relative to the people around you the more you should be handing those decisions off to them and So for me it is not your personal style that you need to find it is what is Appropriate for the team that I'm in I
14:41
Can't remember which order I was going to do this in so the slides might go a bit awry here However, my observation from the sorts of technical work that we do is that even that's not good enough It's not enough to say What is my level of expertise versus my team because actually I found that this changes day by day
15:00
Depending on the topic that's being discussed I've even had examples where this has changed during the course of a Conversation with one individual as we move topic our relative Expertise shifts like the wind so you might have been able to pick a sweet spot in here on the sorts of projects I was doing as an electrical engineer and you could live with that sweet spot for the whole duration of the project
15:25
Not in the kind of work that we do you're moving up and down in here Daily hourly even within the course of a few minutes My Piece of advice is if you find that you're doing that just be very careful hopping from one extreme to the other in
15:43
One hit the people around you will likely find that very confusing and they'll wonder what on earth your behavior is and what's driving it So if you find you do need to shift try to do it gradually one night one notch at a time Quickly I want to look at so what does the behavior that's not in that sweet spot look like
16:02
Well, if you're dictating to people who already know what they're doing I'd call you a git If we're down in the other corner, you're failing to provide your level of expertise and you're leaving people adrift So perhaps we could call that subversion
16:20
Very very quickly. I want to talk about process I know this slide is a bit wordy, but the copyright says I have to put it up like this But what I actually want to draw your attention to is the very first thing on that list And that is the authors of that agile manifesto said that they value individuals and interactions over processes and tools and they chose to put that first on the list and
16:42
I think they were spot on right my observation on process and you as the leader will be in charge of process is that Too many people think they know all about it. They think they're a grand master in some Agile technique or other and all projects should be running that way complete rubbish
17:02
Let's go back to that style and expertise diagram. You're operating here unless you know all about scrum extreme programming prints too and all the other ones that have existed over the years and unless you've had Experience of being in projects that are using it
17:21
You are not an expert on process and if you're not an expert on process What are you doing trying to dictate what everybody else does you're firmly in that left-hand box. You're being a git Instead you should be finding what works for you and for your team by all means get yourself more
17:40
Educated so that you can steal ideas from these various processes But I would suggest that very few of us in this room are really expert enough in the business and the process Of developing software to be operating anywhere near the top of that y-axis So to sum up Practice makes perfect go and find opportunities go and look them out go and seek them and take them on board
18:07
If you find you have to deal with a resentful member of your team Then it's schmooze them bruise them or lose them choose one carefully. Don't just go with the one that you naturally fit with most easily
18:20
Priorities you've got to deal with the fact that the unexpected will come along and you're the person that will have to pick it up So don't make yourself so indispensable somewhere else that that is itself a problem style One notch at a time be aware of the fact that your behavior will have to change over time sometimes very rapidly
18:41
Try and keep the swings from one extreme to another to a minimum move carefully up and down and process Don't be a git Thank you very much for coming to listen to me It's always very nerve-wracking when you stand up and you've had a talk Submitted and accepted and you wonder whether anybody actually wants to bother listening to what you have to say
19:02
So it's great to see you all here My contact details are there and I'm around for the for the rest of the conference. Please do come and have a chat and Thank You Owen
19:22
So we have plenty of time for the questions Okay. Thanks. Oh, and that was really interesting. Um There's a real danger when you're deciding which strategy to use with someone who is
19:43
The potential problem as you indicated How does one judge Which strategy to take because if you make the wrong one, it's going to backfire on you and would Leave you in a worse position than before potentially Yeah And that is very definitely the case for each one of those because the danger with getting rid of someone is obviously you've just shipped
20:05
a load of skills straight out of the door that Possibly you didn't even know you were losing and as I as I said in the talk if you pick a fight with someone And lose it you're in real trouble. That's very difficult to recover and What's perhaps not so well noticed with people often think that what that means is we should always
20:23
Shmooze them We should always try to show them the love the danger with that one is that that can just fail to work For a long period of time and that resentment just festers and festers and festers and in some cases Some people will attempt to spread that poison They'll recruit allies and and you've got a bigger and growing problem on your hands and the project will just fail and for me
20:48
Getting rid of them out the door is often driven by whether or not the organization will allow you to do that in a lot Of organizations that is just so difficult to do that It's not even worth thinking about actually in a lot of cases you may well have had to have picked a fight with them and
21:04
Recorded every last detail of it before you're even allowed to do that in other organizations. It's a lot simpler And So when I want to pick the lose them strategy is Organization driven for me the bruise them strategy really comes down to whether there is a fight that you can very
21:24
Definitely win and be seen to win and if there isn't you're stuck with showing them the love Hoping that it works and possibly kicking them out the door later on when you've proven to the entire world that it won't
21:40
Probably by having three or four fights along the way One Here wonderful talk. I wanted to ask and I kind of wonder Whether you explain this to the team that you are leading, you know that then They then they kinda understand for example, once you are going from git to subversion
22:04
Hopefully not but you know on this and this exit that you are actually flexible within your leadership style As long as the resentment issue has been dealt with then yes Absolutely, I would tend to keep this sort of stuff to myself if I've got that sort of issue to deal with when I first take
22:24
A team on because all too often if somebody's already got a problem with you They'll use anything to try and attack you and by showing that you want to do this sort of stuff it's almost invariably new and it's different and there are certain individuals that will just take that and use it as part of their
22:41
Ammunition and just make your life more difficult. So yes, I would Absolutely as soon as I can and that means the resentment any resentment issues have been dealt with and cleared out of the way But yes, absolutely Hi one I've only been like a either temporarily in my life and I always have this problem actually multiple times that you have
23:07
people who are like longer the company or like just more experience and like you have rookies themselves and Sometimes rookies have very flexible Attitudes to some rules and so on but general pattern for me is not that they dislike you as a leader, but they dislike each other
23:24
Because they have yeah different attitudes to I don't know to code style. For example this actually happened to me and What do you do if they start fighting like and if you don't step in obviously soon enough They they both hate you as well because you don't do your job, right?
23:41
So, how do you solve the problem of people not hating you but hating each other, right? You don't want to fire both of them, right? Yes, I've unfortunately dealt with more than one team where there were Collapses of marriages within the team. Let's say for all sorts of reasons and and yet that cat you you eventually become a
24:04
Mediator a counselor and and I I can only suggest And it's what I've done myself is that if that's what you find yourself doing Repeatedly and and I have done it myself is you go and learn those counseling skills And you can do it. And again, you can volunteer to do it. You can read books on the subject
24:23
You can go and practice it But they're vital and and you really are acting as a counselor and a mediator in a in a fight Between two people often nothing to do with the project that you're working on But actually even when it is it doesn't matter because the fighters become more important
24:41
But those counseling and mediation and arbitration skills are things that you can read about you can learn and you can practice And my suggestion is to do precisely that Yeah question. What's your favorite strategy when the size of a team?
25:00
Exceeds what one single person can actually handle. Of course, you can always do the standard way of forming a pyramid We just have like three sub leaders and once a week you call them in you smack them for what they've done And then you're basically done. Yeah, so it's basic. I think it's the easy path But you lose Connection to the team and if you divide your team and sub departments
25:22
Then maybe once a department will be good because it has a good subhead and the other ones will just fail and they lack Sharing knowledge and so on. So what's your take on that? I Take us back to those leadership styles It really depends on what my level of expertise is versus the people around me
25:41
I've I've seen it go very very wrong when a leader has walked in and decided Organizing ourselves bang bang bang bang bang three department heads or three sub teams or whatever It might be without bothering to find out first Whether the people who were doing the work thought that that was a good idea and guess what it wasn't failed spectacularly
26:02
So it really you know But on the other hand if you've been with that organization for 20 years and you're the person who really knows how this place works Then yeah, put yourselves right at the top of our axis and you decide so it is really one of those decisions That is well, where were you versus the people on your team? How much do you know about how this organization works?
26:25
Versus the people that you're leading. So how long have they been in there this organization and how long have you been there? And I have seen it work very very well indeed where somebody says well, I'm fresh into this company I've never been here before all of you have been here exactly 10 years or more. You tell me how it should be organized
26:43
I'll hold you to it You know, we will decide the process and the organization between us and I will hold you to it But you tell me how we should do it. And so if it really is a case of Where are you on that on that plot?
27:00
And the knowledge that we're talking about in this case and your relative expertise is the knowledge of the organization that you're working within Okay, so let's have one more question And how so with that leadership styles, how do you? Reconcile that with the need to train say if somebody who needs to
27:24
Improve their skills in specific areas thinking in terms like if you've been at the company say 20 years You don't want to be the guy feeling or like all the shit because you just happen to be all the expert in every area So how like how do you make push those to that decision making down?
27:42
So that that other people can develop that skill. Yeah, excellent question This is a cracking example for me of where shifting too far along that sweet spot won't work If if you've got people who are used to being told what to do by somebody who is more expert than them And that's the way in which they've always worked if you suddenly move
28:03
To the other end of the scale and you say right from now on I'm doing nothing. It's all up to you It will collapse it will be so far from what they're used to that They won't very rarely are they going to be able to cope? And so this for me is an example of where you move down that scale one notch at a time
28:22
So if you're starting from a point where you've got a team who is used to just being told what to do You move them to a point where you're asking them what they would like to do But you're still making the call and once you've got them comfortable with that you move to the next one down So as long as you move gradually down that scale, I've seen it work
28:43
I've seen it fail spectacularly when you try and leapfrog from one end to the other and two more questions, I think so Going back to the fights But amongst the teams what if it's more passive so I
29:03
Man is a team where my developers are and I myself is a software engineer but some of the engineers on my team they have had 25 years of experience and They're very very good and they get job done quickly efficiently and some of the other team members of a recent like five plus years of experience and they're very
29:27
you know very like eight and They will spend time going through like the old code and making sure you know Have proper spacing or things like that. How do you manage that?
29:41
Like how do you you don't you want to follow the standards, right? But not also so much that you're losing time of the code should be readable. It's Python is mostly always readable anyway so, how do you Come to that medium and how do you convince your team to?
30:00
Work in that medium, I think there are two separate issues there this firstly how do you deal with the fact that you have some people are far more experienced than others and Slightly less tolerant of those with less experience and that's that's one problem to deal with The second one is where that's reached a point where they are fighting against one another and you've got a fight
30:22
Not yet, so Always best to get it sorted before we reach the fight and I often come back to this diagram because one of the questions I When I say I go around this diagram and one of the questions I want answered is how do how well do I? Trust the process by which I'm getting information. So
30:45
I'm I for example only hearing one side of this argument because this individual takes the time to come and bother me every hour on the hour and I I am Absolutely fully versed in everything that they think about every subject on the face of the planet
31:03
But actually I don't know anything about the other side of the argument So the very first thing for me when I when I hear this sort of thing going on is I must be Confident that I understand Both sides of this argument or fight before I make a single move And then you're really into something you're really into dealing with them in the same way as dealing with the resentment
31:26
can you take some of the more experienced people and Persuade them that with that hard-won experience. That's so Well valued they would be of even more value if they could spread that experience to their less
31:41
Experienced colleagues and if you can find ways of rewarding them each time they do it Rather than rewarding them for the quality of their code Reward them every time they manage to impart a piece of knowledge that improves the code of someone else And that can simply be by calling them out on it in a meeting. I'm not talking about bonuses here
32:04
It can simply be giving someone a verbal pat on the head a thank you a very simple reward But all too often we reward the wrong things and we don't reward It's like dealing with a child a small child. You reward the behavior that you'd like to see and you ignore the bad behavior
32:23
so lots of questions means that you have to reiterate the talk in the application and It's still on Friday look at four Fridays two o'clock, I think in the same room one more question
32:42
So By the way, just to answer yours as well But the people are complaining about the about that sort of things in code reviews I used the app for code formatting no more The question for you one-to-ones. What's your style? Do you like? What's the how's it going the status of the projects? Do you do like more personal level?
33:05
Depends It really depends on the organization that I'm in to be perfectly honest Because some organizations will insist that these things are done in a certain way at a certain frequency and there if that's the case There's no point fighting it. You've just got to go with it Personally, I think these things are far better done
33:24
You know the slide that said we value Interactions between people over processes. Well, I think this is a cracking example If there is a process that says you will sit down at 930 on a Friday morning and have a discussion and here is The agenda that we use every week Well, I think there's a better way of doing that and the better way of doing that is to make sure that you are speaking
33:45
to your team regularly Different people will have a different idea of what sufficiently regularly means to them and you can get it wrong in both directions But it's only by trying it You'll very quickly realize if you're irritating someone because you're making them speak to you too often and you'll very quickly
34:03
Realize that you're irritating someone because they're not getting as much attention as this person over here and I think For me you have to find that level that correct level with each individual member of your team and try to hit it I think that works far better if you're able to do that within the organization that you're in
34:25
Okay, I think it's time to thank our speaker I think we should do it twice