How to deal with tech lead stealing your work?

I don’t know, seems like a bad place. But you get to take advantage of it: they pay you for doing nothing. I would even go further and say tell your tech lead in advance what you are gonna work on, so perhaps he goes ahead and implements it. Or even, write buggy code, add only your tech lead as reviewer and wait for him to copy paste it and merge it with his name.

In any case, spend your working hours looking for a job.

> A few week passes, tech lead submits a PR for a barely related ticket and, instead of cherry-picking my commit, simply copy and paste my code into a new commit that he authors, commits to the main branch without any reviews and closes his ticket.

> I have to abandon my PR without any reviews and close the ticket saying it was made redundant by the other newer ticket/PR the tech lead worked on.

Ok, so the lead reviewed and committed your code. Close the PR, thank the lead for committing your code and move on.

Make your work more visible.

When your PR is ready, send a friendly note to your lead, their manager, and the PM, saying that you'd like to get it into the next release, and it's ready for a review.

Sounds like he has a second job. I would bring this higher up the chain if it happens again. Also have proof with code commits you can show as evidence.

Finger-pointing someone higher in hierarchy always is a bad idea, even if there is clear evidence.

Talk personally to the lead first... If you can 100% exclude misunderstanding and the boss likes the lead dev, I would look for a new job, but:

While doing it, be professional. Keep doing your work (even if it is not accepted), don't be mad or raise your voice. Collect evidence and print it.

If you found something new, you will have to talk to your boss. Have the printed evidence with you and tell/show him, as soon as he asks why you are leaving. Maybe you can prevent others from having a toxic environment by this.

Wait, why does it matter who actually authors the commit that makes it into the final code? Does that come up in performance reviews or something?

If another team member copied my code and pushed it through without going through a proper review, I would just assume they were working on a bunch of different things and probably didn't want to deal with merge conflicts. Is that a possibility here, vs some sort of malfeasance?

But then again I work in a small team that generally trusts one another.

New job, no question. I’d consider putting together a document with the evidence of plagiarized code and piping it to the founder as a favor on your way out depending on how you feel about burning the bridge. And I’d only care about that bridge if I really needed their reference.

Whatever you do, ignore the comments about trying to reason with the lead. This person’s behavior is malignant and there’s no way that they’ll suddenly act rationally when they’re called out.

Seems to me that process is broken here. If there is suitable meeting, maybe it makes sense to raise question how does the process work. After you have been assigned a ticket, what is reasonable timeframe for PR to be accepted? Who should review and accept it? What is the process of committing normal work to main? How are old and new tickets tracked? Should there be linking to old existing ticket?

Don't focus on the stolen work, focus on the fact that there should be process and it should be followed for normal work.

> Keep reminding the team I need a review but only the tech lead actually reviews anything

idea i (less healthy):

maybe that gives you an angle -- if the tech lead is behaving like this with your other colleagues, maybe you can privately agree to review each other's PRs promptly, and cut the tech lead out of the review loop! starve the environment of unreviewed code stuck in limbo for your tech lead to steal, see what happens. this would be dysfunctional in a different way, but hey, a change is as good as a holiday, right?

idea ii (more healthy):

re: "reminding the team" to review PRs, a different way to do code reviews is "pick a victim". pick a specific non-tech-lead colleague and request that they review your PR. maybe roll a die or round-robin them to avoid picking the same colleague each time. that way the responsibility can't be diluted and you can hold a specific colleague accountable .

before you start doing this, you could call it out in a team meeting (standup? retro? having a chat around the coffee machine?) so everyone has a heads up that you're going to change things. you could even say something like "i've noticed that PRs sometimes get stuck in limbo for weeks without review. to spread out the review load, let's try having each PR author picking a specific person as the reviewer. pick a different person each time. if someone asks you to review, please leave a review in a day or call out if you're overloaded and need someone else to step up and review".

If the founder is in earshot and/or you get any pushback, you can say that spreading the review workload and working to get changes through review promptly should increase the velocity that the team is able to ship changes! This is (a) likely to be true, and (b) will make it much harder for someone to argue against what you're proposing, because shipping changes faster is what the founder wants.

If you can easily prove it with just few links - escalate directly to the main boss.

He either fixes the problem or doesn’t care - either way you know what to do next.

Unless your manager cares about your commits then it doesn't matter at all

Call out the bullshit. Say why are you doing this that way? Like I’ve fixed it right there. Do it infront of the entire time every time. One of two things will happen. He will quit before you or you’ll get frustrated and leave anyway.