If There's No Artifact, It Didn't Happen

There’s a promotion case I think about sometimes. Strong engineer, genuinely good work, the kind of person who always knew what was happening across the systems they owned. When it came time to build the promo doc, their manager sat down with them and asked: “What did you do this year?”

They had answers. Plenty of them. But almost none of it was documented anywhere.

The work had happened. The impact was real. There just wasn’t any evidence.

The promo didn’t go through that cycle.

The Invisible Work Problem

Engineering culture has a strange relationship with documentation. We document code, systems, APIs, incidents. But we don’t document careers.

Most engineers assume their work is visible because the work exists. The systems are running. The deploy went out. The incident got resolved. Of course everyone knows about it.

They don’t.

Your manager has eight other direct reports. Your skip-level has forty engineers in their organization. The promotion committee reviewing your case has never worked with you directly. They will evaluate you entirely on what’s written down.

If there’s no artifact, it didn’t happen.

That’s not a cynical take on corporate politics. It’s just how promotion decisions work at any company with more than a few dozen engineers. The people making the call can only evaluate evidence they can see.

What I Watched Happen at Facebook

At Facebook, promotion cycles came around twice a year. The engineers who got promoted consistently weren’t always the ones doing the most impressive work in absolute terms. They were the ones whose work was easiest to evaluate.

There’s a real difference between those two things.

The strongest promo packets I reviewed had something in common: you could follow a thread from “here’s the problem” to “here’s what I built or decided” to “here’s what changed as a result.” The evidence was already there because the engineer had been creating it throughout the year, not reconstructing it from memory six weeks before the deadline.

The weakest ones were reconstructions. An engineer trying to reverse-engineer their own impact from deploys and calendar entries and vague recollections. The work had often been good. But a reconstruction reads like a reconstruction. It lacks specificity. The numbers are approximate. The narrative feels assembled rather than observed.

Promotion committees can tell the difference.

The Artifact Mindset

What changes when you think about your work in terms of artifacts?

An artifact is anything that creates a durable, retrievable record of something you did, decided, or influenced. It doesn’t have to be formal. It doesn’t have to be long. It just has to exist somewhere other than your memory.

Some examples:

A design doc you wrote before starting a project. Even a short one. Even an internal wiki page that says “we’re doing X instead of Y because Z.” That doc exists. It has a timestamp. It shows your thinking.

A post-incident review where you led the analysis. Your name is on it. The work is documented. Months later, when you’re building a promo doc, that’s a link, not a memory.

A short write-up you sent to your team after a migration completed. Two paragraphs: what we did, what changed, what we learned. Ten minutes to write. Permanent record of the work.

An email where you flagged a risk six weeks before the incident that didn’t happen because you caught it. That email is evidence of judgment. Without it, the non-incident is invisible (almost by definition).

A data pull you shared with your manager showing what the latency improvement actually looked like after the optimization shipped. The optimization exists in code. The impact now exists in a document.

None of these are heavy process. They’re lightweight habits that accumulate into a career record.

Visibility Is Not Bragging

Engineers resist this. I see it constantly in coaching conversations. There’s a deep cultural aversion to being seen as someone who promotes themselves. The implicit belief is that good work should be self-evident, and documenting it is somehow taking credit you haven’t earned.

That belief is expensive.

Self-promotion and documentation are different things. Self-promotion is telling people how great you are. Documentation is creating a record of what happened. One is about ego. The other is about evidence.

When you write a clear post-mortem, you’re not bragging. You’re creating institutional memory. When you send a project summary to your team, you’re not seeking credit. You’re closing the loop on work you led.

The byproduct of doing this consistently is that your impact becomes visible. That’s not a bug.

What to Start Doing This Week

You don’t need a new system. You need a few small habits.

Write a project note when things close. When a project ships, a migration completes, or an incident gets resolved, spend fifteen minutes writing down what happened. What was the situation, what did you do, what changed. Keep it somewhere you can find it. This is the raw material for every promo doc, every performance review, every resume bullet you’ll write for the next five years.

Make your decisions legible. When you make a significant technical decision, write down why. A Slack message, a doc comment, a one-paragraph note in the ticket. Not for the record per se - for your future self and anyone who inherits the system later. The artifact is a side effect of good engineering practice.

Share results when they land. If you shipped something that improved latency, reduced costs, unblocked another team, or eliminated a class of errors, send a short note to your team and manager when the metrics confirm it. Not a celebration. Just a close: “The migration is complete, we’re seeing X improvement in Y metric.” That’s documentation. It also happens to be visible.

Keep a running log. A private document, a notes app, anything. Once a week, write down two or three things you did. Takes five minutes. Over six months, you’ll have a detailed record that makes every review cycle and promo conversation dramatically easier.

The Promotion Case That Didn’t Go Through

The engineer I mentioned at the top eventually did get promoted - the following cycle. Not because they did more impressive work. Because they spent six months building habits around documentation.

By the time the next review came around, the promo doc almost wrote itself. The artifacts were already there. The evidence was specific, timestamped, and clear. The committee had something they could evaluate.

The work hadn’t changed. The visibility had.

Your engineering work visibility isn’t about performing for an audience. It’s about making sure the real work you’re already doing leaves a trace. In a promotion process, a design review, or a job search, you will be evaluated on evidence. The question is whether you’ve been creating it.

If there’s no artifact, it didn’t happen.

If you’re in a job search and this is hitting close to home, the SWE Resume System walks through exactly how to translate documented work into resume bullets that communicate impact to hiring managers. You can find it here.