Time Management
What it is
Time management is estimating how long work takes, choosing what to do first against a stated priority, and protecting blocks of uninterrupted time for work that needs concentration. The artefact is a plan you can compare against what actually happened.
Why it matters
Technical work is not interchangeable per hour. A meeting interrupts a debugging session in a way that costs the twenty minutes of re-establishing context as well as the meeting itself, which is why a fragmented day produces far less than the sum of its free hours. The other half is estimation: without recorded estimates, a team cannot tell a slow week from a wrong estimate, and the same over-commitment repeats. Both halves are learnable habits with numbers attached.
Core ideas
Estimate in blocks, then compare
Give each task a rough size — half a day, a day, three days — and record what it actually took. The correction factor for your own estimates appears within a few weeks and is usually stable.
Estimated 1d -> actual 2d (unknown library)
Estimated 1d -> actual 1d
Estimated 3d -> actual 4.5d (integration surprises)
Pattern: multiply by 1.5, and never plan a day full of 1d items
Protect blocks, not minutes
Two or three uninterrupted blocks of ninety minutes beat a day of fifteen-minute gaps. Put them in the calendar as appointments and defend them like meetings.
Batch the shallow work
Email, messages, reviews and small questions are real work but they fragment attention. Give them two or three fixed windows a day and stay out of the inbox between them.
Make notifications default to off, and pull on a schedule
A notification is someone else choosing your attention. Turn off everything that is not a genuine page, and check the channels at your own cadence.
Say no with a trade, not a refusal
“I can do that this week if the migration slips” puts the decision where it belongs and keeps the relationship. A bare no invites escalation; a trade invites prioritisation.
Leave slack, and treat it as part of the plan
A day planned at a hundred per cent has no capacity for an incident, and incidents are certain. Plan four fifths of the available time and the schedule survives contact.
Practice
Track estimates against actuals for five tasks
For five tasks, write the estimate before starting, then the actual, then the ratio.
Done when: you have an average ratio for your own estimates and have applied it to the next plan you wrote.
Defend one two-hour block for a week
Book one two-hour block each day for five days, with notifications off and a single task named in advance.
Done when: at least four of the five blocks happened, and you can name what you finished in them.
Common mistakes
- Planning a day full of one-day items — one surprise destroys the plan; fix: plan four fifths of the time and keep a correction factor.
- Notification-driven work — someone else chooses your attention all day; fix: batch the shallow channels into fixed windows.
- Refusing without a trade — the request escalates instead of being prioritised; fix: offer the exchange explicitly.
- No uninterrupted block — concentrated work never gets a chance to start; fix: book blocks in advance and defend them.
- Estimates never compared to actuals — the same over-commitment repeats; fix: record both and compute your own ratio.
Go deeper
- Problem Solving (08-soft-skills/04-problem-solving) — what the protected block is for.
- Teamwork & Collaboration (08-soft-skills/02-teamwork-collaboration) — the interruptions that fragment a day, and how to reduce them.
- Scrum (Software Development) (04-product-process/10-scrum-software-development) — where estimates and forecasts are used by a team.
- Estimation & Story Points (04-product-process/17-estimation-story-points) — relative sizing at team scale.