Advice needed: difficult coworker and passive manager

[throwawaydev123]

I'm considering leaving my job at a big tech company working on a cool project because I'm having trouble managing my work relationship with a difficult coworker and feel little support from my manager.

I am leading a project which a difficult coworker is contributing to. They see any disagreement with them technically as a personal attack, including when I leave them code review comments. I'm the only one working closely with their code on my team.

I have brought up with my manager the consistent pattern of low quality code, bugs, missing estimates by 5x, 10x.

This has escalated to them leaving me very negative performance feedback and complaining to my manager about my "toxic" behavior. All the other feedback I got from my team was overwhelmingly positive. This coworker said I was "creating an atmosphere of fear" for "ridiculing" and "targeting" them publicly.

I've never received feedback like this before on any other teams. I admit, I am direct and get straight to the point when it comes to code. Should I expect my manager to do something other than telling us to "resolve your differences"? I would really just like this coworker to deliver tasks in a timely manner and not create extra work for me or other people, or at the very least communicate to the team when timelines are slipping.

Any advice? Strategies?

[Jugurtha]

I'll assume you want to continue working there...

Do you have any trace of this in writing?

You have your code reviews in some management system like GitHub and GitLab.

When you have talked with your manager, and when you talk with them, send a recap of the conversation for memo. Same for conversations you have with your coworker.

Make sure it will not become a he said she said issue. Every interaction in writing.

It will become obvious who's doing what, who's not doing their job, etc.

This will avoid the situation where they get fired and tell you "You didn't tell me" or that there were no warnings.

Keep calm and courteous. There are people who count on you losing your shit and say "See what I have to deal with?". Gaslighting and all.

Version control is not just for code.

When doing things in writing, do not exclude th possibility of reading what you wrote and thinking "Holy cow, I'm the asshole". Either way, verba volant, scripta manent.

[throwawaydev123]

> Do you have any trace of this in writing? Yes. One problem was they were merging their code without PR approvals, which caused many regressions. This is generally not allowed in our codebase. My manager was aware of it and the extra work it brought on to the team. It took months for them to correct this behavior, where as most devs, even interns correct in < week. And it only ended when I escalated the issue to my manager's manager. My manager's point though was that the coworker was "improving" which was... true. They had been submitting a higher percentage of PRs over the few months.

sorry for the vent... This was probably the most "solid" issue I had that wasn't subjective.

> Make sure it will not become a he said she said issue. Every interaction in writing. Good point, I should document our interactions even during meetings. I rely mostly on our written communications to think through our interactions but recollections of meetings are unclear. especially when I didn't view some interaction as memorable from my point of view at all but then later it's used as a vague example as "created fear" in a meeting.

> When doing things in writing, do not exclude th possibility of reading what you wrote and thinking "Holy cow, I'm the asshole". Either way, verba volant, scripta manent.

Also good advice. I am not by any means perfect in my communications and sometimes I really was the asshole in some situations.

[Jugurtha]

Writing things down, especially for action items, can clarify but also track decision making to improve it because some patterns become obvious.

For example, at some point when a colleague and I took over, I did a "post-mortem" of all the people who left the company (resignations and terminations) going back a year. I wrote down how these events took place, how they were perceived, etc. A pattern emerged and one of the things that exacerbated these events was information asymmetry. Our next step as people now involved in helping to manage was to reduce that asymmetry as much as possible, and to implement a more dignified way to fire people when it came to that, and the guardrails/flags to correct course to avoid getting to that point. We made sure the feedback was much more explicit when we dealt with people who'd keep on with a certain behavior after they acknowledge it was subpar. When we speak about it, and we document the thing and the intent to change that behavior, and we do it over and over, it serves to refresh memory if you truly are forgetful, and serves to prevent "but you never told me that" or "I didn't know you meant it that way" when someone is into that sort of things.

On the technical side we write good, detailed, issues. When we fix a bug/regression, we try and figure out what drove us to have that bug/regression in the first place. How did we go wrong in our thought process? How did a wrong assumption go unchecked?

These issues help us recognize patterns and notice we've already fixed N bugs that are similar to that one. We then go fix the underlying issues for a family of problems, technical, but also in terms of business process or thoughts. This can be refactoring, introducing tests, adding a checklist, documenting something, etc.

Why did I make that mistake and am I making similar mistakes? Can I solve for a root cause so that I cannot make that mistake again even if I wanted? How can someone else not make that mistake even if I never speak with them?

If we have a regression: why was this working and is not anymore? What changed? Why? How can we prevent that? This broke because I forgot a step in a process. It has happened before. How can I make the process succeed and decouple it from my memory or whether or not I had a good night of sleep? Can this be automated? Can a part of this be automated? We systematically go through that loop and introduce efficiencies that are needed to move fast as a small, tight, team so we can focus on what matters, instead of putting down fires, whether technical or administrative. We put fires, but if the fires start looking familiar, we handle the source. One way to figure out the fires look similar is by documenting things (issues, incident reports) because then the similarity is clear and staring at you and you go "duh!". Having these instances enables you to cluster into families of problems (technical, administrative, business) and solve a more general problem after you've solved one too many specific problem.

