Delegating the Work You Are Best At

Alexander Chua
7 min
Delegating the Work You Are Best At

The short version

  • The work you do best is the work whose standard exists only as execution. Delegating it is a transcription problem before it is a trust problem.
  • Any note you have given twice is a rule nobody has recorded. On one newsletter programme the nine standing rules were written at issue 20 rather than issue 1.
  • A thin brief comes back as confident work with the missing parts invented. The hole is invisible, which is why review misses it.
  • Keep the adversarial pass and run it separately from the making. Generation is fast and sure of itself, so a check running inside the same pass loses to it.

The work you are best at carries a standard you never wrote down, because you executed it instead of describing it. That makes the handoff a transcription job. What leaks are the hundred small decisions nobody knew were decisions, and they leak quietly, because whoever receives the work closes the gap with something plausible.

Why is your best work the hardest to hand over?

Because a brief carries the decisions you can name. Most of what you do at your best happens without stopping to decide, so it never reaches the document, which reads as complete when you check it back.

A batch of twenty posts written to a brief on this site came back structurally clean and missed the documented standard completely: no first-party data, no tables, around 595 words against a bar of 1,000 to 1,400. The standard sat one click from the brief and nothing made anybody open it.

Where a handoff of expert work leaks:

What was handed overWhat I assumed came with itWhat came backWhat closed it
A brief with the standard one click awayThat somebody would open it20 posts, clean structure, around 595 wordsThe standard pasted into the brief
A source file with one line per storyThat a thin entry produces a cautious sentenceInvented detail, surviving a repair passEntries deep enough to write from
A house rule restated in every briefThat stating it enforced it2,801 em-dashes across 200 essays against a rule of zeroA script that fails the build
The making and the checking in one passThat the maker would catch itThe confident half winning every timeVerification as its own pass

What do you write down first?

The note you have now given twice. Once is a correction. The second appearance means it is a rule nobody recorded, and it gets given again every cycle until somebody writes it down.

One newsletter programme we run holds nine standing editorial rules and a QA script, written at issue 20 rather than issue 1, because that is when it became obvious the same notes were going out twice. Eleven issues have shipped under them since, numbers 20 to 30.

Delegating your own craft has an extra step, because nobody hands you the note. You are the one quietly making the edit. Log what you changed rather than only changing it, and the second identical line is the rule.

What happens to the gaps you leave in a brief?

They get filled. An under-specified brief comes back as confident work with the missing parts supplied by whoever received it. A repair pass fixed the structure of that batch, and an adversarial audit afterwards still found invented detail, because the source file held one line per story.

The fix sits at the input. Entries in that file are now long enough to write a paragraph from. A one-line note invites improvisation, and improvisation runs toward whatever sounds right.

What do you keep after you hand it over?

The adversarial pass, running separately from the making. Generation is fast and sure of itself. Verification is the slow pass that goes looking for reasons to reject, and running the two together means the confident half wins. Our 255-page build ran them as two passes.

That pass checks the artifact rather than the report, because the report is written by whoever did the work.

Nobody hands you the note when the work is your own. You are the one quietly making the edit, which is why it never gets written down.

How do you know the handoff worked?

The same note stops appearing. That is the only measure I trust, and it takes several cycles to read, which is why transfers get abandoned early.

The second signal is uncomfortable. Work comes back in a shape you would not have chosen and clears the bar anyway, which means the written rule is doing the job your presence used to do.

The two halves of the transcription job are turning a repeated note into a rule something can check and putting the standard inside the brief.

Frequently asked questions

How do you delegate work you are good at?

Write down the decisions you make without noticing. The mechanical ones become rules a script can check and the rest become a file that lives where the work happens.

Why is creative work harder to delegate than process work?

Because its standard exists as execution rather than as a document. A process has steps somebody already wrote down. Expert creative work runs on decisions the expert makes without stopping.

What should be in a brief for work you normally do yourself?

The standard itself, inside the brief rather than linked beside it. A batch of twenty posts written against a linked standard came back structurally clean and missed it entirely, at around 595 words.

How do you keep quality after handing work off?

Split the making from the checking and check the artifact rather than the summary. Verification inside the same pass as production loses to it. Our 255-page build ran generation and verification separately.

How do you stop people inventing details when the brief is thin?

Deepen the source material until a paragraph can be written from it. A thin entry gets closed by whoever received it, usually with something that sounds right.

When should you take work back after delegating it?

When the bar is missed and no rule exists that would have caught it. Write the rule then. Taking work back over a version difference that still clears the bar cancels the transfer.

Sources

  • Chua Network delivery data across 8 client accounts (internal fact bank)
  • Chua Network engagement records, anonymized (internal experience bank)
Alexander Chua

Alexander Chua

Co-Founder, PipelineRoad. Building companies and observing the world across 40+ countries. Writing about company building, go-to-market, capital formation, and the lessons in between.

More about Alexander

Newsletter

Chua Network Letter

Occasional essays on company building, global observations, and clear thinking. No spam. No SEO bait.