
Noise is mostly other people’s urgency.
Very little of what arrives in a day is genuinely time-critical. It is someone else’s deadline arriving in your inbox with their pacing attached. The discipline is not ignoring it; it is deciding when it gets handled rather than letting the sender decide.
Protect the block, not the day.
Trying to protect whole days fails on contact with reality. Three uninterrupted hours, defended properly, produces more than a nominally clear day interrupted eight times. Everything that needs real thought goes in that block; everything else fills the space around it.
Decide once, not repeatedly.
Most exhaustion comes from re-litigating settled questions — which tool, which format, which shape of meeting. Write the decision down, then stop revisiting it until something material changes. The written version also survives handover, which the version in your head does not.
Finish things.
Half-built work occupies attention at a low level, permanently. Shipping something small and closing it out frees more capacity than starting something promising. A quarter with four finished things beats one with nine in flight.
A triage routine for other people’s urgency
Deciding when something gets handled needs a rule you can apply without thinking. We sort incoming items into a few piles at set points in the day, rather than as each one arrives. The sort itself should be quick; the value is that nothing gets answered simply because it was the loudest thing in the room.
Tell people what the piles are and when you sort them. Colleagues who know that a blocked question gets an answer the same day have less reason to chase it across email, chat and the corridor. That is the aim: fewer repeat messages, without asking anyone to send less.
- Now: a customer is affected, or money or safety is at risk
- Today: a colleague is blocked until you answer
- Scheduled: real work with a real deadline, given a slot in the calendar
- Delegated or declined: someone else should do it, or nobody needs to
Setting up the focus block so it holds
A well-defended block has preparation before it and a landing after it. The preparation is choosing, the evening before, the work it is for, so the opening minutes are not spent deciding. The landing is a short slot afterwards for messages, so the block does not feel like a risk to the people waiting on you.
- Put it in the shared calendar with a plain name, not a vague ‘busy’
- Silence notifications on every device, not just the laptop
- Tell the team how to reach you for a genuine ‘Now’ item, and make that route slightly inconvenient
- Keep a notepad for stray thoughts so you can park them without switching windows
- If the block breaks, restart it rather than writing off the day
A decision log light enough to keep
Writing decisions down only works if the format is light enough to use in the moment. A shared document or a single spreadsheet tab will do. The most useful field is the last one below: the condition under which you would reopen the question. Without it, every passing doubt feels like a reason to revisit.
- The decision, in one sentence
- The date, and who made it
- The options considered and why this one won
- What would have to change for it to be reopened
When the question that keeps returning is technical
Some of the questions a company keeps re-arguing are technical: which tool, build or buy, whether to rewrite the old system. If one reopens with every new frustration, check whether it was ever settled with the full picture in front of whoever decided. Questions like these deserve one proper answer, written into the log with its reasoning and the condition for reopening. Among our consulting packages, the Tech Strategy Consultation takes on that kind of question: its outputs include a build-versus-buy recommendation and a sequenced roadmap, and it starts at ₹3,000.
Limiting what is in flight
Finishing gets easier when starting gets harder. Keep a visible list of work in progress and set a ceiling on it, low enough to feel uncomfortable. A new item joins only when something leaves, either finished or deliberately stopped. Stopping counts too: close a half-built idea with a note on why, so it leaves the list rather than lingering on it.
Define ‘finished’ before you start. For a feature it might be live and announced; for a hire, the offer signed; for a document, sent to the people who need it. Work without a finish line tends to stay in flight indefinitely, and it keeps drawing on attention the whole time.
Learning without losing the week
Learning competes with building for the same attention, and with no deadline of its own it is easy to postpone. Tie it to the work in front of you instead. Learn what the current project needs, apply it inside that project, and write a short note of what you would tell a colleague. The note is what turns reading into something the rest of the team can reuse.
- Keep a running list of questions the work has raised, and pick from it when a gap opens
- Prefer primary sources, such as documentation and specifications, over summaries of them
- Teach it back at a team meeting; gaps in understanding show up quickly when you explain
A reset for the weeks that feel chaotic
Some weeks the routine breaks anyway. A launch slips, a customer escalates, a hire leaves. The answer then is not a new system; it is a short reset that gets you back to the one you already have, done in this order before anything else gets your attention.
- Empty every inbox into the triage piles without answering anything yet
- Cut the in-flight list back to its ceiling by pausing items explicitly
- Book the next focus block
- Check the decision log for anything you have started re-arguing
- Pick one small thing you can finish today, and finish it
MAKIN