Ask HN: How to tell someone they are not doing well at work?

As Danso said, you could mention it to the person which the person in question reports to, and I would do so with caution and vagueness. You don't want to be seen as micromanaging someone elses department.

Other times, it's someone new to the team|company|career who's given a task that directly impacts my area of the app, and they go off and build some monstrously over engineered solution to a not difficult problem, without asking for client (ie my) input. Once had to work with a guy who would implement plugins for the build system for trivial stuff for example.

One that stands out is a guy (experienced, 10 year+) who was hired on to implement a one off for a client such that he was able to re-use a lot of existing code. He systematically went though and cut and paste entire source tree's into a new project. This time, I threw caution to the wind; "don't do that, package it and use it as a library!", no effect. A couple of months later the same guy comes to me with a bunch of bugs related to hard coded paths in the code he'd moved, but hadn't updated the paths. Oh I was a jackass; told ya so, didn't listen did ya?

I have struggled with this over the years. I have tried to be super diplomatic and circumspect. I have tried staying silent, I have tried talking to leads and managers. Here's the thing: nothing works. I have come to believe there is something in the DNA of (some) developers that prohibits asking for or taking advice.

> myself was once in a situation where I thought myself a star team member only to find out later that I was not helping much, and that is putting it mildly. I wasted 12-18 months before I figured this out and moved on.

This is incredibly self aware, and I congratulate you. I believe most developers achieve this after some period of time in the industry, but some never do.

Edit; added a bunch of stuff, this is a sore point for me apparently.

"Hey, the other day when you forced pushed over my code, that was not fun. I lost a day's worth of work and it impacted the team."

If you can't back up what you're saying with concrete examples, you will be ignored.

In general, I try to stick to very solid, objective things which could have been done better. If there was a missed opportunity to leverage existing functionality or libraries, mention this. If a decision was made by a developer with negative consequences, identify how that decision was reached. Often, it was due to a lack of collaboration with other developers and/or a set of assumptions which were incorrect.

There are bad developers, but often there are bad processes which allow bad developers to make situations worse. If I were a developer, and every retrospective involved me explaining why my code blew up or project ran late, eventually there'd be an epiphany. Or I'd get frustrated and leave, which may be for the best as well.

Even "good" devs make mistakes. Part of getting good is having made a few mistakes, and either identifying them yourself, or having a caring (senior) dev point them out and guide you. Some folks are capable of course-correcting and improving, and others are not. It could be that they're a lousy coder, but handle support or QA or some other tangential role with ease.

Regardless, you have to deal with the situation, or the whole team will start to lose motivation. This will become a thorn in the side. The more experienced and capable devs will tire of having their work corrupted. Their quality will decline and they'll leave. Morale will take a huge hit over one person on a team. Better to make a decision about a person earlier rather than later.

Nobody regrets letting someone go too quickly. Everybody regrets letting someone go too late.

Over time, they will probably wonder: "hey, why is this person investing so much time into helping me?" That may be enough for them to get the picture.

if you are in management, consider a carrer 180 :)

I get the utilitarian ideal of "minimizing the pain down the road", but the questions are: how much can you even do to minimize that pain, and what distribution will the pain have.

I'd frame it in one of two ways...

If the manager doesn't know this person is under performing, why? This is a process failure that needs to be rectified, work with everyone who needs to be included on coming up with process changes that will prevent this in the future. Code reviews, retrospectives, 1:1, team reviews, whatever methods seem like a good start.

Addressing the underperformer, what would you suggest for bringing them up to par? What is it, actually that's not up to par? Are they slow? Sloppy? What can help with it? Working more closely with them? Pair programming more frequently? Daily/Weekly/Per Ticket code reviews? Pull requests? Break it down in to actionable bullet points.

If they're too slow because they over engineer, suggesting more time pair programming would be a great idea. If they're struggling with a given technology, maybe an investment in a course could get them to speed? Maybe they get a little analysis paralysis with tasks that are to open ended and undefined. Suggest pairing them with a more senior resource to tighten the mental boundaries and keep them moving along.

I always make it a point when coming to others with a problem to have some suggestions towards rectifying. Now you're not complaining, you're trying to help. Don't expect your plan to be THE plan, it's meant as the conversation starter, and now everyone involved has a stake in a successful outcome.

If their manager isn't responsive, or you can't put a finger on what's off about this person's work, you don't have much you can do.

You're not their boss. Don't review their performance.

However, you shouldn't be afraid to provide constructive criticism to any of the people you work with. So if you see them implementing a solution incorrectly, suggest a different approach, and say why.

