As a tech lead do you cover for your team's incompetence
Posted by Aggravating_Yak_1170@reddit | ExperiencedDevs | View on Reddit | 216 comments
I have 6 devs in my team, and some of them are really bad they take a month to develop a simple feature which ideally shouldn't take more than a week even after that it is very incomplete not a production grade. This is after i do the technical analysis and tell them exactly what to code and where to do what.
I provide strong feedback but it keeps happening and they don't seem to care sometimes I just spend half a day to fix it myself get it over the release after multiple bug reopen.
How do you handle this, for our organization it is not strong enough reason to fire someone. Is it a expected responsibility of a tech lead or what could I do to improve this situation.
EmbarrassedSeason420@reddit
This post is extremely vague.
The poster is likely russian, Polish, Ukrainian or from Eastearn Europe
Some AI tools can replace your junior developers.
Those AI tools will do exactly what you tell them.
Aggravating_Yak_1170@reddit (OP)
I am not from any of the country you mentioned, and it is global team and devs are from all different places only 1 is among the place you mentioned and he is good.
it will not be even remotely possible to replace the devs with AI in our project . We tested a lot of usecases
Lotus_Domino_Guy@reddit
I think they need more hands on help, maybe pair coding or else better lay out the tasks and don't give them features to do, but try giving them specific subtasks and build their confidence with successes. Its awful sucking at your job, especially so bad that your works gets rewritten.
thisismyfavoritename@reddit
wouldn't that be the responsibility of the team lead? If they are coached properly and don't want to work then they should get PIP'd and fired. Not much else you can do
T0c2qDsd@reddit
Yeah, this is basically a manager’s job. If you manage them, you should be providing this feedback & working within the appropriate processes. If you don’t, then you should simply let the person who is responsible for that know.
buttphuqer3000@reddit
Yup and often times that goes nowhere. I had a developer knowingly violate company and state/federal laws. Had local national guard data on his work laptop from his guard duty every other weekend volunteer gig. No encryption. Full Ssn for thousands (md nat guard). He left his work laptop at work and a crack head broke in and stole everything not nailed down. No repercussions. Some employees are just more equal than others. As this guy’s “lead” i’ve spent the better part of a decade trying to get rid of him to no avail. All documented.
BinghamL@reddit
Yep for some reason I've yet to discover, some people are just unfireable.
There are two devs on my small team that 100% phone it in. Months and even years of not following the most simple instructions repeatedly put in front of them (with hand holding), that the rest of the team has to then go back and spend their time cleaning up.
It kills our productivity, morale, and reputation within the company and outside of it as well.
I've been documenting and notifying my boss and his boss. They bring it up in meetings telling the two to pick up the slack, multiple times.
It's very frustrating. At this point I'm convinced the two devs have serious dirt on a higher up. It's the only thing that fits. It would be cheaper and more productive to fire them.
Anyway, been applying and the market isn't doing me any favors right now so I may be stuck in this longer than I want to be. At some point though, it's a job. It seems part of my job description has changed to include "do most of their responsibilities as well, and let them get paid for it."
johnpeters42@reddit
At that point, you could still push for "Look, pay them to play video games if you want, but get them off my team where I have to clean up their crap".
T0c2qDsd@reddit
Sure, but at a certain point it’s just… not your problem anymore.
If it’s documented and nothing is happening? As long as it doesn’t impact your performance review, then it’s not your problem. If it does, then your options are to find a new role or change your estimates to cover making up for that person. But either way unless you have actual management responsibilities + powers, it’s not /your/ problem.
Spiritual_Chapter589@reddit
Golden answer
PoopsCodeAllTheTime@reddit
This responsibility should be on a manager that is in charge of money-related decisions. A team lead might be lower on the rung.
buttphuqer3000@reddit
If op has a team full of “30 years of the same year repeated” types it’s not really possible to lead without a cattle prod and usually the manager has that.
dagistan-warrior@reddit
to cheap to fire
HoratioWallpaper@reddit
My bet is they’re are offshored
McN697@reddit
If a dev is taking more value from your attention than the output they produce, they are a negative contributor. Here, we’re seeing low quality code, causing Production issues which wastes the team’s time. If you can’t fire, then train or isolate them. Isolating can be making sure they only work on tooling or low risk features.
Ahhmyface@reddit
Be careful with that first line, because if you yourself are particularly talented, everyone is a negative contributor.
I've been in many situations where a 2hr fix for me takes somebody else 6 days, 3 1hr meetings, 4 pull request reviews, and a follow up story.
Sounds bad, sure. I wish had more of me. But I don't. Does that mean that I write everything myself?
I don't think so. They need to learn. The bus factor is too high. I need to be able to take vacation. I need to be confident when I get pulled into another project somebody can handle it. That next fix might take me an hour and them 6 but it still saves an hour of my time. If I leave the company they have to maintain it. Their boss has an interest in their development.
I think that's simply the role. You're sacrificing the speed of delivery to build a team, help a company function and improve.
zck@reddit
Additionally, maybe next time they have to touch that area, it only takes 2 days and a 1 hour meeting.
fuckoholic@reddit
or it will take longer because the guy left for greener pastures and you're now training another dead weight
MoveInteresting4334@reddit
Yikes.
Wait.
fuckoholic@reddit
you need to learn to quote not out of context. I am always happy to teach only then to realize that it's a waste of time like trying to teach a dog to sing and then it's my motto.
MoveInteresting4334@reddit
Or maybe you should learn the definition of the words “never” and “anything”
You, by your own admisssion, never teach anyone anything. Those are your words. They are definitive and conclusive. “Never” leaves no room for interpretation. “Anything” leaves no room for interpretation.
Maybe you should also learn how to communicate?
Maert@reddit
I think that ship has long sailed :)
BackgroundNote8719@reddit
I love teaching dogs to sing. If they assign me with a novice developer who just aren’t good enough, I will be more than happy to teach him knowing that it won’t lead us anywhere.
fuckoholic@reddit
Exactly my point. I am happy to teach but it always leads nowhere because learning only happens when you're in the zone and for that you need a lot of time and preferably alone (with a book). I know you tried sarcasm but failed cutely. There is no logical contradiction in my statements.
BackgroundNote8719@reddit
Actually. No. I am not being sarcastic. Haha. I actually do like to teach novice even if it doesn’t lead anywhere. 😂
TimMensch@reddit
I sympathize. I've been in that position myself, and I'll do my best to train the team around me.
But sometimes the answer is to give detailed reports about their performance to management. OP says this doesn't work at their job, at least with some contributors. In a normal market I'd say to find a better job, but in the current market I'd really hammer it home with management if a particular developer literally never actually finishes a task.
And then I'd just do the work myself.
I'll put in a reasonable effort to help teammates understand. I'm not just throwing everyone under the bus. I won't even let them take a month on a one day task without intervening and trying to help them understand what they need to be doing. If they still haven't made progress after a week and I've gone through several meetings and hours of my time have been wasted trying to train them on this one hour task, then I switch to plan B and move them into non-critical tasks or have them write additional tests or something.
I mean, ultimately it's not your responsibility as an IC to ensure that the company can function while you're on vacation or after you leave. It is your responsibility to communicate to management what's required to make that happen. And then when it's time for vacation, you take whatever vacation you need, and if development grinds to a halt while you're gone, that is hard evidence that what you've been telling management is accurate.
If they try to get you to not take vacation, then you take a hard line, and yes, eventually you start the job search and find somewhere reasonable to work.
DWLlama@reddit
Maybe I misunderstand what you are saying about tooling here, but to me that would be high risk, because won't issues with tooling affect the velocity of the whole team?
McN697@reddit
You can skip bad tests or bad steps in the CI with low effort. Correcting bad code in production or building on bad architecture is not low effort.
It’s basically a way to “neutralize the bozos,” as Spolsky once wrote.
DWLlama@reddit
Skipping them has a different kind of cost, though. I suppose if you have to let unproductive engineers work on something, it's best to pick whatever has the least impact to the team as a whole, though.
PlayfulRemote9@reddit
This is really interesting because I often considering working on tooling/devex the highest leverage thing you could do to improve team velocity
McN697@reddit
Agree, the upside is very high and the consequence of failure is only the opportunity cost.
PlayfulRemote9@reddit
But you allocate that to the “worst” dev rather than the highest leverage/staff which is the norm!
cheater00@reddit
there's a lot of valid reasons why an IC would be taking up a lot of a lead's time, such as:
South_Ad3827@reddit
Are you making sure your team has understood what has to be done? You conduct some sort of workshop or a knowledge cross check session before they start coding? Your team needs to understand every transaction, every interaction and every edge case to be successful. Also, your team needs to spend some time testing the feature before they ship it to QA.
Lastly, do you write unit tests to make sure all requirements are covered accurately?
jonatkinsps@reddit
Yes to save face
mufasadb@reddit
What's the structure of your business, do they report to you? Who should be keeping them accountable?
Do they estimate their tickets then just miss timelines lots?
I think the short answer is it they report to you tell them they need to improve, if they report to someone else, tell the person they need to improve.
(Do so kindly and supportively assuming good intent at first )
mattbillenstein@reddit
Fire one of them - if the rest of them doesn't get the message and shape up - fire them too.
08148694@reddit
Is your organisation a charity? Consistently not meeting requirements and expectations of a job after consistent feedback and mentoring is definitely a valid reason to fire someone
Your company isn’t a government welfare program. Them not pulling their weight puts extra pressure on you and the competent devs, and the fact they get paid in the same ballpark as someone who doesn’t the job is a slap in the face to the good employees
old-new-programmer@reddit
I always say the place I work at is a charity. Bringing up "we should let so and so go" really just returns with "we should move them to a different team". No one talks about letting anyone go even though 95% are a drag on the top 5%. And it's really hard to sell another team lead on a member you want to get rid of... "Please take this guy who is under performing, I'm sure he will do better on your team." lol
ub3rh4x0rz@reddit
I can almost guarantee the company undercompensates engineers. Refusing to fire what sound like not just low performers but insubordinate contributors (in the bartleby the scrivner sense) tends to go hand in hand with that -- in a labor buyer's market, you have to be getting comp consistently wrong if you can't find better replacements for the loy of them in like 4 weeks
Steve91973@reddit
Hello. I can understand the frustration that you're faced with. Every team seems to have a mix of people with different levels of motivation, different styles of thinking, and different levels of experience. That is a complicated juggling act that doesn't always have obvious fixes.
Developers can be a sensitive bunch, and I know you're familiar with that fact. Strong and direct feedback is good, but sometimes, a developer won't always know how to incorporate it into what they're doing, other than whatever the immediate action is, like when trying to get a merge request approved and merged. In these cases, perhaps some mentoring and gentle guiding into the habits and methods (that you want to see more of on your team) might be helpful. Sometimes people need to feel like it's a "safer space" to not feel self conscious about sharing when they need help. And when you have deadlines approaching, it can be hard to find the time and patience.
If the team is generally "good enough", it could be beneficial to invest a little bit of "slowdown" to help to mentor and encourage the more junior engineers. The tradeoff that it introduces is something that only you can weigh the cost/benefit ratio of. In my experience, a bit of morale and encouragement can go a long way.
Good luck. It's not easy, but I imagine that it will be incredibly satisfying if you can figure out a solid way to get through it.
SoggyGrayDuck@reddit
You shouldn't be a lead if you don't want to teach
Antique-Echidna-1600@reddit
You own the teams outpost as technical leadership. A good leader always takes responsibility for their team. If there are shortcomings with an individual, that should be handled internally and corrected. Any deviation from this will cause mistrust in your team.
EnchantedSalvia@reddit
Perhaps they need a good talking to, if you don't mind my saying so. Perhaps a bit more. My girls, sir, they didn't care for the Overlook at first. One of them actually stole a pack of matches, and tried to burn it down. But I "corrected" them sir. And when my wife tried to prevent me from doing my duty, I "corrected" her.
TheWhiteKnight@reddit
This doesn't address OP's post at all. He knows he's the tech lead. He knows it's his responsibility, what he doesn't know is how to get lazy engineers to not be lazy.
And "Technical leadership" isn't the same thing as "Reporting manager". So, no, he's not responsible for the output of lazy engineers.
reboog711@reddit
Anecdote: I don't think this is universal, and plenty of people use "tech lead" to mean "People Manager of the team". I think they should be completely different roles.
TheWhiteKnight@reddit
Agreed. And it's hard to say if OP's engineers are reporting to him directly or not here.
Aggravating_Yak_1170@reddit (OP)
Yes they report to me directly.
pwnrzero@reddit
I have a team like yours OP.
I just took the most crucial projects and features under my own wing and developed them myself. Saved my own skin..and my own manager has noticed.
It didn't come soon enough to save my annual review, but if this keeps up I'll be due for a promotion in about 2 months.
As for the team? 8 individuals were let go, transferred, or quit when we didn't hand out free raises.
Cazzah@reddit
If you are a wfh organisation, might be also worth considering theyre simply not working most of the time because they can get awya woth it.
dudeaciously@reddit
I don't understand why you want to cover for them. Expose them and get them out of the door and replaced, no? Eventually this will eat you.
bwainfweeze@reddit
Would you rather have 6 devs completing the work of 4 engineers or 3 devs getting the work done of 3? How’s your boss going to feel having their kingdom cut in half and losing status?.
Lots of places stop hiring. Lots of places in trouble especially. And we hear from people already in trouble. Your assumptions are less likely to hold and you should ask first.
dudeaciously@reddit
I don't understand. So the alternative to having low performers is to just have a smaller team, for the same workload? OP should just replace the obviously unmotivated low performers. After the appropriate talking to and giving them a chance to improve.
bwainfweeze@reddit
That goes without saying. You’re talking about PIP like it’s a carrot and not all stick and acting like I’m the naive one.
In order not to scare the rank and file, most places that are in trouble tell management not to replace anyone who quits. Some of your coworkers have noticed this, and decided that saying something would cause morale to drop and so they either haven’t mentioned it or only to people they trust to keep it in the coffee shop.
If no one has quit then the only way to know this isn’t happening is if you’re actively hiring (not interviewing, hiring. I’ve worked places that were interviewing right before layoffs started). Or you PIP someone and discover you aren’t allowed to replace them.
Your job is to make the most of the resources you have to achieve the goals you’ve been given. And that means getting as much work out of your 0.5x engineers as you can. PIPing them is going on record telling them you think they suck. Yeah good luck getting 0.5x out of them a year from now. They’ll run on adrenaline for a few months and then quit or spin out.
You only get rid of the ones who are actually achieving less by participating than by being on vacation. And the toxic ones. And if you start badgering coworkers, you’re the toxic one.
dudeaciously@reddit
I am particular averse to toxic management, and very sympathetic to us tech workers in the trenches. But if someone is PIPed, and they are not allowed to be replaced, that is just management reducing headcount. Headcount is maintained by budgets. I have always seen empty seats get filled again.
What has me perplexed is the need to keep 0.5x engineers. Eventually, the lack of productivity will either wear out OP who has to do double the work, or get OP fired for being accountable for problems. Truthfully, OP is not being open with management. Bad environment.
bwainfweeze@reddit
That’s Illusion of Control, and you’ll want to work on that.
You don’t know that from context, and in fact you’re wrong.
Usually the person rattling sabers is a disgruntled dev who wants everyone to kiss his ass. His impression is that he’s the first or second best team member, when objectively he’s more like 4th on a good day. They’re trying to distract from their own failings. The ways in which they are not trustworthy.
You spend a lot of time talking to management about how those people he’s complaining about are less productive but more predictable and if you have to lose one it’ll be him.
The most over the top case of this, the person was surprised how muted his going away party was. Everyone was sick of just bullshit,especially the three leads (one, me, the other ex military, and hence zero tolerance for his bullshit).
maria_la_guerta@reddit
If they give a shit and are improving, yes. I'll cover for anyone in those cases. The other side of that coin though is that I usually don't recommend them for high profile projects until I think they're ready.
If they're not taking feedback, and not improving, no. Hardest thing about my job is having "the talk" with management about this, but I do.
The expectation of a tech lead is to level up your team. It's your job to bridge the gap between them not being perfect (which is absolutely reasonable), things still getting done on time, and the team becoming faster and stronger over time. If you as the lead are putting in your half to do that, and members of the team aren't putting in their half, that affects you and everyone around you.
It's not a fun part of the job, but it is a part of the job.
DeterminedQuokka@reddit
True. I will go out of my way to cover for people that I believe in. Or people that I think management has something out for.
Material_Policy6327@reddit
Same
Material-Smile7398@reddit
same
ExtraSpontaneousG@reddit
When would you have the talk with management? What would you be hoping to get out of that conversation?
1NqL6HWVUjA@reddit
Yup, this is the big determinant for me as well. I will always cover for and defend devs that care about the quality of their work, are receptive to feedback, and show signs of improvement (even if slow, or in fits and starts).
But I no longer expend any energy covering for smug brogrammers that think they're above their assigned tasks, which they inevitably implement terribly. Once someone has established that is who they are, I'm done going to bat for them. I'll give blunt feedback about what needs to be fixed, and that's it.
thashepherd@reddit
Ah. Brogrammers.
"Based on your level of personal growth, I think you're ready to operate without me covering for you" :devil_emoji:
Fidodo@reddit
I just let the numbers speak for themselves. When giving updates on the progress of a project you just say "the project is delayed because this story took longer than it should have and is blocked in PR because it introduced bugs". Then the rest of the story tells itself. "Who was responsible for that story?", "Why were bugs introduced?", "Why haven't they been able to fix the issues?". I don't like directly accusing people, I prefer to communicate progress from a team level and then dive into specifics when the issues are exposed.
crunk@reddit
Yep, the accepting feedback thing is the real difference. Had to do the very talk about someone who won't have it at all recently.
s0ulbrother@reddit
I’m not the tech lead on the team but I oversee the devs for half the project.
I don’t cover any of them but I ask the devs who are reporting to me why their statuses are, any questions, etc .
My team is pretty damn green or thinks they are better than they are.
sjones204g@reddit
The best team leads fill in the gaps in delivery hiccups. Full stop. If people aren’t pulling their weight, try mentoring, if that doesn’t work, escalate with your opinion. Get them off your team. Filter out until you’ve got enough winners to deliver.
xXxdethl0rdxXx@reddit
Ok, this is bait right? Every new sentence reads like a “nightmare tech lead” that I would probably make moves to fire or relieve of their position:
Maybe you haven’t been trained very well. Maybe all leads are like this in your organization. At the end of the day, you are absolutely not cut out for leadership whatsoever, without a complete and total—from-the-ground-up—investment in self-training. Read a book on this stuff, the very first chapter will tell you the same things I am.
Aggravating_Yak_1170@reddit (OP)
Actually, I expected a comment like this from some IC. Please get out of the mindset that all leads/managers micromanage. I am not a lead from day one. I spent over 10 years as an IC and know what micromanaging is.
Work is estimated by the devs themselves after it is assigned to them. A one-week estimate becomes a month with many nonstop excuses.
I always assign the first POC or spikes and let the devs do the analysis as a way of learning. "Exactly what to do" comes only after multiple failures, and I try to get some work out of that dev.
When you share this feedback and it keeps happening again, what do you call this other than a "don't care attitude"?
Looks like you are new to the industry and have a lot of prejudice towards people. I am sure it is fruitful for folks to work with you.
xXxdethl0rdxXx@reddit
I’m a manager with 15 years’ experience. There’s a lot I want to say here, but I won’t. I intentionally delivered some pretty harsh feedback, hoping to put you in a certain empathetic mindset, but it clearly didn’t stick. Good luck.
Aggravating_Yak_1170@reddit (OP)
That was my exact question and wanted answers here. How do you ppl handle this situations?
This team is not in the right path, I joined this org 4 months back. The previous lead from this team was fired for not meeting deliveries. Now I know exactly why it happened. Atleast now I heard feedback already from manager that team is doing much better work since I joined but I feel half of it may be I am covering for some poor devs, I don't mind doing it but I am already burnt out in these 4 months that I can't for sure do it for long time.
I don't want to be a person to run away from problems but rather fix it and it was part of that process I had came here looking for some answers if anyone have done this and turned a team around.
Round_Head_6248@reddit
You haven’t worked with lazy or incompetent devs, it seems. I’d love to see you „leading“ four Offshore devs who lied on their resumes about knowing the required language and frameworks, don’t understand anything yet ask nothing in order not to lose face, and aren’t incentivized to improve because they can do the exact same thing (aka nothing) in the next project for the next customer.
xXxdethl0rdxXx@reddit
This is clearly a fresh wound for you. I haven’t experienced this—offshore sounds like a special nightmare—but OP didn’t mention any of that.
Round_Head_6248@reddit
It's not hard to imagine this with nearshore or local devs either.
TheWhiteKnight@reddit
Yeah it absolutely sucks. It kills me to see features get punted into future releases while it's clear as day that the people working on them simply aren't putting in anything close to full days of work.
As a tech lead, it's not my responsibility to make people work who aren't, but it sucks to see. As far as managers to whom these people report to. I don't know what's worse. When they just accept that the engineer is taking 3 weeks to do a 3 hour job, and do/say nothing. Or when they do actually move forward to PIPs etc, and HR pushes back when the PIP goes poorly, and doesn't allow us to fire the person.
In my org, I'd say that a 1/3rd of our engineers are putting in 1/2 days at best. A 5th of them are even worse. It sucks. Thank goodness for the "10X"ers on our team.
Correct-Amount-5186@reddit
Sounds like my team. We have 3 people who are carrying an 8 man team, but even they are starting to lower their productivity to adapt to the other team members output.
kittysempai-meowmeow@reddit
I feel this so much. I could have written all of this too.
Traditional-Unit-274@reddit
stop saving them, let them break it, let them fix it. heck, let them code it there way. i know what it feels like to have a tech lead who thinks there’s only one right way to do it, gives strong feedback on any deviation from the perfection in his mind, shields juniors from their mistakes and fixes them without telling them and it creates a very stifling env. let them breathe, let them grow, stop babying them and then being mad that they’re babies, own your part in it
bulbishNYC@reddit
When I was a tech lead I didn't worry too much about it. Those are people the company chose to hire, this is the speed they move at. I do my best at unblocking and mentoring them, so in a couple of years they can get better. Anything else is not my problem. They could have hired more solid senior people in the US. But management chose to hire some juniors, offshore and set a low salary for interviews. So they got who they got, this is the consequences of their decisions, not mine. Let the managers above you worry about it at their paygrade.
EdelinePenrose@reddit
here’s what i would try in your position: - cover for them by negotiating more forgiving expectations/deadlines/timelines/scopes. - raise the minimum speed by streamlining code patterns into cookbooks/recipes/automation.
zambizzi@reddit
I used to, because I somehow thought it was expected of me, even though it goes against my natural tough love constitution.
In my early leadership years I would pick up the slack and rockstar shit into place. I burnt out pretty hard, eventually. There were no extra bonuses. No awards. No incentives to work harder when others didn't pull their weight.
It breeds a culture of dependency where people stop learning or pushing themselves. Rockstars are a threat to the project and organization.
After those lessons, I've gone full tough love. I communicate what's expected, very clearly, and set them on their way. I help when it's sincerely needed, but I'm willing to let people fail when it's clear that they're not really trying or just don't care. Then we talk about it.
This approach separates the wheat from the chaff, as they say. The good ones step up and the people who don't really belong there, fall off.
I'm going through this right now, where one person was especially trying to carry an entire department on his back. One guy who was nearly fired, has surprisingly risen to the challenge and is now thriving. It's awesome to watch!
Antonio-STM@reddit
An incompetent team is a refelction of an incompetent leader to a certain extent.
As a leader You should know Your team strenghts and weaknesses and account for them preparing Your team for success.
You sound like the typical boss who stands on His team at victories and renega them at failures.
Aggravating_Yak_1170@reddit (OP)
Unfortunately i was thrown in this team since I just joined this company and previous techlead was fired(t I think i now know the reason), I had no issues on leading teams earlier which I hired and built from ground up.
I am not sure why you people just assume things
Antonio-STM@reddit
We dont assune, we comment based on what You posted and commented.
BTW saying You were thrown that team adds up to what many of Us pointed out.
You forget that its a TEAM and You are a member of it and most importantly that You all work for a company meaning a BIGGER TEAM.
If You dont like to be a team member just call it quits and go work as a freelancer and stop pretending.
Aggravating_Yak_1170@reddit (OP)
Again don't assume, I never said I don't like to be a team player.
Your comment makes no sense and not at all relavant about this post. I asked how to deal with someone who doesn't deliver something on time. Again don't assume that i set the deadline and micromanage. It is a 30-40 lines of code for new api has no dependency on any other parts of the application, dev give a effort for a week which i was fine with it and they don't delever even after 3-4 weeks what to do with them?
Antonio-STM@reddit
Terms are given, one can only manage them.
At this point, OK whatever floats Your boat...
Nizurai@reddit
Do you break down big tasks or just let devs do them as they want? Do you write a proper spec? Do you write ADRs? Do you analyse the lead time and do anything to improve it? The problem is not the devs, most likely it’s your development process.
jessewhatt@reddit
don't be a 'savior' tech lead that swoops into everyones work and finishes it off. Your team will learn to rely on you and you will get burned out from shouldering everything.
Assign correct levels of accountability to your team, help them grow.
Traditional_Nose3120@reddit
Before HR admonished us not to, we used to refer to that type of engineer as a sock puppet: their face is getting the credit, but the lead is doing all the work with a strategically inserted hand. That kind of relationship is unhealthy for the company, the lead, and the developer.
Every developer starts off equally clueless in their career, regardless of where they got their degree from. Your job as lead is to make sure that with every ticket, your engineers are getting less clueless and more valuable to the company. The hard part is giving them the tools to be better without actually doing the work for them. If you’re finishing their tickets for them you’re never going to see them turn a corner.
The things I found helpful with problem devs:
People handle single criticisms better than laundry lists. Pick the thing that pissed you off most, then focus on that until they get it right. Then move onto the next abomination.
Break large open-ended tickets down into digestible chunks. As much as we lampoon AI for hallucinating, having too blank of a canvas invites unwanted “creativity”.
Never underestimate the power of a simple checklist. It helps focus the mind of the developer, and helps frame the conversation around a crappy PR.
Be absolutely clear that lack of compliance has consequences, up to and including termination.
Ultimately it’s on you to make the determination if the potential for improvement is worth your investment. If your feedback is clear and unambiguous, and you still get no traction, then the next step is to have the dreaded “this needs to change or we will have to involve HR” conversation. Have that, and if there is no improvement, then bring in HR for the inevitable PIP and managing out process. That’s the suckiest part of management, because even if they’re lazy and incompetent, they are still people with feelings, family, and a mortgage. But at the end of the day the company is a business, not a charity, and your first responsibility is to the company.
Certain_Ring403@reddit
Performance Improvement Plan (PIP)
tjsr@reddit
If you are letting devs run a month on a single feature without breaking it down and there being smaller work units, this is 100% a you problem from a leadership perspective. This sounds like a complete failure not only to break down and scope work, but have devs work collaboratively or to both seek and provide assistance to their teammates.
Too many at the management level ae really bad at breaking this kind of stuff down, it's something I've seen way too often throughout my career - and then they go and blame the ICs.
Aggravating_Yak_1170@reddit (OP)
The actual work is just small, it is broken down already where it will take only 3 days to complete and assign 5 days as effort. Here an example work is a simple api that do query and bulk delete from a table.
tjsr@reddit
Literally from your own words:
We have identified the problem in this whole scenario - it's either your communication, or that you're actively lying and contradicting yourself.
This sounds like yet another problem where the manager is the issue and thinks they're not.
Then it's already too big in many cases. It's pretty clear here that you don't understand software engineering.
Aggravating_Yak_1170@reddit (OP)
First try to be bit open minded, and learn to ask Qs to get clarified first instead of assuming things. I think you are a person who has a low trust, egoistic has lot of prejudice.
I came across many ppl like you. Its no point in explaining it to you. Leads are not lead from day 1, been a IC for 10+ years. I know it doesn't take more than 3 days max to write a 30lines of code for new api where all the db, routing interfaces already present which has no dependency and it is just do a query and bulk delete.
May be just because you are an IC not all IC is good and managers are bad.
bwainfweeze@reddit
If you recall in college, giving people a month to do a project often resulted in worse outcomes than two or even three weeks because they had too much time to procrastinate and avoid the uncomfortable parts. Working to a deadline is how some people work, especially neurodivergent people. And there’s at least 2x the density of neurodivergence in tech versus the overall population.
thashepherd@reddit
1) Blame yourself first as a leader and player coach. "WE succeeded. I failed." Every time. You are a force multiplier and servant leader.
2) Absolutely do not ever under any circumstances throw your guys under the bus in public. ALWAYS praise publicly and criticize privately.
3) Give them the absolute fucking beans in private if necessary. But always, always give them a ladder to climb. Radical Candor is a great book and a great philosophy.
4) Have the stones to (if necessary) get rid of the ones who aren't pulling their weight in order to keep the ones who ARE happy, growing, and working for you.
talldean@reddit
Did they appreciate you giving cover?
I'd work with my manager to let one or more of them fail sometimes, hold them accountable for their own work, and try to pull up the people who want to try pulling up.
If the manager cannot fathom managing them, you should look for new work.
stevefuzz@reddit
Letting people fail to prove a point is some toxic shit.
chrisza4@reddit
Not really. It is actually healthier than have zero room for any failure and never let people make mistake and learn.
talldean@reddit
There are some circumstances in which it’s the healthiest possible option, and this is possibly one of those.
stevefuzz@reddit
It's a balancing act and exactly why I went the architect route instead of management. You can't have a happy team if they can't trust their leader has their back, you can't have a successful team if people lack the talent.
toxicviruse64@reddit
Serious question, What if it’s the other way around? My tech lead is inexperienced and makes bad decisions daily that has cost us years of tech debt at this point. I’ve tried to lead him in the right direction but he is stubborn and controlling.
I usually end up having to clean up his “quick fixes” in some other random PR.
chrisza4@reddit
If I were you I will do this
That's it.
In your case, one thing I want to say is don't fix their problem for them even if they don't care. If it is urgent, you must make everyone know that they aren't performing and you need to do extra work to step in and do it yourselves.
Realistic_Ear4259@reddit
Own their mistakes, give them credit for the wins.
hader_brugernavne@reddit
Your organisation has issues if it will not fire people for being unwilling to learn and follow instructions. This is absolutely reason to fire someone.
Sounds like (if your version of the story is accurate) they are taking advantage of your willingness to cover for them, rather than doing their jobs.
Solid_Wishbone1505@reddit
Sorry, i dont have a solition but, If you are looking for new devs, I am a very hard worker and take pride in my work.
DWLlama@reddit
If you code like you write I wouldn't want to hire you.
Sufficient-Meet6127@reddit
Fire fast, fire often. You have to churn through a lot of bad developers to build a good team. If your developers know what you are doing, they will support you. Productive developers hate working with deadweight.
french-zoidberg@reddit
mistakes yes, incompetence no
urlang@reddit
Give them work that they are able to deliver to a reasonable quality
Break bigger projects down into smaller ones that can be assigned
Guide them away from pitfalls and give them clarity where they need it
You are not really a tech lead if you don't do these things. What do you think the lead part means?
ub3rh4x0rz@reddit
Literally nothing you said addresses what clearly resembles motivation and professionalism problems. This kind of indirect style is infuriating when you're a good contributor on a team with colleagues exhibiting those issues
cserepj@reddit
“This is after i do the technical analysis and tell them exactly what to code and where to do what.”
Sounds like too much micromanagent. Taking away the meaning and joy from the job. Part of this job is discovery.
If any of them is neurodivergent, you are causing them a lot of stress and unability to focus on the task. NDs can’t work on boring tasks. A task not to be boring must be interesting or challenging.
Aggravating_Yak_1170@reddit (OP)
No what I meant technical document with clear direction. Not to a level of code logic that he needs to write.
Exact issue is: I told him to make sure api is secure and not open. I did oauth setup gave him working postman script with demo credentials(which is outside of his scope for the task he was assigned), i told him specifically to secure the api verbally and also mentioned in user story. Now when I see the code there is no trace of any authentication it is wide open to public and he is a senior dev. This is just one instance that happened this week.
cserepj@reddit
In what framework is security something you add as code and not as configuration or annotations?
Aggravating_Yak_1170@reddit (OP)
That is an another big problem, this product has its own complete authentication system written, manages its own users and their credentials(ofcourse hashed). Can't get too much into the detail and also not sure why they have done it like this since I just joined this organisation 4months back.
Previous tech lead was fired just last week and reason manager not fully open with me.
ub3rh4x0rz@reddit
Honestly the person you responded to is just wrong. Security does not exist in a vacuum that code doesnt touch. If anything I'd ask what exact means of integration you expected and whether you communicated that precisely, because someone who doesn't know how to set up auth likely doesn't know exactly how they're supposed to integrate with the out of scope work you alluded to. That said it reinforces your assessment that they're exhibiting ~~laziness~~ passive resistance
stevefuzz@reddit
This is my experience with some outsourced code. I'd rather someone way over engineer security and hit a bunch of walls then just completely ignore the requirement.
forgottenHedgehog@reddit
If they can't do the regular work, they are not fit for the job. Being autistic is not a magic get-out-of-fuckign-around card.
cserepj@reddit
Did not say it was.
MoveInteresting4334@reddit
Or maybe you should learn the definition of the words “never” and “anything”
You, by your own admisssion, never teach anyone anything. Those are your words. They are definitive and conclusive. “Never” leaves no room for interpretation. “Anything” leaves no room for interpretation.
Maybe you should also learn how to communicate?
justwinning1by1@reddit
what do you discuss during dailies if you are not discussing about the progress of the work?
I am no fan of these dailies but sometimes they help a lot to avoid any blockers/distractions and speed up the development.
1:1, feedbacks and typical performance mgmt are already in place. Utilize them.
As a lead, your responsibility should be delegating, guiding, mentoring - not fixing their issues.
Mammoth-Clock-8173@reddit
I find daily standup is often mistaken for daily “status”. In part because of an underperformer on my team, I am trying to turn the language of standup into a more forward-looking, “what are you committing to doing today?”, because I really don’t care what meetings you went to yesterday or whatever. I care about what progress you said you would make and whether you did, and what you think you can do today.
ub3rh4x0rz@reddit
Standup is for blockers and announcements relevant to the whole team. Not "what did you do yesterday, what will you do today?" That is still a status update. Set the expectation that ticket status is to be updated before standup, and deal with chronic abusers of this protocol 1:1. Usually saying "we expect this so thay our daily standups dont devolve into status updates" helps motivate them
moonlets_@reddit
As the lead, you are responsible for the team and its work, but that doesn’t mean you DO it yourself. It sounds from what this post says like you’re doing a ton of handholding that is making their and your lives harder. Strong feedback isn’t going to help, it just makes people that know they aren’t doing well do worse. You need to show, not tell, and that means getting your team members to build confidence by letting them do things themselves instead of you finishing their work, and letting them meet the deadlines you have. I think need to give people room to fail or succeed. This is also a tough thing to do, and not everyone is able to.
fued@reddit
Way too often. Bring it up with team lead and they say there is nothing that can be done.
hockey3331@reddit
I will but usually these are junior people and it's expected that they hit roadblock. I'll usually to a "tag along" session where I take the reins of the project and explain my workflow.
Its lead to a few breakthrough since sometimes people just don't know what the6 don't know and sometimes I make assumptions about their knowledge.
But they usually care. If they don't care...then I guess you guys have to understand why and if you can do anything about it.
NullVoidXNilMission@reddit
Nope
vanisher_1@reddit
What kind of feature are we talking about?
redbarone@reddit
These are opinions.
DoctaMag@reddit
To the outside? Always, 100%, defend everyone right or wrong. No one denigrates my team. I may have to take them aside later and tell them why they fucked up but I never let anyone give my team shit.
Internally? Hell no. If someone isn't performing they need to be given that feedback, put on a PiP and fired if they suck. I have a high performance expectation. We get paid a lot.
No one gives my team shit but me.
Fidodo@reddit
I defend my team all the time, because there's a lot of context that gets lost when looking at progress from the outside.
When it comes to actual incompetence I handle that internally and directly. Talk with the team member. Try to figure out what the underlying issue is and how to help.
But if they don't care, then no, I don't cover for them. As you said, them not caring is not a personal issue that only effects them, it effects the whole team because it means other people have to clean up their messes. When you cover for them then you're not doing your team a favor, you are making the whole team look bad to defend one person who doesn't even care in the first place.
When this happens I explain the situation upwards frankly. I don't directly throw them under the bus because that's just unprofessional, but I point out the scenario from an objective metrics standpoint. "This project was delayed because we fell behind on this story", and then the owner listed on the story exposes the rest of the issue. I don't directly attack any team members, I treat it as a team health issue and it becomes clear when a single person is hurting the team's health.
Your job is to help them improve, and also to communicate your team's progress to higher ups. Your job is not to fire people, so just expose the progress transparently upwards and the issue with the team member will expose itself and if the situation does not improve they will eventually get fired, but it's not your job to make that decision, it's your job to expose the information so others can make that decision.
Also, your process sounds bad if their bad PR makes it to release. Their story should be stuck in code review if it introduces bugs and that should be reflected on them because they're behind on their stories.
TL;DR, I don't punish the entire team to protect one member's incompetence when they don't even care.
zvaavtre@reddit
Echo the PR bit. Don’t let that broken code in in the first place. If you find yourself teaching them via a PR it’s time to have a design discussion at the start of a project not when the PR shows up.
RedditNotFreeSpeech@reddit
There's a guy at work who is trying hard but he's just not in the right line of work. He gets stuck and frustrated but he also just had his first baby so I'm not going out of my way to get rid of him.
zvaavtre@reddit
Part of your job is to hold people accountable. But that also means giving them the responsibility
If you are cleaning messes after hours you are failing to do your job.
Give them metrics to meet and if they don’t meet them then fire them. What exactly those are should be a conversation with buy in. Then get out of their way except for sync up meetings.
Communication throughout this process is essential. By the end of a project nobody should be surprised. If they fail it’ll be obvious well Before then end and there will have been plenty of correction opportunities.
Leadership is about delegation
severoon@reddit
It's your job to take the longer view.
That means if someone is bad right now, but they're working a plan to improve and making gains, that's how it's supposed to be. Everyone will always be working on some things, including you. There's nothing special here, so not really anything to "cover." As they learn and improve, celebrate success.
If someone is weak somewhere and not improving, the focus should not be on past failure but the plan and the goals going forward. Seek commitment to stretch goals and track progress with encouragement. If this just isn't working over a few quarters, then I would try to refocus that person on something they are good at. Most of the time, in my experience, bad SWEs aren't bad, they're just in the wrong place. Move them to something they're better at and play to their strengths.
If someone is just not thriving in the field in general, that's where you have to start escalating. That's not a good situation for them, you, or anyone.
RangePsychological41@reddit
The first things I wonder about is general hygiene. How do the tickets look? Do people put updates on tickets? How do the meetings go? Is everyone on time?
Is there anything to point to at a retro that shows how slowly everyone is moving collectively?
I mean, I could go on and on. There are so many small things that make a big difference. People need to take pride in their work.
Apart from that, they need to commit to a growth plan to have something to measure themselves against.
Ok-Letterhead3405@reddit
For real! I know on my team, there's a lot of frustration right now about how things aren't moving across the board, but the tickets suck and nobody on the team will take any of my feedback at retros about how to better split things up. In fact, it's usually the team lead who pushes back on me, and then I get a little lecture about it, too. They just keep saying "vertical slice" and then writing a ticket for an entire new page.
Our requirements are always missing things, people are cutting corners and getting defensive when asked to go back and add stuff, MRs are huge and don't get properly reviewed, people are constantly cleaning up each other's work.
And the team lead is getting pissy. I don't know what to tell him. He was given plenty of ideas. If he's going to invalidate me at every turn and keep doing things the same way, then yeah, some tickets will get stuck on the board for a while. Tough cookies. I'm not making myself responsible for people writing huge tickets, refusing to break them down, and then being afraid to point more than 8 points on anything. It'll get done when it's done.
Oof. Sorry, I needed that rant!
RangePsychological41@reddit
What do you mean by this:
"it's usually the team lead who pushes back on me"
I thought you are the tech lead? How is there a team lead and a tech lead?
anand_rishabh@reddit
Team lead might be more a people leader than an IC who also has leadership responsibilities
RangePsychological41@reddit
All of my experience has made it clear that the manager role is redundant. Engineers need an engineer who engineers with the engineers. That’s what makes a strong engineering team.
grizzlybair2@reddit
Yep this is a big part of it. I'd wager big the tickets suck, maybe just too big as well. Inexperienced engineers don't realize when information is missing and often dont know what to ask exactly from what I've seen. Have to lead by example and not be an ass about it.
And we can't just expect everyone to produce at the same level at every skill. My juniors would probably take 1 week to do a few of our current stories while it would take me 1 day. Our front end stories, we have 1 guy who could do them all each in a day a piece. But then the rest of the team won't improve skill/knowledge around that piece of our apps, so of course we let others improve and everything takes longer.
But yes also it's hard to be motivated to keep learning and get better if you're manager or team culture is subpar. OP makes it sound like he's provided feedback, but likely in a harsh manner based on his tone. Or maybe he's truly just tired of it, but the tone doesn't sit well with me, and that's coming from a lead with 2 juniors who I would likely describe in a similar manner.
bjenning04@reddit
I usually start with coaching/mentoring, but if that doesn’t work, then management needs to get involved. I will also note that the worse thing you can do is to do their work yourself. I’m guilty of it too, but they’ll never learn if you do the work for them, and if they’re incapable of doing the work even after coaching, that’s where management needs to know so that they’re either assigned to lower complexity tasks or, worst case, managed out.
SlightAddress@reddit
We succeed or fail as a team...
snofla@reddit
I do if I know they’ll listen afterwards and promise to do better.
ottwebdev@reddit
Covering/excuses are great examples of a dysfunctional system.
Responsibility and accountability are your friends.
Kazumz@reddit
No, I never cover. We go down together.
The expectation is for them to pull their finger out when needed and chill when not.
AlexMTBDude@reddit
The answer to your question is totally dependent on where in the world you're located as the cultural differences are huge and need to be taken into account in these situations.
whyregretsadness@reddit
India see their post history
vantasmer@reddit
How do you decide when a feature should take a week or a month?
abeuscher@reddit
I cover for everyone all the time. We're not curing cancer here for the most part and I'm not kidding myself that what my company does is important or necessary. Everyone is there for a check so they can live their lives. And I do not want to interfere with that. As far as I am concerned the only appropriate response to the modern workplace is to mentally check out at every opportunity, take as much money as you can, and hope you get laid off later than earlier.
CreativeGPX@reddit
I do what is useful in context. Sometimes it's useful to say nothing, other times it's useful to say "there were issues", other times it's useful to say "somebody was an issue", other times it's useful to say "steve was an issue" and other times it's useful to say "steve was an issue again/still". Sometimes it's useful to hand the work back and say they have to fix it, other times it's useful to pair them up with somebody to fix it, other times it's useful to fix it yourself. Depending on who I'm talking to, what the problem is, what the requirements are, what the capacity to fire or discipline people is, etc. the answer will vary.
I too work in a place where it's harder to fire people. In that context, it's rarely good to make enemies and you have to factor in the office politics of how to work with, around or through people who aren't the greatest. I find it useful to have some humility and recognize that competence vs incompetence isn't black and white. One way I do that is I try to avoid saying that people are incompetent or bad and instead point to what their strengths and weaknesses are. For example, "he's a brilliant dev, but he's not good at time management" or "she's a reliable dev but isn't great at communication" or "he has good intentions and wants to grow, but has trouble with the fine details." This lets you acknowledge the cause and ownership of the failure without throwing the whole person out. It also can be useful because it tells the person you're talking to how to work with the person. If you tell them "yeah he's incompetent" that's not useful if they have to work with him, but if you tell them one of the things I just said, it tells them what specific things to watch out for and perhaps how they can get the most use out of him. And if word get back to him it's no some vague inactionable slight, it's a clear area that he could work on or point to.
silvercondor@reddit
Pip and fire. If i have to consistently steer i rather use llm
NewBlock8420@reddit
Honestly that sounds super frustrating. Have you tried pairing with them more closely for a bit? Sometimes folks just need extra hands-on guidance before they can work independently. Also maybe break down tasks into even smaller chunks with clearer acceptance criteria - might help them get better at estimating their own work.
I feel you though, it's tough when you're constantly cleaning up after your team. Maybe chat with your manager about setting clearer performance expectations too?
titogruul@reddit
I think it's important for you to manage your team's member incompetencies especially if they impact your responsibilities directly. Covering for them is one option on how to manage it, I'd advise against it.
Sounds like you already escalated this ssue upwards and was clear that the team mate efficiency may not be worth their cost, yet management decide to continue this way. Okay, no problem, I'm sure you can work with this.
That team member is a resource. Sure they are slow and you'd prefer someone more effective but sounds like that's not an option right now. Do they provide some positive value or are they negative? If there is some positive value but delivery timeline long or risk is high, take this into account when assigning tasks to that person. If they only do negative value, then no to critical tasks to avoid undue risk to your work. Make sure you partner with your manager well on this to coordinate.
FWIW, I don't think putting this advice in practice is much fun, but I think that's the best thing to do under the circumstances. Changing the circumstances is hard. So yea, it's a crappy situation all around.
kingDeborah8n3@reddit
They work for you, they don’t work the company… so, yes.
m0rgoth666@reddit
Jesus man. I was tech lead at a small startup so the requirements of the job were actually very mixed and there was an expectation of me to be lead dev and team lead as well.
And yes, even after telling them exactly what to code and where, things that would have taken me like a week at most got dragged on and on because devs usually don’t care enough to think about coherence and edge cases. Not production ready at all. Very often I would have to take over big sections to be able to deliver. Lots of unpaid overtime to cover for it while everyone else logs off at 5pm.
That said I gave up a bit about it and wasn’t that strict after a while. I figured who cares because founder was non technical and wouldn’t care about correctness or robustness or scope, was inflexible with deadlines and would keep quiet even after seeing me work so much overtime. Just delivery on the appointed date. So yeah, lots of tech debt.
Im no longer at that place and not looking forward to being tech lead again 🤣.
captain_obvious_here@reddit
Lack of knowledge, yes.
Incompetence, no.
PM_ME_SOME_ANY_THING@reddit
Incompetence? Look at all this work we put in! Not our fault the database guys suck at their jobs. And what’s the deal with devops, those bums!
TheOnceAndFutureDoug@reddit
Oh hey, the favorite phrase of senior devs everywhere: It depends.
For my part, it's about justification. Are they new? Have they been trained? Is the feature well documented? Do we keep changing shit? Do they keep getting blocked? Do we keep putting them in meetings There are plenty of perfectly valid reasons why a feature "should take a week" but takes longer.
If the dev is new and doesn't understand our codebase, maybe they're new to dev work in general, I pair them up with another dev who will help teach them (that other dev is sometimes myself, it's about availability). We take the time to train our engineers and make sure they know how to do their jobs effectively.
Now, say they've been in the job for more than 6 months, they've got a few projects under their belt, the feature is well documented and planned and nothing is blocking or distracting them? OK, well now we have a conversation about why this feature is taking longer than expected. Gimme a good excuse and I'll give you some space. But if it looks like you're just not doing your job? At some point you get put on a PIP.
On large teams you can have coasters who just do the bare minimum. It's not ideal but you don't always have time to train everyone properly and so long as it's not holding the broader team back it's fine.
On small teams a single bad engineer can be worse than not having an engineer at all so people need to either meet the standard or they need to go. The preference is always that they be trained and helped so they can meet the standard, which should be a reasonable standard.
I don't like putting engineers on PIPs and when I do I'm doing it as a wakeup call with the genuine hope they shape up. It almost never gets to that point, though.
Jolly_Air_6515@reddit
As a tech lead I usually spend a bit of time in discovery, put specific links to code lines in the Jira ticket, specific definitions of done, and expected pipeline phases that must pass.
Now all the juniors have to do is check boxes and do implementation and they can start to create these tickets for future work.
If there is a lot of similar work that must be done, I will show how to do it in a screen share and get everyone to recite the instructions.
I also run a high level goals session, what high level tasks need to be done to accomplish the goals, and the items that need to be done for each task; this helps the team understand the why so they can figure out any ambiguity.
My team doesn’t miss sprint deliverables anymore.
Logical-Idea-1708@reddit
As lead, you have a duty to find out if they are genuinely incompetent or just unmotivated. “Don’t seem to care” does sounds like they’re not motivated. Toxic work environment can be demotivating. How much do you invite the opinion of your teammate? As lead, you have the authority to override people’s opinion, but be aware that can cause people to become demotivated and withdraw from contributing.
travelinzac@reddit
Yes but I make sure management is aware. It's then their problem. Maybe there is a valid reason and it's not my business. The team fails together. I don't fail.
Ibuprofen-Headgear@reddit
Absolutely. I’ll cover for inexperience 100% and the occasional incompetence for anyone that is putting in effort (barring like actual massive issue or legal trouble, etc) or seems to give a shit. I will also spotlight them with credit / pass credit through when praise is given. It’s how I’ve always been as a leader/friend/etc, and part of who I am. I’ll also just straight up people shits broke or we didn’t/wont make a deadline, etc. Now, there is some strategy to how/when I do that last part, I’m not a total idiot, but the combination of the above has served me well. I’m sure I’ve missed some opportunities somewhere because of it, but the flipside is I have less stress, have teams that give effort and know I’ll have their back, and have made my way to exactly the level of management / leadership I want to be at.
Individual-Praline20@reddit
Always. And gosh they are. 🤣
Tom_Marien@reddit
If you really feel you have done everything possible, talk it through with your plus one/manager. You cannot cover for them it’s impossible, you will suffer from it. Also stop fixing, start pointing out the issues and go as slow as the slowest factor. Make it obvious
maulowski@reddit
Yes and no.
Yes if I knew better but didn’t mitigate it. No, if I gave them a task within their abilities and they couldn’t execute. It’s not as fine of a line as one thinks it is.
RevolutionaryYam7044@reddit
This sentence really sticks out to me. It sounds like you are teaching your devs not to think on their own. If you treat them like stupid code monkeys, of course they will behave like stupid code monkeys.
It's hard to develop some sense of ownership and motivation when you're just following orders. Sense of ownership => quality, motivation => speed.
Aggravating_Yak_1170@reddit (OP)
This is something I do after i gave many opportunities for him to learn, generally I give spike or poc story to understand the problem as them to come up with solution. And then next sprint the actual work. Bu it was no really working.
Here what I meant was the technical document with clear direction. Not to a level of literal code logic that he needs to write.
Exact issue is: I told him to make sure api is secure and not open. I did oauth setup gave him working postman script with demo credentials(which is outside of his scope for the task he was assigned), i told him specifically to secure the api verbally and also mentioned in user story. Now when I see the code there is no trace of any authentication it is wide open to public and he is a senior dev. This is just one instance that happened this week.
bwainfweeze@reddit
I think we’ve collectively made some big mistakes in how we treat code ownership in Agile. It being “all our code” is an impedance mismatch with bus numbers. The people who are going to show up and take responsibility when the code breaks own that code. If you won’t take responsibility for something, you’re not invested in it, and if your opinions disagree with those who will, then either you need to get on board or your opinions don’t matter.
So if you keep cleaning up you’re taking responsibility and they are not. That can be due to a lot of reasons but may be exacerbated by your own behaviors.
You have to be careful about documenting unless you have budget to hire more people. Because getting rid of someone is likely to reduce everyone else’s productivity for morale reasons, and if you can’t hire a replacement then you’re putting more work on the remaining team.
But you need to “let the baby fall”, and negotiate a mostly blame-free analysis of those failures and change the process to make them work. Track stories from start to finish. Make sure people don’t start multiple stories at once.
OP, are you Kanban, Scrum, or Waterfall? You can get some of this with Kanban, and Kanban fits inside more org types than does Scrum. Limit the number of stories that can be in progress at once - Work In Progrss, aka WIP limit. Make people finish stories. Make people help each other when their own story is blocked, or when they finish theirs and a high priority story is in progress.
There’s a variant of Kanban that allows for one story to pre-empt the queue at once. It’s not entirely right but it saves a ton of political capital with management that you can then spend on something else. I’ve found it works much better if that story is generally the only one allowed to exceed the WIP limit. Occasionally you can override for extenuating circumstances, like needing to collaborate with someone who is out for medical reasons.
But when you’re over the limit, the next person to finish a story can’t start another. They can go help the person most behind, or work on unblocking another story. That ends up flushing the pipes a bit more regularly, and provide some peer pressure for the perpetually slow.
You can’t get to the bottom of people’s problems if they can’t trust your discretion to discuss their hangups. And the moment you start “documenting” that dies. They will shut down and now you’re both fucked, since it’s your project and you can’t figure out how they tick to feed more work to them.
dantheman91@reddit
Publicly yes I own the output of my team. I've failed if my team is failing and I have not escalated anything. Very early you should be working with your devs to identify why things are failing and improve them. Upscale your devs.
If your devs are performing below expectations that should be escalated to their manager. If the manager doesn't do anything you should go to their skip. And escalate if you're unable to hit your teams goals.
Exotic_eminence@reddit
There are no weak links on my team
I’m great, you are great, we are all great
That’s why it’s a tradition of winning
Most places kick out their weak links so they are always left with the weak links yet to be culled - I harden them so it’s no worries and we can share the wealth with our tradition of winning Most places
Groove-Theory@reddit
I swear this question was asked like a week ago... but ill plop in my same notes
If multiple people on your team are consistently missing the mark, I’d caution against jumping straight to "incompetence" as the root cause.
When multiple devs (not one) "take too long" or hand in incomplete work, that’s often a symptom of systemic issues. So unclear requirements (you say you give them tech analysis but how clear IS it?). Or hidden complexity in the codebase, insufficient onboarding, weak feedback loops, or maybe even unrealistic expectations about timelines.
You may FEEL like you’re giving them "exactly what to code" but even then, implementation can be slowed by tech debt, missing context, or fear of breaking something. And when you step in to fix it yourself, you may get the release out the door, but you also prevent those devs from building the skills to close the gap. And worse, you prevent the company from fixing these systemic (not individual) root causes
A better approach might be to dig into where the work actually slows down: Is the tooling slow or the DX shit? Are they unsure how to test? Do they really know the product as well as you? Is the codebase actually really shit and full of tribal knowledge that they might not have? Is there a culture of blame if something breaks that makes devs paralyzed to try new things?
Until those root causes are addressed, you’ll be stuck in the cycle of frustration, rescue work, and blame. If multiple people are underperforming in the same system, it’s worth questioning the system before writing them off as bad developers. And idk if that's you as a tech lead who has influence to do that or if its more management, but I assure you that trying to optimize developer "competence" is going to be a fools errand.
bwainfweeze@reddit
Also experiencing Deja Vu.
One must also look at whether this is learned helplessness, and how much of the behavior you’re reinforcing. On teams with more than one Lead/Principal, some team members may respond better to one over another. And when hiring freezes are on, you can’t PIP someone without risking losing all of their productivity.
You can use some of the same skills on a “poor” senior that you would on anyone you’re mentoring - figure out what they’re good at, figure out what they’re almost good at, and keep alternating between the two to increase their zone of competence, and try not to give them anything that is outside of that range as it’s just setting them up for failure.
As the lead, you have to manage your own stress as well, but try not to take on any tasks that your team is fit to do, unless there’s just too much of it. Better to work on things that make future work simpler. Or that have to work right the first time (critical support libraries and infrastructure) and spend more time overseeing the rest of the work instead of owning it. Which is another avenue to learned helplessness - all the more senior people get to “work on the cool stuff” and they’re stuck doing grunt work all day every day.
evacygre@reddit
We need more info. How many of them out of the 6 would you say are low performers? Are they all working on the same project? During the whole month that it takes them to complete a simple feature, are there other things that come up? Like other support urgent issues, other bug fixes etc. Do they work on it? During that whole month, do you discuss what's blocking them? Are those reasonable issues? Are there any other areas that they are better at? Ie some people are really good at figuring out the root cause of issues and others are really good at coding practices or system design. What would you say is their strongest areas? If you have a software system, there will always be bugs or things in the design you didn't foresee and blockers. But I think more details are needed to provide actual useful suggestions.
Aggravating_Yak_1170@reddit (OP)
Among 6, 1 is worst, 2 are bad, 2 are good, 1 amazing.
It is all same project, 1/3 of effort goes to support most of the work here is time critical, 2/3 feature development not time critical.
I always put atleast 2 among the worst 3 in feature development since not time critical.
I see technical competence is there, but it is the attitude and unwillingness
No_Loquat_183@reddit
random question: are the devs outsourced or from the US? we have some outsourced devs and they are notorious for just slapping something together without much thinking and/or take an incredible amount of time.
perhaps it’s also a sign to have a better interviewing process to prevent this in the future.
you can only do so much handholding. I would definitely bring it up to your manager though
Aggravating_Yak_1170@reddit (OP)
It is a non US org, and devs are from all around, different continents and not a single location.
What I see is not technical incompetence it is just the willingness and attitude.
nasanu@reddit
I used to. Got in trouble for it, was told to "stop interfering". After that I quit that project, then got demoted several levels at once. That was years ago, the project still isn't finished and I last heard they had 160 bug tickets open. I had like 4 or 5.
And lol people here saying then put them on a pip or fire them. So naive. I was "lead" and was responsible for my teams work, but not their boss and their boss was not my boss either. I complained and complained about them, nothing ever happened till they got me in trouble for not doing everything their way.
Groove-Theory@reddit
I swear this question was asked like a week ago... but ill plop in my same notes
If multiple people on your team are consistently missing the mark, I’d caution against jumping straight to "incompetence" as the root cause.
If several people on your team are consistently struggling to deliver, that’s a signal the problem is bigger than individual skill. When multiple devs "take too long" or hand in incomplete work, that’s often a symptom of systemic issues. So unclear requirements (you say you give them tech analysis but how clear IS it?). Or hidden complexity in the codebase, insufficient onboarding, weak feedback loops, or maybe even unrealistic expectations about timelines.
You may FEEL like you’re giving them "exactly what to code" but even then, implementation can be slowed by tech debt, missing context, or fear of breaking something. And when you step in to fix it yourself, you may get the release out the door, but you also prevent those devs from building the skills to close the gap.
A better approach might be to dig into where the work actually slows down: Is the tooling slow or the DX shit? Are they unsure how to test? Do they really know the product as well as you? Is the codebase actually really shit and full of tribal knowledge that they might not have? Is there a culture of blame if something breaks that makes devs paralyzed to try new things?
Until those root causes are addressed, you’ll be stuck in the cycle of frustration, rescue work, and blame. If multiple people are underperforming in the same system, it’s worth questioning the system before writing them off as bad developers. And idk if that's you as a tech lead who has influence to do that or if its more management, but I assure you that trying to optimize developer "competence" is going to be a fools errand.
Do you want me to also make you a sharper, more blunt Person X version that would probably ruffle OP’s feathers?
mauriciocap@reddit
Pro Tip: always keep people in control and responsible as the adults worth of respect they are, let them know how much of your time you can offer for help and whenand how they can ask.
I also try to make each person show their results in demos, preferably with those who collaborated.
It's a huge risk for management, you and them trying to compensate in any way other than offering each person a list of things they have the skill level to do.
latchkeylessons@reddit
If you keep coaching them and they're not getting better and as far as the business is concerned either missing deadlines or not getting closer to their estimates, then you really just have a management problem and they need to have performance management work done. If that's not within the scope of your lead position, then you need to pass it along to the manager. If their manager doesn't care, move on with your life. If the manager does care, you'll work with them to help formulate the technical basis and expectations that need to be put together to have a performance plan in place that will be effective.
Thin_Rip8995@reddit
you’re not leading a team you’re babysitting one
if you’re handholding, redoing, and unblocking the same ppl over and over, that’s not leadership that’s cover-up duty
stop fixing their code
start documenting failure
weekly reports, metrics, timelines
make the problem visible to your higher-ups
not emotionally, just factually
also: you’re not their mom
they don’t “care” because they don’t have to
build pressure systems
peer reviews, demo deadlines, public accountability
you don’t motivate adults by pep talks you do it by forcing consequences
this isn’t a tech issue it’s a standards issue
raise yours and stop patching theirs
NoFluffWisdom Newsletter has some brutal clarity on leadership and performance pressure worth a peek
pwarnock@reddit
Cover as in shield; not obfuscate. You still have to address ownership and expectations.
aj0413@reddit
No. Covering for bad devs will just eventually create more work and stress for yourself. And it can also end up with you being on the chopping block before them since management will see the success or failure of projects as your responsibility ultimately
BigSwooney@reddit
Going to avoid the obvious that low or negative performers ideally should be let go.
There can be multiple reasons why hiring new muscles isn't easy. Sometimes it's outside the control of a team lead/tech Lead.
When I started as Tech Lead a few years ago I had a lot of juniors under me. My boss introduced me to situational leadership. It's not super profound or anything but it's a nice reflection on how to pick your approach when dealing with people that have varying levels of motivation and competence.
Long story short, if someone has low competence and low motivation there's not much point in going with coaching. You're probably going to have to tell them more or less exactly what they have to do. It sucks, it's unproductive, but it's better than trying to teach them things that won't stick.
serial_crusher@reddit
The team's deliverables are the team's deliverables. It's my job to make sure those deliverables get delivered by their deadlines. That means if one of my teammates fails to do their portion of the work, I might have to step in and get it done, or I might have to find somebody else on the team to step in and get it done.
It's also part of my job to make sure the team is operating efficiently and meeting deadlines consistently. So it's important for me to coordinate with management about process and staffing changes that need to be made to keep the team operating efficiently. If somebody's not pulling their weight, I need to make sure that's visible to the people who can replace them, but I do that by pointing out that I had to swoop in and do their work.
If it's particularly egregious or if I feel like my feedback isn't being considered, I'll strategically let them fail on something that is high visibility but low impact, but that's more of a last resort.
Now, company politics does also come into play here. I've got an under-performer on my team, but he's US-based. If they fire him, he either won't get backfilled or will get replaced by an offshore contractor of similar quality. I cover for him in ways that I don't cover for the offshore devs, because I'd rather work with a low-performer in my time zone than one on the other side of the planet, and because in general I want to sell the image that American devs are a better investment.
UntrimmedBagel@reddit
Hire me instead
_hephaestus@reddit
Going a bit against the grain here, if your organization doesn't let you use bad performance as a reason to let them go, your job is not to upskill them so much as it is to account for their performance in setting up long term roadmaps. If you say "this is what I can commit to" and they say "we need more than that", then that is when you bring up routes to improve engineering performance, framing it as business-reasons first.
Let them know that you are doing what you can with the resources available and try and do more, but in my experience the business end gets more pissed off when you underdeliver vs. underpromise and hitting the targets both sides agree on is how you build the trust to get more headcount.
Expert-Reaction-7472@reddit
coach them using pairing and TDD.
Enforce it until the quality is where it needs to be.
That's your job.
pineapplecodepen@reddit
Have you spoken to the manager? I assume you’re all under the same one…
You need to get management in your park, work together to iron out expectations.
It sounds like the team would benefit from stand ups, where people HAVE to have daily progress updates and talk through their barriers.
Similarly, if the org can afford the slow down and management in on board, pair coding might be an interesting test. Put two devs together so rather than everyone spring-boarding off you, they springboard off each other.
kogitatr@reddit
I'll be honest with them with all the evidence that it isn't satisfactory and holding team's trajectory. Either they catchup with the train or left behind. You, as tech lead accountable for your team, can't just focus on underperformer, it's unfair for the rest of your team
So_Rusted@reddit
Cut them some slack, especially if they've been around... yeah they take 1month to do what can be done in a week. And then do in a week what can be done in a year..
Stock_Blackberry6081@reddit
Employees deserve better workplace protections than they currently have. We need unions and fair, consistently applied progressive discipline procedures when people need to be disciplined. In lieu of these things, managers should do their best to protect people whenever possible.
DeterminedQuokka@reddit
If you stop covering for them they are more likely to get fired. As long as you are covering for them their work will seem good enough.
What I do is choose what I let them fail on. I know which things are the most important and will cause the worst incidents. I am more likely to cover in those areas. If I see something that is in a area that a failure won't be a huge business deal I will let them do it. I frame it less like this and more like "people learn more from failing". I do tend to give the manager a heads up that I'm letting that thing fail and that I'm paying attention to catch the error in observability quickly and throw it back to them.
Another good way to make them fail is to go on vacation. Makes it very clear who can't exist alone.
BaldoSUCKIT@reddit
You can’t force growth. You can encourage, provide opportunities and pathways but you can’t force people to walk through it. I’ve been in similar situations and you have to know when concerning performance is repeated and the person isn’t willing to grow. Treat them like adults, give them opportunities, don’t be biased and give some room for mistakes. After that phase start to think about coaching plans and if they are a good fit to continue.
Former_Dark_4793@reddit
Had a similar situation at my old job, one worker was so bad. I know I am not that good as well but i try to finish in time googling/AI. But that one dude was so bad, i didn’t know how he got hired, he didn’t even know what a NPR was, his locally code and gets used to fail on npe lol….he didn’t know how to use if/else block for a simple step….
Then manager started giving him 16 points story to finish in one sprint. Seems like they just wanted him to quit since they couldn’t fire him….After 2 weeks he left himself….
BeReasonable90@reddit
Yes, it is the lead devs responsibility. That is part of why they are paid more. You are there to cover for those unde you.
A new dev will take time learning the code base and will be much slower for his/her first few tasks then expected as they are going to spend hours trying to fully understanding the code base. Even simple
Even new senior devs may need some adjustment time as simple fixes can be part of big projects that they need to properly analyze to make sure they are not breaking something unintentionally they are unaware of.
If the newbie is just a lazy net negative that is just spending time not working or improving (within a reasonable time frame), then that is your job to log and report this, meet with them to let them know they need to do better and escalate things if needed.
UKS1977@reddit
Every piece of code must be paired. And I record their entire incompetence officially.
Ok-Letterhead3405@reddit
Uh, I think you communicate that to your manager in your 1-on-1's and maybe document all the stuff where you've tried, and the things you've needed to clean up. If you've done your best, then isn't it the manager's problem at that point?
Probably in your shoes, if I did all that and management was like, meh, and nobody's getting fired, I'd just lower my own expectations. Probably your org doesn't have money to pay for better devs even in this economy, I guess? Or doesn't think it's worth the risk to have to re-open the job and find another person who's not much better who now has to be trained/onboarded/learn the repo thoroughly for 3-6 months.
The other thing I will say is that it really helps to 1) keep things positive 2) sell people on how better code will avoid more headaches like dealing with fires. But, if the responsibility for fires only lands on you and upward, they won't have as much motivation to care.
ThePillsburyPlougher@reddit
I cover from stakeholders as they shouldn’t be just shat on by upset clients. But you shouldn’t cover for them to your manager, and if you really want to get rid of them you shouldn’t try to minimize their impact. Give them an expected amount of responsibility for their position. If they fail and stakeholders are upset then your manager will care. If you shove them in a corner and they fail silently, if your managers aren’t very good then it won’t be worth the trouble for them to get rid of them.
kk0128@reddit
Nope. If someone takes a month to develop a simple feature that’s something you need to communicate up.
It’s unhealthy to think that falls completely on you. If you’re not given the proper staffing to hit goals, trying to make up that gap will only lead you to burnout.
Talk to your manager, communicate these problems clearly and often, push to have people let go if needed, or to bring in more talent if dates are under pressure.
madprgmr@reddit
You should probably try to find out what factors are causing these delays. Maybe they are too inexperienced or don't care because they know you'll fix it... or maybe your instructions aren't as clear as you think or maybe there's something else going on preventing them from working effectively.
I'm not sure how an entire team ends up being actually incompetent unless you have no real hiring process at all. Communicate (and log) when they miss expectations and try to determine the root cause. If you are not their manager, bring up your concerns with them as well... but try to come armed with information regarding what you have and have not ruled out as a potential cause (ideally with the log/notes you've been taking).
thatVisitingHasher@reddit
Everyone has bad days. You can’t be 100% all the time, but if no one is telling these people their sped abs quality are actual issues, they probably don’t know it’s an issue.
I’ve been bright in to raise the standards of tech departments 3 times now. It’s amazing how many people work 10-20 years without hearing any feedback or need for improvements.
I know it’s hard at first but simply being constructively honest with people is something our industry needs to do more of. The alternative is the entire team or department gets cut randomly. Poor performing teams don’t stay poor performing forever.
rinne_shuriken@reddit
You need the evil called micromanagement here. Do not wait for deadlines to hit. Check regularly with them on the status. But still, This is actually more of a people management problem than tech load management. Some people are motivated,some are just to clock the hours. Everyone's mileage varies. So, if the pace is not suitable for the teams need, then maybe not the right fit for the team. So at this point, management needs to know this and bring in carrots and sticks. Tech lead is supposed to remove tech blockers and not the human type ones.
iwasnotplanningthis@reddit
Are your solutions good enough? Are your comms good enough? Are your estimates accurate? Are the repercussions for failure powerful? Finally, can’t or won’t? Assess whether your team members can’t (at their current skill level) execute, or whether they simply won’t.
BillyBobJangles@reddit
I'll cover for a teammember making a mistake but consistent incompetence should be brought up with your manager.
WiseHalmon@reddit
Depends what do you want to do? Tell your org you don't want to work with a team of low performers. Or you work with them and continue to tell management you could hire a better team.
Or you can try to encourage them, level them up, spoon feed them, waste all your time on them.
WiseHalmon@reddit
second note: a lot of times I give people tasks with the thought in mind: how can this person save me more time? and if I can't then that's bad
JustForArkona@reddit
I have run into this a few times. I implement a training regimen for the underperforming dev and schedule pair programming and personally provide feedback on PRs, as well as whatever other tips are specific to the conversation.
If the dev doesn't hold up their end of the deal (e.g. One lied about completing the assigned training) THEN I go to management.
It's generally expected that as tech lead, we're the first line of defense, but when things reach PIP level then it needs to escalate.
Upbeat-Conquest-654@reddit
Yes. Every leadership position entails taking responsibility for the performance of the team. At least publicly and towards stakeholders. Internally, you can and should figure out what slows down the team, but you never point your finger at a team member in front of stakeholders.
WiseHalmon@reddit
I definitely give credit where credit is due and give criticism where criticism where due. leaders are not 100% responsible for people's actions
watsonsquare@reddit
This is a tough situation. If you throw your team members under the bus you’ll lose their trust. If you protect them and the keep making catastrophic mistakes, then you’ll answer for their incompetence.
I learned this the hard way, and took one for the team and it cost me my job. I wouldn’t change anything considering how awful the management was in that instance, but considering the current job market I recommend that it’s worth putting your own safety first and act accordingly.
Famous-Composer5628@reddit
I used to suck really bad, had a good team lead who mentored me slowly and gently, i suck less bad now.
I lead features and projects on my own. I can transform business requirements and communicate with the right team owners and can scope out pretty accurately what needs to be done etc (basically i'm an average intermediate now).
People can improve if they want to. Having conversations and being a good mentor (if you have the bandwidth) could work.
LogicRaven_@reddit
What does your manager say?
Did you give feedback 1:1? What was the reaction?
How does your team stay in sync with each other? I would guess if there is a weekly planning meeting, then you would see already after a week that something is iff track.
If you haven’t tried already, you could pair up with them and see what might be holding them back.
davewritescode@reddit
This is the hard part about leadership. Anyone you have on your team behaving like this is sending the wrong message to the rest of the team and causing you to have to pick up the slack.
The sad truth is there’s a lot of good developers out there who are out of work and will put in the time. If you have an org capable of attracting good talent that’s what you have to do.
Euphoric-Neon-2054@reddit
No. As a tech lead your job is not to fix the work of the incompetent. It is to guide, improve and help steward the work of the already competent, and support them to grow their skills, experience and pace. Take it from someone who has tried; there is no amount of work you can personally do to paper over the cracks of a technical delivery culture that does not seriously root out the shortcoming of engineers that do not meet the standard required of the work bestowed upon them. I tried it for almost 12 months and ultimately had to let people go anyway.
I will also say this: if you do not have the authority to manage the performance of your team, you cannot be responsible for the performance of your team. There is no version of a situation like this where if you cannot reform the team, that you can also be responsible for it.
Things you *do* need to check in on:
Are you being clear about the amount of time to achieve a task? Are your technical specifications clear? Do you have documented expectations about code quality and releases? Do you have regular discussions about blockers? Are you regularly checking in to help with progress / review? Do you have a forum for people to discuss difficulties, blockers, or support they need? Do you have any other seniors you can lean on to help drive momentum with you?
If these things are already happening, something is going to have to change with regards to the way that their performance is managed. It needs to be clear, fair, articulate and unambiguous and with plenty of opportunity to demonstrate marked and consistent improvement. In the case that with this guidance over the course of \~12 weeks they still cannot get to a level where they cannot then take responsibility for their own work, they do not have a position at the company and it is not fair on you to have to shield them from that.
A final thought is on 'learned helplessness'. Right now they have learned to be helpless. You have unfortunately trained them that you will fix their broken shit and there is no real problem with that. These people need to learn how to deliver for themselves as item number one, and that involves you removing yourself as a safety net for their lack of care or skill as a regular mode of operation.