Why I Stopped Breaking Tasks Into Smaller Pieces (And Started Breaking Them Into Questions)

There's a version of productivity advice that feels so reasonable you absorb it without questioning it. Break the big thing into smaller things. Make the list. Work the list. It's tidy, it's teachable, and for a long time I believed it completely. Then I started noticing something uncomfortable: the more carefully I decomposed certain kinds of work, the worse the work got.

Not slower. Worse. Flatter. Like something had been squeezed out of it before I even started.

This isn't a post about abandoning structure. Structure matters. But there's a specific kind of structure, the kind built from sub-tasks and nested checklists, that does something quietly damaging to creative and synthesis-heavy work. And there's an alternative that almost nobody talks about, because it looks less productive on the surface and produces better results underneath.

The Advice I Followed for Years (And Why I Finally Questioned It)

Where 'Break It Down' Comes From

The instruction to break large tasks into smaller ones isn't folk wisdom. It has real intellectual lineage. David Allen's Getting Things Done methodology, published in 2001, built an entire productivity system around the concept of the "next physical action": you can't do a project, you can only do the next concrete step within it. Before GTD, the same logic appeared in formal project management frameworks, where decomposing deliverables into work breakdown structures was standard engineering practice. The idea is genuinely useful. When you're coordinating a team, managing dependencies, or building something with sequential steps, decomposition is the right tool.

The problem is that it migrated. It moved from project management into personal knowledge work, from engineering into writing, from assembling things into thinking about things. And somewhere in that migration, nobody stopped to ask whether the tool still fit the task.

The Moment I Noticed It Wasn't Working

The turning point for me was a long-form piece I'd been commissioned to write on how organisations misread their own data. I did what I always did. I broke it into sub-tasks: research phase, outline, draft introduction, draft section one, and so on through to final edit. I worked the list diligently. What came out felt like it had been assembled rather than written. The argument was technically present but the connective tissue, the thinking that makes a piece feel alive, was missing. I'd been so busy completing steps that I'd stopped actually grappling with the problem.

That experience didn't immediately give me an answer. But it gave me a question worth sitting with.

What 'Break It Into Smaller Tasks' Actually Does to Your Brain

Cognitive Load Theory: A Quick Primer

In 1988, educational psychologist John Sweller introduced cognitive load theory to explain why some learning designs work and others collapse under their own complexity. The framework identifies three types of cognitive load. Intrinsic load is the inherent complexity of the material itself. Extraneous load is the mental effort created by poor presentation or unnecessary structure. Germane load is the productive cognitive work of building understanding and making connections.

The goal of good design, whether in education or in how you organise your own work, is to minimise extraneous load so that more mental bandwidth goes toward germane processing. That's the part where actual thinking happens.

When Decomposition Helps. And When It Backfires

For procedural tasks, decomposition is a load-reduction tool. Assembling flat-pack furniture benefits enormously from a numbered step list. The task is sequential, the outcome is fixed, and there's no value in wandering off-script. Sub-tasks reduce extraneous load by removing decisions that don't need to be made.

Creative and synthesis-heavy work operates differently. Writing an article isn't sequential. The introduction often makes sense only after you understand the conclusion. The structure emerges from the thinking, not before it. When you impose a rigid sub-task list on that kind of work, you introduce what researchers now call coordination overhead: the mental cost of tracking where you are in the list, deciding which sub-task to address next, and maintaining fidelity to a structure you created before you understood the problem.

This overhead isn't trivial. Updated research published in 2025 examining cognitive load in synthesis-heavy professional work found that sub-task management for non-sequential projects can consume a meaningful portion of available working memory, leaving less capacity for the generative thinking the work actually requires. The list designed to help you think ends up competing with thinking.

"The structure we impose before understanding a problem is often the structure that prevents us from understanding it.". A pattern noted repeatedly in design thinking research, though rarely applied to personal productivity.

The furniture analogy makes this vivid. Step 14 of an IKEA assembly doesn't need to know what step 8 was doing. Each step is self-contained. But paragraph four of a good essay absolutely needs to know what paragraph one promised, what paragraph two complicated, and what the reader is now ready to hear. You can't pre-slice that into discrete units without losing the thing that makes it work.

The Hidden Cost Nobody Talks About: Checklist Compliance Mode

Execution Mindset vs. Exploration Mindset

There's a psychological state that sub-task lists quietly induce. Call it checklist compliance mode. It's the mental posture of someone whose primary goal has shifted from understanding the problem to completing the items. The work becomes a series of boxes. The satisfaction on offer is completion, not comprehension.

This matters because motivation is not neutral. Research on self-determination theory consistently distinguishes between intrinsic motivation, driven by curiosity, meaning, and genuine engagement, and extrinsic motivation, driven by external markers of progress. Sub-task lists are extrinsic motivation machines. They offer the small dopamine hit of the ticked box, which is real and not nothing, but which gradually displaces the deeper engagement that produces genuinely good work.

