How to Document Your Work Without Writing Anything

Somewhere in your email archive is the nicest thing a VP has ever said about your work. You read it twice, felt good for an hour, and archived it. At your next review you will try to paraphrase it from memory, and it will come out as “I got some good feedback this quarter.” You do not need another daily-writing system to fix that. Selected connected activity can arrive automatically; email can be forwarded; screenshots, links, PDFs, and files can be shared in seconds. Write only when the meaning exists nowhere else.

Your evidence already exists. You're just not keeping it

Think about the last piece of praise you received at work. It probably arrived as an email or a chat message. Where is it now? For most people: archived, scrolled away, gone. The same is true of the metrics dashboard the day your launch landed, the customer thank-you, the announcement that the thing you built shipped. The proof existed for a moment, on a screen, and nobody kept it.

• Praise emails and kudos messages — written by someone else, dated, specific, and more credible in a review than anything you could write about yourself.
• Screenshots — the dashboard at 68% activation, the incident channel after you closed it, the before/after of a redesign.
• Links — the merged PR, the shipped doc, the launch post, the press mention.
• PDFs and decks — the strategy one-pager that got adopted, the QBR deck you carried.

None of this required writing. All of it is evidence. The gap is not documentation skill: this material has no home, so it dies wherever it first appeared.

Let connected activity preserve the first draft

GitHub and Google Drive already know that work moved. With read-only Connected Work, selected activity attributable to you can become a private artifact under the Role you choose. A GitHub pull request, review, or attributable issue closure can preserve the event and its source. A Drive creation, edit, rename, move, comment, permission change, or restore can preserve activity metadata without opening the document itself.

This is not the same as letting an app inspect everything. You choose the repositories, files, folders, or shared drives Bloomly should use, or intentionally enable all available resources under one Role. GitHub access does not read source code or diff patches. Drive access does not read file contents. Each selected resource maps to a Role so a startup repository does not quietly become day-job evidence.

• GitHub preserves attributable pull requests, reviews, and issue closures, with bounded PR context rather than repository code.
• Google Drive preserves names, types, timestamps, descriptions, locations, and actions attributable to you, not the document body.
• The resulting artifact carries source attribution, a date, and Role context before review season asks you to remember it.

The forwarding habit

The lowest-effort version of work documentation is forwarding an email. When praise, a kudos, a shipped announcement, or a customer thank-you lands in your inbox, forward it to wherever your work record lives: a dedicated folder at minimum, a career journal with an inbound address if you have one. The whole action takes about four seconds, and the result is a dated, attributed piece of evidence written by someone other than you.

One rule decides what to forward: if it would feel good to re-read in December, forward it now. Don't evaluate whether it is 'big enough.' Recognition at work is rare enough that almost none of it should be allowed to evaporate, and the sizing judgment is exactly the friction that kills the habit.

The share-sheet habit

The second reflex covers everything that is not an email: the moment proof of your work is on your screen, capture it from where you are standing. On a phone, that is the share sheet — send the screenshot, the link, or the PDF to your record in two taps without leaving the app you are in. The trigger moment matters more than the tool: capture happens when the artifact is in front of you, or it does not happen at all.

• Metric moments — screenshot the dashboard the day the number peaks. A dated screenshot beats a remembered number every time.
• Shipped moments — share the link the day it goes live, while it is still on your screen.
• Said-about-you moments — screenshot chat praise the moment it appears. Chat scrolls away faster than email.

A source-by-source system with almost no composition

The strongest setup uses the capture path that already matches the evidence. Do not copy a pull-request title into a note, download a Drive file just to upload it somewhere else, or rewrite a praise email in your own words. Preserve the original source through the shortest available route, then add context only when the source cannot carry it.

