Stop telling your engineers to "work on visibility"

Every brag doc and skip-level hack is a symptom of a management system that isn't working.

Feb 17, 2026

👋 Hey, it’s Stephane. I share lessons, and stories from my journey to help you lead with confidence as an Engineering Manager. To accelerate your growth see: AI Interview Coach | 50 Notion Templates | The EM’s Field Guide | CodeCrafters | Get Hired as an EM | 1:1 Coaching

Paid subscribers get 50 Notion Templates, The EM’s Field Guide, and access to the complete archive. Subscribe now.

There’s popular career advice aimed at engineers: keep a brag doc, schedule skip-level 1:1s, post your wins in Slack, update your manager after every your big wins. The advice isn’t wrong, exactly. It works. Engineers who do this stuff consistently do get promoted faster.

But if you’re an engineering manager reading that list, you should feel uncomfortable. Because every item on that list is a symptom of a system you’re supposed to be running - and it’s clearly not working.

When an engineer has to build an entire personal marketing apparatus just to get recognised for doing their job, something has broken in the management layer. And that something is probably you.

Visibility

Here’s what happens when visibility becomes the engineer’s responsibility: your best people spend 15-20% of their productive energy on writing update posts, prepping for skip-levels, maintaining brag docs, carefully choosing projects based on who’ll notice the work rather than what the team actually needs.

Some engineers are naturally good at this. They’re articulate, socially confident, comfortable in meetings. They thrive.

Others (often your most thoughtful, deeply technical people) are terrible at it. Not because they lack soft skills, but because the entire exercise feels performative to them.

The result is a promotion system that systematically favours engineers who are good at talking about work over engineers who are good at doing it. As a manager, you’ve essentially created a filter that selects for self-promotion ability and then convinced yourself you’re selecting for impact.

Early in my management career, I’d evaluate engineers partly based on how well I understood their contributions. If someone’s work was not that visible to me, I’d assume it was less impactful. It took an embarrassingly long time to realise that the invisibility was my failure, not theirs.

The question to ask yourself

The question isn’t “how do I help my engineers get more visible?” It’s “why don’t I already know what my engineers are doing?”

If an engineer delivers a three-month project and you have no idea, that’s not a visibility problem. That’s a management problem. Somewhere in your system (your 1:1 structure, your team rituals, your relationship with your own leadership) there’s a gap. And plugging that gap with engineer-driven self-promotion is a band-aid on a broken process.

Think about it from your team’s perspective. When you tell an engineer “you need to work on your visibility” what they hear is: “Your work doesn’t count unless you market it to me”. That’s a brutal message to receive, especially when they’ve been heads-down solving hard problems they believed you assigned because they mattered.

If you’re enjoying this article, consider subscribing to get:

✉️ Free: 1 original post every Tuesday, my favourite posts of the week every Sunday + 10 Notion Templates for Engineering Managers
🔒 Paid: Full archive + 50+ EM templates & playbooks + The EM Field Guide

What managers should do

Instead of outsourcing visibility to your engineers, build systems that make good work visible by default. Here’s what that looks like in practice.

Restructure your 1:1s around discovery, not status updates. If your 1:1s consist of engineers telling you what they worked on, you’re using them wrong. You should already know what they delivered. Use 1:1s to uncover the stuff you’d never see otherwise: the refactor that prevented three future incidents, the mentoring conversation that unblocked a junior, the technical decision that saved weeks of work downstream. Ask questions like: “What’s something you did this month that nobody noticed?” and “Where did you make a judgment call that changed the direction of the work?” You’ll be amazed what surfaces.

Own the upward communication yourself. When your skip-level asks what’s happening in your team, that’s your job to answer - comprehensively. Don’t put the burden on individual engineers to build relationships with your manager. Instead, be the person who says to your director, “I want to make sure you know about the work Jamie did on the migration. Let me walk you through why it mattered”. If you can’t articulate your team’s contributions to leadership, you don’t understand your team’s work well enough. Fix that before you ask anyone to write a brag doc.

Create team-level rituals that surface work naturally. A bi-weekly demo session where engineers show what they built. A monthly “technical wins” roundup that you write and share with the broader org. A lightweight RFC process where design decisions become visible artifacts. These aren’t performative - they’re structural. They make contributions visible as a byproduct of how the team operates, not as extra homework for individual engineers.

Actively sponsor your quiet contributors. You know who I’m talking about. The engineer who fixes the gnarly production issue at 2am and never mentions it. The one who reviews thirty pull requests a week and makes everyone else’s code better. The one whose name never comes up in calibration because they don’t play the visibility game. That person is your responsibility. Put their name forward. Tell the stories they won’t tell. If you’re not doing this, you’re essentially punishing people for having a different communication style than you prefer.

Separate the signal from the noise in calibration. When you sit in promotion discussions, ask yourself: “Am I evaluating this person’s impact, or am I evaluating how well they communicated their impact to me?” These are completely different things. If you can only advocate for engineers who’ve handed you a neat package of accomplishments, you need better information-gathering systems, not better-marketed engineers.

Final words

Look, I’m not naive. Organisational reality means that some degree of self-advocacy will always matter. I’m not suggesting engineers should never communicate about their work or that managing up is pointless.

But there’s a difference between an engineer learning to communicate effectively (which is a genuine skill worth developing) and an engineer building an elaborate personal PR operation because their management chain can’t be bothered to understand what they do.

If you find yourself telling multiple engineers on your team that they need to “work on visibility”, stop and ask yourself a harder question: what am I not seeing, and why?

The answer will almost always point back to your own systems, your own habits, your own blind spots. That’s uncomfortable. It’s also where the actual fix lives.

Your engineers signed up to solve hard technical problems. Let them do that. The visibility part? That’s your job. Own it.