Firstly, examine your own motivations. I find that 95% of people who tell other people they're doing it wrong claim it's for the "good of the company" but really just enjoy feeling better than other people. This is why they fail at ever making friends or convincing people, because they are unwilling to give the advice unless they make themselves the larger person in the process.

If you want to help this one individual, and your motivations are pure, then befriend the individual, and after a few hours see if you can find a way for them to solve it on their own by offering yourself as a sounding board. If done right, they won't realize the degree to which you helped them.

But if you're afraid of over-a-year's worth of time being wasted, it sounds like the larger issue is how inefficient your company is. I'd either make peace with that or try to solve the problem at its root.

I have only a few people I would give honest feedback to and who in turn tell me when I am doing badly. Otherwise it's not worth it.

In the meeting, be direct, but not accusative. Remember, you have concerns, but you don't have their context. You are wrong about things, even if your conclusion is correct and you can help. Present an offer to help. Explain that you are concerned by what you see, explain that you know you don't see the whole picture and would like to know more so that you can understand and you can help. Spend as much time as you can listening and asking questions to understand why things are as they are. You are establishing trust and understanding here, and that's your responsibility.

Once you know enough, you will know how to help. Remember to continue to apply the same non-assuming practices and offer optional assistance. They are making their own choices for reasons you can't always know. If they continue making bad choices, make notes and provide direct feedback about them. Direct feedback is explaining something specific and why you have concerns with it. When you say you have concerns, do not say "this is wrong", say you would prefer something else, or you might do something else. This is to enable discussion, and you need to discuss these things to be effective.

If you go through this for months and you have formed a relationship, but things aren't improving then it is time for a pip, and you should be able to work with the relevant colleagues providing clear evidence and guidance.

HTH

A. Ready and willing to acknowledge personal failings in an effort to mitigate them.

B. Stubborn and in denial, but a painful moving on and the subsequent self reflection will get them on the right path.

C. Extremely stubborn and they may go their whole life blaming others for their failures.

It sounds like you fell somewhere between group A and B when you were younger. Life pushed you into group B when it might have been possible that a mentor could have helped you be in group A. It is also entirely possible that you were firmly in group B at that age and the 'wasted' 12-18 months was actually just a necessary learning experience that school could not provide.

For the moment let's assume that there is an equal chance they are an A, a B, or a C. Talking to A could help them if everything goes right. Talking to B would be at best pointless. Talking to C would probably backfire internally. I don't like those odds.

If you are confident that talking to them will help them and that it is worth the risk, don't tell them anything. It sounds like the improvement they need must come from within. You can ask them general questions that get them thinking in the right direction.

One way to start cultivating this type of culture is with post mortems. It usually involves reiterating every 30 seconds that it is not a finger-pointing exercise, but a session to identify future goals for improvements, in order to maintain the positive tone throughout the session.

Regular planning meetings are another place where it's possible to market the practice of open dialogue. Since these are already focused on upcoming objectives, it's easier to bring up concerns and discuss it as a team. It's also a great opportunity for quieter team member to voice support for something you believe in, which helps an idea gain more traction. Likewise, it helps you stay humble when people disagree with you and bring up arguments that you had not thought about before.

Another place where dialogue can be cultivated is through documentation. I don't mean a passive-aggressive README in the repo that nobody is going to read. I mean through active discussions in tasks-related tickets. There's something about writing things down that helps make vaguer ideas more concrete and actionable.

Semi-related to the previous point is code reviews. The idea here is, again, not to confront or alienate a co-worker, but to give actionable feedback in small enough chunks that someone would feel motivated to do, out of a sense of perfectionism or whatever. Code review also let you familiarize yourself with things that are coming. The challenge with code reviews is that they are difficult to start if they team isn't already on board with it. You can start by pushing commits to code owned by someone else and then nagging them to review it. The idea is to gradually push for a workflow where landing changes (at least large ones) should require someone else's approval. But again, this newfound "power" should not be used for rejecting work, but to foster early communication.

As you grow communication channels, you can also use them to convince others that you should be the one to do the work that you care about.

The biggest trap you should avoid is falling into the "they are stupid" mentality. If things become adversarial, it becomes very very very hard to persuade people. Also, be humble and be realistic. Sometimes decisions that you don't agree with have reasons that have not been brought up to you and that you had not thought about. And sometimes, things will indeed just turn out to be bad even with your best efforts and hopefully those times will be a learning experience for someone. At those points, focus on what can be done, and start the dialogue again.