Dealing with a patronising senior engineer

Question

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.

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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.

Answer 6

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.