3

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!

12
  • 2
    "Despite my best efforts to get him to discuss his approach with the team before commencing" - could you tell us what have you tried or what those efforts consist of?
    – DarkCygnus
    Apr 29 at 17:00
  • 3
    I just added. And that gave me an idea. The senior devs actually don't communicate as much in the chat because they know where everything is and they've solved so many problems already. Maybe he needs to see more senior people asking for buy in as well. Apr 29 at 17:10
  • 6
    Why do you not pair him with someone who knows the ropes?
    – Kilisi
    Apr 29 at 17:14
  • 4
    I also vote for pair programming for a limited time. If he's working remotely, even remote pair programming should help a little bit (even if it's not as good as physical pair programming). Apr 29 at 17:54
  • 1
    This behavior could be because either he is unconfident and wants to avoid doing things "wrong" like asking a lot (which he should do but he thinks it makes him appear incompetent) and the like... Or in contrast to that he also could be selfish and ignore others on purpose because only he is the best and what he does counts. These are two very different attitudes that require very different ways to solve and there might be even more reasons that lead to his behavior. How would you describe his personality?
    – puck
    May 1 at 9:17
9

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

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.

1
  • 1
    This. Yes, this will cause rework, but as long as all the work is on him, he'll get the idea. And to be fair, sometimes it's easier to churn out code to be discussed in a code review than to explain and discuss the architecture beforehand.
    – Llewellyn
    May 1 at 18:40
2

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.

4
  • The fact that anyone can seemingly merge their work without review is also a worrying point. With communication they review in some way, but this is inadequate for any rogue dev.
    – Al rl
    May 1 at 0:22
  • They're not allowed to merge without reviewing. It just keeps getting to review without a discussion happening so that's causing rework. May 1 at 17:05
  • This is a person who has been doing this for over 8 years. They are a mature developer. The other new hire is a Jr dev straight out of university who is demonstrating a considerable level of self-control despite his age. May 1 at 17:10
  • 2
    @RyanVeteze - Of course, only you are in a position to evaluate this developer, but there are plenty of people who have been developing (professionally) for 8 years whom are still junior developers. May 1 at 21:06

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .