For a long time I believed something my dad told me when I was sixteen: “good work speaks for itself”. He meant it kindly. He meant: don’t be a peacock, don’t take credit you didn’t earn, let the results stand. It’s lovely advice for a sixteen-year-old. It is partial advice for a working engineer, and the part it leaves out is the part that determines whether you get promoted.
Good work, in fact, does not speak for itself. Good work mumbles into the void unless someone, usually you, helps it along. Your manager has six other reports. Your skip-level has thirty. The principal engineer who would champion you in a calibration meeting has roughly forty-five seconds to remember what you did this quarter. If those forty-five seconds are blank, you are invisible, regardless of how good the work was.
The trick, and it is a trick worth learning early, is that you can make your work visible without becoming the kind of person who posts a LinkedIn carousel every time they merge a PR. There is a middle path. Most quiet engineers never find it.
”Good work speaks for itself” is mostly a trap
Let me be specific about what’s wrong with the original advice, because I don’t think it’s malicious, I think it’s calibrated to a different world.
Good work speaks for itself when you have one boss, one job, one product, and that boss watches you work all day. That world existed for some of our grandparents. It does not describe most modern engineering teams. Modern engineering teams have asynchronous communication, distributed reports, two managers in a recent reorg, and a Jira board that is read by exactly nobody outside of standup. The default state of your work is “buried in a private channel and a closed pull request”. The default state of your manager is “underwater”. Counting on your manager to surface your impact is like counting on a stranger to find your wallet on the metro. It might happen. You wouldn’t bet your career on it.
The other failure mode of “good work speaks for itself” is more subtle. It assumes that the people in the room have the context to interpret what they’re seeing. They often don’t. Your senior PM may not know that the seventeen-line dbt change you made saved the team six hours of weekly manual reconciliation. They may not know it because nobody told them, and the reconciliation pain happens on a different team they only see in a quarterly review. Without a sentence from you, that work has no narrative. With a sentence from you, it has a story, and stories are the unit of memory in any organisation.
So no, good work does not speak for itself. Good work needs help. The question is just how to help it without sounding like you’re auditioning for a TED talk.
The weekly note to your manager
The single highest-leverage habit I’ve ever picked up, and the one I recommend to anyone within shouting distance of a promotion case, is the weekly note to your manager.
It’s a simple thing. Once a week, usually Friday afternoon, I send my manager a short Slack message or email. Three to five bullets. What I shipped, what I’m working on, what I’m blocked by. No formatting flourishes, no metrics dashboards, no big “weekly report” header. Just three to five bullets in plain language.
Here’s a real one I sent a few months ago, lightly edited:
- Shipped the v2 of the customer events pipeline. The new one drops the legacy Postgres staging step, runs in seven minutes instead of forty, and I’ve left the old DAG running in shadow mode until next Wednesday for safety.
- Started looking at the Looker model that the marketing team has been complaining about. Early read: it’s a join order issue, not a data issue. Will know more by Tuesday.
- Blocked on getting access to the new Snowflake account. Filed a ticket with IT on Monday, pinged again today.
That note takes me twelve minutes to write. It does several things at once. My manager knows what I shipped this week, which is the input she needs for any conversation about my impact. She knows what I’m tackling next, so she can redirect me before I waste two days on the wrong thing. She knows I’m blocked, and unblocking me is something she can actually do. And, crucially, when promotion calibration comes up six months from now, she has a paper trail of my work that her brain didn’t have to generate from scratch.
Some managers will ask for these. Most won’t. Send them anyway. The ones who don’t ask are usually the ones who need it most, because they are the most overwhelmed.
Demoing in standup, releasing in writing
Standup is a strange ritual that has lost most of its original purpose, but it does have one underrated use: it is a tiny, low-stakes stage where you can show your work to your team. Most people use it to read out their Jira tickets, which is boring and forgettable. Use it for a thirty-second show-and-tell instead.
“I shipped the new alerting rules yesterday. Here’s the dashboard, you can see it caught two real issues in test runs already. Let me know if you want me to add anything for your domain.” That’s it. Thirty seconds. It costs you nothing and your team now knows the thing exists, which is the prerequisite to anyone using it or remembering you built it.
The same logic applies to release notes. If you ship anything that affects another team, write a short Slack message in a public channel: what changed, who it affects, where to find the docs, who to ping if it breaks. I’ve seen engineers ship beautiful internal tools that nobody used for six months because nobody knew they existed. The fix is one paragraph in #engineering. It is not a marketing campaign.
Help others find what you built
Here is a move I learned from a senior engineer I admire. Whenever she shipped a tool, an internal library, or a non-trivial piece of analysis, she did one extra thing: she found the next two or three people who would benefit from it and told them directly.
Not in a public channel. A direct message. “Hey, I just shipped a thing that does X. I noticed last month you were doing Y, and I think this might save you some time. Happy to walk you through it for ten minutes.” That’s it.
What she was doing, without thinking of it this way, was building a quiet network of people who knew her work. Each of those people would, later, mention her tool to someone else, and her name would come along for the ride. By the time her promotion case came up, half the engineering org had used something she built. The case wrote itself, because she had been writing it slowly for a year.
This is, I think, the cleanest version of “self-promotion” available. You’re not posting on LinkedIn. You’re not sending a “look at me” email to a wide list. You’re solving a real problem for a specific person, and as a side effect, that person now knows what you do. There is nothing icky about it. It is just being a useful colleague, on purpose, in a way that compounds.
The middle path: factual, frequent, focused on impact
If “good work speaks for itself” is one failure mode, the other is the LinkedIn-bro version. The engineer who posts every two weeks about their own brilliance. The Slack message that ends with eight clapping emojis self-tagged onto their own announcement. The “humble brag” that is neither humble nor accurate. We’ve all rolled our eyes at this person. Don’t be them. Their reputation calcifies in a different but equally bad way: people start discounting their wins because the volume is so high. The signal-to-noise ratio collapses.
The middle path has three properties.
It is factual. State what shipped, in plain language, with numbers when you have them. “Reduced p95 query latency from 4.2s to 800ms” is a sentence. “Crushed it on perf this sprint” is a vibe. The first is forgettable in a good way: it’s accurate, and your manager can quote it later. The second is forgettable in a bad way: it’s vague, and your manager can’t.
It is frequent. The weekly note. The thirty-second standup demo. The release notes in Slack. Small, regular, low-key. Not the once-a-quarter highlights reel, which always reads as defensive even when it isn’t.
And it is focused on impact, not effort. Effort is invisible to your manager and irrelevant to the business. Impact is what they remember. “I worked all weekend on this” is a complaint dressed as an achievement. “This change is now saving the support team about ten hours a week” is the same work, framed in the language of value. Train yourself to translate every “I worked hard on” sentence into “this enables”, “this saves”, “this unblocks”. The work is the same. The story is much better.
Takeaway
The quiet engineer’s playbook is not about becoming loud. It’s about being slightly more deliberate than feels natural. A weekly note to your manager. A short demo in standup. A direct message to the two people who’d benefit from your work. Numbers when you have them, plain language when you don’t. None of this is bragging. It is just letting your work be findable, by the people who need to find it, in the channels they actually read. Do this for a year and you will not have to wonder whether you’re being seen. You will be seen, because you helped.