Ask HN: How to tell someone they are not doing well at work? | Hacker News Reader

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

60 pointsptero52 comments

What is a good (or the least bad) way to informally tell someone who does not report to you that they are not doing well at work? Should one even try?

On the one hand, I would like to limit the coming pain -- I 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. I wish someone gently helped me, although it would not be easy -- it was my first job after grad school and of course I knew myself what I was doing better than some dude in the next office.

On the other hand, it is a minefield. I am high enough in the food chain that such talk, even informal, could be seen as an interference; he may also decide to shoot the messenger, complain to HR, etc.

Thoughts?

View on HN

What about reframing this as how to help someone do better at work? Once you change the perspective, your motives are pure and the person you'd like to help is likely to feel less threatened.

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.

Exactly. Judging their performance won't help. Offering to help them will.

Also, it sounds like you're worried about conflict of interest since this person doesn't report to you. Would it make sense to approach their manager with something like: "I've noticed EmployeeX doing X at work. Have you noticed that too?" That helps see if you're in alignment with the employee's manager. Maybe the other manager has reasons for encouraging or tolerating that behavior. That's important for you to know before you offer to change it.

If you are in alignment then something like "It reminds me of a situation I was in earlier in my career. Do you mind if I ask EmployeeX if they'd be open to some coaching around the issue?" That way you get everyone on board.

Transparency and honesty will usually help diminish people's fear of "interference". And if the manager or employee aren't willing to accept your help or see things as you do, then it's better to accept that and focus on your role and responsibilities.

I disagree with this, and would be very cautious of doing something like this in a business setting.

No matter how nicely you put it, you're going to come across as "I know more than you, I noticed this and you didnt, I can help and you cant". Especially stepping in and offering to coach, without being asked, in a department that isn't yours... I wouldn't like it if I were the other manager, I wouldnt like to see it if I was senior management.

If your environment allows for and encourages a more open structure, where you're confident you're not overstepping your bounds, yes this would be the tact to take. Considering you have to ask HN if this would be overstepping your bounds, just don't. Just stick to your stuff.

"in a business setting" ... I wish we'd all stop accepting crappy work environments just because they're a "business setting". There's no business setting certification that they have to maintain ... nothing is set in stone, and we don't have to accept stodgy work environments.

If this isn't an environment where you feel comfortable talking to your coworkers ... then gtfo of there and find a better work place (not directed at you or OP, just in general :) ).

I agree 100% and think that OP __should__ absolutely be able to approach a coworker and mention this sort of thing. But, in the OP's interest (assuming OP wants to keep job in good standing) I made my recommendations.

"Business setting" sucks. I'm in a "family-like" work environment where I can approach anyone from CEO to Reception with ideas, feedback, or ask for feedback. It's fantastic. I wish all companies were like this. Unfortunately, that's not the case.

I agree with the tactic of being willing to help them. Yet there needs to be a frank discussion in that it is made clear they are not meeting expectations. Then you can move on to how you can help them improve.

TBH, I suspect the best option for him is to just move on to another company. He is sharp, always learning and young (supposedly irrelevant, but we all know it helps). He should have plenty of options.

For us, though, he never finishes anything he starts. He does three quarters, then considers it done and ignores requests to wrap it up, so 90% of his work has to be completely redone. That, unfortunately, is baked into his reputation by now, so even if he has perfect execution from now on he would be carrying the reputational baggage he collected over the last years for a while.

Does he know this is a problem? Have there been frank discussions about how this habit is harming team productivity?

If he's been there for a few years and he hasn't changed despite repeated nudges and explicit warnings, yeah maybe he needs to go.

If I'm honest though, smart and always learning isn't compatible with refusing to improve a bad habit. If he's as sharp and eager to learn as you say, it seems like he would be open to feedback.

"Reputation" is quite silly. If the problem goes away and he stays, why the hell should his "reputation" come into it?

I've experienced this so many times, it's depressing. Often it goes something like this, I'll sit near the guys (it's always guys) in the other team and overhear how they're planning to implement something, when the library or framework they're using already does that, but they don't know about it. If I say something, I'm ignored, and they go off and write a bunch of buggy code that causes everyone problems down the line.

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.

I just want you to know that should you ever happen to see me attempting to re-implement code that already exists, please please please tell me.

> He systematically went though and cut and paste entire source tree's into a new project

wait, did he not have an explanation of this?

I think you were made to be a solopreneur.

Maybe it's because you come off as a pompous prick? Instead of acting like a know it all you should perhaps come at the situation from a more diplomatic perspective.

This is to GP's point: you're not perceived as trying to help, you're perceived as being a pompous ass. As they say, no good deed goes unpunished.

This is why I just leave places that have this type of shit going on, you can't help and people will not listen. You can actively harm your career/reputation if you try. Just go somewhere better.

