BusinessProduct 24 min read Translated August 5, 2026

How to Delegate Responsibility

I always thought delegation was a fairly simple topic. I never used to talk about it, because setting a task is the bare hygienic minimum every manager should be able to do. But every time I walk into a new project, I discover that the most elementary things about how one person hands another a task simply aren't being done.

I always thought delegation was a fairly simple topic. I never used to talk about it, because setting a task is, in my view, the bare hygienic minimum every manager should be able to do. But every time I walk into some new client project, or start working with partners, or get invited into a startup as a consultant to fix the production cycle, I discover that the most elementary things about how one person hands another person a task simply aren’t being done. And on top of that — half the times I make a mistake myself, careful analysis shows it was also a delegation mistake. So let’s sort this topic out.

Let’s start by answering one question.

Why is it hard to delegate responsibility?

I think all of us — whether or not we know how to delegate, whether we’re in ninth grade or twenty years into running a business — still have some problems with delegation. When one person sets a task for another, difficulties come up one way or another.

What gets in a manager’s way when setting a task?

Before you read on, I’d ask you to think for half a minute and answer the question: “What difficulties do I run into with delegation?”

Here are some of the answers people have given me before. (By the way, if your answer isn’t on the list, you can send it to us — later we’ll aggregate the data and write an update to the article.)

When I was preparing the training on delegation, I did a trial run at JetStyle and asked the same question. The champion answer was entirely predictable:

It’s faster and cheaper to do it myself

But besides that one there were another dozen popular ones:

1. You don’t know what the other person is capable of

How do you tell where the limits of their ability are? Everyone understands that it’s great to set tasks in the zone of proximal development — that is, tasks the person is capable of, but for which they need to grow a little. Then it’s interesting for them, they develop, and you in turn grow your own talent pool. But how do you tell where their zone of proximal development ends?

2. The project has a lot of legacy, it’s hard to hand it all over

In the client business it often happens that you inherit a task where other people have already broken a lot of firewood before you. And you, by the way, don’t know what underwater firewood is in there, and you have to somehow sort it out and take a completely incomprehensible thing into your responsibility. This is one of the scariest stories precisely because you can’t tell in advance how deep the abyss goes.

3. The boundary of the task is unclear

You set a task and don’t understand where it ends, because for you it’s a new subject area. So you don’t know how to tell whether the person doing this task on your instructions is even moving in the right direction.

4. It’s unclear where to start

For example, you have experience as a line manager at a big Russian company. And now you’ve been handed something that neither you nor anyone around you has ever done. For example, you need to take the company’s sales into Europe. To do that, something has to be done. But what exactly? How do you set tasks for your people? You have no experience, no reference standard, no instructions — only obligations.

5. “I’m not competent to set tasks like this, but I have to”

Imagine: it so happens that setting tasks you understand nothing about is now your responsibility. Most likely this is again the situation where the area is new to you. But you don’t have any other task-setter.

6. “I thought I was competent to set this kind of task, but no”

Usually this case is just a development of the previous one, which makes it an even scarier story. You overestimated your competence. You thought you were competent but, for example, were afraid to admit to yourself that you weren’t. Or you admitted it, but only to yourself — not to your subordinates, and certainly not to your bosses. And later it turns out you set the task badly, because the competence wasn’t there after all and you were lying to yourself and to everyone around you. An extremely painful story for a manager.

7. One person estimates, another sets the task, a third does it

A common story in big companies, when people haven’t agreed anything among themselves at all, and the one who suffers most is the person trying to deliver the task. In a company of 20 people this problem shouldn’t exist, but in companies of 70 people and up it unfolds in full.

8. Priorities are unclear

Nobody knows what to do first, what second, what third, what all of it is for and where it leads. And how to choose what not to do. And what can be sacrificed and what can’t. And how not to tear yourself apart.

How do you evaluate an employee?

I have a problem with firing people. I’m not a spiteful person, it’s hard for me to hurt someone. Like many people, I don’t like saying unpleasant things to people. And when I was working out how to do early prevention of the things I’d end up firing people for, I thought it would be better to tell them straight when hiring them: “Folks, here’s what matters to me and here’s what I’m going to fire you for — know it up front.” There are five such factors.

None of the factors on this list is good or bad in itself — only in its trend. What matters, for example, is not so much how fast you are relative to your colleagues, but whether your speed is rising or falling. If it’s rising and it’s clear you have every chance of catching up and overtaking — fine. If it’s falling, something has gone wrong and it has to be fixed. The manager’s job is to notice this in time and fire a warning shot.

