You did the work. The hard kind—the three weeks of chasing a race condition that only showed up under load, the careful refactor that made the next six features trivial, the quiet design call that saved the team a quarter of pain. Then your performance review comes around, and your manager—who likes you, who’s genuinely on your side—can’t quite say what you did. Not because the work wasn’t real. Because they never saw it happen.
This is the part nobody warns you about when you go remote: In an office, some of your visibility was free. People saw you at the whiteboard, overheard you unblock someone in the kitchen, watched you stay late. None of that was a measure of your impact—but it added up to a vague, ambient sense that you were doing things. Take away the building, and that ambient signal goes to zero. The work doesn’t get less valuable. It gets less visible. And invisible work is, for every practical purpose—promotion, credit, getting pulled into the interesting projects—work that didn’t happen.
Work in the open, not in a summary
The instinct most of us have is to fix this at the end. Do the work heads-down, then write the big summary, present the finished thing with a bow on it. That’s backwards. By the time you’re presenting, the interesting part is over—the reasoning, the dead ends, the moment you realized the obvious approach wouldn’t work. You’re narrating a conclusion when the value was in the process. This is showing your work applied in real time. The fix is to work loudly: make the work visible as you do it, in shared and durable places, not after the fact in a status update nobody reads. (share this quote)
In practice that means thinking out loud where others can see it. The issue you open before you start, with what you’re trying and why. The pull request description that explains the approach, not just the diff (it may even be longer than the diff). The “here’s where I’m stuck, here’s what I’ve ruled out” message in a public channel instead of a private one. The rough draft shared at 40% instead of the polished thing shared at 100%. You’re not adding a layer of reporting on top of the work. You’re doing the work in the open, where it leaves a trail.
I’ve opened a few thousand issues; the ones that mattered most were the ones I opened before I knew the answer. The tell: if it only lives in your head or a DM, it isn’t loud yet. (share this quote)
Like a bear bell
I think of it like a bear bell (bells you attach to your pack when hiking bear country). You don’t ring it to show off—you ring it so the bear hears you coming. The danger on the trail isn’t the bear—it’s the startled bear, the one you surprised rounding a blind corner. Every org has them: the stakeholder who learns about your decision after it ships, the team that discovers from the changelog that you rerouted around them. Surprise people like that, and they don’t get curious—they get defensive, territorial, loud.
I learned this the hard way. GitHub’s (then) CEO and General Counsel once DM’d me about an urgent, time-sensitive feature. I assumed my own leadership was already in the loop, so my team went straight to work—focused on the time-critical work, not the time-critical communication. Our leadership first found out when the feature was ready to ship and we kicked off the launch: docs, blog post, the rollout. It was not good. The feature went out—there was an executive mandate behind it—but the launch had made the people I reported to look out of the loop in front of their peers. I don’t know that their trust in me ever fully recovered.
Working loudly is the bell: the low-effort, ambient signal that you’re on the trail and headed their way. Your work and your decisions reach people as something they saw coming instead of an ambush, and they get the chance to respond early and productively.
Loud, not bragging
Which is also the answer to the objection I hear most: won’t I look like I’m bragging? There’s a real difference between narrating your work and performing it. Performing busyness is noise about work—the “just pushed through lunch 💪” posts, the green-dot theater, the reply-all to look engaged. Working loudly is the work itself, made legible. One is activity cosplaying as impact. The other is impact you can actually point to. If you’re sharing the artifact—the issue, the PR, the doc, the decision—you’re working loudly. If you’re sharing your effort, you’re just being loud.
The payoff compounds
The payoff is bigger than getting credit, though you’ll get that too. (share this quote) When your work is visible in progress, people can help. Someone spots the bug in your approach before you’ve sunk three days into it. A teammate who solved the same problem last quarter drops a link. The senior engineer who’d never have been pulled into a private thread weighs in on the public one. Loud work compounds—it invites collaboration that silent work never gets the chance to.
I like to joke that the hardest part of open source is googling to find out whether someone already solved your problem (share this quote) before you spend a week solving it yourself. Inner source—the same habits inside a company—is no different: work loudly so others can find you, and look around so you find them before you redo their work.
Managing without surveilling
I once led a team at GitHub that split, roughly down the middle, into two styles. Half of them did everything—and I mean everything—in issues. Weekly reporting was a GitHub search on my end: their work was already written down, already visible, and the interesting opportunities tended to find them. The other half worked mostly in DMs and in their own heads. Some weeks I’d get a crisp update; some weeks their work never reached the people above me at all, because I had nothing to point to. Same team, same caliber of work. At end-of-year reviews, that gap didn’t stay small—it compounded into the story each person’s year got to tell.
If you manage people: this is how you lead without surveilling. You don’t need standups-as-status-roundup or “just checking in” pings when the work is legible by default—you can see it, link to it, build on it. You get to evaluate your team on what they actually shipped instead of who happened to be online when you looked. Make the work visible, and you can finally reward outcomes instead of hours. The alternative—rewarding the people who are merely around—is how good remote engineers quietly conclude they’re better off somewhere else.
The trail test
Here’s the test, on the work you’re doing right now: could your manager write your review from the trail alone—not from your memory, not from a meeting you’d have to attend, but from what you’ve left behind? If yes, you’re working loudly. If no, the work might be excellent, and it’s still happening where the one person whose job is to see it can’t. Ring the bell. (share this quote)