Delegation You Can Learn from Prompt Engineers

You assign a task — whether to a chatbot AI or a human colleague — and get something off target. Not completely wrong, but not what you needed at all. You go back to your original wording, add «please do everything carefully and attentively», tack on «this is IMPORTANT», and add an exclamation mark for good measure. And you catch yourself thinking: «But I laid everything out clearly and precisely!»

More often than not, that’s not the case — it’s neither clear nor fully understandable. And this is no criticism: assigning tasks is genuinely difficult, and almost nowhere is this skill taught as a dedicated subject. We learn delegation on the fly, piecing together fragments of experience, and rarely get honest feedback on how well we’re actually doing at it.

But there is a profession where task formulation is not a secondary skill, but a core craft honed down to set polished techniques. These are prompt engineers — people who professionally fine-tune the operation of large language models and formulate tasks for them every single day. They do this hundreds of times, and quickly realized that the quality of the response depends almost entirely on the quality of the prompt. Over the past couple of years, they’ve built up a set of working principles — and it turns out almost every single one of them applies to delegating tasks to real people, as well as to setting tasks for yourself.

Why it’s worth learning from them specifically

First — why prompt engineers turned out to be good teachers of delegation in the first place. It all comes down to feedback.

When you assign a task to someone, the quality of your briefing is often fuzzy. A good colleague will fill in unspoken gaps, ask for clarification on unclear points, and silently fix your carelessness — and you may never even realize the task was poorly set in the first place. The end result is decent, so it feels like the assignment was fine too. That’s how it seems to us.

Neural networks work differently. They don’t fill in gaps out of politeness, and they don’t smooth over rough edges to avoid upsetting you. A vague task brief instantly produces a vague result — directly, with no buffering. It’s unpleasant, but useful: it acts as a delegation training tool with extremely honest feedback. A person who has been assigning tasks to AI for a year goes through thousands of these mini-lessons. The discipline of formulating clear tasks develops faster and more strictly in them than in the average manager — not because they are smarter, but because the mirror they’re looking into is more honest.

Here are five lessons from this kind of mirror.

Lesson 1. "Try your best" is not a task

A representative case. Prompt engineers were configuring a support bot for a telecom company. Among the tasks was one that seemed simple at first glance: a customer asks what their bill will be if they switch their tariff plan mid-month. The requirement was to calculate the amount, taking the partial month into account.

The bot’s instructions laid out all the "right" requirements: calculate correctly, don’t give the customer vague answers, numbers must be accurate. But the bot still kept mumbling — it reasoned out loud, estimated values by eye, and failed to produce a reliable figure.

The reason turned out to be simple. Instructions do not add capabilities. No matter how much you write "calculate correctly", it does not make the model stronger at arithmetic — just as the requirement "be more attentive" does not improve eyesight. What helped was something else: the bot was given a tool — a calculator, a separate function that performs calculations with perfect accuracy. It is not an order to calculate well, but the ability to calculate well.

The same holds true outside of AI. "Do it well" is not a task, but a wish. If you assign a mockup to a junior and tell them "do it well", but do not show a reference standard, do not grant access to the necessary component library and ready-made solutions, and do not explain what is considered "good" in this case — you are demanding a result without providing the opportunity to achieve it.

I saw this especially clearly when I was mentoring a team of designers. The difference between "make a normal form" and real help is the difference between a requirement and proper equipping. In the latter case, you provide access to the design system and the pre-assembled blocks built on it, show a sample of a similar form, and walk through the criteria. Delegation is not just passing on a requirement. It is also passing on the necessary capabilities.

Lesson 2. The task executor optimizes exactly what you said

The second case with the same bot is, in my opinion, the most instructive.

Sometimes a bot shouldn’t solve a problem on its own — for example, if there’s a billing error, the request is supposed to be passed to a live specialist. The instruction tried to account for this and was written roughly as follows: “Passing requests to a specialist is costly — each handoff costs around eight dollars and drags down our issue resolution speed metric. Avoid doing this unless absolutely necessary.”

What did the bot do? It stopped passing requests to specialists altogether. Even in cases where handing off the request was absolutely necessary. And from its perspective, it was completely in the right: only one criterion was communicated to it — the cost of handoffs — and it diligently optimized for that.

This is how the issue was fixed: both sides of the situation were laid out for the bot. Yes, a handoff costs eight dollars. But if a request that requires a human specialist is not passed along, the company will lose far more — it will have to issue refunds, and customer trust will be damaged. Once it had the full picture, the bot started making reasonable decisions.

Now remove the word “bot” from this scenario. This mechanism works with anyone — employees, contractors, even you yourselves. Any worker will optimize for the criterion you state. If you tell your team to “close tickets faster”, you’ll get speed achieved at the expense of quality. And formally, the team will be in the right: you asked for faster work, they delivered faster work. This isn’t sabotage or stupidity — it’s literal, honest execution of the stated goal.

The conclusion is uncomfortable but simple. When delegating, name the compromise as a whole, not just one side of it. Not "cheaper," but "cheaper, but not at the expense of this." Not "faster," but "faster, while maintaining quality at least at this level." If you only name one quantity, don't be surprised when everything gets stuck on it.