1. Speed

Measured in colleagues, and it should be growing. If you’re slower than people with the same level of competence and you’re not growing, that’s bad.

2. Predictability

More important than speed. It has to be possible to rely on you. If we hand you something and you’ve taken it into your responsibility, then we have to be sure you’re a dependable member of the team and you’ll do it. And if you suddenly don’t do it, then the moment you realize you’re deviating from the plan, you’ll come and say: “I’m stuck.” Even if your manager isn’t pinging you, you’ll do it yourself and not sit under the ice alone.

And the developer- and designer-specific version: if you said you’d be working on this task for a given number of days, you work on it for that number of days, and at the end you have the result that was agreed on.

3. Ability to learn

This is about how many times a person has to be told something. Ideally zero, of course, because they get it themselves. And nobody likes repeating more than twice. When you work in IT this usually isn’t a problem. It happens that a person doesn’t make much use of their intelligence, but that doesn’t mean they don’t have any. In that sense, when someone doesn’t get something, in most cases they simply aren’t pointing their focus of attention at the task, or for some reason think “I’m actually great as I am and I’m not going to listen to you, idiot” — but don’t say it out loud.

We work in a technology industry that changes fast, and the ability to learn is a critically important factor in it. If a person learns slowly, if they take ownership of their experience slowly, they’ll be falling behind all the time.

4. Autonomy

The most important factor, inversely proportional to the amount of management a person requires. And it’s the most important because the scarcest resource a company has is the time of qualified managers. Your company can do exactly as much as you have management for, and you spend that management on control. So any sane manager wants to spend the minimum management on control — that is, spend exactly as much as it takes for the needed effect to fall out of the person.

There’s a direct consequence of this — at what level of abstraction can a task be handed over? Here we have a whole spectrum, from “we chewed absolutely everything over and controlled everything” to “we handed over a chunk of the business to run.” So in effect, growth in autonomy is what allows the company to promote you.

And the reverse process is precisely a fall in autonomy.

Say a person used to have high autonomy. So the manager says: “Look, there’s this problem, please deal with it.” That’s a task at a high level of abstraction, and the manager assumes the person will somehow sort it out. And then discovers: aha, that doesn’t work. Goes back to them: “Here are the parts this problem consists of, here’s how we’re going to solve them, please do this part first.” Leaves, and watches what the subordinate does. Say it turns out he can’t do it himself. “Okay, look, this part is solved by these means, for this go there, for that go over there, this you learn over here, and here you’ll do these tickets. Clear?” If that didn’t help, then the next level down: “Right, we take one ticket, it’s solved as follows — the code is over there, write it like this here, here’s a working pattern for you.” And we go down from the top until predictability starts falling out of the person.

From my point of view, the main symptom that a person has to be fired is when they’ve headed down this ladder and crawled to the point where you have to spend more and more of your control to get the next little piece of benefit. Once, when they joined the company, they climbed up this ladder, and now something has gone wrong. From effective interaction between manager and subordinate you’ve arrived at a system that doesn’t mutually amplify energy but mutually damps it.

At that moment you fire the warning shot: “Look, to get a result out of you I have to spend more time with every next round. That doesn’t work for me. I think your problem is that you’re slow / unpredictable / learn slowly / just don’t want to be autonomous. Please do something about it. If you want me to help you, ask. If there’s no progress, we’ll fire you.”

Let’s note in parentheses that it may very well not be the subordinate’s fault. What I’m saying is that the manager–subordinate pairing has broken. It’s precisely this social molecule that has stopped working, and it’s precisely this that has to be repaired. But if we’re talking about firing, it’s clear that managers get fired less often, because they’re harder to replace.

5. Self-control

There’s one more factor that makes working with a person hard for everyone. It’s hysterics. Actually “hysterics” is a strong word that can easily be pinned on anything, warranted or not. I’m talking about a specific case — a person can’t cope with their emotions and dumps everything inside them onto their colleagues, so that they’re not the only one hurting. This does happen, and on a human level it’s understandable. But if the person isn’t ready to work on it, if they don’t want to discuss what could be done so it doesn’t happen again, if they use it as a communication technique — it drains the team’s energy. The target state of a group is mutual trust and a willingness to “share consciousness” with the people next to you. For that, the environment inside the company has to be safe. If someone can’t and doesn’t want to learn to control themselves — the exit is over there.

