You deliver the dashboard on Monday. By Tuesday afternoon someone in the meeting is asking whether the team still needs anyone to maintain it. The thing you built across four days of squinting at refresh failures, rewriting half the data model, and untangling a relationship that was set up backwards is now "a dashboard." Singular. Static. Already part of the furniture.
The faster the turnaround, the less work it looks like. The cleaner the output, the less visible the effort behind it. The more you actually know what you're doing, the more obvious the answer seems to people who don't have to do it.
The instinct here is to call this a perception problem and prescribe a perception fix. Talk about your wins more. Send a Friday update. Get yourself in front of leadership. None of that solves the actual issue, and most of it makes capable people feel like they're auditioning for a job they already have.
The competence paradox is structural, not perceptual
The markers people use to read effort - time taken, visible struggle, complexity in the final artefact - all go down as you get better. The first time you built a Power Query refresh you spent two weeks on it and broke it three times. The second time you wrote one in an hour. Same problem, same delivery, fifteen times less suffering. The person watching you finish in an hour didn't watch the two weeks. They have no calibration for what "an hour" represents in your hands versus theirs.
This is the trap. The visible signals of value are the same signals that go away as you become competent. So the better you get at the work, the less the work telegraphs that it was work at all.
"Just be more visible" misses this entirely. You can be in every standup, send the weekly update, and post on the team channel - and if the artefact you ship still looks like it took twenty minutes, the volume of communication doesn't override the picture. People discount activity. They don't discount difficulty when difficulty is named for them.
Name what was hard about the problem, not what was hard about doing it
This is the move that actually shifts things, and it is much smaller than career advice usually makes out.
People are skeptical of effort claims. They are not skeptical of problem claims. "This took me ages" is easy to dismiss. "This was tricky because the join key was stored as text on one side and an integer on the other, and the duplicates only showed up after the date filter" is information, not boasting. The complexity lives in the problem. You're describing the problem. The fact that you solved it is implied, not declared.
This works because it changes what the listener is evaluating. They stop asking "did this person work hard?" - a question they will mostly answer "no" by default - and start picturing the actual shape of what you were dealing with. Once the problem is legible, the work to solve it doesn't need a defence.
The form is short. One or two sentences, delivered casually, attached to the delivery itself. Not "before I show you this, let me explain how hard it was" - that lands exactly as poorly as it sounds. More like a footnote: "Done. The data model needed a rebuild before this was usable, but it's clean now."
Don't deliver in silence, but don't deliver a speech either
The other thing that helps is the post-completion note. The work without a record is invisible; the record without the work is theatre. You need both, and you need to keep them proportionate.
A two-line message at delivery time does most of the lifting. What it shipped. What was non-obvious about it. That is enough for anyone who cares to ask follow-up questions, and it leaves a permanent record in the channel for the people who don't ask but who will later wonder where the new report came from.
The version of this that doesn't work is the multi-paragraph wrap-up at the end of a quarter. Reviews are the worst time to make a case for yourself. The audience is half-listening, the timeframe is wrong, and the framing has already shifted from information to evaluation. The version that does work is the one that happens at the moment the work happens, when the context is fresh and the artefact is in front of everyone.
This week
The next thing you finish - especially the one that came together quickly - send a short note when you deliver it. State what shipped, name one thing that was non-obvious about it, and stop. Don't qualify it, don't soften it, don't apologise for the effort.
Calibrate this against the test from How to Talk About Your Work Without Bragging: would you say this exact sentence about a colleague's delivery? Then it's not bragging. It's a record of what happened.
The arc starts at Nobody Knows What You Actually Do - the original problem - and the next post on May 22 is about how to handle the version of this that gets worse, not better, when you move into a senior role. The competence paradox doesn't fix itself with seniority. It deepens.
Frequently Asked Questions
Isn't this just self-promotion with extra steps?
No. Self-promotion is "look how great I am." This is "here's what happened, and here is the part of the problem that wasn't obvious." The difference is that you're describing the work, not yourself. If a colleague had done the same thing, you'd describe it the same way without thinking it was bragging on their behalf.
What if my manager already knows what I do?
Your manager is one person. Promotion conversations, calibration meetings, and headcount decisions involve a room of people who are not your manager. The record you build at delivery time is what they see. Your manager's private knowledge of your work doesn't transfer into that room unless they can summarise it in a sentence, and your delivery notes are the source material for that sentence.
Doesn't this make me look like I'm fishing for credit?
If you append a half-page of justification to every deliverable, yes. If you ship the work and add one line about the genuinely non-obvious part of the problem, no - that's the same shape as the engineering team's PR description or a designer's hand-off note. It's professional documentation, not lobbying.
What about work where nothing was non-obvious - it was just steady output?
Then a one-line "shipped, links inline" note is fine and you don't need to manufacture difficulty. The discipline isn't to inflate every task. It's to stop deflating the tasks where the difficulty was real and unobvious.
Does this work in a remote-only team?
It works better. In an office, some of this happens by osmosis - people walk past your screen, hear you on a call, catch the frustrated muttering that signals you're untangling something hard. Remote teams have none of that ambient context. The written record is the only record. If you don't write it, it didn't happen.