21

I’ve recently started at a new company (5ish months) where I was brought in to help improve coding standards and development practices. Since joining it’s been very clear that my team is the singular cause for just about everything bad around here - frankly nobody has a clue what they’re doing.

It’s not just me - since my very first day all I’ve heard from other team leads is how truly inept everyone on my team is.

Now, I’ve had nothing but praise from management and have been asked to lead or help plan several projects despite a relative lack of experience, but that’s outside my team. When dealing with members of my team I’m usually treated with condescension and overruled because they claim to know more.

I can work around this, but there is one colleague of mine who really takes this to a different level.

He recently got given a project that he, frankly, is way out of his depth for, and badgered me repeatedly over three weeks to help him with. He kept coming to me with trivial (really trivial) questions which I would answer only to be asked something similar ten minutes later. Eventually I got tired of this (and he was running behind schedule by a lot) so I offered to take it off his hands (despite having my own project to deal with). He gladly handed it off to me, but strangely kept on telling everyone he was working on the project in stand ups, or at best how I’m helping him. Three days later I overheard him telling our team lead he’d get the project done in two days (something I never agreed to, and that shows how little he understands about the project - it’s worth a few weeks of work at least). I started making more of a point of how I’m doing the work in team meetings, so now he’s started telling people he’s helping me (something they are happy to believe because he is more senior), even though he has nothing to do with the project and couldn’t help if he wanted to. Frankly I’m not okay with him swooping in and taking credit at the end after all the work I’ve put into this project, nor am I okay with him patronising me by suggesting he is helping me when he has no clue how any of this works anyway.

How can I make it clear to everyone that this is my work (and just mine)?

EDIT: we are the same level in terms of job titles, although I report directly to the head of desk (I.e the boss of the team lead) whereas this engineer reports to the team lead.

2
  • 2
    Comments have been moved to chat; please do not continue the discussion here. Before posting a comment below this one, please review the purposes of comments. Comments that do not request clarification or suggest improvements usually belong as an answer, on The Workplace Meta, or in The Workplace Chat. Comments continuing discussion may be removed.
    – Kilisi
    May 20, 2023 at 6:03
  • Could you explain why you don't just stop doing the work that you took off his hands? If he's telling everyone that he's doing the work, and it doesn't get done, then how can you be blamed for it later?
    – user541686
    May 20, 2023 at 8:25

6 Answers 6

51

This is a management issue, not a peer issue

The company hasn't given you any positional authority here, and the team isn't willing to give you any itself. You need to keep your manager updated on the issues you are facing. Tell them what needs to happen to make progress in the team. As to peer-based meetings, feel free to correct people who say things about your work that aren't true. But the better lesson here is don't let people give you work. You won't be rewarded for delivering things other people were responsible for.

8
  • 7
    Agree that the right answer is to ask management to deal with it. Disagree re not accepting work from peers -- if you have the time, and if you keep management informed that you're doing so.
    – keshlam
    May 17, 2023 at 14:21
  • 1
    @keshlam It's not a matter of "letting management know". It's supposed to be approved by management and initiated by them. You can't just randomly do whatever you want in a company, and accepting work that isn't yours is part of that. I'm part of a finance team, I can't just randomly decide to start working on payroll stuff because it has highly confidential information. Projects can have things like this and a standard staff is not in a position to make this type of decision.
    – Nelson
    May 18, 2023 at 0:48
  • 2
    @Nelson: We have experienced very different workspaces. Mine have been far more cooperative/team-based than yours, apparently. You're probably right for your department; much less so for engineering, especially within a single department where everyone is normally operating under the same security rubric -- and in the exceptions we wouldn't ask anyone to help who wasn't authorized to see the data. I've been on a project where we did a lot of work preparing a synthetic dataset for folks to work on without having to be exposed to live data...
    – keshlam
    May 18, 2023 at 0:53
  • 2
    It was not in the OP's best interest to go around management in the first place and volunteer to take over the project that wasn't assigned to them.
    – spuck
    May 19, 2023 at 16:53
  • 2
    @keshlam I'm also in one of those "cooperative/team-based" workspaces, and I'm still expected to at least say something before I just take over someone else's project in whole or in part. Other than being common courtesy, it's also a matter of efficiency. If I just went rogue and started picking up tickets meant for other people, there would be a lot of confusion over who was working on what, and a lot of work would end up being duplicated with no clear answer on what approach the team is supposed to use or base other design decisions on. The attempt to be helpful would backfire spectacularly.
    – Abion47
    May 20, 2023 at 4:05