• GitHub: connect the repositories you want, map each one to a Role, and let attributable pull requests, reviews, and issue closures create the initial artifact. Add a separate entry only for missing judgment or outcomes.
• Google Drive: select the files, folders, or shared drives that belong to the Role. Attributable creation, editing, renaming, moving, commenting, permission changes, and restores can become evidence without reading the file body.
• Email: forward the single message that contains the praise, decision, or launch confirmation to your personal @in.bloomly.cc address. Keep the sender and date instead of paraphrasing them.
• Screenshots, links, PDFs, and files: share them from the app where they already exist. Use web upload when the source is on a computer rather than your phone.
• Text or voice: use an entry for the sentence no artifact can supply — why the project was hard, what you decided, who you aligned, or what you learned.

A weekly review then becomes quality control instead of data entry. Check whether the Role is correct, ignore low-signal artifacts, and add the result when it arrives after the original event. A pull request merged on Monday may not show customer impact until Friday; the source artifact preserves Monday, and a short outcome update preserves Friday.

This system also creates a better privacy habit. You decide which connected resources are in scope, which email to forward, and which file to share. Evidence does not need to become less private merely because capture is easier. Keep proprietary details inside the private record, use employer-approved metrics, and disconnect a provider whenever the boundary no longer fits.

What counts as an artifact

In Bloomly, an artifact is a private evidence record created from connected activity, a forwarded email, a shared screenshot or link, a PDF or file, or a web upload. It preserves where the evidence came from and summarizes what the source can support. Entries are separate: they come from text or voice and capture the reasoning or reflection that exists only in your head. Useful source material by Role includes:

• Engineer — the merged PR link, the incident postmortem, the latency graph before and after, the design doc that got adopted.
• Product manager — the launch email, the activation dashboard, the pricing decision one-pager, the customer quote.
• Designer — before/after frames, the usability-test highlight clip, the handoff file, the praise from engineering.
• Manager — peer feedback about your reports, the hiring confirmation, the calibration outcome, the team health survey delta.
• Sales and customer-facing — the closed-won notification, the customer renewal email, the deal recap, the QBR deck.

From pile to proof

A folder of screenshots is a heap, not a record. Three things turn captured material into usable evidence: a date, a clear summary of what it shows, and a home next to the rest of your work record. Eleven months from now, 'Screenshot 2025-06-11 at 9.41.12 AM.png' tells you nothing; 'VP praise — Q2 launch coordination' is a line item in a promotion case.

This is also where memory research is unkind: the context around an artifact (what the number meant, why the praise was earned) decays on the same forgetting curve as everything else. Summarize at capture time, or accept that future-you will hold a screenshot they can no longer explain. If a tool does the summarizing for you, the system gets cheaper still; if not, one typed line at capture time is the entire cost.

When you should still write

Artifacts hold the proof. They do not hold the reasoning. A screenshot of a dashboard cannot explain the decision that moved the number, what you tried first, or what you would do differently. Those are exactly the things interviews and self-reviews ask about, and three written lines on a hard decision still beat any artifact of its outcome.

The honest framing: connected activity, forwarding, and sharing are the low-friction layer, not the whole story. They survive the months when you will not write — busy quarters, bad stretches, new jobs. Let artifacts preserve the evidence. Add an entry when the source cannot explain the choice, lesson, or human work behind it.

Common pitfalls

• Saving everything — a record of two hundred undifferentiated screenshots is a second inbox. Forward what would feel good to re-read; skip the rest.
• Captures without summaries — an unlabeled screenshot is a memory test you will fail in December.
• Scattered homes — camera roll plus email folder plus bookmarks equals three places to forget. Evidence needs one address.
• Keeping praise only in your head — 'my manager said good things' is not evidence. The message is. Keep the message.
• Waiting for big evidence — the quiet artifacts (a stabilized system, a mentored teammate's first win, an adopted process) are the ones that vanish, and the ones reviews undervalue when you cannot show them.

You do not need to narrate every workday to have a useful record. Connect the sources you trust, forward the evidence that arrives in email, and share the proof already on your screen. Write or speak only when the decision, constraint, or lesson lives in your head. The work created most of the evidence. Your system keeps it, your Role protects the boundary, and your context makes it useful when review season arrives.