How to be an effective senior engineer?

This is a great question and topic and I appreciate the context you've given around everything.

From your writing alone, I can tell you are doing what you can and taking every step in the right direction.

The sense that I get is that the feedback you are receiving and the structure within the team is very informal. It seems like the feedback given was more offhand and not part of targeted growth conversations. Let me know if I'm off here. I'm going to work under that assumption.

With that, I think what could help your situation is adding structure.

Given what you're experiencing, to start I'd recommend asking your manager to have a conversation about growth to get a sense of where you're at and what you can improve and start working toward to ensure you're succeeding at your current level and can start thinking about the next level.

Let your manager know that what you'd like to do is look at the current level expectations and the next level expectations. You'd like to discuss them and categorize where you're at with each of them as a "red", "yellow", or "green." All of this should be done outside of the context of the problems you brought up in this question. It should just be a general career growth discussion.

As you go through each expectation, you can ask questions that get you more info on what sort of things would get you to a green (from a red or yellow). "What actions would you recommend to bring me to a green?" Or you can suggest some. "If I started doing these things by this date would that get me to a green?"

Color coding:

Green: Has been meeting this expectation for some time and shows that will continue

Yellow: Has started to meet this expectation but needs to show it more continuously

Red: Has not shown this expectation yet or has only shown it minimally.

The reason I recommend this exercise is that it will move you away from the offhand feedback to a higher level. Once you have the higher-level picture, you can take that into your current project and figure out how you can apply it there. You can also more easily align with your manager on why you may be taking certain actions. "Based on our discussion around expectations, since these were my biggest areas of development this is what I'm working on."

I'll quickly jump back to your first question:

• Let your TL know you'd like to take on more responsibility and ask how you can help. Ideally, you could be involved in a more leadership capacity. Ask if they would be open to that or if any ideas come to mind for them. If you have ideas of ways you could take stuff off their plate so they can do stuff they want to do more of, then feel free to suggest it
• Find some other area to excel or be an expert in. Something that will be memorable by the stakeholders. It could be just having a really solid understanding of the technicals, shipping before deadlines, cutting scope, giving really memorable demos, being a role model for communication, creating high quality documentation, there's always room to stand out.
• Be ok with just doing what the TL expects in a really solid way. Sometimes the opportunity to shine won't be there as much. That's okay. You could let your manager know that you'd like to take on a leadership role in an upcoming project; or you could find some opportunity for improvement and try to make it become a project. If you are the one bringing it to the team, you'll almost certainly be the one to lead it.

I hope this helps and I know this topic has a lot of nuance around it. I offer coaching calls that are free for the first 15min one. Feel free to take advantage if you'd like to discuss this in more detail: https://superpeer.com/careercutler

From what I'm seeing, I think you're doing well and now the problem is being in a team of people who may be working constant crazy hours vs the on occasion crazy hours. Unfortunately, it is true that the more hours you put in the more work you get done, but there is obviously a limit to what can or should be done. I'm in a position myself right now where I just don't enjoy the work being given to me and need to find something else to do. As a reminder, level of ambiguity is relative to how much knowledge you have in the area. I don't like pulling the long hours people like your teammates like pulling as it implies there's just an inefficiency in how the work is being done and you should take some time for higher leverage learning to make the process of the main work go a lot quicker. Some folks may not agree with me, but then its their prerogative to work those crazy weeks while I continuously leave early and enjoy my evenings.

For the 2nd point about long hours, do you have a handle on why the whole team is working so hard? Is this a particular crunch time, or is this just the working culture of the team? Sometimes these crazy hours are opportunities to revamp something a process slowing everyone down (e.g. on-call or post-mortems), or perhaps create a quick utility tool that could help people.

This is also surprising to me since I know Meta had 2 rounds of layoffs recently, and my impression is that no work got done in the weeks surrounding the layoffs since there was so much chaos and uncertainty.

My advice on the topic of long hours is to work smarter and not harder. A common affliction among software engineers is Parkinson's Law:

Parkinson's Law: the old adage that work expands to fill the time allotted for its completion.

If 6pm is a hard stop to get your work done, do you have a clear idea of what absolutely must get done? This is really an exercise in prioritization, so here's a video about evaluating team importance and the masterclass about time management.

I really like the idea of getting small wins (in a company like Meta, 1 diff every day is much, much better than 1 massive diff every 15 days). And you absolutely should collect input about timelines and priorities with your TL and manager.

Also related is the topic of avoiding burnout, since you're in a high-pressure environment with long hours. Kuan and Casey have great thoughts about that here.