3

Dealing with conflict with your TL

Profile picture
Entry-Level Software Engineer [E3] at Metaa year ago

I have been having a hard time dealing with my tech lead. He’s e5 and leading our project. I’m aiming for promo end of this half and I feel like he’s really using that as a weapon against me.

For the project I am on, he gave me some deliverables. For one of the deliverable d1, I pushed back as there was no clarity. He basically said you have to do it or someone else will. I pulled in my manager and eventually the manager said it’s his project, his decision.

Fast forward, after spending a good week or 2 on this , we were asked to stop the project due to the alignment issues I had highlighted earlier.

The whole deliverable d1 was de prioritized and I was asked to work on something else (d2). It’s close to the end of the half now and the Teach lead is asking me to do more work to show that d1 made any progress and it was landed.

Despite working super hard on this, I have not clear deliverables. I think this is a directional problem. A lot of this was out disambiguating stuff. He’s also said stuff like you don’t seem to be working much on this.

I feel quite frustrated that despite working a lot the TL doesn’t seem to acknowledge any of the work or doubts cleared.

  • How do I deal with this when I keep doing things and he keeps moving the finish line slightly ahead?
  • I’m also tired of his snide comments such as this really isn’t e4 scope but I can say it is for you.
187
3

Discussion

(3 comments)
  • 4
    Profile picture
    Tech Lead/Manager at Meta, Pinterest, Kosei
    a year ago

    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.
  • 3
    Profile picture
    Engineer @ Robinhood
    a year ago

    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!

  • 1
    Profile picture
    Founder of Expanded Skills • Former Head of Engineering
    a year ago

    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.

Meta Platforms, Inc. is an American multinational technology conglomerate based in Menlo Park, California. The company owns 3 of top 4 social networks in the world: Facebook, Instagram, and WhatsApp. More than 3.5 billion people use at least one of the company's core products every month.
Meta279 questions