On May 24, 1883, the Brooklyn Bridge opened. Emily Warren Roebling was honored in a speech by Congressman Abram Hewitt, who called the bridge “an everlasting monument to the sacrificing devotion of a woman.” She’d spent eleven years running the project—learning engineering, managing construction, solving problems that stumped experienced engineers.
But here’s the twist: Emily deliberately hid her work. She had to pretend her bedridden husband was still in charge, or he’d lose his job and the family would lose everything. Contractors and workers knew she was brilliant. The public didn’t. It worked. She protected Washington and completed the bridge.
It took until 1951 for a plaque acknowledging her role.
You might think: “See? That’s why I need to be visible!” But wait. Emily’s situation is the opposite of yours. She was hiding on purpose for strategic reasons. She knew what she was doing.
Most engineers aren’t hiding their work on purpose. They just don’t realize it’s invisible until it’s too late.
The uncomfortable truth: Good work doesn’t automatically become visible. And unlike Emily Roebling, you probably don’t have a strategic reason to hide it.
Why Engineers Stay Invisible
Here’s the pattern you’ve probably experienced:
You refactor a critical service. Deployments go from taking 45 minutes to 8 minutes. You save the team hours every week. Three months later in your performance review, your manager asks what you’ve been working on, and you realize they have no idea about any of this.
This isn’t necessarily because your manager is bad. They might be managing eight other people, sitting in six hours of meetings a day, and barely have time to read code reviews. They need you to make it easy for them to see what you’re doing.
But there’s a deeper problem: you probably have a visceral resistance to self-promotion.
You’ve seen the engineer who talks constantly about their work. The one who sends update emails for fixing a typo. The one who somehow gets credit for team projects they barely touched. You don’t want to be that person. So you stay quiet.
The result? Your excellent work is invisible, and someone else’s mediocre work with good PR gets the recognition.
This is the real problem: The gap between work quality and work visibility is where careers go to die.
The Culture Question You Need to Answer First
Before you do anything, you need to figure out: Does visibility even matter at your company?
Some places promote based on clear metrics and actual impact. Your work speaks for itself because there are systems to track it. If you’re at a place like this, visibility work is minimal—just make sure the data reflects your contributions accurately.
But most companies aren’t like that. Most companies promote based on a foggy mix of perceived impact, manager advocacy, and who the VP noticed in meetings. At these places, visibility is essential.
And some companies—be honest with yourself here—are pure politics. The person who gets promoted is the one golfing with the CTO. If this is your reality, no amount of visibility work will help. Update your resume instead.
How to tell which one you’re at:
Look at the last three people promoted
Did they have clear, measurable impact? Or did they just seem to be everywhere?
Does your manager actually know what you work on, or do they rely on what they hear in meetings?
If it’s the latter, keep reading. If you’re not sure, assume you need to work on visibility.
Three Things That Actually Work
I’m going to be honest: most “visibility systems” either don’t work or aren’t worth the time. Here are the three that have the best ROI.
1. Weekly Updates to Your Manager (10-15 minutes)
Every Friday, send your manager a short message. Email works. Slack works. Whatever they actually read.
Three sections:
Shipped: Reduced API response time from 800ms to 200ms for /search endpoint (PR #347). Affects 12K requests/day.
In Progress: Investigating database connection pooling issue causing intermittent timeouts on checkout flow.
Blocked: Need infra team to enable feature flags in prod before I can proceed with A/B test.
Why this works:
Creates a searchable record of your work
Takes manager burden off remembering everything
Shows you’re thinking about impact, not just tasks
Time investment: 10-15 minutes if you’re actually tracking your work. Longer if you’re trying to remember what you did all week.
Culture check: If your manager doesn’t read these after a month, have a conversation. Ask: “How do you prefer to stay updated on my work?” If they say “I don’t need updates,” you might be at a place where this doesn’t matter. Or you might have a hands-off manager who still expects you to be visible somehow—figure out which.
The uncomfortable truth: This takes time. 10 minutes a week is 40 hours a year you could spend coding. Is it worth it? At most companies, yes. At some companies, no. You have to decide.
2. Write Actually Good PR Descriptions (2 extra minutes)
Most engineers write PR descriptions like:
Fixed checkout bug
That’s a waste. You’re already writing the PR. Spend two more minutes making it useful:
Problem: Users were charged twice when clicking “Buy Now” multiple times quickly (3% of transactions, ~$15K/month in refunds)
Solution: Added idempotency key to payment requests. Duplicate requests within 5 minutes now return the original transaction instead of creating new charges.
Testing: Unit tests for idempotency logic. Manual testing with rapid clicks in staging.
Why this works:
Documents your thinking
Makes code review easier (reviewers are more likely to approve quickly if they understand the context)
Creates permanent record of impact
Culture check: This one works almost everywhere. Good PR descriptions help everyone, regardless of company culture.
3. Speak Up in the Right Meetings (Variable time)
This is the one everyone avoids because it feels like “playing politics.” But here’s reality: If you’re never heard from in meetings, people assume you’re not doing anything important.
You don’t need to talk in every meeting. You need to talk in meetings where:
Decisions are being made about architecture or technical direction
Leadership is present and listening
Your project is relevant to the discussion
What to say:
Share context: “For the search latency project, we found that 80% of slow queries are coming from the recommendation service”
Ask smart questions: “Have we considered how this affects the mobile app? Their offline mode might break”
Offer to help: “I’ve dealt with something similar on the payment service. Happy to share what we learned”
Recognize others’ work: “Max’s caching implementation is what made this possible—we’re seeing 70% fewer database calls”
Why this works:
Makes you memorable to people who matter
Associates your name with valuable contributions
Actually helps the meeting be productive
Culture check: This is extremely culture-dependent. In some teams, speaking up is welcomed. In others, there’s a strict hierarchy and junior engineers are expected to stay quiet. Read the room. Watch what happens to other people who speak up.
The hard truth: If you work at a place where speaking up gets you shut down or ignored, you’re probably at the wrong place.
The Power Move: Demo Your Work
Here’s what almost nobody does but has 10x the impact of anything else: actually showing what you built.
When you finish something significant, ask for 5-10 minutes in the engineering all-hands or team meeting to demo it. Not a presentation with slides. An actual demo of the thing working.
How to do a good demo:
Start with the problem (30 seconds)
“Checkout was failing for 3% of users when they had more than 10 items in their cart”
Not: “I worked on the checkout service”
Show it working (2-3 minutes)
Actually click through the thing
Show before/after if possible
“Here’s what used to happen... and here’s what happens now”
One key technical insight (1 minute)
“The issue was a race condition in how we were updating cart totals”
Don’t go deep into the weeds unless asked
Impact (30 seconds)
“This affects about 2,000 orders per week, roughly $40K in revenue we were losing”
Connect it to something people care about
Credit the team (30 seconds)
“Thanks to Maria for the code review and catching the edge case with gift cards, and to the data team for helping us measure the impact”
Why demos are so effective:
People remember what they see. Six months later, they’ll forget your weekly update about the checkout bug, but they’ll remember watching you click through and fix a problem live.
More importantly: You’re proving competence, not just claiming it. There’s a difference between “I worked on performance” and showing a dashboard where response times drop off a cliff when your change deployed.
The reciprocity factor:
When you publicly credit others in demos and meetings, something interesting happens: they start doing it back. Engineers are more likely to mention your contributions when you’ve established a pattern of recognizing theirs.
This isn’t manipulation. It’s how healthy teams work. Good engineers know they don’t work in isolation. When you say “This was possible because of Max’s caching work,” you’re:
Being accurate
Making Max more visible
Creating a culture where people acknowledge each other
Making it more likely that Max mentions your work next time
The engineers who get promoted aren’t always the ones who did the most work. They’re often the ones whose names come up when leadership asks “who should we tap for this?”
That happens when multiple people are saying your name in meetings.
The Honest Assessment
Do this for three months:
Send weekly updates to your manager
Write good PR descriptions
Speak up once or twice in important meetings where you have something valuable to say
Then evaluate:
If your manager starts:
Referencing specific things you’ve done in 1-on-1s
Asking you to present to leadership
Mentioning you for new opportunities
→ Keep doing it. It’s working.
If nothing changes:
Have a direct conversation with your manager: “I’ve been trying to communicate my work better. Is this helpful? How do you prefer to stay updated?”
If they say it’s helpful but still nothing changes in 3-6 months, the problem isn’t your visibility
Consider whether this is the right place for your career
The Real Lesson from Emily Roebling
Emily Roebling did extraordinary work on one of the most ambitious engineering projects of the century. She strategically hid that work to protect her husband and complete the bridge. It worked. The bridge got built.
But for nearly 50 years after her death, most people didn’t know her name. Recognition came too late.
You probably don’t have Emily’s constraints. You’re not hiding your work to protect someone else’s job. You’re just not thinking about visibility.
Question: Do you want recognition while you’re still around to benefit from it?
If yes, make your work visible.
If you say “I just want to build great things and don’t care about credit” be honest with yourself. Is that a principled choice, or are you just uncomfortable with self-advocacy?
One is legitimate. The other is a career limiter.
Your work matters. Make sure someone knows about it.
P.S. If you want my help with the tech lead transition, I’m opening up a private community for senior engineers.
Video courses. Expert workshops. Q&A calls. 1:1 support.
👉 Join waitlist
Great ideas for any individual contributer. I am going to share this with my self-directed leaders who are asking how do I demonstrate a commitment to my team members? Some of these ideas may do just that! Thanks
Couldn’t have said it better :)