6

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

Profile picture
Senior Software Engineer at Intuita year ago

Working hard and staying on top of my sprints, I lead a team that focuses on developing tools for customer support to onboard our new features.

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.

Despite my efforts, I feel I am not acknowledged or seen as impactful and intelligent. I suspect biases at play but cannot substantiate them concretely.

How can I change this perception and ensure that my contributions are recognized and valued within the team?

How can I turn around the situation to be perceived as important and impactful, aligning my hard work with the recognition it deserves?

151
4

Discussion

(4 comments)
  • 4
    Profile picture
    Career Coach • Former Head of Engineering
    a year ago

    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.

  • 3
    Profile picture
    Android Engineer @ Robinhood
    a year ago

    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.

  • 3
    Profile picture
    Tech Lead/Manager at Meta, Pinterest, Kosei
    a year ago

    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:

  • 2
    Profile picture
    Tech Lead @ Robinhood, Meta, Course Hero
    a year ago

    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?"

Intuit Inc. is an American business software company that specializes in financial software. Intuit's products include TurboTax, Mint, QuickBooks, Credit Karma, and Mailchimp.
Intuit16 questions