On the business side, I also analyzed our past projects and tried to figure out what worked and what didn't and the reasons behind them. This has shaped our current process of doing business. With that analysis, a certain number of things to clarify made it into a sort of checklist with our clients. For example, one of the things that doing that made us do is to explain very clearly to the decision makers that the people who will use our product [we do bespoke enterprise products leveraging machine learning] must be at the table. We need them at the table, or we know the project will fail. One other item is to make sure we nail down the problem with the client before we even get to the "ML" stuff or implementation. One other item was to make sure the person we are dealing with has decision power and the budget.

Doing this, we're much more profitable now with the third with one eigth of the number of projects and a high success ratio, because we don't start projects we know will fail [that don't check the boxes or where there are too many red flags].

I had a file called `lessons` where I documented mistakes. It could be anything, such as arriving almost late at a client meeting because I had assumed X, or not doing the proper diligence on something because of Y, or removing a line of code in a careless commit as I thought it did nothing because there was no reference to something, but it turns out it was used at runtime dynamically.

Therefore, when I say to document things, it's not only as a "cover your ass" or as an "exibit A" against people. It's to keep evidence against bullshit, even more so yours, and address it. The goal is to function, get the job done, learn, and build a better organization that can go on and do good thing.

Sorry for the sloppy writing and no editing. I wrote a bit about some of these issues here https://news.ycombinator.com/item?id=26182988

That answer contains links to other answers related to aligning the team, product, leveraging your time, communication, etc.

[Frypa]

Here is something I did that actually worked.

I had the same issue, and I was new to the company. The guy looked like he hated my guts. So I tried to look for something he really wanted and did him a favour. This could be anything really. Then I tried building relationship slowly and it worked. If you go to your manager now, he may think you are not ready for leadership. Sometimes you have to deal with issues by yourself.

If you tried everything, then try and have a talk with your manager. But before you go to see her/him, be prepared to explain the issue and the solution. Otherwise you will be seeing as the "complainer" who can't work with other people.

[throwawaydev123]

Did you feel like the person who hated you could have seen the favor as "one upping" them or "showing off"? In the past I've tried to help the co worker but I'm not sure if I was harming or helping the relationship now that I think about it.

[muzani]

"All the other feedback I got from my team was overwhelmingly positive."

If this is true, then you have nothing to worry about. The complaining person is an underperforming outlier and the rest of the team would be eager to use your feedback to get rid of them.

However, something about this story feels off. It could be a Byzantine fault - multiple parts of the story being untrue, creating a false overall picture. It could well be that you're actually creating an atmosphere of fear where others agree with you because that's the easiest form of conflict resolution.

If your manager is saying "resolve your differences" and not taking sides, it could be that you're both seen as troublesome.

[throwawaydev123]

It is indeed hard to take a step back and view without my own biases. I definitely have had my faults. I sometimes respond in a short and direct way that can be seen as aggressive. I can agree that I am part of the problem, but I have a hard time seeing myself as the one creating most of the problem, fear, especially given all the signals that I am doing well at my job (recent peer recognition of achievements, recent promotion) with the exception of this issue.

So maybe you are right and time will tell how this will go.

edit: actually is there a strategy I can get honest feedback from other coworkers if indeed I am creating fear in the team as you say? I would want to know so I can stop whatever I'm doing.

[muzani]

Feedback from your boss or anonymous feedback helps. One on ones help in identifying these things too. This is difficult to do without management, but you might be able to propose it.

Though as long as you are aware of it and checking the tendency to do so, it should be fine.

[bjourne]

The way you are describing your situation reveals some immaturity on your part in relation to your leadership role. As a project manager, it is your job to make things work and to deal with "difficult" coworkers. Remember that people aren't "difficult" per se, most want to do a good job and they may have rational reason for acting in certain ways.

You should talk to your coworker. And you should realize that perhaps you have contributed to your work-relationship having deteriorated. It may not be all on them.

[throwawaydev123]

Yes, I agree, it's not all on them and this is a learning opportunity for me as well.

[GianFabien]

Don't leave your job. You appear to be working for a good company with lots of potential opportunities.

I get the impression that your manager might be protecting your under-performing coworker. So I suggest a two step approach:

1. Go to your manager, explain that out of your team of N persons, all but one work well with you and you with them. Request that somebody else work with the one coworker that you have problems with.

If your manager refuses, then:

2. Go to HR or your manager's manager and explain that you are working well with your team and only having conflict with one coworker, who in your assessment is under-performing and for reasons unknown to you the issue isn't being addressed by your immediate manager.

Thus ask to be assigned to a different team within the company or if no such position is immediately open, to be relieved of working with the errant coworker.

[theli0nheart]

Have you shared your feelings with the difficult coworker?

Why does it matter to you that their estimates are off?

How do they create extra work for other people?

[Irongirl1]

Read Ben Franklin's autobiography; you are looking for the book story.

[throwawaydev123]

Sorry, can you elaborate a bit more? I read his autobiography a looong time ago but I don't recall much of it. Maybe time for a reread.

[Irongirl1]

Do you have an assistant who does your work for you? I'm not being facetious, but I gave you a lead...it is for you to do the follow-up...or not. I'm not the one with the problem.