How to handle mediocre team as a Senior
Posted by Floorman1@reddit | ExperiencedDevs | View on Reddit | 24 comments
Been in my current role just under a year and feeling a bit stuck.
The company has a history of questionable architectural decisions. When I first joined, I had some imposter syndrome coming from a smaller company with a pretty stale tech stack.
Things improved a lot over time, mainly due to a recent lead who really changed how we approached things. He questioned decisions, pushed for better standards, and made it feel normal to challenge ideas instead of just going along with them.
Because of that, I’ve grown a lot. Our PR process is much stricter now. We try to call out issues and improve things instead of just approving to keep things moving. If there is pushback, he is usually the one holding the line.
He is now leaving, and I am worried about what happens next.
I am happy to offer guidance and support, but it feels like some people are more focused on getting things done quickly than doing them well. There is not always much appetite to think through better approaches if it slows things down.
I do not want to become the person who blocks everything and frustrates the team, but I also do not want to slip back into just approving things and letting quality drop.
I considered going for the lead role but feel like I might need a bit more time before stepping into that.
For those who have been in a similar situation, how do you balance maintaining standards with not alienating the team when you do not have strong leadership backing you?
scoopydidit@reddit
I have left mediocre teams. If you're an engineer who cares about the craft and you're working with people who don't give a shit... leave.
In my case, i was doing double time because my team were doing 1 hour a day. I felt a burden to keep the team afloat whilst they logged off everyday. It didn't matter what hour of the day you checked their online status, they were offline. Every standup was "yeah still doing XYZ task" (5 mins task, but they're doing it 5 days now). My manager was too incompetent or probably didn't care enough himself to get them to pull their weight.
Some people would say they were living the dream. And I agree. They absolutely were. High paid job and doing little to no work. But they are doing that because someone else is carrying the weight.
Furthermore, when they did work, they weren't very good at their jobs. I recall one time explaining the most basic architectural design of our project to a team member who was on the project 3 years. I'm pretty sure it went in one ear and out the other.
Furthermore, they will reach out to me before looking into issues themselves. They hope I will solve their problem and they can go log off for a bit whilst I do that.
These teams will drain your work life balance and you won't learn anything working with them. Change your surroundings.
Old_Cartographer_586@reddit
I feel your frustration. In my current role, I am by far the most technical person. But my boss who talks to Claude all day “is an expert” on all things all of a sudden.
He’ll argue that everything in our code should be agentic (even simply things like is the user_name present in the API call), we had to stop building a Data Lake because Agentic AIs will get that data for us. On top of that the team below me is a bunch of vibe coders.
I swear half my job is refactoring!
All this being said, the way I’ve been holding up standards is, I’m forcing a shared md file in all projects with our coding standards so Claude can reference that. All PRs go through me for review. All architecture decisions go through me. All this while I’m trying to upskill these vibe coders who can do a simple for loop in python.
It’s hard, draining and tbh my wife has caught me not being able to switch off from work because of it.
Do what you can, but don’t kill yourself for it because layoffs will come eventually and unfortunately us who know what we are doing - are expensive
JuanAr10@reddit
I'm in a very similar position. It gets to the point where you start asking yourself if you are in the wrong!!!
If you find a solution that doesn't require leaving the company, let me know!!
WhileTrueIQ--@reddit
I’ve been in the same situation. Go for the lead position.
A new lead is a wildcard that may not work in your favor. At the very least you’ll need to compensate as they ramp up, on top of covering for your mediocre teammates.
Best career decision I ever made. And no, I didn’t feel ready either. Confidence grows in a few uncomfortable months, you’ll figure it out.
HiSimpy@reddit
This usually means architecture decisions are happening without an explicit decision record and acceptance criteria. As a result, the team repeats weak patterns and senior engineers feel blocked. Introduce a lightweight decision gate with owner, rationale, and rollback trigger.
agileliecom@reddit
The lead who changed how your team approached things and is now leaving was your shield and you probably didn't fully realize it until he announced he was going. I've been in banking for 25 years and the single biggest factor in whether a team maintains quality isn't process or tools or standards. It's whether there's one person with enough credibility and enough spine to say "no, this isn't good enough" and have the room accept it. That person just left your team and now the question is whether you become that person or whether the team slowly drifts back to approving everything to keep things moving.
The "I don't want to become the person who blocks everything" fear is the thing that will prevent you from doing what needs to be done. Because holding the line on quality in a team that wants to move fast will always feel like blocking. The developer whose PR you sent back with comments will feel slowed down. The PM waiting on a feature will feel frustrated. Your manager will hear "the team says the new senior is being difficult with code reviews" before they hear "the new senior is preventing us from shipping bugs to production." That's the political reality of being the quality gate without the lead title to protect you.
What worked for me wasn't holding the line on everything. It was picking two or three non-negotiable standards and being flexible on everything else. For my team it was: no PR merges without tests for critical paths, no architecture changes without a design doc, and no deploying on Fridays. Everything else was negotiable. That gave me credibility because the team saw I wasn't blocking for the sake of blocking. I was blocking for specific reasons they could understand and eventually agree with.
The "I considered going for the lead role but feel like I might need more time" hesitation is your imposter syndrome talking not your judgment. You just described a year of growth under a strong lead. You understand why quality matters. You can articulate it. The person who worries about whether they're ready for leadership is usually more ready than the person who never questions it.
honestduane@reddit
Why is he leaving?
That's the red flag you should be looking for it might be that you should be looking to leave as well, maybe following him is the safest choice,
tiagocesar@reddit
He's showing you exactly what to do, people only leave this quickly if they are fired, find a much better job, or perceive that the current environment is not gonna contribute to their growth so they move on. Two and three seem the same but they aren't.
SeaComment4680@reddit
the spacing is kind of odd here
upsidedownshaggy@reddit
Man who let their bots off the leash again?
TheWhiteKnight@reddit
> I am happy to offer guidance and support, but it feels like some people are more focused on getting things done quickly than doing them well. There is not always much appetite to think through better approaches if it slows things down.
This has been a problem everywhere in my experience. It's really unfortunate. My take is that you can try but will get wildly different milage getting mediocre engineers to be better than mediocre.
Our good engineers are good because they have skill and pride in what they're doing. They believe in building solid software, understand and know why best practices are important, etc.
You can't teach anyone pride.
We have different levels of engineers, from worst to best:
Get literally almost nothing done. Everything takes forever and even after something took 100X longer than it should, it's still a bad implementation. They don't care and are lazy, barely working.
Get stuff done but it's slow and poor quality.
Get stuff done in medium time but poor quality.
Get stuff done in good time but poor quality.
Get stuff done in good time with good quality.
Get way more done than 1 - 5 but poor/medium quality (fast but hard-to-maintain clever code)
"10X engineers". Get way more done than 1 through 5 with excellent quality.
Good luck. Your best defense is being super careful in the hiring stage. Your team is only as good as what it's comprised of. Hiring is a minefield unfortunately.
laramiecorp@reddit
It feels like 5 and 6 can be considered on the same level or interchangeable, depending on the circumstances and needs. Getting way more done with hard to maintain is almost a guarantee that high quality will never be obtainable or a growing tech debt wall later, but 5 is intentionally slowing down and slowly making progress there.
TheWhiteKnight@reddit
Agreed, maybe 5 and 6 are in the wrong order.
Justin_Passing_7465@reddit
Talk to your teammates. Be frank with them: "Do you guys remember how much the work sucked and our software quality sucked before Bob joined the team and started demanding quality and rejecting PRs? Do you guys want to go back to that? Do you want to go back to wading through shitty code all of the time because we kept merging shitty code into our baseline? No? Then we need to keep implementing Bob's insistence on quality, after Bob leaves."
That might help; it might not. Some teams can't be salvaged.
Acrobatic-Regret7808@reddit
how do you handle the imposter syndrome now?
coordinationlag@reddit
The coordination trap here is that standards without enforcement create a vacuum. When the lead who pushed quality leaves, the system naturally reverts to the path of least resistance.
What actually works is making quality visible in the workflow itself. Not extra meetings or documentation, but automated checks that block obviously bad code from reaching the baseline. The coordination cost of fixing it later is way higher than the friction of preventing it upfront.
Been on teams where we added simple linting rules that forced everyone to see their code through the same quality lens. Nobody liked it at first, but three months later everyone appreciated the stability.
_sikandar@reddit
Get a life outside of work
melodyze@reddit
Taking your claim at face value, don't know if your claims are correct.
Even if you were the owner of the company fixing a mediocre team is very hard. It's not really possible from being an IC. As an IC you can build something valuable and conceptually separate and make a new team. But that's not usually worth it.
Generally, orgs decay in quality over time. It's almost like a natural law. Entropy increases, companies become messier and slower, the market shifts underneath of them, and the better people leave first, which increases entropy even more and slows things down even more.
Savings-Giraffe-4007@reddit
Don't do it unless leadership asks you to.
People wants to keep their jobs and the current ask is do more ship faster quality does not matter.
There's a reason that guy is leaving.
gemengelage@reddit
People only adhere to processes when they either understand how they help them or fear the consequences.
I'm not a big fan of fear tactics and realistically your means to use them in your position are pretty limited. So I would focus on thoroughly documenting your team's processes (remember, even if you define the processes as the lead, it's the team's process, not yours) and try to get your team to buy in. Highlight whenever your processes prevent a potential issue.
As the lead you are inevitably going to become the lightning rod for negative feedback to some degree. You need to be able to handle that. You need some thick skin and the vocabulary to tell people that you don't care about their opinion without hurting their feelings.
Lastly, the best move I made when I was leading a weak team (I wished for a mediocre one), was to get a good developer to join my team. It took some tactful complaining to management, but after a while they gave in and transferred a colleague from a different team to mine and that was a life changer for me. Suddenly I had someone who I split my work with, delegate difficult tasks to and who largely had my back in difficult discussions.
CicadaAmazing9971@reddit
reminds me of that time i tried something similar
Saki-Sun@reddit
It's a balance. Every team needs someone to push to be better. Someone that generates the reports or fixes bugs.
Some will learn and get better, for some it's just a 9/5.
liquidpele@reddit
You don't step into roles suddenly, you migrate into them. If you're not already doing half the stuff the lead was doing, then you're not the lead and you're not ready to do that, you can't just switch it on like a light switch. That said, you had a good team member who showed you what it looks like, so learn from it and start practicing it. Get out of your comfort zone.
EdelinePenrose@reddit
you can always deliver with the quality that you want to see. you don’t need to become a cop. your job is not to fix the team.
what have you told your manager about this situation and what have they said in response?