Disrupted team dynamic

Posted by Remarkable_Tip3076@reddit | ExperiencedDevs | View on Reddit | 23 comments

2 years ago I joined a new team that was fairly mature, most of the developers were senior except myself (3 YOE), it was a small team and I felt we worked really well together. Everyone had their own field of experience and it didn’t feel like anyone was holding us back. I was learning off everyone, every day.

At the end of last year we lost a dev and got a couple of new ones. The team feels like it’s changed a lot since then - even though the replacements were senior for senior, I feel like I’ve gone from a role where I learn a lot to one where I am gating quality, not learning. I know this is partly because I am maturing into my role - but should I really expect to be teaching seniors? My colleagues make basic mistakes, use genAI in the absence of genuine understanding, and (the thing I find most frustrating) don’t put effort in to understand the solution.

I am repeatedly explaining basic concepts like how to avoid null pointers to developers more senior than myself. I am repeatedly explaining the solution that is well documented. Is this normal? Was I very lucky over the last year? How can I avoid burnout from working with these people?

[-]

Zestyclose_Humor3362@reddit

This sounds incredibly frustrating and honestly pretty common when teams change composition. You were lucky to have that initial group where everyone genuinely cared about craft and learning. What you're experiencing now isn't really about years of experience but about fundamentally different approaches to the work.

I'd focus on documenting these quality issues and their business impact like deployment delays or bug fixes eating into feature work. If leadership hired these folks and isn't seeing the problems, they need concrete data. At HireAligned we see this mismatch all the time - teams that look good on paper but have completely different values around code quality and continuous learning. Sometimes the issue resolves itself when people realize the standards, but often it's just a culture fit problem that won't change.

[-]

Slow-Company-2960@reddit

I bet your company has a high weight on coding challenges. This skill could be learnt to pass a test but doesn't replace years of experience. I feel the same you're feeling, got a Senior who aced leetcode but doesn't know sh* about actual work.

[-]

CautiousRice@reddit

Welcome to our world.

[-]

Antique-Stand-4920@reddit

- Use static code analysis tools to automatically point out (some) problems so that you don't have to

- If those devs repeat the same mistakes after you've pointed them out, take an increasingly long time to get to give them review feedback (e.g. exponential backoff)

[-]

DeferentGecko@reddit

What's the point of the exponential back off here? It's not like they'll notice that's what's happening. It'll just generate friction and they may kick off about you taking ages to review.

Would suggest a more head on approach. Keep links to where you've given certain types of feedback before.

If you see patterns of the same type of feedback, take them aside and explain that you've given feedback about xyz a few times and it's still happening. Not in a confrontational manner, genuinely being curious about why it's happening.

Do they disagree with your feedback? That's worth understanding. Does the llm they're using not know your feedback?

Ultimately if it then continues happening, it's an issue for your EM. Share the places you gave feedback, tell them about the time you approached them about it.

[-]

Antique-Stand-4920@reddit

What's the point of the exponential back off here? It's not like they'll notice that's what's happening. It'll just generate friction and they may kick off about you taking ages to review.

I'd prefer the direct approach myself, but it sounded like the OP tried that (with the exception of bringing in the EM), but wasn't seeing improvement. The main goal of the backoff approach is to give the OP more control of his/her time. If the OP is spending time on low-value tasks like reiterating certain notes on reviews, then the OP is not spending it on more valuable tasks. That can become a liability for the OP.

[-]

Remarkable_Tip3076@reddit (OP)

Thanks, yeah I think static tools will make sense. There’s some stuff like enforcing non null that we’ve never needed as everyone used to be aligned.

[-]

MechatronicsStudent@reddit

Sounds like you implicit coding standards from the old team need to be explicit. Also that feeling of learning and nobody holding the team back usually means you were holding the team back with your learning.

[-]

volatilebool@reddit

The issue with Senior is you could be a senior for a year or 10 years. Someone could be a senior with 10 years of experience that is super knowledgeable or the dreaded 1 years of experience times 10. Some people are moved to senior that aren’t actually what you’d consider senior

[-]

PayLegitimate7167@reddit

Ouch it’s ok to teach business context (that is something you have more experience) and dev processes but fundamentals very surprising

[-]

Remarkable_Tip3076@reddit (OP)

Yep, I have been left a bit speechless by some of the PRs, as has one of the devs I worked with all last year. I’m happy to teach and I like working in a team, but it’s shocking some of the choices people with 20+ YOE are making!

[-]

PayLegitimate7167@reddit

Sometimes they get older and sadly they go into decline

[-]

GammaGargoyle@reddit

Senior title means nothing in this industry. Thats just a fact. It all starts with the hiring process, which i imagine you don’t have much control over.

[-]

PayLegitimate7167@reddit

I never call myself senior for a reason

[-]

Adept_Carpet@reddit

You were very lucky over the last year, yes. It does sound like the new hires are below average but there are a lot of devs out there who are below average.

Before LLMs, these people would simply create nothing and eventually carve out a niche writing documentation, doing manual QA, communicating with clients, or making coffee (if they were generally good employees, but bad at writing code). It was a simpler, happier time.

Now they can churn out enormous volumes of slop. You are getting burnt at both ends and aren't getting the help with the ancillary tasks you might have gotten from them in the past.

[-]

Huge-Leek844@reddit

Comminicating with clients? I dont get it how devs can go away with just talking to customers. One colleague just receive emails and defer the technical work to us. We could just cut the intermediary lol

[-]

Remarkable_Tip3076@reddit (OP)

Thank you, that makes a lot of sense! I actually worked with one of them a few years ago (before genAI), and they seemed great. When I heard they were joining the team I was looking forward to working with them.

It’s definitely an adjustment working with people who don’t seem to care about the solution or code quality. I have asked some of them if there’s anything the existing team members can do to make it easier for them onboarding. I was concerned that I was being overprotective of our existing code style and perhaps being resistant to change. They didn’t seem bothered though.

[-]

Huge-Leek844@reddit

I am a new hire and i only ask questions about processes or when i do a Change but dont want to harm everyone else. Its my first time on a big team.

In my previous job i was teaching if else to a guy with 2 years of experience. He only worked on customer support and documentation.

[-]

LogicRaven_@reddit

When a person leave or a new person joins the team, a new team is born. Your new team needs more support than the previous one.

Whenever a question comes up, discuss it with the team as well and make it part of the team standard. Write it down and automate the checks for it whenever possible.

Not putting effort into understanding a solution is a tougher problem. There could be motivational issues or unclear explanations or else. Maybe your manager could step in and support the team here.

[-]

Remarkable_Tip3076@reddit (OP)

That’s fair! Thanks for replying