Hacker News new | ask | show | jobs
by FennNaten 3828 days ago
From what I've read, I'd say that you seem a bit too soft for a team lead. That's something you can improve though, but it looks like it's a bit late for this project.

A team lead's role's spread across several areas: ensuring the project is set up in a healthy way to optimize quality/speed ratio, mentoring team members, and working with product managers (if applicable) to solve problems/remove obstacles which can harm the project.

From your narrative, you seem to cover first and maybe second point, but be completely off the loop on the third one. When faced with a defective team member as K seems to be in your story, you have to solve the issue. Start with talking one-to-one with the problematic element to see if things can be settled, and if not, go up the management chain without hesitation, explaining clearly why K's behavior is harmful and proposing some actions.

You say that you're 'not invited' to their meetings, and that's an issue because you mustn't rely on 'being invited', you should be the one who drives the thing and invite the others. If you don't rise up and speak for yourself, nobody will, and the blame will fall on you. A lead is not passive.

One important thing is putting each of your action in the perspective of the project. You're not 'pointing finger' at a coworker, you're stating that the project can't move on and is at great risk because of some missing parts, and you're willing to work with the responsible of those parts to have them done.

Same thing for your reviews, you're a lead, you shouldn't be given a paper to sign and vague excuses. Firmly request detailed explanations, and if not provided refuse to sign anything.

If after taking enough actions, things don't resolve as they should, start looking elsewhere for work. A company which fails to take the good advice doesn't deserve talented devs, and there is more opportunities for talented devs than talented devs to fill them up.

But on your end, don't accept tasks as lead if you're not prepared to assume the 'lead' part of them.

[edit: formatting]

1 comments

There may be some truth in this, but I think it's overstated. The OP did speak up about major issues with the project, even suggesting moving people from the front end team to the back end team, which was done.

I don't think there's much one can do about an co-worker at one's own level, who is successfully blaming everyone else for the project's problems, accumulating influence, and driving away competent subordinates. You just have to get out. Eventually management may figure out the real problem, but if they don't get it yet, you can't wait around for them to get a clue.

From what I read, OP did speak up at the beginning to say that backend was late, but never directly put K's methods as the center issue, to avoid 'pointing fingers'.

Even when transferred team members complained, before leaving, OP didn't state in the text that anything was brought up to management.

There are orgs where managers 'above' the team lead level are completely clueless about the technical side, and OP's company seems to be of this type if K's getting away with her behavior, meaning that she can bullshit her way through this if nobody on the same level rises the issue.

Still, I'd agree with getting out of this type of org anyway, but upon reading I just feel like OP didn't 'fight' properly. There are several levels of action that one can take in this situation: trying to influence the coworker's behavior, face to face discussion, documented report of what's wrong to management, asking for an assessment of project state by another experimented tech lead... And these actions have to be taken early on, quitting being the last resort.

Note that I'm bringing this up because I haven't seen these mentioned explicitly in OP's writeup, so I assume that none of these strategies have been tried, but I may be wrong.