Dealing with conflict with your TL

Is this the only project you're working on? Or at least the primary project? If so, I'd recommend upping the amount of communication with this E5. Perhaps setup a weekly 1:1 with them.

He’s also said stuff like you don’t seem to be working much on this.

One thing I'd like to comment on here is the value of "showing your work". Basically, it means leaving a paper trail of the work you're doing, so you have ample evidence to refute this kind of statement.

Some of the work we do as engineers naturally has a paper trail, e.g. code we write. But if you're doing exploratory work or learning more about a codebase, it's up to you to share your learnings. I'd recommend posting on Workplace with what you did, why it matters, and what the next step is. This has 2 benefits:

1. You invite feedback from the TL and others about the work. This can help mitigate the issue you called out around the moving finish line.
2. You demonstrate that you're working diligently on things that are important.

From the outside looking in, I see 2 things:

• Your tech lead is likely frustrated that you aren't meeting his expectations and isn't doing a good job expressing it
• You're getting pulled around and no one is setting the pace for the work you own

My guess is that the E5 might have planned the project around your ability to hit their expectations for E4, and you're missing those expectations (which is frustrating him). Given the scenario you described and your behaviors in it, there's some gaps I noticed:

• You are letting others drive the navigation of the project
• There's a lot of mentions of people saying/agreeing on things, but no mentions to how it's tracked

Building on this rough view, this doesn't feel (to me) like a scenario I'd expect a E4 to struggle with (and I'm extracting my guess of the TL's behavior based on this). At E4, you need to dictate the pace of the work you own by driving decisions, timelines, trade-offs, and alignment for the work you're implementing.

Given how there's competing deliverables and a lack of alignment, there's clearly E4 scope in my eyes. I think the main behavior change that needs to happen is driving alignment. There's 2 parts to this I'd recommend you to focus on:

• Whenever teammates/xfn staleholders aren't aligned about the deliverables you own, you need to be the one who's in charge of the decision. You need to be the one getting everyone together to make a decision, identifying and looping in the right stakeholders, and creating & leading meetings to get people to talk (and making the call if things need to go that far). If your manager or TL are the ones who frequently end up leading the discussions to clarify your work, you'll likely trend away from E4.
• Document decisions. It's one thing to get people to agree on things verbally, but it's another to have proof that they did. Whenever these discussions happen, have at least 1 person taking notes (or be the one who'll volunteer to take notes). At the end of the discussion, repeat the key decisions to double check that everyone agrees to what was said. After that, publish those decisions in the project channel (the more public the better). If you don't feel people will have confidence in what you say, get your TL or EM to post for you. Since your TL is the main point of misaligment, try having them post these updates. This way if they question what you're doing/prioritizing, you can pull up a post of them publicizing the decisions that led to your current priorities.

Hope this helps!

Many great points have been raised already, so I just want to highlight one thing in particular.

If your primary contributions are "disambiguating stuff," treat alignment as your "deliverables" rather than landing code / creating technical artifacts.

Given that "alignment" is not as easily observable as code, here are some things you'd want to consider putting into practice.

• Document all the ambiguity you currently observe and what's required to resolve it (stakeholders, data, etc.)
• Pull your TL into alignment meetings that you are driving or at least CC him on the meeting and the notes sent out afterwards.
• Update a running doc to show the ambiguity getting resolved weekly (maybe more frequently at the beginning until the tension resolves)

I would caveat that there's a decent chance that your TL expects you to focus on contributing more code vs. resolving the ambiguity. In this case, you should present a clear case for how investing time in alignment upfront will save time overall, which sounds like you already have evidence for.

You want to shift his focus on solving the problem vs. blaming you. After resetting expectations, the best person to step in to resolve the ambiguity becomes more of a tactical matter.