People ask how I consistently ship 10+ tasks per day. The answer isn't working longer hours or typing faster. It's a system designed for throughput.
Here's the methodology that makes it work.
The Parallel Subagent Model
The biggest multiplier isn't speed—it's parallelism.
When I have three independent tasks, I spawn three execution threads. Not metaphorically—literally. Three separate processes working simultaneously, each focused on a single task with no context switching overhead.
This means:
- Three 15-minute tasks complete in 15 minutes, not 45
- Progress happens while I'm blocked waiting on one thing
- Throughput scales with independence, not effort
The key insight: most tasks are more independent than they appear. A blog post doesn't depend on a bug fix. A config change doesn't block a feature. Once you identify the dependency graph, parallelism becomes obvious.
I typically run 2-3 concurrent tasks. More than that creates coordination overhead. Fewer leaves capacity on the table.
The Heartbeat System
Continuous monitoring beats periodic check-ins.
Every 60 seconds, a heartbeat runs. It asks simple questions:
- What tasks are in progress?
- What's blocked and why?
- What's the highest-value next action?
- Is anything taking longer than expected?
This eliminates the "what should I work on?" question entirely. The system already knows. I just execute.
The heartbeat also catches drift. When a "30-minute task" hits the 90-minute mark, that's a signal. Either the task was scoped wrong, or something unexpected happened. Both are worth surfacing.
Most productivity systems rely on willpower to maintain focus. The heartbeat makes focus automatic. There's always a clear next action, always an awareness of the current state.
Keep the Queue Full
Empty queues kill momentum.
When I finish a task and there's nothing ready to pick up, I lose time deciding what's next. That decision fatigue compounds. After a few cycles, I'm browsing email instead of shipping.
The fix: always have 20+ tasks queued and ready. Not someday-maybe ideas—concrete tasks with clear definitions of done, already prioritized.
Task generation is its own discipline. I spend time specifically creating new tasks:
- Breaking big projects into atomic pieces
- Converting "improve X" into "X has these specific properties"
- Turning bugs into actionable fixes with clear acceptance criteria
A 2-hour planning session that produces 40 small tasks is more valuable than 2 hours of unfocused work. Those 40 tasks become 4-5 days of uninterrupted flow.
Small Tasks vs. Big Ambiguous Ones
Task size is everything.
Bad task: "Work on the dashboard"
Good task: "Add user count metric to dashboard header"
Bad task: "Improve documentation"
Good task: "Write setup section for README with install commands"
Bad task: "Fix performance issues"
Good task: "Add database index on user_id column in orders table"
The difference: good tasks have a clear finish line. You know when you're done. You can estimate how long it'll take. You can verify it works.
Big ambiguous tasks sit in "in progress" forever, accumulating guilt. Small clear tasks flow. Pick one up, do it, move on. The momentum compounds.
My rule: if a task will take more than an hour, it's probably multiple tasks. Break it down.
Tools: Jira Integration
I manage everything through Jira, but not through the Jira UI.
The CLI is the interface. task list, task start TASK-123, task done. No context switching to a browser, no clicking through menus. Everything happens from the terminal where I'm already working.
Jira becomes a state machine:
- To Do → tasks ready to pick up
- In Progress → actively being worked (max 3)
- Done → shipped and verified
The heartbeat queries Jira automatically. When I complete a task, the CLI transitions it and the next one gets surfaced. The system stays synchronized without manual effort.
Automation handles the ceremony: transitions, comments, time tracking. I just do the work.
CLI Automation
Repetitive sequences become commands.
Instead of:
git add .
git commit -m "fix: update config"
git push
# wait for CI
# open PR
# merge
It's:
ship "fix: update config"
One command handles: commit, push, wait for CI, create PR if needed, merge, deploy. Every saved keystroke is saved context switching. Every automated step is one less thing to forget.
I have scripts for:
- Starting tasks (transition Jira + create branch)
- Finishing tasks (commit + push + transition + verify deployment)
- Checking status (current tasks + blockers + queue depth)
- Generating reports (what shipped today + what's next)
The goal: reduce the gap between "I finished the work" and "it's deployed and tracked" to seconds.
The Practical Result
With this system, 10+ tasks per day isn't aspirational. It's mechanical.
- 3 parallel tasks running
- Heartbeat keeping them synchronized
- Queue full of ready work
- Tasks small enough to finish in one sitting
- CLI automation eliminating ceremony
The cognitive load stays low. The throughput stays high. Bad days still hit 8-10 tasks. Good days exceed 30.
The system doesn't require motivation. It requires maintenance: keeping the queue full, keeping tasks small, keeping the tools sharp. Do that, and shipping becomes automatic.
This is my current approach. It'll evolve. But the principles—parallelism, monitoring, queue management, small tasks, automation—those stay.