
Ask HN: How to tell someone they are not doing well at work? - ptero
What is a good (or the least bad) way to informally tell someone who does <i>not</i> report to you that they are not doing well at work? Should one even try?<p>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.<p>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.<p>Thoughts?
======
dmourati
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.

~~~
everdev
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.

~~~
muzuq
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.

~~~
CodeCube
"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 :) ).

~~~
muzuq
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.

------
le-mark
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.

~~~
virtuexru
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.

~~~
le-mark
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.

~~~
diyseguy
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.

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

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

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

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

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

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

------
NumberCruncher
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).

------
danso
Are you able to talk to the person to whom this underperformer _does_ report?

~~~
zakfu
Came here to say this.

------
Tade0
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

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

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

------
raggi
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

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

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

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

------
francesca
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/](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.

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

------
blahblah3322
Often times it is best to not say anything.

------
corpMaverick
You could try using the Socratic method.

------
onion2k
Post on HN and hope they see it. :)

------
JSeymourATL
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...](http://www.huffingtonpost.com/russell-bishop/self-help-are-you-
critici_b_627267.html)

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

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

~~~
gaius
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.

------
nichochar
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?"

------
gcb0
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 :)

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

------
Mz
_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.

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

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

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

------
borplk
Don't do it.

------
ensiferum
Don't bother.

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

