A work journal is a running record of what you did, what you decided, and what you learned. It is the least fashionable productivity practice there is — no app required, no system to configure — and it repays the effort more reliably than most of the systems that replaced it. Five minutes a day produces something you will be grateful for at your performance review, during a handover, and the third time you solve the same problem.
What it is for
Four concrete returns, all of which arrive later than the effort.
Recall. "What did I actually do in April?" is unanswerable from memory and trivially answerable from a journal. This matters at review time, when writing a status update, when someone asks why a decision was made, and when a client queries an invoice from four months ago.
Thinking. Writing forces you to articulate a problem, and articulating it frequently solves it. The practice of writing down what you are stuck on, before asking anyone, resolves a meaningful fraction of the questions you would otherwise have asked.
Continuity. Coming back on Monday, or after two weeks' leave, to a note saying where you were and what you intended next is far faster than reconstructing it. This is the return you feel most often.
Evidence. Promotion cases, appraisals, project retrospectives and occasionally disputes all require specifics. "I improved onboarding" is weak; "reduced onboarding setup from three days to four hours in March, documented in the runbook" is not, and only one of them is available a year later.
What to write
The trap is treating it as a diary. It is a log, not a narrative, and it should take five minutes.
Each entry, roughly:
- What I did — specific enough to mean something later. "Reviewed the vendor responses and shortlisted two" beats "vendor work".
- What I decided, and why. This is the highest-value line in the journal and the one most often skipped. The reasoning behind a decision evaporates within weeks, and it is what everyone asks about later.
- What I learned — a fact, a command, a fix, a piece of context about a person or system.
- What is blocked, and on whom.
- What is next — one or two lines, so tomorrow starts without a warm-up.
Occasionally worth adding: numbers (before and after), names (who asked, who agreed), and links (to the document, the ticket, the message). Those three are what turn a note into evidence.
What not to write
- Not a to-do list. Tasks belong wherever you track work; a journal that becomes a task list stops being a record. See task management best practices.
- Not a performance. Written for an audience, it becomes marketing and stops being honest, which destroys the value.
- Not everything. Completeness is the enemy of the habit. Five minutes.
- Nothing you would not want read. Assume, sensibly, that anything written on a work system may be seen by your employer, and in some circumstances disclosed. Frustration with a colleague, speculation about someone's competence, and anything about a legal matter should stay out. Write facts; keep judgements about people out of the record.
Format
The best format is the one you will keep using, and simple beats sophisticated:
- A plain text or Markdown file per month, appended daily. Searchable, portable, will still open in twenty years, syncs anywhere.
- A notes app — Obsidian, Notion, Apple Notes, OneNote — if you want linking and search. See note-taking with PDFs in Notion and annotating PDFs in Obsidian for the document-adjacent uses.
- A physical notebook, if writing by hand suits you. Not searchable, and the constraint keeps entries short. Photograph pages periodically if you want a backup — scanning documents with your phone, and handwriting recognition in documents if you want them searchable.
- A repository, if you already live in one. A
journal/directory of dated Markdown files, committed daily, gives you history and backup for free.
Whatever you choose: date every entry, ISO format, and keep it in one place. 2026-08-06 at the top of each entry makes the whole thing sortable and searchable — the reasoning is in naming and versioning shared files.
Building the habit
Habits fail on trigger and duration, not on intent.
- Attach it to something that already happens. End of day, before closing the laptop. Or first thing, writing yesterday — which some people find easier because the day is complete.
- Cap it at five minutes. Set a timer if necessary. A journal that takes twenty minutes gets skipped on the days worth recording.
- Accept gaps. Missing three days is not failure; abandoning it after missing three days is. Write "gap — was in workshops" and continue.
- Lower the barrier. One keyboard shortcut, one file, always in the same place. Anything that requires navigating to a tool will not survive a busy week.
- Write badly. Fragments, no punctuation, private shorthand. It is for you.
Getting value back out
A journal nobody reads is a diary. Build in the moments where you read it:
Weekly. Skim the week when planning the next one. It surfaces what actually took time versus what you thought would, which is the most useful planning input there is. See weekly planning that actually works and the end-of-week review habit.
Monthly. Pull out the three or four things worth remembering. This is the raw material for status updates and, eventually, for a review.
Before writing an update. A status update written from a journal is specific and takes ten minutes; one written from memory is vague and takes thirty. Status updates people actually read and writing a weekly report for your manager.
Before a review. Six months of entries turn an appraisal from a memory exercise into an editing one. This is where people who keep journals notice the difference most sharply.
Before a handover. A journal is a substantial head start on a handover document: project handover documents guide.
The team version
The individual practice has an organisational counterpart. When entries about decisions and lessons are written where others can read them, the journal becomes a shared record:
- Decisions with reasoning belong in a durable log rather than a personal file: writing a decision log.
- Repeatable fixes and procedures belong in shared documentation: building a team knowledge base and writing standard operating procedures.
- Incident learning belongs in a postmortem: writing a blameless postmortem.
The journal is where these start. A weekly pass that promotes the two or three entries with wider value into the shared record is the mechanism that turns individual notes into institutional memory — and it is much easier than trying to write those documents from scratch when they are needed.
Summary
Write five minutes a day: what you did, what you decided and why, what you learned, what is blocked, what is next. Keep it dated, plain, private and short, and do not turn it into a to-do list or a performance. Read it weekly for planning, monthly for the highlights, and before any review, handover or status update — and promote the entries with wider value into the team's shared record, which is where the practice stops being personal and starts compounding.
