How to create influence in a team of Mid-Level Engineers?

If it was me, I would look to create opportunities. I would also change the objective function here. It sounds like everyone on the team sees an opportunity created for them and fights for it. However, that's all about them. If you are instead trying to improve the product and project, find what will help the product the most. That will naturally lead you to the most impact.

Taro has a lot of videos with examples of projects that have the scope to help people make mid-level, senior, and staff project. Those often involve finding pain points (e.g. in the development process, for customers, etc.) and addressing them. Do that start to end. Find a high-impact opportunity, gather objective proof it needs to be addressed, then create a prototype solution. Present it and gain consensus. It's obviously something you are leading then. Once you convince others it is important, they can help you. And you can do it well, leading an improvement start-to-end. Including gaining adoption, documenting it, selling it, and measuring the impact at the end.

Occasionally, you are lucky and given scope within a project (e.g. retiring engineers or engineers who are promoted and give it to you). That's what many people are looking for. However, the thing most within your control is creating scope that delivers value. That's also most valuable for the product and makes the strongest case for a promotion, in my opinion.

Can you partition the influence into various segments so you can focus on one?

Perhaps another way of phrasing this is from the knowledge perspective. Influence comes from having more knowledge about a specific (important) area, so that people naturally come to you with questions.

Can you find a segment that is less crowded and become the expert on that? In the ticket backlog process you mentioned, too many people are raising their hand, so it's hard for you to have the influence you're looking for.

However, if you dominate the knowledge about something specific that people care about (on-call process, feature rollouts, a new tool), you will organically become influential. Some important notes:

• This requires making a bet on something that you think will become more important. (Yes, there is some element of luck here.)
• You also need to ensure you "market" your knowledge and share it with the team in a helpful way, as discussed here.
• One way to find an under-served domain is create the domain! i.e. invent a new debug tool or introduce a helpful new process for your team. This becomes increasingly common at higher levels, and it's what David mentioned above!

Which game would you rather play?

• Game 1: The rules and prize are well-defined, but you need to fight past 5 other talented, hard-working people in order to win. A couple of them have more than 2x the experience in this game than you do!
• Game 2: The rules are hazy and the prize can be either lower or higher than that of Game 1. But you are literally the only competitor.

Playing Game 2 is a no-brainer. It's riskier, but it's way more fun than Game 1 and you have far more control over it.

As you might have guessed, Game 1 is competing with each other for scope while Game 2 is going off on your own path, innovating, and creating your own scope.

At a Big Tech company like Snap with such incredible engineers, I am sure there's technical scope growing on trees - At Meta, there was no shortage of jank and stuff that was on fire. You just need to put in the effort to find it. Stop fighting in The Hunger Games and go be a fruit picker instead, searching for those trees.

In terms of how to create your own scope, David put it beautifully and we have a bunch of in-depth, real-world examples here: [Taro Top 10] How To Create Scope As An Engineer

Best of luck!

Like others have said, finding your own scope is the way to go here.

One undervalued opportunity is to resolve problems that sit on the intersection of domains. This means not limiting yourself to the engineering org, but look for where engineering interacts with other orgs such as Product (or infrastructure/platform in other places).

Usually the most problems exist here with the least number of people paying attention to them. Resolving the tensions between data science and data engineering was where I made most of my impact in my first Head of Eng position. A close second was resolving issues between with our security & compliance teams (data privacy, data residency issues, etc.)

TL;DR - look for opportunities to influence cross-functionally or at least let the issues that occur cross-functionally guide what you could work on.