 Felly mae'n flarchau credu cyd-dod o bobl, defnyddio gyda'r chael cyflawn. Fe'r teimlo arall ei bod gennym ni gennym llwyddiadau ar ein chael, ac mae'r teimlu yn roeddenі i ddiw'r llwyddiadau. Mae'n gwahanol am fwy, ac preafwn yn gweithio yn gwneud yn gweithio. Mae gallwch yn dasb fallenen i welwyddiadau a gwych chi i ddechrau o'r lle. Felly fe dros, os mae'n gwahanol i'r lle. Rhaid. Mae'r intydwledd ond i'w mor hwn. Mae'r ysgol yn y ffordd gan y rhain yng ngryffiliad. Mae'r gwaith yn ei ddod yn saltiaeth. Dyna'rgymellol yn yw mwylaidau. Rydyn ni'n ddod, ychwaneg am y gallwn gwiswyddiad. Mae'r intydwleddol yn eto mor hwn i ddweud i chi wneud o'u g marking y gael sy'n meddwl i chi i chi'n bloddugwy, ac mae'n gallu masgyn ar y program. Mae'r thamol yn 1981. Mae'n llunio ni cael o'r bod hyn yn amrywau. I will probably learn everything I need to know about programming on that machine. I'm not sure I've learned a great deal since, to be perfectly honest. That, if you're old enough to recognise it, was the logo of what was at the time one of the biggest employers in the UK. I joined ICI in 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 heavy-duty stuff. I stayed with them for about ten years in my career, did all sorts of engineering projects, 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 final-looking gentleman here. I started working for myself in 2001. 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 organisations, 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. 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 I did various roles in that organisation at various levels of seniority. 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. And then more recently, and this is actually the reason I 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. 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 do I want to tell you about the time I spent with Scouts and the time I'm going to be spending with the UK Python Association? And this brings me to my first point. 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. These are skills like any other and they must be practised 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 an organisation 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 very readable, it's written a bit like a novel. The author was a world champion table tennis player and he slowly realised that if he looked at the top ten 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 realised 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 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 practised and can be improved. I thoroughly recommend you go and 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 at how fast it turns round the other way. In a volunteer organisation, 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 going to have to do a sneak peek at what my next slide is because I haven't got my speaker notes. Right, okay, what are we going to come and talk about next? 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 organisation. 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. Now, it might be 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, it 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 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, 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. 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 won it, make sure everybody else around them knows you won it. Make them very, very nervous of picking a fight with you ever again. 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 properly, you pick your fight carefully and you make damn sure you win it. And the third one is, get rid of them. Now that's more difficult in some organisations done in others, in 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 shmwsum, bruwsum or lwsum. 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 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. Again, I'm going to 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 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. So this little diagram is something that I carry around in a little laminated A5 card in my bag. I will regularly daily scan that diagram. What I'm asking myself is do I know what's going on in that bubble? Do I trust the process by which that information is coming to me? 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. First and foremost, do I know what's going on? Do I trust the process by which I find out what's going on? Is only then can I run round there and work out what are all the problems I've got and how do I deal with them? I can't put them in priority for you, but what I can do is to give you a little tool that I've found helps me and one or two others, because I'm not the person that first came up with this, 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? 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 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. 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 back seat and you can come back to it later. Right. I'm trying 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. So at the top you've got dictatorial, that is, you're the leader, you make the decisions and nobody else even gets a say. On 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 take consensus and get everybody with you, but it's your call and you will make a call if you need to. A democratic is where you have a voice and it's equal to everybody else's. 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. 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. So we've taken those styles and put them on the y-access. 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. 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. That's right, doesn't show up on this screen. So the sweet spot of where we should be operating 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 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 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 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. 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 one hit. The people around you will likely find that very confusing and they'll wonder what on earth your behaviour is and what's driving it. So if you find you do need to shift try to do it gradually one notch at a time. Quickly I want to look at so what does the behaviour that's not in that sweet spot look like? 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. 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 in interactions over processes and tools and they chose to put that first on the list and 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. Let's go back to that style and expertise diagram. You're operating here unless you know all about Scrum, extreme programming, Prince 2 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 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 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. If you find you have to deal with a resentful member of your team then it's schmoozum, bruzum or loozum. Choose one carefully, don't just go with the one that you naturally fit with most easily. 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 behaviour will have to change over time sometimes very rapidly. 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 wants to bother listening to what you have to say. So it's great to see you all here. My contact details are there and I'm around for the rest of the conference. I'll have a chat. Thank you, Robin. So we have plenty of time for the questions. Thanks, Owen. That was really interesting. There's a real danger when you're deciding which strategy to use with someone who is 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. That is definitely the case for each one of those because the danger with getting rid of someone is obviously you've just shipped a load of skills straight out of the door that possibly you didn't even know you were losing. 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. What's perhaps not so well-noticed, people often think that what that means is shmooson. 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. In some cases, some people will attempt to spread that poison. They'll recruit allies and you've got a bigger and growing problem on your hands and the project will just fail. For me, getting rid of them out of the door isn't driven by whether or not the organisation will allow you to do that. In a lot of organisations, 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 recorded every last detail of it before you're even allowed to do that. In other organisations, it's a lot simpler. And so, whether or not to pick the lose them strategy is organisation driven for me. The lose them strategy really comes down to whether there is a fight that you can very 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 of the door later on when you've proven to the entire world that it won't. Probably by having three or four fights along the way. Here, wonderful talk. I wanted to ask, and I kind of wonder, whether you explain this to the team that you are leading. Then they kind of understand, for example, once you are going from Git to Subversion, hopefully not, but on this axis 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 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. 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 ammunition and just make your life more difficult. Yes, I would, absolutely, as soon as I can, and that means any resentment issues have been dealt with and cleared out of the way. But yes, absolutely. Hi, Owen. I've only been a leader temporarily in my life, and I always have this problem multiple times that you have people who are longer in the company or just more experienced, and you have rookies themselves, and sometimes rookies have very flexible attitudes to some rules and so on, but the general pattern for me is not that they dislike you as a leader, but they dislike each other because they have different attitudes to code style, for example. This actually happened to me. What do you do if they start fighting? If you don't step in, obviously, soon enough, they both hate you as well because you don't do your job, right? 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. You eventually become a mediator, a councillor, and I can only suggest, and it's what I've done myself, is that if that's what you find yourself doing repeatedly and I have done it myself, is you go and learn those counselling skills, and you can do it, and again, you can volunteer to do it, you can read books on the subject, you can go and practice it, but they're vital, and you really are acting as a councillor and a mediator 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 fight has become more important. But those counselling 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 favourite strategy when the size of a team exceeds what one single person can actually handle? Of course, you can always do the standard way of forming a pyramid where you 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. So I think it's the easy path, but you lose connection to the team, and if you divide your team in sub-departments, then maybe one sub-department will be good because it has a good sub-head, 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. I've seen it go very, very wrong when a leader has walked in and decided this is how we're organising 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. So it really, but on the other hand, if you've been with that organisation for 20 years, and you're the person who really knows how this place works, then, yeah, put yourself right at the top of that axis and you decide. So it's really one of those decisions that is, well, where are you versus the people on your team? How much do you know about how this organisation works versus the people that you're leading? So how long have they been in this organisation 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 exact 10 years or more. You tell me how it should be organised. I'll hold you to it. We will decide the process and the organisation between us and I will hold you to it, but you tell me how we should do it. So it really is a case of where are you on that plot? And the knowledge that we're talking about in this case and your relative expertise is the knowledge of the organisation that you're working within. OK, so let's have one more question. So with that leadership styles, how do you reconcile that with the need to train, say, somebody who needs to 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 like all the shit because you just happen to be the expert in every area. So how do you push that decision making down so that other people can develop that skill? Excellent question. This is a cracking example for me of where shifting too far along that sweet spot won't work. 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, they suddenly move 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. 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, I've seen it fail spectacularly when you try and leapfrog from one end to the other. And do more questions I think. So going back to the fights amongst the teams, what if it's more passive? So I manage a team where my developers are, I myself as 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 are recent, like five plus years of experience, and they're very, you know, very, like, pep eight, and they'll 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? Like, how do you, you know, you want to follow the standards, right? But not also so much that you're losing time. The code should be readable. It's Python, it's mostly always readable anyway. So how do you come to that medium, and how do you convince your team to work in that medium? Well, I think there are two separate issues there. Firstly, how do you deal with the fact that you have some people that are far more experienced than others and slightly less tolerant of those with less experience? And 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 to fight to deal with it. Not yet. So always best to get it sorted before we reach the fight. I often come back to this diagram, because one of the questions I, when I say I go round this diagram, and one of the questions I want answered is, how well do I trust the process by which I'm getting information? So am 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 am absolutely fully versed in everything that they think about every subject on the face of the planet, but actually I don't know anything about the other side of the argument. So the very first thing for me 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 really into dealing with them in the same way as dealing with the resentment. 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 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, 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. It's like dealing with a small child. You reward the behaviour that you'd like to see and you ignore the bad behaviour. So lots of questions means that you have to really rate the talk in the application and it's still on Friday, looking for Friday at 2 o'clock, I think, in the same room. One more question. So, by the way, just to answer yours as well, but the bad behaviour people are complaining about that sort of thing in code reviews, I used yep for code formatting, no more. The question for you, one-to-ones, what's your style? How's it going, the status of the project? Do you do more personal level? It really depends on the organisation that I'm in to be perfectly honest, because some organisations will insist that these things are done in a certain way, at a certain frequency, and 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. The slide that said we value interactions between people over processes. I think this is a cracking example. If there is a process that says you will sit down at 9.30 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 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 realise if you're irritating someone because you're making them speak to you too often and you'll very quickly realise that you're irritating someone because they're not getting as much attention as this person over here. 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 organisation that you're in. I think it's time to thank our speaker. I think we should do it twice.