Why Decompose Tasks?

Complex tasks are hard:

Easy to miss steps

Hard to track progress

Overwhelming to start

Easy to get lost

Breaking them down helps:

Clearer path forward

Visible progress

Easier to parallelize

Better estimates

The Decomposition Process

1. Understand the Goal

Before breaking down, understand:

What's the final deliverable?

What does success look like?

Who is it for?

What constraints exist?

2. Identify Major Phases

Big chunks first:

Project: Build API Integration

Phases:
1. Research the API
2. Design the integration
3. Implement core functionality
4. Add error handling
5. Test thoroughly
6. Document

3. Break Phases Into Tasks

Each phase becomes tasks:

Phase 1: Research the API
- Read API documentation
- Test endpoints manually
- Identify authentication method
- Note rate limits
- Document data formats

4. Identify Dependencies

What needs what:

- Implementation needs research complete
- Testing needs implementation complete
- Documentation can start after research

5. Estimate Effort

Rough sizing:

Research: 1 hour
Design: 30 minutes
Implementation: 2 hours
Error handling: 1 hour
Testing: 1 hour
Documentation: 30 minutes

Decomposition Patterns

Functional Decomposition

By what it does:

User Registration:
- Validate input
- Check email uniqueness
- Hash password
- Create database record
- Send welcome email
- Return response

Sequential Decomposition

By order:

Data Pipeline:
1. Fetch raw data
2. Clean and validate
3. Transform format
4. Enrich with metadata
5. Store in database
6. Update indexes

Layer Decomposition

By system layer:

Feature: User Profile
- Frontend: Profile component
- API: Profile endpoints
- Database: Profile schema
- Integration: Avatar service

Parallel Decomposition

What can run together:

Research Phase:
- [parallel] Research API A
- [parallel] Research API B
- [parallel] Research API C
- [sequential] Compare and decide

Task Sizing

Too Big

❌ "Build the entire application"

No clear next action.

Too Small

❌ "Type the letter 'H'"

Micro-management, overhead.

Just Right

✅ "Implement user authentication endpoint"

Clear, actionable, completable.

Rule of Thumb

Tasks should be:

Completable in one focused session

Describable in one sentence

Clearly done or not done

Tracking Progress

Simple Checklist

## Project: API Integration

### Phase 1: Research
- [x] Read documentation
- [x] Test endpoints
- [ ] Document findings

### Phase 2: Implementation
- [ ] Setup project
- [ ] Implement auth
- [ ] Implement core endpoints

Status Updates

## Status: 2025-02-01

Completed:
- API research
- Initial design

In Progress:
- Core implementation (60%)

Blocked:
- None

Next:
- Finish implementation
- Begin testing

Handling Complexity

When Task Is Too Vague

Ask clarifying questions:

What specifically needs to happen?

What's the expected output?

What are the constraints?

When Dependencies Are Unclear

Map them explicitly:

A → B → D
    ↓
    C → E

When Estimation Is Hard

Break smaller until estimable:

"Implement feature X" - No idea how long

Break down:
- Research approach: 30min
- Setup: 15min
- Core logic: 1hr
- Edge cases: 30min
- Tests: 30min

Total: ~3 hours

When Scope Creeps

Track against original plan:

Original: A, B, C
Added: D, E
Removed: (none)
Impact: +2 hours

Discuss: Should we defer D, E?

Communication

Starting Work

"Breaking this into steps:
1. [step 1]
2. [step 2]
3. [step 3]

Starting with step 1 now."

Progress Updates

"Progress update:
✓ Completed: steps 1-3
→ Current: step 4 (designing solution)
○ Remaining: steps 5-6

ETA: ~1 hour for remainder"

Completion

"Task complete:
- Deliverable: [what was produced]
- Location: [where to find it]
- Notes: [anything important]"

Common Mistakes

Not Decomposing

❌ "I'll just figure it out as I go"
→ Gets lost, misses requirements

Over-Decomposing

❌ 50 micro-tasks for simple feature
→ Overhead exceeds value

Ignoring Dependencies

❌ Start task C when B isn't done
→ Blocked, wasted work

Forgetting the Goal

❌ Completing tasks that don't serve the goal
→ Busy but not productive

Practical Example

Request

"Build a weather notification system"

Decomposition

## Weather Notification System

### Phase 1: Design (30 min)
- [ ] Define requirements
- [ ] Choose weather API
- [ ] Design notification logic

### Phase 2: Core Implementation (2 hrs)
- [ ] Weather API integration
- [ ] Notification trigger logic
- [ ] Message formatting

### Phase 3: Delivery (1 hr)
- [ ] Notification channel integration
- [ ] Scheduling system

### Phase 4: Polish (1 hr)
- [ ] Error handling
- [ ] Testing
- [ ] Documentation

Total: ~4.5 hours
Dependencies: Phase 1 before 2, 2 before 3
Parallelizable: None (sequential)

Conclusion

Decomposition turns overwhelming into achievable:

Understand the goal

Break into phases

Break into tasks

Identify dependencies

Execute and track

The skill improves with practice. Start with any complex task and break it down.

Next: Project Management Basics - Managing larger work