Ask HN: Direct report has difficulty working in a team. What do to?
I discovered they didn't really work as a team at all. They barely interacted with each other. Pieces of the code were owned by a single person and they had different naming conventions, different CI/CD processes, etc. Basically it was 5 1-person teams in one.
I was hired to implement best practices and turn the situation around because the company is expected to grow faster in the next few years and upper management rightly so thinks this situation won't scale.
All team members seem averse to change but that's just human nature. However, one person in particular is pushing back on every proposal.
For a very simple example: there was a discussion about adopting CODEOWNERS and automatically adding the owners as reviewers. Basic stuff, right? This person said he doesn't understand why we want this, that this is just paperwork, that there is no benefit, this will slow us down, etc. You can see they don't know much about or don't like to work in a team.
Another example: let's stop committing code to the master branch directly and instead work with PRs and reviews. Same arguments as above.
In a normal situation, I'd be pretty blunt about the new reality and work with this person to adapt BUT I'm sensing this won't work.. given the initial signs. The bigger issue here is that this was the first developer working in this team and there is a lot of knowledge they know that nobody else knows. There is no documentation either (and they don't think there should be). It's a pretty nice job security situation.
I have to work harder with this person and maybe come up with a miracle to help them work in a proper team setting. I just can't fire them, the company let this linger for so long and now my hands are tied.
Any advice?
5 comments
[ 3.4 ms ] story [ 21.9 ms ] threadI'd do the following:
1. Make sure you have complete admin control over the git repos.
2. Clearly communicate that pushing to master/main branches will no longer be allowed, all changes need to go through the PR review process. Document this process in the same place you'd like to see the developers start documenting their work too, make sure they're aware, and ask if anyone doesn't understand how it works (branching, etc.) Also test this process yourself and make sure it works as expected.
3. After everyone has had time to review the doc and no questions have been brought up about how it works flip the switch and prevent any merges directly into master/main on all repos (in Github you can do this with branch protections.)
Once the initial shock of (gasp) having to review code changes wears off, you can start adding other processes as needed, CODEOWNERS, consolidating CI/CD, etc in a similar manner.
Worth noting: If this troublesome developer leaves in frustration, they're going to experience the processes you're describing pretty much anywhere else (save for a similarly dysfunctional shop) they may or may not know that too. If they're resistant to process change, perhaps they'll be resistant to job change too.
I would add to keep your manager apprised of the findings, plans for improvement, and risk mitigation should the team member decide to leave.
You should also make your mind up how much disalignment the team can stomach and when you draw the line in working with that person.
And talk to HR. The good ones have tools & coaching for how to handle such cases. The mediocre can at least advise on what to document in case you later decide to dismiss the person.
So work with the team to figure out what repos actually need this policy applied, don't just apply it blindly. Similar reasoning could be applied to most other things. Don't just go issuing wide-ranging edicts because you can, without understanding the actual downstream impact.
Whether this is a conscious or subconscious move on the part of the "difficult" team member, don't allow yourself to be manipulated. As long as you have full access to the source code, deployment pipelines and full control over the domain, it's always possible to figure out how things work and document them after the fact. Sure it can be a big pain in the butt, and you'll often find yourself failing to understand why things were done a certain way; but with skill and patience you can demonstrate that the "indispensable" lone wolf genius is a lot more dispensable than he thinks he is.
Obviously it's much more preferable to find some way of working together that honours his contributions while also moving towards a more scaleable way of working, but you can't force another person to change their approach if they are not willing to co-operate, learn and grow.
You don't have to win this guy over on day one. If you can get them onboard, the loudest detractors often become the most prominent supporters in the long run. Take time to understand his concerns, outline your goals, and get his input. You have a greater chance of success by giving him a voice at the table to help define the solutions. You can also outline how code reviews allow him to have an opportunity to review other people's code, making sure it's up to his standards, playing to his ego.