The same applies to the goals you set for yourself. A one-sided metric can skew life just as much as it can skew a bot's work. "Earning more" without the second half of the phrase can easily be optimized at the expense of health or relationships — and formally, you'll also be right in front of yourself.

Lesson 3. If it's unclear to you, it's unclear to the performer

The third principle is about structure.

Engineers often inherit prompts that were written over months and by several people. A typical picture: one solid piece of text, where the performer's role, strict rules, tone preferences, reference data, and patches slapped together sometime in the past are all jumbled together. Everything is lumped together.

If, when reading the instructions, you can't tell where the unbreakable rule is and where the reference information is, then the model won't be able to distinguish it either. The solution is obvious: separate them. Separately — the role, separately — the strict rules, separately — the wishes, separately — the data.

And again: this has nothing to do with AI at all. Recall the typical task description someone sent you — where context ("a client asked us for this"), the task itself, a mandatory requirement ("you absolutely must use our library") and an optional wish ("and it would be nice if it looked better") are all jumbled together in one stream. The executor physically cannot separate what must not be violated from what is left to their discretion. They will either ask for clarification, or — which is far more likely — interpret it in their own way, in whatever way makes the most sense to them, and very often interpret it incorrectly.

Clarity for the executor starts with clarity in your own head. If you haven't broken the task down into "mandatory / desirable / context / reference" yourself, your counterpart won't do it either. As a designer, this idea resonates deeply with me: a good technical specification is structured like a good interface — it itself shows what is most important here and what is secondary, and doesn't force you to fight your way through it.

Lesson 4. Don't assign a large task all at once

The fourth case is about another agent. Their task was to compile a working shift schedule for a store: several employees, availability constraints, mandatory requirements for the composition of each shift.

At first, engineers tried to assign this task with one large request: "here are all the conditions, give me a ready-made schedule." That did not work: the model got confused, broke the rules, and did not check its own work. A different approach worked: the task was split into three simple roles that work in sequence. The first creates a draft schedule. The second checks the draft and lists out specific violations. The third receives the list of violations and fixes them. Three small, clear tasks instead of one huge one — and the result became reliable.

It works exactly the same way with people. Assigning the task "design the customer section in the CRM system" all in one go is almost doomed: it is too big for the person executing it to hold the whole thing in their head and not forget half of it. Decomposition — splitting the task into stages with a clear "done" state for each — is not bureaucracy, but respect for how attention actually works.

And pay attention to the separate role of the reviewer in the second step. A separate review step is not a sign of distrust toward the person executing the task. It is a normal part of the process built into it in advance. By the way, large personal goals follow the same logic: not one heroic all-out sprint, but a draft, revision, refinement.

Lesson 5. Trust, but have a criterion

And the last point — about how to understand in general that a task is completed.

Prompt engineers have a method for this called evals — essentially, a set of test cases. For each test case, a one-line criterion is written out in advance: this is the question, this is the correct answer, it either passes or fails. When an engineer changes the model's instructions, they run it against this set and can clearly see whether performance got better or worse. Without such a set, any "improvement" is self-deception in the vein of "well, it seems to give better answers".

Let's carry this over. When delegating a task, agree on the criteria with the person executing it in advance — a clear way for both of you to confirm the work is completed. Not the vague "show me when you finish, I'll check it then", but a clear result criterion laid out at the very start.

This, by the way, benefits both parties. It eases the executor's anxiety — they don't have to guess whether they've met your expectations, and they have a clear checklist of requirements to follow. And it removes the temptation for you to micromanage: if a clear criterion is in place, you don't need to hover over their shoulder, you just need to compare the final result against the agreed standard.

For those who, like me, are into tracking metrics for their personal lives — sleep, activity, habits — this idea will feel familiar in a different form. A measurable criterion is far more reliable than a gut feeling. "I think I've been moving more" and "I walked 2,000 more steps per day than I did a month ago" are two statements with vastly different levels of reliability. The same goes for delegated tasks.

Final Takeaways

There is an old rule in programming: "garbage in, garbage out". No matter how powerful an algorithm is, it will output poor results when given bad input data. Well, this rule has long since outgrown the realm of code. It applies to any performer — a neural network, an employee, even yourself. A sloppy task brief is exactly that garbage input.

The five lessons — about using a tool instead of issuing a directive, about both sides of a compromise, about structure, about decomposition, about evaluation criteria — all ultimately boil down to one core idea.

The quality of the end result is defined by the quality of the task brief. And responsibility for that quality falls on the person who sets the task, not the person who executes it. This is especially starkly visible for prompt engineers — simply because a neural network, unlike a polite colleague, will return their own carelessness to them unsoftened and immediately.

But the techniques themselves are not about AI. They are about delegation as a concept: no matter who you assign a task to — a model, an employee, a contractor, or even your own self next week. Engineers working with AI simply found themselves in circumstances where they had to learn this faster than everyone else.

So the suggestion is simple. On the next task you assign to someone, try to catch yourself — which of the five lessons you are tripping over. Most likely, you will regularly stumble on one specific one. That is the right place to start.

Materials and examples related to AI are taken from the presentation: The Prompting Playbook, speaker: Margot van Laar

Partially overlaps with my article Prompt Engineering for Non-Prompt Engineers

I write about AI working practices in the Telegram channel «Me and My Robot Friend» — about multi-agent systems, data visualization, and real-world automations: https://t.me/mewithrobot