It’s hard to turn this point into a formal rule, because hysterics usually happen in places where it’s hard to work out what actually happened and who’s at fault. But I’m completely convinced that people should know this is unacceptable, and that if you lose control of the vehicle, “your license gets taken away.”

So, those are the 5 factors. I’m not suggesting you adopt exactly this system; yours may be different. Ours is like this because we’re a production shop.

This approach means people know what we want from them. It works well when there’s early prevention. When the qualities you value people for, and the ones you’ll fire them for, have been named out loud.

If a person deviates from these rules for the first time, you tell them: “Dude, nothing terrible has happened, you’ve got a problem here, fix it.” They fix it over some period, you thank them for it, and after that they’re doing fine. Or they come to you and say — I tried, not all of it worked out — that’s fine too, the question is the trend.

But if you don’t do early prevention, then you and this person end up in the state I used to end up in when I was a young manager. It goes roughly like this. There’s a person; it’s not that they screw up badly, but they’re somehow not performing much, and you have to decide what to do about them. As a manager I start thinking that maybe it’s me. Maybe I didn’t set up a good enough greenhouse for them. Maybe I haven’t chewed everything over for them yet and the mistake is on my side, so I give them one more chance. There are exceptions, of course, but in my experience the person should have been fired right away. And in fact I’d ruined them much earlier, back when I hired them. That is, once again — I don’t want to say the person was bad. You simply let the relationship with them go to seed, and now you’re spending the company’s energy instead of accumulating it.

Okay, we’ve talked about how to evaluate an employee. Let’s get back to the manager.

What are a manager’s duties?

Every one of us (except those who are simultaneously the company’s director and its sole owner) has a contract with someone above: with the board of shareholders, the director, the team. And in that contract there are four very important things that any manager, in my view, owes their subordinate.

A manager exists for their subordinates, so that they do their work better. For some this is a counterintuitive idea — many think it’s the manager who owns their subordinates, while he himself supposedly owes nothing to anyone. But when you understand that this isn’t so, and that you, the subordinate, can use any manager for their intended purpose, interaction in the team improves. So let’s talk about the manager’s obligations toward the subordinate.

Give a goal

This is the main one. Because a person who doesn’t own the system can’t pull a goal out of nowhere for themselves. And if you allow your subordinates to take goals for themselves and don’t hand them out yourself, you’re creating a revolutionary situation. That will definitely come back to bite you later.

Give resources

All sorts: where to learn, what material resources to use, where to get colleagues who’ll help… A great deal is buried inside the word “resource.”

Provide boundaries of responsibility

That is, explain:

  • how the markers we’re running toward are set up;
  • what happens to us when we get to the end, and what happens if we don’t;
  • what each of us is responsible for and what we’re not;
  • what neighboring boundaries of responsibility exist, and so on.

If there’s one thing in business that has to be prepared carefully, it’s boundaries of responsibility. In the places where we’ve drawn the boundary of responsibility unclearly, a mess is guaranteed to breed.

Give feedback on progress toward the goal

When there’s no feedback, a person quickly loses the motive for the activity, does not quite what you need, and is demotivated as hell — because they don’t understand whether the company needs what they’re doing, or what people think about how well they’re doing. “Maybe they think I’m actually not that great.”

Feedback is a super-skill. And not only for a manager. I’ve written in more detail about how to give feedback in a way that moves a person toward the goal in the article “How a designer should give and receive feedback”.

What do I mean by the word “goal”?

In my view, “goal” is a heavily overrated word, because it’s just some point we’re walking toward.

A goal is actually the answer to the question: “Why do this, where will we end up, and what will we get for it?”

And you have to be able to give that answer sincerely, and in a way that can’t be falsified. Because as you move toward the goal, at some point you’ll realize the goal is out of date and a new one has to be set. But how? For that you need to understand your current state. And if you happened, God forbid, to have been lying to yourself, that’s the moment your problems start.

What matters is that in your contract as a manager with your subordinates the answer to the question “Why?” has to be set the same way, so that both you and they need everything that’s happening for the same thing. Then you won’t have a conflict.

The goal has to be shared — by the manager and by the subordinate. For me it sounds roughly like this: in what parrots are we going to measure our success? How will we know that we’re moving where we want to go? Do we all really want this?

For example, we all need our company to earn more money. If that’s true, then when the company earns more money, all of us are better off.

Or, for example, we’re doing this because we’re a research company, we’re all scientists and we genuinely want to find out how the world works. This matters to all of us. Both to the person who gives the goal and to the one who accepts it.