The shift is subtle enough that you don't notice it happening. You sit down to write something important. You open your task list. You read "Draft section two." You draft section two. You tick the box. You feel productive. But you never asked yourself whether section two should exist, what it actually needs to accomplish, or whether the whole structure you planned last Tuesday still makes sense now that you understand the problem better.

How Sub-Tasks Kill Creative Momentum

Divergent thinking is the cognitive mode that generates unexpected connections, novel framings, and the kind of insight that makes a piece of work surprising rather than merely competent. Convergent thinking is the mode that evaluates, selects, and refines. Both are necessary. The problem is that they don't coexist comfortably, and sub-task lists are convergent thinking tools dropped into work that needs divergent thinking first.

When you're in checklist compliance mode, the mind is oriented toward closure. Open questions feel like inefficiency. Unexpected tangents feel like distraction. The very mental wandering that might produce the insight your work needs gets suppressed because it doesn't map to any item on the list.

This is the cost nobody names when they recommend breaking things into smaller pieces. It's not that the method fails to produce output. It often produces output efficiently. It's that the output produced in checklist compliance mode tends to be the output you planned before you understood the problem, not the output the problem actually needed.

Enter the Information Gap: Why Questions Are Motivationally Different

Loewenstein's Information Gap Theory Explained

In 1994, behavioural economist George Loewenstein published a paper that reframed how researchers think about curiosity. His information gap theory proposed something precise: curiosity isn't a vague feeling of interest. It's a specific response to perceiving a gap between what you currently know and what you want to know. The gap creates a kind of cognitive itch. Closing it is intrinsically rewarding, not because someone told you to, but because the mind is built to find resolution satisfying.

This has a direct practical implication. If you frame your work as a set of tasks, you're not creating information gaps. You're creating obligations. "Write introduction" doesn't make you curious about anything. It tells you to produce something. The emotional valence is duty, not discovery.

Curiosity as a Productivity Engine

Now consider the alternative framing: "What's the one thing my reader needs to believe before anything else I write makes sense?" That's a question with a gap in it. You don't know the answer yet. Your mind immediately starts searching, not because you willed it to, but because that's what minds do with open questions. The information gap is already pulling you forward.

This is motivationally different in a way that compounds over time. Willpower-dependent motivation depletes. You start the day with a certain amount of resolve, and every act of self-discipline draws it down. Curiosity-driven motivation doesn't work that way. When you're genuinely curious about a question, the thinking sustains itself. You don't have to push. The gap pulls.

There's also a structural difference in how questions keep the mind oriented. A task puts the mind in a closed state: execute, complete, move on. A question keeps the mind in an open state: search, consider, connect. For work that requires synthesis, that open state isn't a luxury. It's a prerequisite. You can't synthesise well while your mind is oriented toward closure.

The other thing questions do, which tasks can't, is invite revision. If you're halfway through answering "What's the strongest objection to my central argument?" and you realise the argument itself needs rethinking, the question accommodates that. It was always asking you to think, not to produce. A sub-task called "Draft counterargument section" does not accommodate that. It asks you to produce something you planned before you understood what you were doing.

How I Actually Break Work Into Questions Now

The Question Decomposition Method

The method is simpler than it sounds, which is part of why it works. Start with the goal of the work, stated plainly. Then ask a single question: "What do I need to understand or decide in order to move forward?" Write down whatever comes up. Don't filter yet. The outputs of that question become your working questions for the project.

Here's what that looks like in practice. Suppose you're writing a strategic plan for a product launch. A traditional sub-task list might look like this: research competitors, define target audience, draft positioning statement, write executive summary, create timeline, identify risks. Each item is a production obligation. The list tells you what to make, not what to think about.

A question list for the same project looks different: What problem does this product solve that competitors aren't solving? Who has the most to lose if this product doesn't exist? What would make someone who's sceptical of our positioning change their mind? What's the single constraint that, if removed, would change everything about how we launch? What does success look like in twelve months, and how would we know we'd missed it?

Those questions don't map one-to-one onto the sub-tasks. That's the point. They're not a renamed checklist. They're a set of cognitive prompts that activate actual thinking, and the thinking produces the deliverables rather than the deliverables being the point.

Types of Questions for Different Kinds of Work

Not all questions do the same thing. Over time I've settled on a loose taxonomy of four types, each of which activates a different cognitive mode.

Diagnostic questions orient you toward understanding the current state: "Why hasn't this problem been solved before?" or "What's actually causing the friction here?" These are useful at the start of a project when you're still mapping the terrain.

Generative questions open possibility space: "What would this look like if the usual constraints didn't apply?" or "What's the most counterintuitive approach that might work?" These activate divergent thinking and are most valuable before you've committed to a direction.