Yeah, don't down vote this, it's valid. All I can say is I've been hyper aware of this, I've really tried to not be pompous or condescending. It's always, ok, this again, let's try the Socratic method this time. Or, ok, this time I'll cite the documentation. But yeah, like others have said, I don't try anymore. Unless it directly impacts what I'm working on. Then I'm just a dick, or move on.

Oh god, I've been there too. It's like watching code cancer develop and I'm helpless to stop it. Maybe if they can name an anti-pattern for this that can be readily referred to. I usually try to refer people to Clean Code by Robert C. Martin. But everyone presupposes they are smarter than me and old guys like him and smarter than the people who already wrote and tested and attained widespread adoptance (word?) of whatever library or framework already does this stuff he's re-writing. I've come to believe its an attempt to establish job security by writing vast tangles of custom code all their own. Trouble is when you have non technical managers who see him churning away - checking in loads of code and spending hours 'fixing' bugs (he introduced himself) so on paper he comes out looking way more 'productive' than others - so he becomes a darling.

I think that many developers are worried about being seen as stupid, one way they choose to handle this fear is to not take advice - the macho developer route. It is not a tactic conducive to success at programming, but it is a tactic conducive to handling the fear of not being smart enough.

Some of the advice here is pretty bad.

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.

If this person doesn't report to you, you're best off not doing anything without their manager on-board. Otheriwse, leave it alone.

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.

IMO don't stick your nose where it don't belong.

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.

People around here tend to look down on "Agile" practices, but having a dedicated time for honest retrospectives on a schedule (rather than when things break) eases situation. If you can get the team together (physically or otherwise) on a regular basis to evaluate how things are going, pride and nerves tend to fall away.

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.

Unless you already have a good rapport with the person, I wouldn't suggest intervening right away. You should get to know them a little more first.

Once you know them, as someone else in the thread suggested, be positive and offer to help. "I see you're doing X. There's a great blog post/paper/etc about that! I'll send it to you." If they come to you for advice, don't tell them what to do to solve the problem. Ask them questions that might lead them to finding the answer themselves. People feel better when they feel they were able to come to a solution, even if you guided them.

And if you're ever not sure, remember this: these people are your colleagues, not your friends. They're adults and they have to be responsible for themselves. Be friendly to them, but don't treat them the same as a friend. Friendship is more intimate and you aren't "forced" to be around your friends when the relationship isn't going well. You have to work with your colleagues everyday whether you like it or not.

That being said, it's been hit-or-miss with this approach for me at work. Sometimes you just have to tolerate a coworker's behavior even if you aren't happy with it.

If I had a good personal connection with that person I might say something, otherwise I'd be quiet. You could upset the person or the person's manager by criticizing. Most people and companies are really not set up for honest feedback.

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.

Giving advices no one asked for seems to be an intuitive solution for the problems of others. No one cares whether your idea works and the idea of others doesn't, because solving that damn problem is the only thing everybody cares about, right?

Wrong. In fact if you are right you are a smart ass making the others look like morons. If you are wrong you look like a moron. If you are right but nobody cares you may solve the problem by yourself and end up doing the work you are not paid for. People may get used to it and drink margaritas on the beach while you are fixing their bugs. Again and again. Until you burn out, jump ship and start fixing the problems of your new co-workers. Because solving that damn problem is the only thing everybody cares about, right?

What works is the "let them learn through pain" technique: Focus on your own tasks and cover your own ass. Make sure that your project works. This will help you to outperform the others who are distracted by giving unasked advices. Let the others fail. Let them learn what does not work. Let them feel the pain. If they need help they will come to you, because you are the outperformer who doesn't made them feel like a moron with his unasked advices. If this moment comes, be patient and helpful.

In this specific case I would focus on the following:

- Cover your ass. If you have to do with this given person make sure he knows what your expectations are and give him a deadline. It makes easier to track whether he delivers only 90% or not.

- Cover your ass. Deal with him like with a pawn in a chess game. What does a pawn of your opponent do? Basically nothing but annoys you blocking a field (delaying your projects). Do the same to him. Pick one of your pawns (an underperformer on your team) and put it in front of him (on the same dead-end project) and block his movements (keep him occupied and prevent him from working on mission critical code bases).

Are you able to talk to the person to whom this underperformer does report?

Came here to say this.

I've seen this, hell, I've been such a person.

In order to do something first you have to find the reason why this person doesn't perform to expectations. Some examples: - This person hates this job.

- He/She has personal problems.

- This person somehow managed to slip past the vetting process.

You can only really do something about the third one by suggesting improvements in the recruitment process. Most of the time your only option is to either offer help of some sort or patiently wait until that person resigns or gets fired.

EDIT: formatting