And in that sense half (if not more) of the whole problem consists in making sure nobody lies to themselves along the way and then lies to their subordinates. And if a manager hasn’t given the employee a goal in their contract, then they’ve failed the manager quest.

The same goal can sound different

Now let’s talk about setting a goal with an eye to what gives us energy. The energy we need in order to want to work, I call mana. In games it gives magical power. In life it motivates you to work.

When we set a goal for a person, what we’re actually telling them is roughly: “If you do this, you’ll get this kind of mana” — because different people are motivated by different things. I have a theory that there are six motivations for work:

Six motivations for work arranged around a person: priority and skill growth; process and belonging; duty and ritual; reward and power; result; curiosity and self-assertion

1. Priority, leveling up skills

“We’ll do something first, before anyone else. The whole market will say that those guys over there were the first to build this thing.”

2. Process, belonging

If in an interview you hear: “Being just a person doesn’t satisfy me, I want to be part of something cool,” or “What matters to me is that it’s interesting, working with interesting people” — this is it. The person wants to be in demand within their immediate group, and wants that immediate group to say that their skills matter to it. Their life isn’t meaningless, because their comrades need them.

3. Duty, ritual

Duty and ritual move people very powerfully; thanks to them, people do something simply because they believe they ought to. What matters to them is doing the same thing every day and performing a specific ritual, so as not to go crazy and to give life a shape. The older they get, the more important this thing becomes, because you have to hold yourself within some boundaries and not think: “That’s it, I’m dropping everything and moving to the North Pole or to Bali, so as not to move to the cemetery.”

Result and reward

What’s the difference between them?

4. Reward is when I did something and did it and did it, and then I was given some thingamajig for it, or got it myself. For example, I earned money. Or fame. It doesn’t much matter how I earned it. What matters is how much I earned.

5. Result is when it doesn’t matter whether I was given anything for it. What matters is that there’s now a certain thing in the world that I genuinely wanted to bring about. For some reason I needed it. I wanted the world to change in a particular way — for example, so that people don’t suffer. Or so that people do suffer.

6. Curiosity, self-assertion

This is a very powerful driver, especially in technology companies. If this driver doesn’t matter to an engineer, they’re a bad engineer — don’t hire them. A normal engineer has to assert themselves through having learned something new; that’s their modus operandi.

So. When you give a goal, you have to understand how it’s connected to the energy of the activity. As a reminder, from my point of view a goal is the answer to the question: “Why do this, where will we end up, and what will we get for it?”

The same six motivations, now with the outer points connected to each other — the space of values in which a goal is a point

In these terms the goal becomes a point in a space of values, and we have to construct that point so that on the way to it we get as much as possible of the value we measure success in. As acting subjects we set ourselves goals so that we want to keep acting. It’s simply a property of human beings; it works for everyone.

What words do people say when one motivation or another is characteristic of them?

The six motivations phrased as sentences: "we'll be the first to do…", "we'll become part of a great team", "we'll get this much money/control", "we'll make the world better / prove this truth", "we'll achieve this effect", "we'll discover the answer to this question"

When you set a goal, you as a manager have to understand well what gives energy to you and to the person you’re formulating this goal for. Because the answer to the question “Where will we end up and what will we get?” can be given in every one of these variants.

By the way, I have a separate long article about group dynamics. It goes into more detail on how to build a team, whom to hire, and how to find the key to a specific person.

How to set up boundaries of responsibility

I have a checklist that I use when I hand out tasks from the manager’s role. I update it from time to time; right now it has 6 points.

Shared goal — This is why we’re doing it, where we intend to get to, and what we’ll get for it

If this point is missing and we start straight at point 2, it means we don’t think the person we’re handing the task to has any agency at all, or that they’re an independent personality. And that means we’re going to spend a lot of our control on them. And it’s clear why: if they don’t know why we’re doing this, they won’t be able to change their shoes on their own when they hit a dead end.

Task — This is what you have to do

This point is there for synchronization. Even if you’re talking to a very autonomous person, you need a shared picture not only of the goal but of how you’re going to move toward it. Simply so you can tie the actions of everyone else in the process to their actions.

Shared understanding and synchronization — Repeat back in your own words how you understood the task

This point exists in every culture of giving orders: “Now tell me in your own words how you understood what I just said to you.” It’s very important that it’s said in different words, not in mine — otherwise the person is just retelling what they heard, with no guarantee that they understood it. Why spend time on this? To find out whether it landed in their thinking, whether they got it or didn’t get it, whether our maps of reality lined up at that moment.