Evaluative questions bring convergent thinking back in: "Which of these approaches is most defensible?" or "What would I have to believe for this to be wrong?" These are useful once you have material to assess.

Constraint questions clarify the boundaries of the problem: "What can't change here, and why?" or "What does this have to do, at minimum, to be worth doing?" These prevent scope drift and help you understand what you're actually optimising for.

The questions don't all need to be answered before you produce anything. Often the act of producing something, a rough draft, a diagram, a half-formed argument, is itself how you answer a question. The method isn't a replacement for doing the work. It's a different way of orienting yourself toward it.

A Real Example: How This Changed One Project Completely

The Old Approach and Where It Stalled

Last year I was working on a long piece about why organisations consistently misinterpret their own performance data. I'd been commissioned to write it, had a clear brief, and felt confident enough in the subject that I built a detailed sub-task list before I'd written a word. The list had eleven items. Research phase. Identify three to four case studies. Draft the framing section. Explain the statistical concepts. Draft the practical recommendations. And so on.

I worked the list. I completed items. After two weeks I had a draft that was, by any objective measure, fine. It covered the topic. The structure made sense. The case studies were well-chosen. And it was completely, thoroughly boring. Not because the subject was boring, but because I had produced exactly what I planned to produce before I understood what the piece needed to be. The sub-task list had insulated me from the actual problem.

The piece stalled at the revision stage because I couldn't figure out what was wrong with it. Everything on the list was done. The list said the work was finished. But the work wasn't finished.

The Question-Based Reframe and What Opened Up

I scrapped the list and replaced it with questions. Why do smart people in organisations keep making the same data interpretation errors? What's the emotional function of bad data analysis, what does it protect people from having to confront? Is this a literacy problem or an incentive problem, and does the answer change what I should recommend? What would a reader need to believe about their own organisation before any of my examples would feel relevant to them?

Within a day of working with those questions, I'd found the actual argument: the problem isn't that people can't read data, it's that accurate data interpretation is often professionally risky, and organisations have quietly evolved cultures that reward confident misreading over uncertain accuracy. That argument wasn't in my original plan. It couldn't have been, because I hadn't understood the problem yet when I wrote the plan.

The piece came together in four days. Not because questions are magic, but because I was finally working on the right problem instead of completing a list I'd built before I knew what the problem was.

When Sub-Tasks Are Still the Right Tool

Not everything deserves a question. That's the honest starting point here, because this post isn't arguing that task lists are broken. It's arguing that they're frequently misapplied, which is a different problem entirely.

Procedural work vs. synthesis work

Some work has a known path. You've packed for a trip before. You know the list: charger, passport, three days of clothes, the toiletry bag you always forget and then buy at the airport anyway. Writing that down as a checklist isn't a failure of curiosity. It's just sensible. The same goes for running a deployment checklist before pushing to production, or doing a grocery shop from a weekly meal plan. The destination is clear. The steps are established. A task list is the right tool because the only real risk is forgetting something, not misunderstanding something.

This is what researchers sometimes call procedural work: execution against a known template. The cognitive load is low by design. You want it that way.

Synthesis work is different. It involves figuring out what to do before you can do it. Writing a strategy document, designing a new feature, deciding how to approach a difficult conversation with a client. These tasks don't have a template. The path to completion is part of what you're trying to discover. Dropping them into a task list gives you the feeling of structure without the substance of it.

How to know which mode you're in

The diagnostic is simple. Ask yourself: if someone handed me this project fully completed, would I have been able to predict every step they took? If yes, that's procedural. Use tasks. If the answer is "not really," that's synthesis. Use questions.

Most real projects contain both phases. A product launch has a procedural tail (briefing the team, scheduling the announcement, updating the website) and a synthesis core (figuring out the positioning, the message, the timing). The hybrid approach works well here: questions for the discovery phase, tasks for the execution phase. You don't have to choose one for the whole project.

This is a tool selection argument. The hammer isn't wrong. You just shouldn't be using it on screws.

This Directly Contradicts Something I've Written Before

In early 2024, I published a post on this site called "How to Stop Procrastinating by Making Tasks Smaller." It did well. People shared it. I got emails from readers saying it helped them finally start things they'd been avoiding for months. I'm genuinely glad it did that.

It also wasn't the whole picture, and I've been sitting with that for a while.

What I got wrong in my earlier thinking

The earlier post was built on a real insight: large, vague tasks are intimidating, and intimidating things get avoided. Break them down, reduce the friction, get started. That logic holds. The problem is that I applied it universally, as if all tasks were the same kind of thing. I didn't distinguish between work where the path is known and work where the path is the problem. So readers who were genuinely stuck on creative or strategic work got advice that helped them feel productive without actually moving them forward. They broke their vague task into five smaller vague tasks and called it planning.