14

Here's what I would do:

First, talk to your manager, in private. Publicly calling out your senior engineer in standup is not the right way to go about this. Tell your manager the story that you told here, as you told it here. The senior engineer was coming to you with a lot of extremely basic questions and wasting your time; rather than have him interrupt you often with stupid questions (don't say "stupid question" to your manager, that comes off as aggressive and condescending, but make it known that these are questions to which a senior engineer should know the answer), you decided to just do the work yourself, as you were essentially doing the work anyway. So it is you, not him (the senior engineer) who has been doing all the work and is in charge of the timeline and tasks.

At this point, there might be something going on behind the scenes that you may not know about. As an example, this might be a PIP project for the senior engineer, and the fact that he is incapable of doing it may simply mean he's going to be fired. Instead, in the meantime, you're doing his work and he's taking the credit and you're going to save his job, which is neither your responsibility nor is it even in your best interest (if this team is as bad as you say it is, then it's in everyone's best interests that they all get fired ASAP). It's also important, for recordkeeping purposes, to know who's doing what and when.

Now, your boss has a couple options here. He can either say "thank you for letting me know, I'll deal with it", or he can reprimand you. In the former case, you've now told your boss that you're working on this project and that it bothers you that the other engineer is taking credit, and it's up to your boss to take action based on that. In the latter case, you know where you stand; you tried to help out, and you got reprimanded for it.

In the former case, take a step back for a week or so and see what happens. See if the senior engineer stops trying to take credit for your work or if your boss starts to address the issue. If he's not addressing the issue after a couple weeks, follow up and let him know it's still bothering you, and continue following up until it goes away.

In the case that your boss is opposed to acting on your behalf, or if the situation drags on for too long without any action, give the project back to the senior. Simply tell him: "You're taking credit for this project, you should do it. Yourself". And by "yourself", you mean "yourself". If he comes to you with a question that you believe should be below the level of a senior, log that he asked you the question (so you could follow up with your boss later) and say "google it" (or something of that nature). If he complains that you're not helping him, remind him that he's the senior and he's the one who should be helping you, not the other way around. If your boss comes back and asks you to help him, remind your boss that you were the one who took this project but he was taking the credit, and make it known that you're not comfortable with such an arrangement. Once he's back in full control of the project that he's taking the credit for, you can put on your sunglasses and sit back and relax while you watch the project crash and burn. Just make sure to keep yourself out of the blast radius.

8
  • 4
    “Tell your manager the story that you told here, as you told it here.” - I would avoid the story that was told here, it is extremely arrogant, especially after only 5 months on the job. If a senior developer came to a junior developer for assistance I would be troubled by the fact
    – Donald
    May 18, 2023 at 1:55
  • 3
    @Donald Eh, I don't think there's anything inherently troubling with a senior engineer coming to a junior with a question. It's very normal for both senior and junior engineers to have specific expertises that not everyone else in the office has. I basically taught both C# and Java to the senior engineers on my team while I was a summer intern in college. I also learned stuff from them. A decade and a half later, I continue to both teach and learn from engineers both more and less senior than myself. But, of course, if the questions a senior is asking demonstrate incompetence, that's a problem
    – reirab
    May 19, 2023 at 1:43
  • I do think there's degrees of reprimand here... for example, "Thanks for helping, but in future please always follow (procedure) if you need to transfer a story from one dev to another." OP might be coming from a good place but still have caused a decent amount of headache if this task was part of a PIP or something. May 19, 2023 at 16:47
  • @Donald It may sound arrogant if something that the OP told us is not true or if he is exaggerating or misunderstanding something. But if what he told us is not biased, then it is a big red flag for the company. They have a senior engineer that cannot solve a basic problem in his field and he is not even able to do proper research, but he asks a junior to do his job instead. ... May 19, 2023 at 16:56
  • 1
    @Donald I'm with Lorenzo on this; without additional information I'm assuming everything OP said is true, and that the senior engineer is coming to OP with basic questions that a senior developer ought to know or be able to figure out independently, and also that the entire company knows this team is the bottleneck in terms of issues. That's a huge red flag. OP might be exaggerating (or outright lying), but I'm assuming he's not and the problem is actually bad.
    – Ertai87
    May 19, 2023 at 20:22
8

You are currently being taken advantage of, and it is in your power to change it.

It looks to me as the senior developer knows that he is not good at what he has been assigned to, and found a way to look better to management by exploiting you.

As you are colleagues who will need to work together in the future you will need to find a way to handle this yourself.

My suggestion is talking to him in private and say something like

I am very busy with my own work, and I am helping you on top of that to be a helpful colleague, but I really do not like that you don’t give me credit for that in public. What can we do about that?

If he starts giving you credit, fine. If not, you can simply say that you must finish your own work before you can help him and then decide on your own how much or little (if any) that will be. If he really needs your help more than that tell him that you need the person responsible for your time to tell you to help him. That makes it a manager issue.

You have more power than you think. Feel free to leverage it.

4
  • Now the senior engineer has an excuse why the project is not getting done: "OP said they would help, but now they are not helping. I have to do it all myself now." Which may backfire, especially since the OP doesn't have the track record or political capital at this new job.
    – spuck
    May 19, 2023 at 16:57
  • @spuck OP _has helped - this is explicitly said in the question. The I would expect the response to this to be along the lines “I have helped what I could reasonably do. I was not expecting this much work was necessary or I would have run it through the project owner to be sure that he/she was ok with the decrease in velocity” May 19, 2023 at 21:15
  • Right, but your answer suggests the OP can stop helping, if they don't end up getting credit for the work to their satisfaction. If the senior has the ear of management and their colleagues, they could present the OP as being the reason the work isn't getting done.
    – spuck
    May 19, 2023 at 23:06
  • @spuck please reread, down prioritizing helping, not necessarily stopping completely. May 20, 2023 at 8:34
5

This answer assumes that there exists some ticket system for tracking updates being made. If no system exists then that is the number one priority before any other actions are taken.

Dismiss offer to help during stand ups

When he gives status during stand ups that he is helping you. Right then and there cut in and state that his help is not needed and you have it under control and that you will request help if needed, and he should be working on something else. Do not call him out on lying.

Let the ticket system do the talking

All requirements, defects, improvements, and other updates to the project baseline should be tracked in some kind of system. Anything actively being worked should be assigned to the person working it. As soon as you took over the project for the colleague the associated ticket(s) should all be reassigned to you.

Then when it comes time for the turnover meeting only people who are assigned a ticket(s) should be the ones providing status on said tickets. Since your colleague does not have the ticket(s) assigned to them then they will not have a chance to talk letting you control the initial narrative. At which point you provide the current status and your estimate for how much more time it will take to complete. Since they were not helping you, you do not mention any help being provided. If questioned on it, then speak truthfully that you have not received any help from him.

If the team lead is paying attention they should ask why it is taking you so long when your colleague said it would only take two days. At which point you can explain the exact technical work needed to complete it. The lack of status and thus contribution by your colleague should be pretty obvious after a few turnover meetings.

4
  • 3
    And/or check-ins in the version control system ... if they don't have one of those, it's REALLY time to find a new job! May 17, 2023 at 21:36
  • 2
    @Sharpenologist If OP was brought in to "help improve coding standards and development practices", and they sees a lack of version control, that is a golden opportunity to do exactly what they were hired for. You suggest they quit?
    – Edward
    May 17, 2023 at 22:57
  • 2
    @Edward ... It's 2023, any company doing software development that doesn't already have SOME kind of version control system - no matter how 'bad' it is [think Visual Source Safe] is probably in more trouble than the OP is getting paid to fix [and/or doesn't have the authority to fix & enforce compliance]. The behavior of the offending 'Senior' developer is evidence that there's a systemic problem, but if the OP doesn't have sufficient authority [in this particular case, hire/disciplinary/fire authority] then IMHO, OP should get out of this company and in to a company where OP can thrive. May 18, 2023 at 15:29
  • @Edward, if they are 5 months into it and haven't been able to drag the team into the 1990s with a version control system, quitting just may be the right answer.
    – spuck
    May 19, 2023 at 17:00
1

This sounds like a classic case of the Dunning-Kruger effect: someone so bad that he can't see how bad he is, and therefore thinks that seniority means that he's actually better than everyone else, compounded by management who didn't know any better, and promoted him to "senior" in the first place.

So, as others have noted, this isn't about coding, this is about politics.

The strategy is to split the team into "useful" and "not useful" people, but without making it obvious to them that that's what you're doing.

I would focus on "you were hired to help improve coding standards and development practices".

Start by assessing who among the team is amenable to re-training in these matters, or even better, already has some knowledge but is having it squashed by the Problem Person.

Make these people your allies. Gradually form a team-within-a-team that runs projects according to these better practices, with a loose flat management structure: "mentoring, not micromanagement."

Aim for diversity: male & female; big picture and details; pictures and words; early birds and night owls.

Reduce interaction with the rest of the group as far as possible.

Then I would have a conversation with the manager who hired you to "fix things". They clearly already know there's something wrong, so they're unlikely to brush you off.

Discuss your concerns about the team's regimented seniority getting in the way of fixing things, and the level of distraction from "too many trivial questions".

Explain that "code management" is about enabling multiple people to work effectively on one project, and how the team is currently failing (badly) on this point.

The strategy is to split the team into "useful" and "not useful" people, but without making it obvious that that's what you're doing.

Get the manager's buy-in on:

  1. taking some of the team on secondment to trial your proposed improvements; suggest the people you've already identified;
  2. if possibly, moving this working group to a separate seating Pod;
  3. you running training sessions, with them as part of your own KPI; get budget approval to bring in lunch if you run them at lunchtime.
  4. making check-in, bug-fix, and bug-cause metrics part of your own KPI, with a view to making it part of the KPI for other people as well.
  5. making peer-review part of KPI.
  6. allowing the working group to avoid most whole-team meetings, and instead convene its own meetings.

Start running training seminars.

Convene "working group" meetings and run them as if they were a proper team meeting.

Continue to second people from the main team, but if people are disruptive, rescind their secondment and send them back to the "main" team.

Eventually you will have the larger group, and you can talk to your manager about it being formally recognized as a separate group. By then it should be really obvious that your group is getting stuff done and the "main" team aren't.

In the end you won't even have to complain to get the Problem Person removed; you simply provide management with the tools to assess his contribution, whereupon it becomes obvious to them that he's a dead weight and they should let him go.

PS: I would normally write "they" and "them", but in my experience of such people, the Dunning-Kruger affects males almost exclusively, so I use "he" and "him" advisedly.

3
  • 6
    Dunning-Kruger affects males almost exclusively [citation needed]
    – WoJ
    May 19, 2023 at 9:58
  • 2
    The strategy is to split the team into "useful" and "not useful" people - I do not think this can be done in a productive way b May 19, 2023 at 12:49
  • ...someone so bad that he can't see how bad he is, and therefore... We miss more context to assess whether this is true or not. I have an alternative in mind: he was put in that place because he "knows important people" (or he snuck into that position because of bad management) and he is so cunning and manipulative that can pull the "do my job for me, but I take the merit with a straight face" trick on the junior without getting busted. I've met people like that and some friends of mine met them, too. Heck! I've known people who made a lifelong career behaving like that! May 19, 2023 at 19:16
0

Eventually I got tired of this (and he was running behind schedule by a lot) so I offered to take it off his hands (despite having my own project to deal with).

Finish your own project before helping others. Let him takes ownership even his project runs behind schedule unless his project having impact on yours until someone higher up assign you to help him. Even you are offering help, try to limit the hours to a scheduled catch-up with a list of questions rather than disturbing your own schedule.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .