Time Management
Why Code and Meetings Should Never Share a Task
Code vs meetings time tracking is the split most consultants skip because it feels fussy. You already know you were “on the website.” The standup, the Slack huddle, the PR, and the actual implementation all happened for the same client, so they land on the same task. That is how a six-hour build quietly becomes a ten-hour blob, and how your next quote inherits a lie.
The job is not more timesheet rows for their own sake. The job is to see, by Thursday, whether the money hours were implementation or conversation. If those two share a name, you will only find out at invoice time — which is too late to course-correct, and too late to explain.
A simple rule: if a client would be surprised to see it on the same line item as “wrote the feature,” it is a different task. Meetings, reviews, and support are real work. They are not secretly implementation.
What goes wrong when everything is “Website Redesign”
A flat dump of hours is easy to start and impossible to learn from. You finish a week with 32 hours on one task. Was that a slow codebase, a talkative stakeholder, or three unplanned triage calls? You cannot tell, so you do the human thing: you guess, then you either underbill the talking or you feel guilty about the coding.
Estimates vs actuals fall apart in the same place. You quoted eight hours of implementation. You tracked fourteen because two hours of daily standup and four hours of “quick syncs” lived on the implementation task. Next time you pad the quote instead of naming the meeting. Clients hear padding. You hear self-defense. Nobody gets a cleaner scope. We already unpacked that failure mode when meetings live on the Implementation task. This post is the catalog you can copy so it does not happen again.
The same smear shows up in billable units clients can actually read. “Website Redesign — 32 hours” is a number. “Implementation 18, Meetings 6, Code review 4, Support 4” is a conversation you can have without sounding evasive.
A task taxonomy that survives an invoice
You do not need twenty statuses. You need a short, boring list you reuse on every client. Time belongs on a task, so the names have to be the units you are willing to defend.
Copy this set, then stop inventing
- Discovery. Interviews, audits, reading the last vendor’s mess. Often unpaid or capped — name it anyway.
- Architecture. Spikes, ADRs, “how should this talk to billing.” Not the same as typing the feature.
- Implementation. The code, the query, the screen. Protect this name like a budget.
- Code review / QA. Reading diffs, fixing CI, clicking through staging. If it is not creating the feature, it is not Implementation.
- Meetings. Standups, workshops, “can you hop on?” If people were talking, it lives here.
- Support. Production fires and “quick looks” after launch.
- Internal / admin / sales. Your overhead. Track it so your sticker rate stops lying. Do not put it on the client’s implementation line.
Subtasks are for slices inside a name — “Homepage mockups,” “Checkout API” — not a way to hide meetings under Implementation.
How to switch without running three clocks
The fear is friction: if Meetings and Implementation are different tasks, you will forget to switch when a huddle starts. That is a real failure mode. The answer is not one blob task. The answer is a switch that is cheaper than honesty-after-the-fact.
Keep both tasks under the same client and project so you are not hunting a tree. When a meeting starts, stop the implementation timer and start Meetings. When it ends, switch back. If you only remember at 5 p.m., log the forgotten meeting as its own entry instead of stretching the implementation block. Reconstructing is allowed. Smearing is what ruins the dataset.
Context switching is already expensive. A shared task does not reduce the switches. It only deletes the evidence. If your day is four clients before lunch, the taxonomy still holds: each client gets Implementation vs Meetings, not one “busy” bucket for the whole morning.
What to show a client vs what you keep for yourself
Not every internal name belongs on a PDF. Some clients want phase totals. Some want dates. Some want “development” and will bristle at “standup.” You can still track Meetings even if the invoice groups by project. The report is a What × Who × When generate step. Pivot by task when you are thinking; pivot by project or client when you are billing, if that is the agreement.
The private win is the weekly look. If Meetings ate nine hours and Implementation ate eleven, you do not have an estimate problem. You have a meeting problem — or you are underquoting facilitation. Either way, you can say so with a straight face. If those nine hours are invisible, you will “just work faster” next sprint, which is how burnout dresses up as professionalism.
Hourly work should show the split. Fixed-price work needs the split even more, because the overrun will otherwise get blamed on “the code was hard.” Maybe it was. Maybe the steering committee met twice a week. You cannot renegotiate what you cannot name. Reports are how you look; the taxonomy is how the look means anything.
A one-week experiment
Pick one active project. Create Meetings and Implementation as sibling tasks if they do not exist. Do not rename the last three months of history. Just run the split forward for five days. On Friday, generate one report for that project and pivot by task. You are looking for a ratio, not a confession.
- If Meetings is under 15% and the project is healthy, your blob task was probably fine — keep the split anyway for the next quote.
- If Meetings is over a third, the next conversation is scope of facilitation, not typing speed.
- If Code review / QA is quietly huge, that is a staffing or quality-bar issue, not “implementation ran long.”
Stop when the names are stable. A taxonomy you change every Monday is just another blob.
Where MinuteShark fits (without turning this into a tour)
If you want the hierarchy to match the taxonomy — client, project, then those task names, with time on the task — MinuteShark is built that way on purpose. Start the timer from dashboard search. If you forget the huddle, log it in plain English and confirm the card before it writes. Do not merge the meeting back into Implementation to make the day look tidy.
Getting started is still the same four steps: client, project, task, start. The only change this article asks for is which tasks you bother to create. Reports can then tell you what the week actually was, instead of what the blob implied.