"The map is not the territory. And a list of steps is not the same thing as understanding what you're actually trying to do."

That's the gap. Sub-task decomposition assumes you already understand the work. For a significant portion of the work most of us do, that assumption is wrong from the start.

Why I'm comfortable updating my position

Publicly changing your mind feels uncomfortable in a way that it probably shouldn't. There's a version of credibility that depends on never being wrong, and it's a fragile, exhausting version. The more durable kind comes from being willing to say: here's what I thought, here's what I've learned since, here's how my thinking has shifted.

The earlier post was right for the context it was written in. It helped people who were avoiding tasks because those tasks felt too large. It was less useful for people who were avoiding tasks because those tasks were genuinely unclear. I didn't see that distinction clearly enough at the time. I do now.

The Objections I've Heard (And My Honest Responses)

When I've shared this approach in conversation, three objections come up almost every time. They're worth taking seriously, because two of them are genuinely good points and one of them dissolves under mild scrutiny.

'But I need concrete next actions'

This is the GTD objection, and it's the most legitimate one on the list. David Allen's system is built on the idea that your brain needs a clear next physical action, not an open loop. Questions, on this view, are open loops. They create anxiety rather than resolve it.

Here's the thing: questions and next actions aren't mutually exclusive. A question like "What's actually preventing us from launching this in June?" is answerable. You answer it. Then you identify the next action that the answer reveals. The question is the step before the step. It doesn't replace the action; it produces the right action instead of a plausible-sounding wrong one.

'Questions feel too vague to act on'

This objection is usually a sign that the question isn't specific enough yet. "How do I grow the business?" is not a useful question. "What's the one thing that would make our onboarding conversion rate obvious to diagnose?" is. The difference is specificity and answerability. A good question has a knowable answer, even if you don't know it yet. If your question sounds like something a philosophy professor would assign for a semester, it needs to be sharpened.

The test: could you sit down for 45 minutes and make meaningful progress on answering this? If not, the question is too large. Break the question down, not into tasks, but into smaller questions.

'This won't work for teams'

Questions can be assigned. They can have owners, due dates, and acceptance criteria, just like tasks can. "Determine which customer segment has the highest churn risk and document the top three hypotheses by Friday" is a question-framed deliverable. It's trackable. It's assignable. It also tells the person receiving it what they're actually supposed to figure out, rather than just what they're supposed to produce.

Start with one project. Not your whole system. One project, one week, and see what the questions surface that the tasks were hiding.

Try It This Week: Your Question Decomposition Starter Kit

The fastest way to test this is to take something you're already working on and convert it. Not hypothetically. Actually do it, right now, before you close this tab.

How to convert your current task list

Pick a project that's been sitting on your list longer than it should have. Open the task list for it. For each sub-task, ask: "Why is this on the list?" If the answer is "because I need to figure something out before I can do it," convert that task into a question. If the answer is "because I know exactly how to do it and just need to do it," leave it as a task.

Questions to ask about your questions

Three prompt templates that tend to unlock things:

"What do I need to know before I can make this decision?" This one surfaces hidden dependencies. You thought you were ready to act. You're not. Now you know why.

"What would make the right answer obvious?" This reframes the problem as an information gap rather than an execution gap. It points you toward what to go find out.

"What am I assuming that might be wrong?" This is the uncomfortable one. Use it anyway.

Start with just one session. One project, one hour, one honest reflection at the end. Did the questions make the work feel more alive, or did they just add friction? That answer is data. Share it, here in the comments or wherever you talk about this kind of thing, because the more people test this, the better the picture gets.

The Bigger Habit This Points To

Task management is, in the end, a relationship with work. And the shape of that relationship matters more than the specific system you use to manage it.

Curiosity as a meta-habit

Curiosity isn't a personality trait you either have or don't. It's a trainable habit, built through repeated practice of asking questions instead of assuming answers. Every time you convert a vague task into a specific question, you're doing a small rep of that habit. Small reps compound. This is what researchers mean when they talk about intellectual humility as a skill rather than a disposition: it's not about being uncertain all the time, it's about staying genuinely open to being wrong about what you thought you already understood.

Reframing productivity around understanding, not output

The standard productivity frame is output-obsessed. Tasks completed. Items cleared. Inbox zeroed. These are measures of motion, not measures of progress. A question-based approach reframes the goal: you're not trying to clear a list, you're trying to understand something well enough to act wisely on it. That's a different game, and it tends to produce better outcomes precisely because it slows down the part that deserves to be slow.

The provocation to close on is this: question decomposition is one application of a broader reframe. What else in your work, your planning, your daily routines, might be worth converting from a statement into a question? What are you treating as solved that might still be worth examining?

That's not a rhetorical flourish. It's a genuine invitation to keep looking.