Turning the Spotlight on Unsung Efforts: How to Be Perceived as Important and Impactful?

Do you have metrics set up quantifying the value that you're bringing? If your team's goals is to save customer support time, it might be helpful having metrics around the time needed for customer service to onboard a new feature. Once you have that value, you can multiply it by the dollar average a customer service agent gets paid to paint a clear picture.

Another line of thinking might be you're trying to get acknowledgement from the wrong crowd: engineers generally don't have that much visibility about support, but the folks on support who are using your tools would. If you get acknowledgement from customer support leadership, that might help get acknowledgement from the engineering side.

Two thoughts in addition to the great ideas from Jonathan:

• Can you create more focus (and education) around the work your team is doing? e.g. schedule a bi-weekly meeting where you talk about the features you're building, how they contribute to a metric moving, and invite feedback.
• Can you chat 1:1 with key people on the team to understand what they view as "important" work? Then, in your messaging of the customer support tools, you can connect the dots to what they mentioned as important. If you can't do that, I'd try to expand the scope of your work so there is some overlap.

See also:

• What To Do If Your Manager Doesn’t Care About Your Work
• "How can I get my work better recognized by leadership?"
• "How can I make sure that I get full credit for my work?"

Though this work is consistently given priority in team meetings, it is often sidelined or perceived as less critical compared to other product-facing features.

I would try to figure out the misalignment between "consistently given priority" vs. "often sidelined". One scenario that often happens is people will say things such as "we need to reduce tech debt" when what's actually happening is "we want someone to take this one since nobody else wants to / rather be doing feature work".

Like Jonathan mentioned, proposing a metric to make it easier to track progress is a great way to start. Making it easy for others to celebrate your accomplishments is another big factor. For example, instead of waiting to announce your "win" verbally in a live team meeting (especially if you're more introverted), provide a written update beforehand and ask if your lead can support you in "celebrating wins" on the team.

Sometimes you just need to nudge the team culture in the right direction by taking the initiative to start a "share your wins" channel with the support of your management instead of fighting for airtime during live meetings.

Personally, I've had a documented "win" from someone on my team shared all the way up to the CIO since we drafted the email in a way that made it really easy for your leadership to write a one liner and hit the forward button.

Customer support is obviously necessary but often under-appreciated work because:

1. The underlying process (i.e. the CX agents helping customers) is manual
2. Observability is bad due to #1

At the end of the day though, customer support is impactful and can be measured just like everything else humans and computers do. Here are some ideas:

• Measure how long new feature onboarding would take without your tool and compute the delta
• Measure time saves across CX agents overall
• Draw a connection between your work and overall feature quality/stability

Something neat I saw at Robinhood and Meta is that there's a "Customer support tickets filed" metric anybody running an experiment can include in their analysis. So when product teams launch new features, they can see if there's an uptick in people complaining to CX and adjust/revert accordingly. It's a really high-impact metric as at the end of the day, the customer is always right and there's just some aspects of product quality you simply can't fully capture with logs.

At a higher-level, adding observability is a super common senior -> staff project I have seen. Since staff engineers need an overwhelming of influence on team direction, it's vital that they have clear numbers backing up their case. Adding these metrics is always hard, but it's necessary, and "hard but necessary" sums up what a staff engineer does in a nutshell.

This other discussion might help as well: "I want to become the "data guy" in my company - How can I do that?"