Delegate it
Do you know the word “delegation”?
At first glance, everything is clear with him: with one hand you grab the task, with the other – the lucky one from your team and you stuff it in delegate! An employee with invaluable experience, you with a lot of free time and high team performance.
Or not? Sometimes, instead of invaluable experience, an employee is left without free time and bonuses; you are left without a promotion, performance, and trust in the team. Unfortunately, delegation works well the first time for very few people. This is a separate and complex management skill.
How, when delegating, can you bring benefit to the team and yourself, rather than harm?
Below the cut we will analyze the important components of success.
Adequate Expectations
Let's say you have a “task”. In general, any: create a microservice; prepare a presentation to the board of directors; migrate data to a new database; turn the page in the application.
And you are thinking about delegating it.
How well and quickly do you think the work must be done in order to be accepted and tell the person that he did it?
If your answer is:
The result should be as if I did it myself.
I have bad news for you: delegation will almost certainly fail.
The only way to get results with the same quality and speed as you do yourself is to do the work yourself. Your employees have different skills and ways of thinking than you. And that's okay.
The good news is that for most problems, in addition to the “reference” solution (if there is one at all), there is also a “good enough” one.
“Good enough” is exactly what you should strive to achieve as a result of delegation.
– I have an idea how to sweat and implement an http-handler with a response in 50 ms. And how critical is it? Well.. 500 will do (the page loads in about 600). Now 700 is already bad, and 500 is quite good.
– We need to prepare a demo + presentation of the project. Ideally, of course, the fonts and headings would be proofread + beautiful diagrams would be drawn. But enough for understanding – clear headings + diagram of the key component. The rest is nice to have
Formulate a “good enough” result for completing a task and agree with yourself that you will accept work of this level. Do not move on to the next steps until an agreement is reached!
Selecting an artist
Okay, we agreed with ourselves on what result is considered good enough. And how long will it take us to get it? How to choose an artist?
Let's consider possible relationships “person – delegated task”, which are often encountered in practice. In all cases, we will assume that the person, at a minimum, does not actively resist the tasks received and is fundamentally motivated to work.
Motivation is a separate big topic, another article will be published about it.
a. The person will complete the task easily and absolutely without risks. He has done this many times.
Tactically safe: if the employee does not get hit by a bus, he will actually cope. Most likely, you won't even have to redo it.
The default option is in one of three cases:
The bar for a “reasonably good” result is close to the “perfect” level. For example: you implement critical logic in the billing of your service, an error will lead to multi-million dollar losses per second
There is little time for the task. For example, you need to release “tomorrow” (or even “yesterday”)
The person is tired and wants calm and measured work, without challenges and stress
Why is this option not the default for all occasions?
He has a strategic problem:
If a person is a completely safe and reliable performer for a task, most likely, he himself will perceive the task as a routine. It will not be a challenge, will not help him reach a new level, and so on. If you delegate only In this way, employees will begin to rot and stop developing. The most proactive ones will start changing jobs.
So use this delegation scheme wisely.
––
b. The person will “probably” cope. The task is a little more difficult than those he often solves. Or is new to him in general, but you believe that he will figure it out.
Strategically – the best type of tasks for developing employees and the team. Exactly this kind of delegation allows you to pump up people and maintain non-material motivation in work. This delegation scheme must be used if you want to develop the team.
But, of course, it has tactical risks. Our “probably” will be realized: a person will stumble, understand something incorrectly, will have to redo it, etc.
That's why:
Do not use this scheme if it must be done “tomorrow” or “perfectly”.
Formulate the “image of the result” as specifically and in detail as possible. About him – in the paragraph below
Make sure that the person is motivated more than at the level of “well, okay, so be it.” Without this, difficulties and mistakes can seriously cripple him.
––
c. The person is almost guaranteed to fail. Its level is significantly lower than necessary to complete the task
– Why are we even discussing this case? Everything seems obvious – you shouldn’t delegate tasks according to this scheme, right?
Yes. Well..almost.
There is an interesting corner case: a person really wants to learn how to solve such problems and grow. His eyes are burning, he is eager to fight, but the task exceeds his skill not even 2, but, say, 10 times. For example, an engineer recently learned how to make edits to existing microservices, and you have a big new project coming up, where you need to rivet one service per week.
Obviously, a person cannot become responsible for a project. But if the task can be decomposed or the deadline is not super-tight, a useful output can be achieved by such a scheme:
Select a competent project manager (sometimes it's you. Sometimes it's another engineer on the team)
Put an eager newbie in charge of a part of the task + monitor the progress of the project as a whole. Ask the person responsible for the project to mentor him
The project will come together later than if it were completed by a competent employee, but it will provide strategic advantages:
– A more advanced hard player and, importantly, a motivated newcomer
– A more advanced software engineer (yes, these skills also need to be developed)
– Strengthened horizontal connections in the team
I repeat, this can be done if you are a beginner. a lot of motivation and project deadlines allow. Well, don’t forget to ask the “old man” 🙂
Image of the result for the performer
– Okay, we have an understanding of what “good enough” is. I’ll ask the employee to do it and accept the task when it’s “good enough,” right?
Almost.
Before a person gets down to business, it is necessary to clearly and write down in as much detail as possible what is literally expected at the outputIf he is taking on such a task for the first time, the explanation simply by definition cannot be too detailed.
Several criteria that will help you understand that the result is described transparently and well:
1. A clear deadline for completing the work must be indicated.
2. The result must be tangible and measurable. With a minimum of room for interpretation.
“Make it so that it's awesome” (you're laughing, but I once received a service code with a comment like this) – an absolutely immeasurable result, bad.
Develop a service for working with products in a store”
– a little better, but still bad.
Develop a service with three http handlers: creating a product, editing a product, deleting a product, and receiving a product
– better.
Develop a service with three http handlers: creating a product, editing a product, deleting a product, and receiving a product. Creation and editing should take 100 ms, reading should take 50 ms. The code must be covered with unit tests. He should be reviewed by Team Y
– better.
––
Sometimes, when you try to formulate the result, you find that you yourself don’t see it clearly enough.
Who the hell knows what kind of handlers we'll need. We need to talk to the product + do some research – then we'll see.
And that's okay. So we write it like this:
a. Formulate what the service should do. To do this: talk to the product, collect requirements here and here, and put together a design document
b. Open a design doc about me, after which we will formulate the requirements and deadlines for the next stage and update the task
Even if the result is still hidden in the fog, after thinking, you can always formulate what at least the first stage of work should look like. In such cases, it is important to be able to honestly describe the degree of uncertainty and outline a possible path. The more uncertain the task, the higher the likelihood that the person taking it on will produce something other than what you expect.
– Aren’t we killing space for creativity by describing the result in detail?
This is a fine line that is important not to cross. As long as you introduce restrictions that reduce the likelihood that a person will go “the wrong way” or do “the wrong thing”, everything is okay. A good solution also needs to be thought up. Sending people to sort through all the “bad” ones is time-consuming and expensive.
But literally describing what code needs to be written in what file is too much.
Be as specific as possible about “what” needs to be done. Don't say “how” unless necessary. Clarify until both you and the person doing the work are absolutely clear on where to go.
Intermediate control and feedback
There are simple and short tasks. I received it today and brought the code tomorrow. In them, the process of control and feedback is straightforward: you look at what happened and say what could have been done differently. It’s important: not just “you did it so well,” but “here, you should have done this and that.”
And sometimes they are extended in time.
The “issue a task” + “check the result” tactic doesn't work for them.
At least, unless you are a sadist and don't want the person to have to completely redo the work several times.
If an employee has taken on a project that will last several weeks or months, it is important to check how things are going not after several weeks, but after several days.
Agree at the very start about regular check-ups: stand-ups; individual status meetings on the project; letters – as long as you both feel comfortable.
It is important for the manager at these check-ins to be involved and honestly reflect on the person’s progress and actions, and not just wait for the words “I have a problem” / “I think I’m doing something wrong, etc.” If the performer is not very experienced in performing tasks or has not done such tasks at all, he may not independently understand that he has a problem. This requires a detailed look from someone who has already performed such tasks.
8 out of 10 projects could be done faster and better if the performers received feedback about problems earlier 🙂
Types of delegated tasks
Tasks that require manual work (writing code / laying out a page / etc.) are obvious candidates for delegation. It is not difficult to form an image of the desired result, agree with the employee, control, etc.
But as a leader, you also have other valuable work for the team, right?
– Conducting stand-ups
– Team project management
– Mentoring and employee development
– Negotiations with partners
– …
So, processes and communications can also be delegated.
Holding a meeting / agreeing / collecting status on a project is also work that you need to be able to do.
Firstly, it takes up your time and intellectual resource (even if it seems that you do it automatically and easily);
Secondly, there is also a bass factor in communications and processes. If, when you go on vacation, the team's performance / finishing complex projects and negotiations / feedback for employees sag or disappear completely – this is a sure sign that you have become a bottleneck in processes and communications;
Thirdly, solving such problems also develops employees. Negotiation, communication, and process skills help them grow to managerial positions (by the way, do you already have a deputy? This, by the way, is a prerequisite for promotion to the next position) and, suddenly, just be more successful in life: it’s better to bargain when applying for a job, deal with conflicts (everyone has them), mentor, and so on and so forth.
How to delegate processes and communications?
Just like tasks.
1. Formulate an image of a “good enough” desired result.
Yes, meetings should also have a result.
For example, the result of team planning is, oddly enough, a plan for the week/month/quarter recorded in some tool. Certified by product and lead.
The result of a meeting with subcontractors on the project is a set of agreements reached: who, how and when will implement the logic for such and such features, when team A will pull out its crutch from the..back of team B, and so on
If the meeting (or series of meetings) is really useful, you will be able to formulate and write down what result you expect
2. Select the right employee
In addition to hard skills (they don’t disappear anywhere! Isn’t it important for you that a person understands everyone who is speaking?) software is also added.
– How can you tell if a person is a softy?
For example, based on personal impressions from conversations with him + feedback from colleagues.
– It seems like a software one, but I’m still afraid to delegate. He’s never done this before—what if he can’t handle it?
Mistakes by subordinates are normal, that’s why you’re here. It’s just like with a person’s first attempts to write code: you sit down next to him and watch how he does it. If it turns out badly, you catch the meeting in the moment, and with it, subsequently, you sort out mistakes and ways to do better.
Suddenly, negotiations, like coding challenges, allow for multiple attempts. Couldn't reach an agreement the first time? No problem, meet again the next day.
3. And further down the list – formulate an image of the result for the employee, give feedback, etc.
Responsibility
Last but not least: responsibility for the result.
When you delegate a task to your subordinate, he becomes responsible for the result of its implementation to you.but your responsibility to your stakeholders does not disappear.
If you chose the wrong person, didn’t provide support along the way, didn’t give comments at the right time and the task was screwed up, you don’t have the opportunity to say: “well, Vasya leaked the task, I was just standing there.” This is partly why you need a leader: you can delegate your tasks, choose performers, let them make mistakes and develop them, but for large stakeholders and higher-level managers you are still responsible for the result. Delegation is your implementation detail.
Keep this in mind while doing the rest of the steps 🙂
Let's sum it up
If you want to delegate a task:
Agree with yourself about a reasonably good, realistic result.
Choose a contractor. If possible, choose one so that the task becomes development for him. But do not forget about strict deadlines and the cost of mistakes.
Clearly communicate to the person (preferably in writing) what exactly he should do and when.
Track progress, join in problem solving, and regularly provide feedback on task completion.
Don’t forget that you must be ready to answer for the results in front of external people.
Well, that's it! Easy to say, hard to do 🙂
Share your approaches and life hacks for delegation in the comments. The matter is complex and multifaceted, I am sure that there are many techniques. The article deliberately did not include everything possible in order to leave room for discussion.
Lots of other content about the life and work of leaders, discussions, questions and consultations can be found in my channelI'll be glad to see everyone who drops by.
Until next time!
