TL;DR: “Do it however you like” only helps people who can already picture their first move. To everyone else it reads as fog. In the design-tool workshops I run, that one instruction reliably leaves roughly half the room stuck at the ten-minute mark — this is the shape of a recurring pattern across sessions, not a headcount from one session I logged. Adding three cheap artifacts (a named default tool, two or three finished examples, and the first three steps written out) is what, in my experience, gets the stuck group moving. The same fix applies to tickets, onboarding docs, and review requests; there’s a before/after ticket template below.
Quick answer
If someone freezes on a task you delegated, the problem is rarely motivation — they can’t picture their first move. Hand them three things: a named default tool (“use X unless you already have your own”), two or three finished examples in different styles, and the first three steps written out. In the workshops I run, this is what consistently gets a stuck cohort moving again, for about ten minutes of prep.
Some context first, because “workshop” can mean anything: I run corporate training sessions in Japan for non-engineers, office staff learning to produce simple digital content, with a free browser-based design tool of the Canva variety on every machine.
In one of these workshops I handed the room what I thought was a generous brief: “Make one visual piece on this theme. Any tool you like. Thirty minutes.” Then I walked to the back of the room, quietly confident. I had left the task loose on purpose, because tight instructions suffocate people who already know what they’re doing.
If you assign tickets, onboard juniors, or ask people to review your code, you issue that same brief more often than you think. The workshop just happens to be a place where the failure becomes visible in one room at one time.
The participants with prior design-tool experience started within seconds, tools open and hands already moving. Exactly the effect I’d hoped for.
More than half the room froze. At the ten-minute mark, none of them had started. Blank new files, hands nowhere near the mouse, eyes drifting somewhere above the screen. I stood there watching my own instructions pin more than half the room in place. (I’m describing the recurring shape of this, not a session I have contemporaneous notes for — treat the numbers here as illustrative, not a measured result.)
What the frozen half actually said
I went over and asked, quietly, what was blocking them. The answers clustered hard:
- “I don’t know which tool I should use.”
- “I don’t know where to start.”
- And one person, more honest than the rest: “I can’t picture the finished thing at all.”
Nobody was slacking; every one of them wanted to move. They were standing in fog without a map, genuinely unable to tell which direction the first step went. The same blind spot shows up outside the classroom too — anywhere someone hands over a task with “do it however you like” attached.
Why you can’t see the line from the giving side
The same sentence does opposite work depending on who receives it. To an experienced person, “any tool, any approach” is a runway; their first move is already in their head before you finish talking, and the freedom is just space to extend it. To a beginner, the first move doesn’t exist yet, and the open space converts directly into anxiety. The difference isn’t in the task. It’s in whether the receiver already owns a first step.
The person delegating can’t see this line, because they crossed it so long ago they’ve forgotten it was ever there. It’s a blind spot built into delegation itself, which is why good intentions don’t fix it. I had good intentions and a roomful of frozen people.
I should say plainly that none of this is a new discovery. Andy Grove called it task-relevant maturity in High Output Management: how much structure someone needs depends on their maturity at this specific task, not their seniority in general. Situational-leadership models say something similar, and instructional design has the worked-example effect, decades of evidence that novices learn faster from studying finished examples than from open-ended problem solving. I had read some of this and still stood in a room watching my own brief freeze half the room. Knowing the framework and noticing the line in front of you turn out to be different skills. What follows is the noticing part, plus the exact artifacts that worked.
The three changes
Next session, same style of task, same participants. I added three things.
1. A named default tool. “If you’re unsure, use this one; it’s free and it’s plenty for today. If you already have your own tool, use that instead.” One sentence, and the entire “which tool?” question disappears. Note the escape hatch: experienced people opt out at zero cost.
2. Two or three finished examples, in deliberately different styles. A text-heavy one, an image-heavy one, a mix. Show a single example and people copy it. Show a spread and they see the shape of done without mistaking any one sample for the right answer.
3. The first three steps, written out. Pick a template. Type a title. Swap one image. Deliberately trivial, because anyone who finishes step three has already started, and starting was the whole problem.
At the ten-minute mark of the next session, nobody was still stuck.
Before you take that shift at face value, a few caveats. This wasn’t a controlled comparison, and I’m reconstructing it from memory rather than notes taken at the time. The participants were on their second session in a familiar room, so some of the improvement is plain familiarity. And I introduced all three changes at once, so I can’t tell you which one carried the result. What I can offer is that the three artifacts map one-to-one onto the three blockers the frozen half had named out loud.
There’s a second thing I care about at least as much, and this part really is just my impression, not a count I kept. Before the change, I’d spend a chunk of every session circling the room, re-explaining the same thing to whoever was stuck. Afterwards, that circling mostly stopped. The three artifacts cost me maybe ten minutes of prep and bought back most of my session.
I made the same mistake again, and caught it in seconds
I’d love to tell you I was cured. In the very next exercise, video production this time, I said “do it freely” again. The habit turned out to be stronger than the insight.
The difference: when I saw the first participants freeze up, I didn’t wonder about their motivation. I knew immediately what I’d forgotten to hand over. I stopped, split the work into four explicit steps, and re-issued the task mid-session. Most of the group that had frozen made it to a finished video before the session ended — I don’t have a baseline number to compare it against, and I’d rather not dress up a recalled impression as a measured result.
Nothing about the participants changed between my first failure and my second. What changed was how fast I recognized the freeze. Once you can see the line, the same mistake costs minutes instead of a session.
This is your ticket queue
Swap the classroom for a sprint board and the mechanism is identical.
“Refactor the export module however you think best” reads as trust to a senior and as fog to the junior you actually assigned it to. “Set up your environment however you prefer” costs a new hire their first day, paralyzed among options that all look load-bearing; the fix has the same shape, a default setup path plus “diverge freely if you have opinions.” Even “self-serve” internal platforms fail this way: the people who most need them can’t tell which of the forty documented options is the normal one, so they file a ticket instead.
Then there’s the review request: “take a look when you get a chance.” Look at what? For what? A junior who approves a PR they didn’t fully understand is frozen too; they’ve just found a way to freeze that doesn’t block anyone, which makes it harder to spot. The same three artifacts fix it:
Before: "Take a look when you get a chance."
After: "Review the retry logic for correctness only; style is
covered by CI. Maria's review on #482 is the depth I'm
hoping for. Start with worker.ts — the rest follows
from it."
Enter fullscreen mode Exit fullscreen mode
A named scope as the default, a finished example, a first step.
Platform engineering already solved this for infrastructure and named the solution the paved road: a default path that’s obviously fine, which experts may leave whenever they want. I’m borrowing the analogy wholesale. The only thing I’m adding is the observation that it works on humans, at ticket granularity, for about ten minutes of effort.
The reusable artifact: one ticket, before and after
Before, the version I used to write:
Title: Improve error handling in the export service
The error handling in the export service is inconsistent.
Clean it up however you think is best. Ask me if you have questions.
Enter fullscreen mode Exit fullscreen mode
After, the same ticket with the three artifacts installed:
Title: Improve error handling in the export service
Default approach: use the same error-handling pattern the billing
service uses — that's our house style. If you'd rather use a
different pattern, propose it in a comment before you start.
What "done" looks like: the billing service and the notifications
module are two different-but-acceptable shapes of finished. Skim both.
First three steps:
1. Read the billing service's error handling (about 20 minutes).
2. List every outbound call in the export service as a comment
on this ticket.
3. Convert ONE call and open a draft PR. We'll agree on direction
there before you do the rest.
Enter fullscreen mode Exit fullscreen mode
One difference between the classroom and the codebase deserves a callout. In a thirty-minute workshop, a wrong first step costs nothing; on a refactor, a wrong first step costs rework and merge pain. That’s what step 3 is compensating for: converting one call and opening a draft PR turns “agree on direction” into a checkpoint that happens while being wrong is still cheap. If you copy nothing else from the template, copy that.
As for “ask me if you have questions”: the response you’ll get from a junior is usually silence, because the honest question (“I can’t picture the finished thing”) feels unaskable. The second ticket removes the need to ask it.
Grade movement, not polish
One more change, same root. I used to praise the most polished output, which quietly means praising the people who already owned a first move. So I changed the closing question of every session to: “What’s one thing you can do now that you couldn’t this morning?” Under that question, both cohorts leave with a win; the experienced person picked up a new tool, and the beginner finished the first thing they had ever made.
The engineering equivalent: after a junior’s first ticket, don’t open the retro with the elegance of the diff. Open with what they can now do unassisted.
Isn’t this micromanagement?
Micromanagement specifies every step. This specifies steps one through three and then stops; everything after step three still belongs to the other person.
The check I run before any handoff takes one beat: can this person already see their first move? If yes, freedom is a genuine gift, so give it generously. If not, name the default, show what done looks like, write the first three steps. Then get out of the way.
FAQ
Won’t juniors fail to learn scoping if I always scope work for them?
They can’t learn scoping from a blank page; the frozen half of my room produced exactly nothing to learn from. But “hand over less scaffolding each time” is too vague to act on, so here is the fading order I use. Remove the written first steps first: after someone finishes two or three scoped tickets, have them draft the first three steps themselves and review the draft before they start. The draft is your readiness signal — when it roughly matches what you would have written, stop supplying steps for that class of task. The named default fades on its own; people stop using it the moment they develop opinions. Keep the examples longest, since “what does done look like here?” is a question even seniors ask. Scaffolding creates dependence only if you never start asking for the draft.
How do I scaffold without insulting the seniors?
Phrase the default as a default: “use X unless you already have your own approach.” Experienced people opt out in one second and lose nothing; that single clause served both halves of my room. When in doubt, ask what’s blocking. The frozen half told me exactly what was missing the moment I asked quietly.
Isn’t writing three artifacts per ticket a lot of overhead?
Compare it to what you’re already paying. By my own impression I was spending a large chunk of every session re-explaining the same instructions, one stuck person at a time; after the change, that mostly went away. Ten minutes of prep against a session of firefighting is the cheap option.
What if I can’t articulate the first three steps myself?
Then the task wasn’t ready to delegate, and you found out before your junior did, at the cost of one uncomfortable minute instead of their week. Treat “I can’t write step one” as a signal that the ticket needs more definition before it goes to anyone.
You don’t have to pave the whole road. Name a default, show two or three finished examples, write the first three steps, and get out of the way.
답글 남기기