The way I see it, they are either:

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.

I've been the person who wasn't performing to expectations, and I've been the Manager who has had to tell people that they haven't been performing to expectations.

In my case, when I wasn't performing well, simple honesty would have gone a long way: it was simply a case of I didn't know. "Hey, Ian, you know, there's this python tool that you can run called pylint that makes sure that your python code meets community standards before you commit it," (it was my first real exposure to python) or, "spaces not tabs," (first real programming job @IBM before being rolled back to a hardware project). I was fortunate enough to have mentors and leaders who provided me with books, challenges, and guidance to make me a better programmer -- while doing so in a positive way (not a PiP: those are about as demoralizing as they come, yes, I'm looking at you, CollabNet) to make me a stronger programmer and a better person.

When I was a leader, I tried to move it to a non-threatening setting: lunch or coffee. I tried to take the steps that were used on me that I thought were positive -- You are part of a team, and we don't want to leave you behind; here is $100 to spend on books, and here is a list of books that you should start out on. Here are some programming challenges to get you started out. Here are some internal mentors who can help you. Don't be afraid to reach out to any member of the team -- don't feel ashamed. We are a team. When one person fails, we all fail, but, when we succeed as a team, each one of us succeeds.

Is this perfect?

I don't know.

Would this pass muster with HR these days?

Probably not. I do have a heart.

Request a meeting, and make sure the subject demonstrates that it is about feedback and/or an offer of mentorship/assistance, but do not add specific details. Pick the term based on their personality. If they refuse, that's ok. If you want to push, grab some "water cooler" FaceTime, and try to suggest that you need it, gently.

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

I would say talk to the person they report to. If that's not an option for some reason, tread cautiously. You need to provide specific examples and how it impacted you and the organization.

"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.

It doesn't sound like your problem, and maybe the person they report to thinks the employee is doing a good job.

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.

Your caution is well justified. Don't do it. If the person's performance is impacting your work, then it's on-topic for you and your boss only.

The chain of command may seem fusty and formal but it was invented to handle personnel issues (among other things). It's a thousands-of-years old technology and you should use it rather than fight it.

I'd offer to go out to coffee or lunch with this person, open up and ask if you could be of help. Just opening the door might be helpful. If the person isn't doing well, they are most likely getting feedback from their manager, or feel it in some way. If you open up and show you care, you set yourself up as someone who matters to this person, and then you set yourself up for giving candid feedback. I recommend reading everything by Kim Scott on this. It has helped me https://www.radicalcandor.com/

If this person's poor work is impacting yours, tell your manager. If this person's poor work is impacting your team, address it with their manager. If they come to you for advice on their performance, then give them feedback.

Star team members don't do things like try to take over the resposibilities of other managers. Team members talk to the other managers in private if they have an issue with someone reporting to them. Another general option is to start a company wide mentoring program.

Often times it is best to not say anything.

You could try using the Socratic method.

Post on HN and hope they see it. :)

I was reminded of a brilliant example of prefacing feedback aimed towards improvement. Ask this kind of simple question: “if my zipper were down, would you tell me?” > http://www.huffingtonpost.com/russell-bishop/self-help-are-y...

Is this your company? If not, why would you care about the work of other employees? You should only care if their lack of work hurt your own.

Start by talking to this person's manager. You have prior experience in this situation, which means you would be an effective mentor for getting this person out of this situation. However, such a relationship should begin with, be approved by, and be on the radar of this person's manager.

Then that manager will go to the OP's manager and say, tell your people to keep their noses out of my team.

And if word gets out that the OP goes behind people's backs to tell tales, noone in the company will ever trust them again.

The only way to win is not to play.

People think I'm a sociapath so take my advice as you will, but the way I would frame it is plain and simple: be honest, brief, and vulnerable.

Something along the lines of "This is a hard thing to bring up, but I think you may be underperforming. Do you feel like this is the case? How can I help?"

if your company have quarterly reviews, came up with time excuses to not write that one person every time. slow but for people with cripplingly bad social skills, that should be enough for management to catch up and work with that person.

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

Just remember, when you point a finger there are 3 pointing back

On the other hand, it is a minefield.

Unless one has an extremely compelling reason to do so, one should not make go walking through a minefield.

How are you evaluating their performance? It is unlikely that you have a full knowledge of all of their duties.

I tell myself that every day. (actually no I don't, I'm unemployed)

I generally find that you can't effect change if you only deal with problems reactively as they come up. I find that people are more receptive to feedback if open dialogue is part of the culture of the team.

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.

Don't do it.

Don't bother.

I encounter this too. But I know that people don't listen to me, and as you mention the potential downside is quite large, so to me that all adds up to keeping my big yap shut. The calculus may vary for you.

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.

Reply on news.ycombinator.com