Ask HN: Direct report has difficulty working in a team. What do to? | Hacker News Reader

Ask HN: Direct report has difficulty working in a team. What do to?

3 pointsthrowawaymgmt125 comments

I've been hired as a manager for a software development team with 5 people that grew organically and was managed by the VP of Engineering but he hasn't have enough time to properly manage it for a long time so they were just left to do work on things that they wanted without much oversight. I'm told it was like this for at least 3 years after the VP couldn't focus on it anymore. Yes, it's odd given this team does a lot of critical work but I guess they were trusted to self-manage.

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?

I'd like to add that building trust with the team is vital for your and their long-term success. Have one-on-one conversations with everyone on the team and outline what you're trying to do (build a team that can scale) and that you need their help to achieve it. Ask for their input and listen.

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.

This is a crappy situation to be in for sure, the company definitely let this linger for far too long.

I'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.

Good approach.

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.

I agree with this in principle, BUT... be reasonable, and don't go in thinking you have to "show this guy" or communicate to the team what a hardass you are. There are, in my experience, always exceptions to pretty much any policy. If you say "all commits need the PR workflow" I'd posit that that really means "for actual application code that ultimately winds up released" and nothing more. If you now try to apply that policy to every random repo with some POC, demo, experiment, or throwaway code of some sort, you're just going to piss people off needlessly.

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.

> It's a pretty nice job security situation.

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.

Reply on news.ycombinator.com