Transcript
Stanier: At a more abstract level, 20 years ago, if I'd submitted a talk about delegation to a tech conference, especially such a good tech conference. Do you reckon that the organizing committee would even accept the talk? We've come a really long way in seeing that it's not just the software that gets built. People get built. People work together in order to build software. This is the title of the talk, how to supercharge a team with delegation. Why is it that you came here to watch this particular talk? Just think about it. I don't need anyone to say anything. Is it because that maybe you were a new manager and you were looking to do a better job? Is it that you're an existing manager looking to hone your skills? Potentially, you're an IC, who's looking to use some of the tools that managers use all the time in your own day job to become more effective in your own, or none of the three. There are reasons that you're here listening to this. What I want you to do is to try and take away some of the stuff I'm going to talk about today and implement it in your jobs immediately, because I really think that you can.
Let's start off with two bad examples of delegation because everyone likes bad things. Imagine that this is an imaginary email from the imaginary CEO of the imaginary company that you work for. It's forwarded to you, says, FYI. It's from the customer success department via the CEO saying we really need better dashboards. Has anyone received emails like this in their job? That's quite a lot of people. It arrives in your inbox. You think, "That's cool. The CEO has emailed me. I must be fairly important. We need better dashboards. FYI, do I need to do anything? I'm not sure. I won't do anything. Maybe it's just top of mind." Four weeks later, the CEO comes past your desk, looking very disgruntled and angry, and says, "Why haven't there been any updates to our dashboards in the last four weeks? Did you not see my email?" You say you did but it wasn't clear that you had to do anything whatsoever. This is, fire and forget. This happens all the time. We'll have a look at why this happens and what it means in terms of delegation soon.
Has anyone worked with a micromanager before? Who just won't get off your back? Imagine that at 8:45 in the morning, you're asked to do something. You say, "Yes. No problem. I'll do it as the day progresses." The more you're coding away at something else, they're sending you messages about, have you done it yet? Do you need some help? Even at midday, they've done some of it for you. Who's worked with someone like that? Lots of people. What I'm trying to say is that this stuff happens all the time. The root cause for all of this is often to do with delegation, fundamental cornerstones of activity that people really should know how to do, because we all work together.
Outline
That's what this talk is all about. What we're going to be covering is three things. The first thing is, what is delegation and how you can do it. Giving you a framework in which you can do it effectively. If you left the room at that point, and I hope that you don't, you will probably know more about delegation than many new managers in technology because I really do believe that we are in effectively a skills crisis in management, and even in individual contributor land. Because so many people become new managers, there's no training. There are no resources. They don't know where to read things or where to turn. They do a bad job. It's not their fault. It's just the environment is not there for them to learn.
I'm also going to go into how individual contributors can delegate too. This isn't because there are new fancy ways that individual contributors need to use. There are reasons that ICs can delegate. They have a really good impact on the team. Then we're going to look at something more human, which is the loss of control. You're here at QCon, which means that you're a diligent professional. I can see you're diligent and professional. As you progress in your careers and you want to own bigger things, whether that's bigger teams, bigger pieces of infrastructure. You're going to have to deal with the fact that you can control less of what happens on a day-to-day basis. How do we deal with losing control? How can we become comfortable within that?
My name is James. I'm Senior Vice President of Engineering at Brandwatch. I always feel a bit weird seeing all the other speakers who've worked at six bazillion companies when I've worked at one. Eight-and-a-half years ago, some seed funding happened at a small company in Brighton, and I joined as an engineer. Three VC rounds later, and a whole bunch of growth, we're now 800 people around the world. I was very interested in management. I was fortunate enough and very lucky to be able to grow with the company as a manager. Delegation is really important to me, because it's my day-to-day. I've got about 65 people around the world, in various different subdivisions and teams. This is effectively my job. This talk encapsulates everything about delegation that I use day-to-day, all the time.
The reason that delegation is really interesting is because it is this old cornerstone that is within absolutely everything that goes on at companies today. I liken it to music. There are so many genres of music out there, so many great artists doing different things. You may look at the current landscape of music and think, how does all this connect? If you do some archaeology, you'll find that there are these old seminal records that were real turning points in music. I don't know if anyone knows which record that is? Exercise to the reader. If you understand the past, and if you understand the fundamentals, then you can much better engage and understand what happens now. The old classics do matter. The old classics matter when it comes to teams, and management, and getting things done. Because when your team's having an argument about how many columns you should have on your board, whether you should do Scrum, or Kanban, or Lean, or something else, or do 2-week sprints, or 1-week sprints. What's the process for moving a ticket from one place to the other? How many thumbs do you need on a pull request? These are all surface level arguments, but underneath them are real fundamental things like what is ownership, accountability, responsibility? Who owns what and does what? Understanding the fundamentals underneath this can make you engage better in what's going on today.
What Is Delegation?
We're going to talk about delegation, which I think is probably the cornerstone of how we get things done collaboratively, because if you understand it, you can do a better job today: IC, or manager. What is it? I'll give you a partial definition to begin with. This partial definition is that delegation is the transfer of responsibility for a task from you to another person. You have to do a thing. You give it to somebody else, they now have the responsibility. You have delegated it. You'll see why it's a partial definition. Because consider how delegation is a thread that runs throughout entire companies. What does it really mean to delegate things and to transfer responsibility? The CEO of a company runs the company. Fundamentally, the buck stops with them. However, a company, especially a big one, the CEO can't do the work themselves. They can't be an expert marketer. They can't write all the code. They can't do the finances. They can't settle all the deals. The CEO will hire various different people who are specialists in these areas to do that thing. What it means is that the chief marketing officer is responsible for the marketing activity. The chief technology officer is responsible for all the engineering, and so on. It makes sense.
Imagine something bad happened. This is going to highlight something to do with accountability and responsibility, which I think are really important to understand. Imagine that there's an engineer in a technology department that on purpose leaks a whole bunch of customer data in public. The person who is responsible for doing that, the engineer, probably gets fired if they did it maliciously. There's a press conference where journalists are asking questions. Who is it that turns up to answer those questions? It's the CEO. That's because the CEO is fundamentally accountable for everything that goes on within the company, even if they aren't responsible for actually doing that thing.
Accountability and Responsibility
The first step to understanding how to delegate is understanding the difference between accountability and responsibility. Accountability means that you are held to account for the completion of something and its quality. That could be a task such as implement this endpoint. It could be run the engineering department, or even run the company. Responsibility means that you're the one that's actually doing it. If you can understand the difference there, then you can begin to think about delegation more thoroughly. We can update our delegation definition in that delegation is the transfer of responsibility for a task from you to another person, but critically, you remain accountable. The quality of that thing being done, the timeliness of it being done, is on you the person that has delegated it. This is why the person who leads the team is accountable for everything that goes on within the team.
If we have this definition of delegation now, let's look at those terrible examples from the beginning and try and pick apart as to why they're so terrible. Our fire and forget CEO. What they've tried to do is delegate something to you. It's not clear what that thing is. It's not clear what needs to be done, or when. They've delegated the responsibility to you. They haven't maintained accountability for it being done because they've been unable to specify what it is, when it is, and why it needs to happen. What happens in the fire and forget example, is that there is an abdication from accountability. Stepping away and not doing the proper job of delegating while remaining accountable.
On the other end of the scale, we have the micromanager, who is strangling you with being unable to let go. If we think of delegation here, this is where the manager in question is unable to actually give you responsibility for getting the task done. Because they're clinging on to it desperately, to the point that halfway during the day, they'll do a draft of it themselves. Micromanagement is where delegation is happening without the transfer of responsibility.
Those two things are almost at the end of a spectrum. They're different things happening. That's because delegation is effectively a spectrum. It looks a little something like this. This is the framework that you should use if you're delegating work. From the left to the right, we see delegation increasing, and acting in counterbalance to that is control. That makes sense. Because the more that you delegate, the less control that you have over exactly how it's being done. For example, if you were delegating a task, then you have to think about how much you're doing, how much the other person is doing, and where it sits on this spectrum. Starting from the left, if there's no delegation whatsoever, there's 0% of that, but there's 100% control, which means that you're actually doing it yourself. You haven't delegated it at all.
On the other end of the spectrum, there's full delegation, which is where you've given it completely away, and you've let go of all of control of that thing happening. People typically understand that. Where quite a lot of managers don't get it right is that they forget that in between those two places, there's this sliding scale of delegating tasks. This depends on how expert the person is at doing that particular thing. What guidance do they need? For example, you could be showing somebody how to do something. You're delegating a slight amount to get their input. Fundamentally, you are in control. That gives an opportunity for someone to learn something for the first time. As we step along, you can see how the control is slowly relinquished in that they could do something with some guidance from you, instead. Maybe some explicit instructions, maybe you tell them exactly what you want, and then they do it. Or you could relinquish even more control. You could give something to somebody, but just check in fairly frequently with them, maybe once a day at the standup to see how they're getting on. As we go down, we can get more infrequent with our check-ins. We can even get to the point that they'll just tell you when it's done.
For example, if you imagine you have a senior engineer on your team, and that senior engineer broke your API. They've already written 50 endpoints. They know how to do it. Some work comes along where another endpoint needs to be written. Where would you put them on here? I would argue that you'd be on the right-hand side because you know they know how to do it. You know they'll do it on time. You know that they'll do it to a good quality. You don't really have to be involved that much as a manager because it will get done. If, for example, you had a graduate engineer on your team who maybe doesn't have a huge amount of experience, then the code base is new. The processes are new. You'd probably be somewhere on the left of this diagram, because you know that you need to have a more active involvement in how they're getting things done.
Delegate Tasks to People along the Continuum
The important thing is, regardless of the experience of the individual, whether they're a senior or a graduate, you delegate tasks to people. You don't just delegate to people. Let's go back to the continuum to give you that example. We've talked about our senior engineer, and our senior engineer is an expert at writing endpoints in the API, because they wrote the whole thing themselves. However, imagine that they had to do some work upstream on your search indices, and they've never touched them before. They don't know how to change the schema. They don't know how your data pipe works. You probably don't want to delegate to the point that they would just tell you when it's done, and give them their support because they do need support. What you would do is move to the left. Give them some more guidance. Maybe pair them with someone who works on that part of the infrastructure, so that they have the environment they need to get the job done, because the task is different. Regardless of people's seniority, their expertise at given tasks changes.
The same is true with the graduate. Fair enough, they might be on the left-hand side most of the time. For example, if there's a particular task that you delegate to them, where maybe they just need to spin up a new application on their own, a standalone thing. It's in a framework they've used before, because maybe they did it at university. You can go down to the right. You can just let them get on with it. You don't need to be there all the time. You delegate tasks, you don't delegate broadly to people.
Delegation Do's
Do delegate, because fundamentally, if you delegate to lots of people, you get more done collectively than if you were doing it on your own. That's a no-brainer. Do delegate to challenge people, because you know you have the opportunity to give things to people that are slightly outside of their comfort zone. Do retain just enough control, because no one wants fire and forget. Nobody wants micromanagement. They want something in between that suits them for the task that they're doing. That gives you the confidence that things are going to get done to the right quality and on time. That gives them the space that they need to foster the creativity on the task, and to get things done, and be happy.
Delegation Don'ts
Don't abdicate. That's where you just give something to somebody and don't care about it anymore. You've abdicated from accountability and you've done a bad job at that point. Don't do that. Don't also assume that people work the same way as you. If you've seen that API endpoint in your head and you've seen the code, and you've visualized exactly how it needs to look. Then you delegate it to somebody else, and they write it slightly differently. You can't control that. You have to accept that people work in different ways. Don't, whatever you do, steal back control. It's your responsibility to delegate things and nudge them to the left and the right on that scale. Not just jump in at the last moment and do something for somebody. Has anyone had that happen to them? It's really humiliating and not nice at all.
From the Office to the School
What I want to do here now is make a case that delegation is just as important to individual contributors. It's a really excellent tool. What we're going to do is go back 100 years, and we're going to go to Russia to a school, figuratively. This is a chap called Lev Vygotsky. He was a developmental psychologist who studied learning in children. What he was thinking about all this time ago was, how is it that children learn best? If you try and imagine a good teacher that you've had in your past, maybe someone who'd been really supportive, who've been able to challenge you the right way. Give you the right material that progresses your learning. There's a bunch of qualities that you can think about. You can also think about bad teachers. I've had bad teachers, where perhaps you don't get the support that you need. Perhaps the material was too hard. Maybe you've had a lecturer at university and you just leave knowing absolutely nothing because it was too complicated. What's the difference between those good teachers and those bad teachers? This is very much what he was studying at the time.
What he found was that there's this interesting area called the zone of proximal development, which is a sweet spot for learning, a sweet spot that accelerates the speed in which children learn. What you have at the bottom is what the student already knows. If you've ever done some mathematics homework, for example, where all the questions are really easy, you breeze through it. You think that's great. I got 100%. What have you actually learned in that moment? Probably not a huge amount because you already knew it. The sweet spot for learning lies just beyond where you're comfortable and where your scaffolding is. If you're able to give people work at that point, and offer them the assistance that they need to make that mental leap. Then they learn the quickest. Good teachers will be focusing the material there for the students, so that they're able to accelerate their learning the quickest. Beyond that is where a student doesn't know what that particular material is, even with assistance wouldn't be able to get it and understand it. In the same way that if you send a mathematics professor to a nursery, even though the professor knows everything, he can't teach them advanced algebra because they don't have the scaffolding.
Task Difficultly
Let's turn this circle diagram, and let's stick it on its side. From the left to the right, we have the difficulty of a task increasing. Then we're able to draw these dotted lines that define those three areas that are on the circular diagram. On the left, there are tasks that the learner can do unaided, the easy stuff. That's your senior engineer writing the API endpoint for the 50th time. In the middle, there's something that's just difficult enough, that puts the student or the member of staff in their zone of proximal development, that with some guidance and some mentorship, they're able to make that intellectual leap, and complete the task. Feel good about it, and also learn. Beyond that there are tasks that are too difficult for people. You wouldn't give your graduate engineer who's just joined your company, the task of rearchitecting the entire storage infrastructure, because they just wouldn't know where to start because they haven't had that experience yet.
What I'm going to make the case of is that if you take this and you map it against the delegation continuum. Then it's not just a thing about managers giving people work when it comes to delegation. It can be a really powerful tool for individual contributors to foster learning within the team. Because if you're that senior engineer and you're receiving a piece of work to do that's just too easy for you that maybe it's even boring. Why not think about delegating it to someone who is less experienced? To someone where this work is actually in their zone of proximal development, and that you can mentor them through it. Because by picking the right place in the delegation framework, you increase the skill of that member of staff, and therefore you increase the skill of the team.
Delegation can be learning because every task is a chance for learning and mentorship. If you're a manager, you can delegate something to somebody who's less experienced, and assign them a mentor for them in order to get it done. It means that individual contributors have delegation as a tool as well, all the time, on absolutely anything that you get done. Imagine a world where everybody within your engineering department understands all of this stuff. Wouldn't that create a really interesting and exciting opportunity for learning? We did not lower the barrier of entry for less experienced people coming in because they know that everyone's thinking about their tasks in such a way that they could be a learning opportunity as well.
Letting Go of Control
We've covered two things so far. We've had a look through delegation itself. We've looked at accountability and responsibility. We've looked at the continuum. We've also seen how delegation can be learning. We've looked at some old learning theory from 100 years ago in order to prove that point. You're at QCon. You're diligent professionals. You're interested in your career development. Clearly, you come to things like this because you're really interested in your career development. As your career goes on, you want to own bigger things. Maybe you want to run a bigger team. Maybe you want to run multiple teams, a division, a department, a company. If you're an individual contributor, maybe in the future, you could see yourself owning a really large piece of infrastructure: Amazon, or Google, or Netflix. Maybe that's what really motivates you. For the manager and the individual contributor in those situations, you have to get comfortable with letting go of control. Because there are things that you can do yourself, like writing some code that you can do. If you want to own the search infrastructure at Google, you need to be comfortable that there are thousands of engineers across all time zones, doing updates to it at all times. If you want to run a company, if you want to run a division, or a department, then you need to be comfortable with that. You can't be involved at the level of every single line of code being written because you can't be awake 24/7. You can't be waking up every night in a cold sweat, panics with anxiety about everything that's going on, and how you are unable to affect the outcome. You have to be comfortable with this.
We're going to have a look at what it means in terms of mindset. Because good delegation means increased team output, and increase in spirit, experience, and skill in the members of the team if things are delegated for learning. You can do more as a manager and as an IC. All that's positive. The reduced control fundamentally increases your worry, and your stress, and your anxiety as a human being. We can't fight against that. That's just our nature. What do we do?
It doesn't matter that this is Andy Murray. It's just a tennis player. If we think about what you can control and what you can't control in the context of a tennis player? A tennis player can control their fitness. They can control their nutrition. They can train. They can have a good coach. They can try really hard to practice and become better at what they're doing. They can't control everything. In terms of a tennis match, they can't control their opponent. They don't know how their opponent's going to play. They don't know what the weather is going to be like on the day. They don't know if they'll maybe have a slight cold when they're playing. There are things that they absolutely cannot control.
On a more macro level, a tennis player also has some amount of talent, and then some amount of hard work. They can't control how good they are at a global level. They can try their best. In an era of Federer and Djokovic, and in an era where there's these dominant players, it may be the case that that particular player is never going to be world number one. Or even if they are, it's very brief. They can't control whether they get injured. If it is the case that they can't control that, would any tennis player right now even bother, because they know they can never be the best. They do. The same is true in all sports.
Stoicism (Epictetus)
What is it about the mindset that allows that to happen? Let's sidestep again to not Andy Murray. This is an illustration of an ancient philosopher called Epictetus. Ancient Greek and Roman philosophy was interesting. It was less about academic pursuits, less about publishing papers. Philosophy back then was more about a way of life, a way in which you can live your day-to-day that increases the pleasure that you have of being alive. Stoicism was a branch of ancient philosophy that was concerned about maintaining one's inner tranquility. What do I mean by tranquility? We all experience negative emotions every day. We have stress. We have anxiety. We have worry, fear, too many Slack messages. There's a whole bunch of things that we have to deal with all the time. Stoicism was about how do we live our lives in such a way that we reduce the amounts of these negative emotions that we have to deal with?
Dichotomy of Control
Epictetus was born a slave. However, somehow, through these stoic principles, he was able to be a prolific philosopher, so prolific that I'm able to quote him in a slide. Paraphrased and translated, he said that some things are up to us, and some things are not up to us. That might seem mildly infantile or not particularly profound. Actually, it's fairly profound, in that you can clearly see this dichotomy of, there's some stuff that I should really worry about, because I can control it. There's some stuff, I really can't. You can split this out into a dichotomy of control, for example, where the things that I have control over, I should absolutely worry about the outcome. If I need to write some code, I have complete control over that, assuming that I can deploy it. I work really hard. I do a good job. Make sure it's very thoroughly tested and I'll deploy it. There are some things that I have no control over. I shouldn't worry about the outcome. I don't know whether the company is going to go under for some reason, nor do you about your own companies. I don't know about my health. I'll try my best. I shouldn't worry about these things, because fundamentally, I cannot control them.
The Dichotomy Is a Trichotomy
Wait, think about Andy Murray. We talked about the things he couldn't control. Surely, that doesn't cover all possibilities. There's this book which is a summary of stoicism written in the last 10 years by William B. Irvine, who is a professor. He pitched the case that actually there's a third thing. The dichotomy is a trichotomy. It's actually very applicable to yourself in your life. It's applicable to Andy Murray as a tennis player. It's applicable to you at work as well, because it very clearly encapsulates what it means to own bigger and bigger things and be able to deal with that anxiety of not being able to control everything. William Irvine said that there's actually a trichotomy of control. There are things that you have control over, which you should worry about, so write that code well. There are things that you have no control over, such as getting hit by lightning, or the company going under. Just don't worry about the outcome. For things that you have some control over, and think about Andy Murray. He doesn't have control over a tennis match, because he's playing. Think of you delegating work. You don't have control over the work being delegated because you are enabling it to happen. What you should do for things that you have some control over is that you should set some goals. Try your best. As long as you do those things, then you can be happy and you can maintain your tranquility.
Control Do's
There is a framework in which you could use to not worry. When it comes to control, accept that we humans are control freaks. We want control over everything all the time. That micromanaging example is someone who just needs control and can't let go of it. You have to get comfortable being uncomfortable when it comes to delegating work as a manager, or as an individual contributor, because you could run a big team. You could run a company. Or, you could own a huge piece of technical infrastructure. You need to be comfortable knowing that you can't control every single variable that's going on. You get comfortable by delegating more. This is something you have to take away and start doing every single day until it just becomes natural. It takes a long time for it to become natural. What you should be doing when you delegate is that you should be exercising some control. You should be thinking about what you're delegating. You should be using that continuum that we saw earlier. Then you should be setting goals with the person that you're delegating to, and then, ensuring that they've got the environment to succeed. That you and they are trying your best. As long as you're doing that, you're doing the best that you can. You shouldn't worry. Try your best.
Control Don'ts
When it comes to control, you shouldn't worry unnecessarily. You can't be the principal engineer of Google search if you're constantly awake, 24/7, sweating because of all the code being committed all the time. It just doesn't work. The same is true if you're the CEO of a multinational company. You cannot be concerned about every sales deal, every line of code, every single email that comes out of the marketing department, because you would drive yourself mad. Don't hoard tasks. Keep control because that will prevent you from delegating well. Don't be the manager who grabs everything important in order to shield their team from responsibility, because without letting go of it, you aren't able to do more. Don't steal control back. Where you become so uncomfortable that you reach your breaking point and go, "Actually, no, I'm just going to do this myself." Because not only is that bad management, you really humiliate people at the same time. Don't, whatever you do, deal with the loss of control, by getting rid of all of it, and firing and forgetting, like our CEO in that example email.
With those three things, which is, how to delegate, also, how to make people learn through delegation, and also, how to deal with control. If you delegate well, and you delegate all the time, then you can actually arrive at a really interesting point with your career and with your day-to-day. Imagine that you delegated everything very well. You have your capacity, which is, however many hours a day you spend working. If you delegate well, then your default workload doesn't necessarily have to be your total capacity. You don't have to be the manager or the IC with their hair on fire because they've got so much stuff to do they can never do it. You can actually free up capacity in your day for doing really important things. That can be planning for the future, maybe working on your career tracks, fixing your hiring process, focusing on cultural things. It also fundamentally means in emergencies during interruptions, and when your staff needs you, you have the capacity to be there. Delegation is a route that you can use in order to get to this point. This is a really powerful point. Because people would think you are an incredibly organized person, and just a wonderful manager, and a wonderful colleague. I'm not here yet, but this is something to aim for. This is the bullseye.
What We've Learned
Here's what we've learned. We've looked at delegation, which hopefully you can all go away and do now. We've looked at accountability and responsibility being fundamentally different. We've then seen how that turns into the delegation continuum, which allows you to pick according to the task, where you need to be for each thing that you're delegating. We then looked at the zone of proximal development, which is just outside of the comfort zone or the skill of somebody. How you can give them work and give them assistance, and then they will learn at the most rapid pace possible. Then we've looked at the trichotomy of control, which is that there are things you should worry about. There are things that you shouldn't. Things where you exercise some control, you can set goals and try your best to relieve your anxiety about it. Then you too, with all of these tools can be a master delegator. You can own that huge piece of infrastructure at a FAANG company. You can run a company yourself if you wanted to, with all of these tools, because you've worked with people who run things bigger than what you run. You can probably identify, they don't do this particularly well either. If you can master it, you can do this too. You can become more senior, and own more, and be happier in your career.
Management Book
I've just almost finished this book. When I started as a manager, there were no resources that I felt were super easily accessible for me as an engineer. I don't have any management in my background. I did a PhD in compilers before I got started. What could be further away from management? What I really wanted to do was to write a book that if I could have landed it on my desk 10 years ago, it would have fast forwarded me much quicker through my management journey. That's this book. It's 352 pages of super goodness. It's not just for managers. It's also for ICs. It's all the tools that effective managers use in their day-to-day that are just about communication, about collaboration, about managing your own time, about managing others. I think it's really useful. If you're interested, you can buy the beta version, which is available on The Pragmatic Bookshelf right now. I also have a blog called The Engineering Manager, which I've written less off for obvious reasons because nothing on the left's been coming along. I'll be posting a lot more again soon. Or, just follow me on Twitter, and we can have a conversation.
Questions and Answers
Participant 1: When you delegate things, and when you have things delegated to, you are accountable for those things. Especially, when you delegate things you do have to become comfortable with being uncomfortable. Accountable sounds like counting, accounting, being able to account for, being called to account, and having, which makes me think of a ledger. Should you have a ledger of the things you are accountable for or the things that if you're delegating to other people, that they are accountable so that you avoid over-tasking somebody you're delegating to, or over-tasking yourself?
Stanier: Usually, I've found that at single team level, the processes that people use, which are typically some Scrum or Kanban type thing, do a lot of that management of resourcing within the team, naturally by itself. It's interesting you say ledger, because I have a little sheet that I have with each team, and what that team is currently working on, and a link to their Jira board, and the people who are responsible for things. That I use as my little dashboard interface into all the things that are going on at any given time because that then allows me to go, "I think maybe this week, it's most important for me to be over there helping out on that thing." That's what I use. It's what I do, do. I don't do it granular. There are things like your email inbox and your to-do list that need to act as records of what's going in and out, and so on. I do actually have a ledger thing for my teams. It keeps things in my brain.
Participant 2: Do you have any advice for dealing with managers that are delegating badly, if you're dealing with the fire and forget manager?
Stanier: It's really tricky. I'm assuming that this is because you have this problem.
Participant 2: No.
Stanier: That's a question of rapport. How much rapport do you feel like you have with that person? Do you have a trusting relationship with them where you'd be able to actually bring that up? I've done this talk internally at the company quite a lot as well. It has that moment of people going, "That's what's happening right now?" Then you can point to the continuum slide, and say, "Can we talk about this thing that happened last week, because I've found this thing? Do you think we did that? Or did we do that?" Rather than having to really bring it up. If you do have the rapport, just bring it up and talk to them about it. Say, "There's a way that we can make this better both for you and for me," if you are able to delegate better. I know that's not a silver bullet. It's a conversation definitely to have.
Participant 3: Do you have any tips on habits to build on, like remember to delegate? Because often, I work in teams, and I do want to delegate, and sometimes the velocity of the team just got me caught up that I forget to delegate. Any tips on that?
Stanier: I don't have any super concrete tips. The phenomenon you describe is totally true, because as you get busier, you get more overwhelmed. A lot of this just goes out the window because your focus as a human is I need to just do the thing. That's when a lot of these anti-patterns begin to happen because you're excited to do the thing. I'll take all the tasks myself. I'll just do them. Maybe even simple things like just having Post-it Notes on your monitor that just say, delegate. Then stick a little printout of the continuum above your board or something just to encourage it. Just constantly talk about it, just frequent communication, and self-reminders all the time.
Moderator: Actually, I think I've fallen into the problem of being the fire and forget manager. Because when you're a micromanager, it's really obvious, everybody hates being micromanaged. Actually, you think, "I'm great. I don't micromanage. Just do everything." What are your techniques for not forgetting to not fire and forget?
Stanier: Taken to an extreme, if you fire and forget everything, then what's your job? That's not a criticism of you, of course. Maybe it's about introspecting, how are you adding the most value? Maybe you can delegate 95% of the things that you need to do, but actually spending more time with the person doing one of those particular things, is actually an amazing use of your time. Actually, if you've got to the place where you've delegated pretty much everything, then that's great because you've got time. You've got the time to spend with people and to just bring things to the left of that continuum, with just a few things and offer some really good support.
Participant 4: Hypothetically, your friend has delegated a task, which is perhaps a bit more challenging than expected. You can see the person is dying. You say, don't take back control, but you've got to do something. What do you think that something should be?
Stanier: If you need to get more control, you've been moving to the left, just gradually. Maybe you've got a point where you've said, do the thing, and tell me when it's done. As you say, you can see that they're struggling. It's just not happening. Maybe you could approach and say, "Could I assist you?" How about once a week, or once a day, or whatever you think, can I just check in and just see how you're doing? If you have a good enough rapport with that person then you won't be coming across like you're trying to look over their shoulder. They'll see that you're coming from a kind, loving place where you want to try and help them. You need to just slide the scale a little bit, not go all the way to the end.
Participant 5: There was the accountability side that you're meant to keep, and then you delegate the rest of it. How do you start to encourage people to take accountability from you as well?
Stanier: I was actually thinking about that as a potential question that I might get at the end. If you think about it, it's transitive. Isn't it? Because if the CEO is accountable for everything, then they give responsibility to the CTO, but actually they're accountable for the department, they transfer subsets of that responsibility downwards. That was a way I was thinking about it. It doesn't answer your question whatsoever. Have you got an example of where you'd like that to happen?
Participant 5: I'm the CTO of a company, and we're very small. We're a startup. One of the guys always wants every task to be really well scoped out for him. Rather than taking on the responsibility of saying, "This is how long I need to do it. This is exactly how I'm going to do it. This is roughly what it needs." He wants all that pre-written for him, which is a big overhead on whoever's running the team.
Stanier: Do you think that he knows that it's a big overhead on the person running the team?
Participant 5: I'm not sure.
Stanier: That's an interesting place to start. I know it's great that everything's super well defined, but it's a big sink of time up front. Those requirements sometimes can change. Try and maybe focus on giving that particular person outcomes to achieve rather than specific tasks. Then see whether they can then define the tasks within that outcome. That maybe could work as a nice movement towards it without just having to say, "It's really annoying. I have to write everything for you." Maybe that could work.
Participant 1: I have a follow-up that might actually be a partial answer to those two questions. Suppose you are being delegated to, and you think the way you were delegated to seems unclear to you, and you feel you don't have a ledger of what you're accountable to. How can you effectively essentially communicate with the person, or people to whom you're being delegated to, to get that ledger? I suspect that answering that question might also answer the question of how to avoid fire and forget. Because I think that feeling of, I don't have that ledger, or I don't understand my accountability enough to have that ledger leads to those problems.
Stanier: You're being delegated to, but it's not particularly clear what a good outcome is, and what you really need to do?
Participant 1: Or if you're being delegated to, but you are unsure how to recognize success, and recognize this thing is more impactful than this thing in those situations.
Stanier: Like many things, I think it just comes down to the conversation. If you have to do some work, and it's not clear as to the impact, for example, or a prioritization call. It's a conversation to have with whoever gave you the work. Say, "I really want to do a good job. I really want to make sure I'm making the best use of my time. Can we maybe sit down together and define the outcome better, define what success means, define what I need to do," so that it can work for both parties?
See more presentations with transcripts
