01The problem
Some work is easy to see. A ticket closes. A dashboard ships. A bug disappears.
Other work is quieter. You clarify a vague problem. You draw the first useful architecture. You turn a messy idea into a prototype. You explain the same concept to three teams until the organization finally has language for it.
That kind of work matters, but it evaporates fast. It lives in calls, chat threads, whiteboards, demos, half remembered decisions, and someone's head. A month later people remember that progress happened, but not what changed or why.
Evidence-based work is a practical answer to that. It does not mean turning every action into a report. It means important work should leave enough trace that future you, your team, or your manager can reconstruct the value.
02The method
The method is simple: after meaningful work, capture the smallest useful record of what happened.
Not a novel. Not corporate theater. Just enough to answer five questions:
- What was the situation?
- Which trade-offs mattered?
- What did we design, build, decide, or test?
- What happened as a result?
- What can be reused next time?
This is especially useful in roles where the job is partly to create shape: solution architecture, data work, consulting, product discovery, AI enablement, internal tooling, platform work, and technical leadership.
03The five pieces of evidence
Context
The situation, question, constraint, or confusion that made the work necessary.
Trade-off
The options that were considered, including the direction you deliberately did not take.
Design
The model, flow, interface, prototype, standard, or plan that made the work concrete.
Result
The demo, decision, feedback, changed behavior, delivery outcome, or next step.
Reusable lesson
The pattern, checklist, anti-pattern, or question that should be carried into future work.
Links
The artifacts that prove it happened: diagrams, decks, docs, repos, tickets, recordings, or decisions.
The last box is deliberately boring. Links matter. A beautiful explanation without a path back to the actual artifact becomes another memory game.
04A one-page template
This is usually enough:
# [Topic] evidence note ## Context What was the question, situation, or trigger? ## Trade-off Which options, constraints, or risks mattered? ## Design or approach What was proposed, designed, tested, or built? ## Result What changed? Demo, decision, feedback, output, next step? ## Reusable What should we reuse next time? ## Links Diagrams, docs, tickets, repos, decks, demos, decisions.
If it needs more than one page, fine. If it needs less, also fine. The point is not length. The point is that the work becomes findable and defensible.
05The habit
I like the rhythm of a small weekly loop.
- Write short evidence notes for important design, discovery, prototype, and knowledge-sharing work.
- End each note with one reusable lesson.
- Once a week, pick the strongest notes and link them together.
- Once a month, turn the best notes into a small portfolio of impact.
This makes performance conversations less vague. Instead of saying "I picked up a lot of things", you can point to designs, decisions, prototypes, sessions, standards, and lessons that other people can use.
06The boundary
The danger is obvious: evidence-based work can become documentation cosplay.
That kills the point. Small tasks do not need ceremony. Random opinions do not need a record. Meeting notes without a decision do not automatically deserve to live forever.
If you will need to explain it, defend it, reuse it, hand it over, or scale it, capture it. If not, keep moving.
Done well, evidence-based work is not bureaucracy. It is professional memory. It lets good work survive the meeting where it first appeared.