From Invisible To Indispensable: An Engineering Manager’s Guide To Showing Impact

Prove your impact, without the politics.

· 5 min read
A person walking into the spotlight.

If a tree falls in a forest and no one is around to hear it, does it make a sound?

It’s the same when you work as an Engineering Manager (EM). You might think your results are obvious. Your team delivers, the product works, and people seem to be happy around you. But if you don’t make your impact visible through numbers and narrative, your contributions risk going unnoticed.

When you don’t show impact, it’s easy for stakeholders to assume you’re just keeping the engine running rather than really improving things. And that’s the fast lane for being overlooked for recognition, resources, and promotions.

This post will help you to:

  • Track
  • Frame
  • And communicate your impact

So your work gets the recognition and support it deserves.

Tell your story, share your numbers

It’s not enough to quietly do great work. The people around you, especially your stakeholders, need to see it. And this requires deliberate communication.

Ideally, focus on two things:

  1. Quantifying the impact
  2. And narrating the journey that led to it

Think of it like this: anyone can report metrics. But you’ll also need to tell a story about change. And just like any story, it needs a beginning, middle, and end.

Let’s say your team spent months addressing technical debt. Features go out 20% faster, the bug rate drops, and team morale improves. The importance of this achievement is unquestionable. But unless you explain:

  • What you changed
  • Why it was difficult
  • How you executed it
  • And the results (with actual data) 

Chances are, no one realizes how impactful it was. And when nobody sees it, nobody values it.

Speak two languages: engineering and business

One of the hardest parts of being an EM is bridging the gap between what engineers care about and what business stakeholders want.

We know engineers focus on experience, process, and quality. However, stakeholders usually care about things like speed, customer satisfaction, and outcomes. If you don’t translate one to the other, your efforts might fall flat.

For example, you may know your app’s UX is painful (even if response times are fast). Your developers complain and customers churn – but on paper, performance looks fine. So, what do you do? 

You find what can be measured – and measure it.

For example, how long it takes users to complete tasks, where they drop off, or how frequently they use a feature. Then, you correlate that with technical improvements and customer feedback.

Don’t just say: “We fixed the UX.” Say: “Task completion time dropped by 30%, and churn declined by 15% after our updates.”

That’s the bridge between engineering language and business language – and you’re the one who has to build it.

It might be intimidating, but it’s not rocket science

Although putting everything together is definitely intimidating at first, you don’t need a PhD in astrophysics to be able to measure impact.

Try starting with what you already have. And what you already have can simply be:

  • Time to merge PRs
  • Number of rounds before approval
  • Bug count per feature
  • Deployment frequency
  • Incident rates
  • And developer satisfaction via surveys

Or, think about your hiring and onboarding processes: how long does it take new engineers to make their first meaningful contribution? Where do they get stuck? What slows them down?

The trick isn’t sophistication – it’s relevance. Choose metrics that track what you’re actively trying to improve. Then, use storytelling to fill in the context. Reporting a 30% improvement alone is different than explaining what caused it, highlighting what changed, and showing the before and after.

Ok, but how do you measure the sky?

Fair question. How to measure the unmeasurable. How do you measure something like happiness? Or motivation? Or culture

Well, you do it by approximating. 

Imagine you added focus time to calendars or cut back on meetings. If morale improves after that, that’s a signal. You can also analyze indirect metrics. For example, if your bug rate goes down after a major refactor, maybe it’s not just cleaner code – maybe your engineers feel more confident and focused.

Whatever you measure, make sure it is useful. The truth is everything can be represented (either directly or by proxy). It is up to you to be creative and honest in how you frame it. Maybe you can’t measure the sky, but you can count some clouds and birds.

Yes, it is promotional – but that doesn’t need to be a bad thing

Many EMs (especially introverted ones) feel uncomfortable “selling” their work. It feels like bragging or politics. In fact, this happens not only to EMs. I get that.

But promoting your team’s work is essential. Not only does it make their efforts visible, it ensures they get the credit they deserve. And you can think of it like sales: good sales do not push something people don’t want. Instead, they show them the value. 

Always try to match the message to what stakeholders care about. Again, instead of saying: “We improved the testing pipeline”, say something tailored to their wants: “We’re now releasing features 25% faster with fewer bugs in production”.

Yes, it is a pitch. But one that gets attention – and funding.

Use AI and automation to reduce the manual load

Tracking all this data sounds like a lot of work. Because it can be. You can go as far down the rabbit hole as you wish. And that’s why you should make the process as automated and low-effort as possible. If tracking requires lots of manual data entry or constant oversight, it won’t last.

Instead, build simple systems to capture what you need:

  • Analytics tools that automatically log usage
  • Dashboards that visualize key dev metrics
  • Surveys sent periodically
  • And AI to analyze unstructured data from Slack or meeting transcripts

For example, you could run transcripts from team meetings through an LLM and prompt it for insights on morale or blockers. Think about it as a kind of sentiment analysis. 

The judgment will be yours in all cases, but with data, you will judge better.

If you are not being seen, try reflecting

If you’re early in your EM career and feel unseen, the first step is reflection.

Ask yourself:

  • What exactly do I want to be recognized for?
  • What have I improved in the past 3-6 months?
  • And what changes has my team made that others may not know about?

From there, identify one or two simple metrics you can track. Then, start sharing the results. You don’t need a big dashboard or formal system. A well-crafted Slack message or internal blog post is enough to get started. 

You might struggle with communication – that’s normal. Most new EMs do. But it’s part of the job, and writing is your friend. Put your results in writing: keep it short, clear, and relevant. Over time, your comfort will grow.

The short version: why quiet EMs should be loud about their impact

You’re doing impactful work. However, if others don’t see it, it’s as if it never happened. That’s why you have to measure it – and talk about it.

Start with what you’re improving:

Instead, lean into it. Get comfortable speaking both engineering and business languages because you’ll have to communicate with different audiences. Make your impact easy to understand, and more importantly, make it relevant to your audience.

Remember, even if you feel uncomfortable, this is not about bragging. You are giving yourself and your team the credit you’ve earned. Because when you get good at showing impact, things like securing a budget or growing your career will follow.

Next week, I’ll show you how to move beyond raw numbers and craft a narrative that resonates. I’ll cover framing, context, and communication – so your metrics don’t just exist, they speak.


Ready to take back control of your engineering career?

Join my newsletter and get a copy of my Daily Priorities Tracker for free!


Originally published on Medium.com