How to talk about team instead of just self?

Having team influence is part of being mid-to-senior level. You-scope is entry-level scope.

I am a little confused at the phrasing here, though. You’re asking how to talk about it, but I’m not sure if you are actually doing it. If you don’t know how to enunciate impact, that’s a general growth area and should be something your manager or mentor is able to aid with directly. If you are coaching through effective code reviews, and have taken some common feedback and socialized it as code guidelines for the team, new lint rules, or whatever… then you are having team impact. To enunciate that you need to show that there were X reviews in a given period with Y problem, and now it never happens.

If you’re not having team impact that’s a different problem than not knowing how to talk about it. You should assess what you are good at, and be spreading that to the team through process and training. You should be assessing what you and the team could be better at and getting the help from others to fill those not just for you but for the team. You are close to the problems the team has, you should be starting to assess what those are, and either ideating solutions or seeking them from others if you can’t figure them out. I wouldn’t put it explicitly on you to be prioritizing these, getting them scoped, getting them on a roadmap, getting resources, and so on… that’s a little more senior-scope, but you should be starting down this path and getting senior or manager aid to get the rest done.

Does your team have a set of benchmarks or goals? If so, I'd start a discussion around what success looks like for the team on various dimensions, eg. Quality.

Once you have that defined, it should become much easier to document how your work ladders up to the team goals. When you have conversations with the team or manager, you should always phrase your work in service of what the team cares about.

Here's an example:

Team goal: reduce flaky test failures by 60% this half

Let's consider 2 ways of phrasing the work you did here.

Poor phrasing: I fixed all the flaky tests in the module that I own.

This is not a very good way of describing what you did. It focuses on what you did in your silo, but doesn't connect it back to what the team actually wants.

Better phrasing:

• We started by fixing all the flaky tests in the module that I'm most familiar with.
• Thanks to Mary for the help here, this went way faster with her contribution
• We still have several modules left to hit our goal, but we created a doc which outlines the process we used to identify and fix flaky tests, so it should be much easier for all of you. I estimate that repeating the work across 4 more modules will let us hit our goal, and here are the candidates I propose we work on next. Let me know if you have questions.

This is much, much better. You start by providing a rationale for why you started with a module, thanked someone on the team for their help, and then you went the extra mile to make it dead simple for others on the team to contribute. This is more work than the first phrasing, but you'll be perceived so much better.

Thank you for great advice Lee & Rahul. As a mid-level engineer, I do work on many things that has team-level impact. but while talking about it in quarterly conversations I feel stuck and not know how to effectively communicate impact I was making/trying to make

On top of the excellent thoughts from Lee & Rahul, here's my thoughts:

• At the end of the day, you aren't just doing work at random (or at least you shouldn't be): Every single task you do should further the team in some way.
• Here are some ways your work can advance the team:
  • Land some impact towards a team KPI/OKR - This is the most common one. A super common example of this at a larger company like Yelp is that the team needs to boost metric X by 10% this half and your project contributes 1%.
  • Makes the team more efficient - This kind of work is called "Better Engineering" at Meta. This includes things like refactoring, improving the oncall process, and making internal tools faster.
  • Improves the quality of your team's product - This can be design polish, performance improvements (e.g. making APIs/pages load faster), and fixing bugs.
• Whatever it is, you should understand the broader context behind whatever you're working on. For entry-level and earlier mid-level engineers, their mentality is mainly "I am writing this code, because I got put on this task/ticket". Once you start pushing for senior as Lee mentioned, your mentality needs to shift to be more high-level, seeing the forest instead of just the trees. Deeply understand why you are investing your time wherever you are.
  • To get that more "bird's eye" view of what your team's goals are, talk to your manager, tech lead, and senior/staff engineers on your team.
• When it comes to communicating accomplishments, try to weave in "We" as much as possible instead of just talking in terms of "I". Accomplishments are rarely done in complete isolation. For example, take this multi-million dollar SEV I fixed during my time at Instagram. It was a collaborative effort between myself, an iOS engineer, and a data scientist (and I made sure to give them a ton of props for their support). Spreading thanks is crucial towards building that social capital you need to become a true senior engineer.

On a related note, I recommend this in-depth write-up I did on writing stellar project update posts (which covers the thanks angle).