Stop Re-Solving the Same Work: Use a Personal Decision Log

A task list tells you what still needs doing. A decision log tells you why you are doing it this way.

That distinction matters when your work contains recurring judgment calls: which stakeholder to involve, which source counts as current, how much review a draft needs, what qualifies as an exception, or when to stop investigating and make a recommendation. If you do not record those choices, the next similar task starts with a search through old messages, files, and your own memory. The work may be familiar, yet it still feels new.

A personal decision log is a lightweight record of choices that are likely to be revisited. It is not a diary, a project-management system, or a running archive of every action. Its job is narrower: preserve the context that would otherwise disappear between interruptions, changing priorities, and repeat assignments.

This is a form of cognitive offloading: using an external record rather than relying entirely on memory. Research on reminders and other external aids examines how people move intended actions and supporting information into their environment; the useful workplace lesson is to record the information your future self would otherwise have to reconstruct. Research on cognitive offloading and prospective memory also points to an important boundary: an aid works only if you can find and use it when the moment arrives.

Choose decisions worth recording

The first mistake is logging too much. Recording every small choice turns a helpful system into another administrative task. Start with decisions that have a reasonable chance of creating repeated work if their reasoning disappears.

For an individual contributor, that usually means one of four things:

• a choice you expect to make again within the next few months;
• a choice another person may question, inherit, or need to approve later;
• a choice based on constraints that may not be visible in the finished work; or
• a choice that would be expensive to reverse because it changes a workflow, audience expectation, or source of record.

Consider an operations analyst preparing a monthly report. They discover that two internal systems show different customer counts. After checking the reporting calendar and speaking with the data owner, they use the billing system for the executive report because its figures align with the period used for finance. The report itself may show only one number. Without a note, next month’s analyst—or the same analyst after a busy week—has to reopen the entire question.

The log entry is not “finished monthly report.” It is “used billing-system count for executive report because the reporting period must match finance; revisit if the finance calendar changes.” That is a decision with context and an expiration condition.

Use a threshold before you write

Ask one question at the end of a piece of work: “If this comes up again after I have forgotten the details, would I need more than five minutes to explain the choice?” If the answer is yes, write a record. If the decision is consequential for others, write it even when you personally expect to remember it.

This threshold keeps the habit proportionate. You are preserving costly reasoning, not proving that every hour of your day was justified.

1. Record choices that would take more than five minutes to reconstruct later.
2. Include exceptions to a normal process when they affect the next person’s action.
3. Skip routine actions that are already covered by a stable checklist or reference guide.
4. Write a shared record when the decision changes how colleagues should work.

Write the minimum context needed to restart

Borrow a simple structure from decision records used in technical work: capture the context, the decision, and the consequences. The UK Department for Education describes lightweight decision records in those same terms, because a later reader needs to understand what was decided, why, and what follows from it. Its guidance on architecture documentation is aimed at systems work, but the structure transfers well to recurring knowledge work.

Keep each entry short enough to write before you lose the thread. Four fields are usually sufficient:

1. Decision: State the choice in plain language.
2. Context: Name the trigger, the relevant constraint, and the information checked.
3. Consequence: Say what this enables, excludes, delays, or changes.
4. Review signal: Note the event that should cause reconsideration, if one exists.

Do not begin with a long account of every meeting or every option. A decision log is useful because it compresses the path to the next action. If the detail is already documented elsewhere, link or name that location in your note rather than copying it.

This format also distinguishes a decision from an assumption. “The regional lead will approve the wording” is an assumption until confirmed. “The regional lead confirmed the wording; legal review remains required” is a recordable decision state. Mixing the two creates confusion when work changes hands.

Put the record beside the work it governs

A decision note hidden in a private notebook creates a second search problem. Put it where you will look when the work restarts: in the project folder, at the top of the recurring brief, in a shared knowledge page, or in the relevant ticket. The correct location depends on who needs the context.

Use a private log for personal working choices, such as the sequence you use to reconcile a recurring report. Use a shared location when the decision changes what colleagues should do, where they should find an answer, or which version of a process remains active. A decision that affects a team but lives only in one person’s notes is still fragile.

There is a further location rule: keep the note close to the source material, but do not place sensitive details in a broadly accessible page just for convenience. A short entry can point to the approved restricted location when the underlying evidence contains private information.

Public-sector guidance on decision records makes the same practical point: preserve the reasoning with the documentation it affects, so people can assess earlier choices when circumstances change. The UK Government Digital Service guidance specifically recommends recording context and consequences rather than leaving later teams to infer them.

Use the log to recover after interruptions

Interruptions do not merely consume the minutes spent answering a message. They also leave you with an unfinished mental model: what you had checked, what remained uncertain, and which choice was pending. Experimental work on interruptions shows that resuming performance depends heavily on the specific task being interrupted, which is one reason a generic reminder such as “finish analysis” rarely restores useful context. Research on training to reduce interruption effects supports the practical idea of creating task-specific cues for return.

Before you switch away from a task that requires judgment, write a restart line. It can be one sentence: “Next: compare the April exception list with the new eligibility rule; do not send the summary until the policy owner confirms whether contractors are included.” This is not a completed decision record yet. It is a temporary marker that helps you resume without replaying the entire task.

When the choice is made, convert the restart line into a durable entry if it passes your threshold. If the issue proved routine, delete the marker. This two-stage approach prevents abandoned half-thoughts from turning into permanent documentation.

Review only when a signal says the decision may be stale

Decision logs fail when they become a museum of old choices. You do not need a weekly review of every entry. Instead, give each substantial decision a review signal: a date, a policy change, a new stakeholder, a tool migration, a recurring cycle, or evidence that the original constraint no longer applies.

For example, a content specialist may decide to collect approvals in a document rather than email because a campaign involves six regional reviewers. The record should say when to reconsider: after the campaign, if the reviewer group changes, or if the approval sequence causes delays. It should not say “permanent process” after one unusually complicated project.

Your log should also record reversibility. A reversible choice can be tested and adjusted. An expensive-to-reverse choice needs clearer context before you act. This is especially useful where work systems intersect: changing a file naming convention is easy to undo; changing a field definition used across reports creates downstream confusion unless the record explains ownership and impact.

Keep ownership visible

A decision note cannot assign authority you do not have. If a manager, data owner, or policy owner made the call, say so. Your entry can state what you are responsible for next and what remains outside your control. This prevents a useful record from becoming an accidental claim that you approved a decision on someone else’s behalf.

Use names where the note is shared and the work requires a contact. Use roles where the record may last longer than the current assignment. “Confirm with the payroll-data owner” remains understandable after a reorganization; “ask Maya” may not.

• Give each consequential entry a date, event, or owner change that triggers review.
• Mark whether the choice is easy or expensive to reverse.
• Replace repeated decision entries with a maintained instruction when the rule has become stable.
• Archive or label superseded decisions so old reasoning is not mistaken for current practice.

Start with one recurring source of rework

Do not build a new workspace, template library, or elaborate taxonomy on day one. Pick one recurring task that regularly makes you search old messages or wonder why you made a previous choice. Create a single running document or page called “Decisions and restart notes” beside that work.

For two weeks, add an entry only when one of these happens: you choose between plausible options, accept a constraint, make an exception, or stop an investigation because the available evidence is sufficient. At the end, read the entries once. If several are asking the same question, promote the answer into a checklist or team guide. A decision log is not the final home for stable instructions; it is often the evidence that shows a stable instruction is needed.

Try one small action today: before closing your next interrupted task, write one sentence that begins, “The next person needs to know that…” If the sentence changes how the work should resume, save it beside the task.