How to encourage new team member to communicate at the same level as the rest of the team

Question

I manage a team of 5 developers, a QA and a BA. Over the last two years the team has transformed from an attitude of cowboys in silos to a communicative, collaborative group.

In particular the devs solve coding problems and come up with effective design patterns and solutions together. They discuss options, new ideas, research and investigate and decide on the best approach to take. If one dev is feeling strongly about an idea they'll prove it out and demonstrate why it's good. It's obvious how much we've evolved and how much more effectively we work and the team talks about it frequently.

We recently added a 6th (Sr) and 7th (Jr) dev. Both are very capable coders. But one (the Sr) is turning out to be in the silo category. He has walls up all the time. He tries to solve problems on his own for hours and only comes up for air or relents when asked by me or someone else. Despite my best efforts to get him to discuss his plan with the team before commencing he continues to check in new code that implements or duplicates design patterns that already exist elsewhere. He plows through and creates PRs which then needs to be revised or completely refactored due to duplication. A lot of his code is excellent and he is obviously a talented coder but the amount of refactoring and additional effort it's causing is getting exhausting.

He recently caused an issue that had a downstream effect on two other dev teams and had a dozen people up until 4am last night trying to resolve. The issue could have been easily avoided if he had asked some questions instead of approaching the issue with the smallest degree of humility and asking someone else for support. I'm sure he's not feeling good about the snafu he caused yesterday. He is well aware of his error.

We are all working remote rn so that might be having have some affect but I get a sense that even in an office environment this would play out in a similar fashion.

Things I've tried:

• 1:1 check ins where I re-iterate that he should discuss his approach first and mention that he is not visible in the discourse. He understands this and says that he'll ask questions. He hasn't.
• git commit comments where I've ask him to discuss new patterns with the team before adding. He responded that he had a feeling that his pattern was going to cause a discussion and he felt it could happen in the git comments. I reminded him that it's better to discuss first before implementing. measure twice. cut once.
• To get my two senior devs to check in frequently and ask if he is stuck or has questions.
• re-iterating always for people to ask questions in our Teams chat before implementing a solution.

If anyone has any thoughts on how to motivate someone to discuss anything / everything and engage with already collaborative and supportive team then I'm all ears.

Thanks!

Answer 1

I think that at the moment, we cannot give a specific advice, because we and you do not have all the information we need. Your post sounds actually very objective and you seem to feel friendly towards him, but I see no explanation of his point of view.

Until now you only commanded him to change his behaviour to be same as his colleagues. On one hand he should adjust to be able to work with the existing team, on the other hand there is no guarantee that your working style will scale with more people.

So let's try to get more information by starting an open-minded discussion.

1. Invite for a one-on-one call.
2. List the events objectively and without judgement. Do not state that it's a problem that he works differently, because it's not. The problem is that his way of working is causing overhours and duplicate work.
3. Ask him if he understand that there is a problem. Make him explain it by his own words to be sure he understood it. If he doesn't understand it, explain your point of view.
4. Ask him how he wants to avoid those problems in future. Ask him what he needs from you to be successful. Do not tell him to mimic his colleagues, because this kind of micromanagement will not help in the long run.
5. Decide together on an action plan and a follow-up meeting to discuss the progress.
6. If he doesn't improve, be honest and tell him. So either he finds a solution or you part ways - because there was no cultural fit.

Answer 2

A lot of his code is excellent and he is obviously a talented coder but the amount of refactoring and additional effort it's causing is getting exhausting.

It takes a village.

I’m assuming that you have a code review process before new code gets merged - and that his new / duplicate / will-be-refactored pattern are making it’s way thru when it shouldn’t. Your entire team owns the codebase, so part of the issue is that the rest of team allows his code to go thru by not declining the PR. The team must be diligent in enforcing your best practices - allowing bad code in is the same as accepting the associated risks with that - including staying up until 4am. The team needs to be comfortable rejecting PRs that doesn’t meet your best practices.

Repeated PRs for non-conforming code should result in repeated declines, that way it is clear to this developer that the team adheres to your best practices, and that he should respect that if he wants his PRs to get in.

Answer 3

To be honest, this sounds like a failure of management on your part: you continue to over estimate his maturity as a developer. You are treating him as a mid-level (or senior) developer, when he really is a junior one, and you are not adjusting your management style accordingly.

In my mind, the maturity level of a developer is, to some degree, independent from someone's "talent" as a coder, or ability to produce "excellent" code. A mature (senior / mid-level) developer is someone who produces quality (simple, maintainable, etc.) code as effectively as possible, whose code flows well with the rest of the code base, who doesn't create duplication but reduces it, who knows when to ask questions, how to research and discuss solutions, etc.

The person you describe sounds like a junior developer. They might write "awesome" code, but there is a lot more than that to being a developer.

As a junior developer, this person needs to be told "use this, it already exists, DON'T REWRITE IT", a junior developer needs to be told "I want you to present your ideas to the group, before proceeding" (and have the presentation scheduled on the calendar). You need to manage this person much more closely than you have been.