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

Profile picture
Mid-Level Software Engineer [L4] at Snap24 days ago

Hi. Sorry for the long post.

My manager is quite happy with my performance as an IC, so in our 1:1s during feedback sessions, his suggestions for me are usually around increasing my influence within the team. Drive decisions, improve processes etc.

To add some context, Snap has a HUGE L4 band. Bigger than most companies (L5 at Snap is equivalent to E6 at Meta). This means we have a LOT of L4 engineers.

So right now I am in a situation where my team has 6 L4 engineers, ranging from 3 years of experience to 10 years of experience, with me falling towards the lower end of this range. To make matters worse, we also don't have a TL or Principal Engineer in the team. Which means we don't have a "guiding" engineer in the team to help "decide" on important technical decisions.

This has some consequences.

There's a big scope for "showing influence" in the team. Since we don't have a TL, every important decision is an opportunity to influence the team. And literally every L4 engineer is trying to jump on that ship. So we have this situation where people try to out-influence others (not sure if thats a word). This leads to lots of debates, lots of pointless meetings, and people eventually "fighting" over trying to be the decision makers for a decision.

A real example scenario: we recently had some discussions about improving our operational tickets backlog process, and literally every single L4 in the team wanted to write a doc on it to suggest improvements, to introduce a process to make the ticket backlog handling better, to show "influence" in the team.

I guess my question is, in a team like this, how should I try to build my influence ? I realize that everyone in the team is trying to achieve the same, so what can I do different. I know this is not a unique situation and very very common among more senior ICs, so hoping to pick their brains.



  • Profile picture
    Senior Software Engineer [IC3] at Nvidia
    24 days ago

    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.

  • Profile picture
    Tech Lead/Manager at Meta, Pinterest, Kosei
    5 hours ago

    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!