Contract — Here are your resources, authority, and constraints. Say that you’re taking this task into your responsibility

A very important point. Usually with the first three everyone manages more or less. Everyone does the second. Some do the third. Managers who are halfway decent do the first. But almost everyone skips the point “say explicitly that you’re taking this task into your responsibility.” If the person hasn’t told you, using their mouth, that “yes, I take responsibility for this task, it’s my task now,” then they can go on thinking to themselves: “The boss wanted something from me, but by the way, I didn’t promise him anything.” They haven’t come into a resourceful state and haven’t taken the responsibility baton from you. This is the crucial point, because responsibility transfers only after this. If you don’t do it, it won’t transfer psychologically. And of course it’s much easier for a person to take on anything at all when they’re responsible for nothing.

Control — This is how I’m going to check on you

This is the hardest point, because you as a manager have to invent a method of control. And to invent it you either have to be very un-lazy and simply allocate a lot of your own time, or come up with some criterion. On top of that you have to negotiate the criterion in such a way that both sides understand it the same.

Exit from the agreement — This is how we’ll be exiting this contract

In other words — how I’ll fire you off this task. You have to say out loud at the very start: “Here’s what I consider unacceptable boundaries.” The earlier and the better you understand this and voice it, the lower the probability that you’ll end up firing this person, because they understand the situation the same way.

There must be no situation where it’s unclear whose task it is, where it’s sort of no longer with the manager but not yet with the subordinate. A gradient is out of place.

If a task stops being yours, it’s either finished or you’ve given it to someone else — and that someone has to acknowledge explicitly, in one form or another (with their mouth, in writing, by text message, however), that yes, it’s now theirs. They have to do this outright. Otherwise you get a situation along the lines of “on my side the bullets have left the barrel.”

How to use your manager for their intended purpose

There’s another side to this story, and I didn’t grasp it right away. It’s important to know how to use your manager for their intended purpose when you’re the subordinate.

In principle, all six points we talked about above (goal, task, contract and the rest) can be secured for yourself even in the case where the task is set for you badly — in the sense that something just lands on you from above. I sometimes find myself in that situation too, for example when a client or a partner who stands earlier than me in the value chain sets a task for me badly.

With experience I’ve developed a way to set the boundaries of the task and the contract myself when I take a task into my responsibility. It looks like this:

1. Why are we doing this?

Of the six points this is the only question — because here the answer has to come from the owner of the system. They alone know the true answer to: why this system exists, what it’s for, what they themselves want, and what I’m helping them with. Without this you simply must not take the contract. If you weren’t given it, you’re unambiguously taking on more responsibility than you should.

And after that I set the frame myself, but I talk it through with the source of the task, so that we have a shared picture:

2. Here’s what I intend to do.

3. Here’s my understanding of the task.

4. I need these resources and this authority in order to take on this responsibility. I’ll be acting within these constraints.

5. Here are the points at which, and the form in which, I’m going to report to you.

6. Here are the conditions under which I’ll exit this contract if you break any of its points. And here’s how you can exit this contract if I fail to meet my obligations.

This is a fairly aggressive stance, and honestly, you shouldn’t condemn your subordinates to it. It means that you as a manager set tasks, to put it mildly, not very well. But the person doing the work should switch this method on not only in manager–subordinate relations, but also in contractor–client or partner–partner relations (it makes no difference whether you’re the junior or the senior one; what matters is that your pictures of the world are synchronized. See the article about this).

In any case — you have to be able to arrive at the target state of the system. One in which we all understand why we’re doing this, what we’ll get for it, what our responsibility looks like, and how we’re going to synchronize. Then we’re acting toward shared goals, within a shared picture of the world, and we have every chance of being an effective system.

P. S.

On the subject of delegation I have not only this talk but also a practical training, which I run for high-school seniors, university students, and managers of all kinds, including at FRII. And I’ve tried to make the training useful for people with any level of competence (in the sense that if I went through such a training myself, I’d also get some practice out of it). People who already do all of this practice the skill of giving an order one more time. People for whom not everything here is familiar and clear acquire that skill.

If you’d like to run a training on delegating responsibility at your company, write to me.

Something here you disagree with, or want to apply to your company? Let’s discuss it — disagreement is the more interesting conversation.

Want to discuss a project?

Discuss a problem