Skip to content

Time Management — Best Practise

Make the Pressure Commitment Loop your default for new work and deadline risk: see capacity, size the first useful outcome, set the scope boundary, state the commitment, then check it early.

The commitment card

Before you say yes, write this small card where the requester can see it:

  • Outcome: What will a user or teammate be able to do when this is done?
  • Deadline: What date or event matters, and why?
  • Must-haves: The smallest set needed for that outcome.
  • Not now: Nice-to-haves and explicitly excluded work.
  • Estimate: A range based on comparable work, plus the work's main parts.
  • Assumptions and risks: What must stay true; what could change the range.
  • Capacity: Current commitments that compete for the same time or people.
  • Decision owner: Who chooses if scope, date, or priority must change?
  • Checkpoint: The next date to check the biggest risk, before the deadline.

For Maya, the card says: manual dashboard CSV by Friday; no scheduled emails or custom columns; filter reuse is the main risk; check it Wednesday; the product owner chooses any scope change.

A repeatable weekly routine

  • At the start of the week, see capacity. List commitments, deadlines, meetings, and expected support work. Leave room for normal interruption rather than planning every hour.
  • For each new request, clarify the outcome before estimating. Ask: who needs it, what proves it works, what date matters, and what can wait?
  • Estimate the first useful version. Compare with finished work, split it into a few parts, give a range, and write the assumptions. If the unknown is large, commit first to a short discovery task, not to the whole imagined solution.
  • Protect the boundary. Put must-haves and nice-to-haves in separate lists. When a new item appears, ask what it replaces or whether the date changes; do not let it silently join the promise.
  • Answer requests with a trade-off. Use one of these forms:
  • Yes: "I can deliver outcome by date if assumption."
  • Yes, smaller: "I can deliver core outcome by date; extra follows later."
  • Yes, if we swap: "I can take this on if we move current work. Which is higher priority?"
  • Not by that date: "I cannot safely deliver this by date. I can start later, reduce it to scope, or hand it to owner."
  • Run a short checkpoint before the halfway point. Share: finished scope, remaining scope, changed assumption, and decision required. Do not wait for a perfect answer before raising a risk.
  • At the deadline, close the loop. Record actual time, final scope, and which assumption changed. Reuse that evidence for the next estimate.

Working under pressure

  • Pause before promising. A fast response can be: "I will check my commitments and reply by 2pm." This is more useful than an instant promise you will later break.
  • Make the urgent choice small. Ask for the minimum version that makes the event succeed, then put the rest in a follow-up with an owner.
  • Surface the decision, not your stress. Say "filter reuse makes Friday risky; choose simple export or move the date," not "I am overloaded."
  • Keep the release path in scope. Testing, review, monitoring, or rollback that protects the committed outcome is part of the work, not optional cleanup.
  • Escalate with options. People can help when they know the decision: remove scope, move the date, add someone, or accept the risk explicitly.

Self-check before committing

  • Can I name the outcome in user language, not only a task name?
  • Did I look at current commitments before answering?
  • Is the estimate a range with evidence and assumptions?
  • Did I separate must-haves, nice-to-haves, and out-of-scope work?
  • If I said yes, did I state the outcome, date, and conditions?
  • If I said no, did I state a clear constraint and a real alternative?
  • Is there a checkpoint before the deadline and a person who can make the trade-off?
  • Did I keep safety and correctness in the committed slice?

Signs the habit is working

  • New requests lead to visible priority choices instead of private overtime.
  • Your updates describe a finished or at-risk outcome, not just a list of busy tasks.
  • Scope changes come with a decision about date, priority, or help.
  • Your estimates become easier to explain because they start from past work and recorded assumptions.