I had a "go to" guy quit my team. This guy always came up with new frameworks, technology, and all engineering stuff. Anyway, he did not really knew about these tech stack and always over engineered everything. Since he did not know the stuff and loved over engineering things, he applied so many things in the wrong place. He wrote one code pattern in one place, and another pattern in another place.

This guy is respected by many junior engineers in my team and I have a feeling that they think we lost a good team member which is obviously not the case. After he left (about a week ago,) our work progress is much faster compare to when he worked in the team and touching code here and there.

I do not want any of my team members feel that we lose anything. In fact, my team is much more productive without this guy. Should I address this in a team meeting by stating facts and reasons why he was out? or Should I just not say anything? What is the best thing to do in situation like this?

The reason I felt I needed to address this was because he was a "go to" guy for few engineers. He talked as if he knew everything but he did not. I just did not want these guys to feel bad.

What I did was, I waited until a weekly team meeting and told everyone that they had done a great job and I was so proud of them. A couple guys who picked up his code realized that it was badly design or over engineered.

  • 92
    Based on how you describe this person, how is he the "go to" guy? Unless you're making some sort of pun about goto commands and it being associated with spaghetti code.
    – Dan
    Commented Jul 24, 2018 at 17:05
  • 39
    Yeah, usually a "go to" person is "used to describe the best person to deal with a particular problem or do a particular thing, or the best place to get a particular thing or service". So the exact opposite of how you seem to be using it.
    – msanford
    Commented Jul 24, 2018 at 17:07
  • 5
    By using the word "employee" does that mean you are the manager?
    – DarkCygnus
    Commented Jul 24, 2018 at 17:08
  • 51
    "After he left (about a week ago,) our work progress is much faster compare to when he worked in the team and touching code here and there." - Also, coming to think of it, if he already quit and everyone is productive, why do you need to explain anything?
    – Dan
    Commented Jul 24, 2018 at 17:29
  • 10
    @BillLeeper Nothing did happen. People leave. This happens all the time. Turnover is normal. So I'm with Dan and would like to know why OP thinks anything needs to be addressed here. OP, did you drop the ball with this person's departure or something?
    – Lilienthal
    Commented Jul 24, 2018 at 20:42

7 Answers 7


As the manager it is your job to keep your employees from getting distracted. If it was me I would not mention of this individuals bad points or the bad code. At the same time don't encourage the bad things he did either.

Something along the lines of:

Bob was a really great programmer and he will be greatly missed. He has chosen to pursue another opportunity and we wish him well. I am really proud of you as a team and how you are coming together to keep our timelines moving and continuing to do the great work I know you are capable of.

This doesn't say anything specific, yet praises your team at the same time. Over time you can carefully unravel some of the messes and tighten things up.

Once the dust settles it would be time to introduce the discussion of various coding standards. Don't bring them down from on high, but encourage the team to develop them and then ask them to hold each other accountable. This should head off some of the problems you had.

  • 28
    You might want to leave out saying he "was a really great programmer" if you don't truly believe that to be the case. The rest of the statement is good; it can work without giving undue praise. Or, praise him for more specific things that definitely were true, like his enthusiasm.
    – Maxpm
    Commented Jul 25, 2018 at 11:48
  • 3
    +1 In the best case, you can boost your team's confidence when they see that they actually took the loss of this "valuable member" very well, productivity-wise. By time they will understand that this person wasn't actually very useful. You just need to make sure that nobody wants to "fill the gap" by wildly employing new stuff left and right.
    – xLeitix
    Commented Jul 25, 2018 at 15:45

By saying anything negative about them you run the risk of looking petty. As a leader you are much better to just let results speak for themselves and let the team come up with their own theory on the cause. If you have performance metrics that you are monitoring you can definitely congratulate the team on "a marked improvement in metric X over the past Y weeks" to foster that idea but definitely don't mention anything at all if your impression of improvement is purely anecdotal.


Should I address this in a team meeting by stating facts and reasons why he was out? or Should I just not say anything? What is the best thing to do in situation like this?

I don't think it's necessary.

If progress is much faster as you describe it they will also notice the improvements and draw their own conclusions.

Calling a meeting or similar to basically say "Don't feel wrong that he left, we are much better and efficient now" is not something I would recommend (as it is basically throwing dirt to his reputation deliberately).

Perhaps he was not the best coder out there, but from your post I can see he was very enthusiast and keen, and even your "go to" person, so I'd say you should give him credit for that and just let your professional relationship end smoothly.


We had one of those here before I started. Loved new frameworks, design patterns and tools. Really didn't understand them.

The problem was he had the old management enamored with his 'skills'. New management with actual architectural skills came in and 'Bob'* (not his name) understood he was in trouble. Bob* just left and never came back, He couldn't support the code he wrote so it was up to others (one of the reasons I was hired) to decipher the mess he left. Much of his code was just copied from stackoverflow. The problem was he didn't understand what he was copying.

How do you handle with your team? Say "Bob* has resigned. I know some will miss him. Now it's up to us to keep moving forward". Anyone experienced will know what really happened and the junior developers will eventually (when they have to support some of the stuff 'Bob' wrote) why it was best he left.

*No offense to anyone named Bob.


I would opt to very briefly (30 seconds or less, if possible) explain the technical and professional reasons why this person was not a good fit while still valuing who they are as a person. Then never bring it up again while moving on to the work ahead.

While I agree with most of the answers here I believe a little transparency can do a lot of good for the overall morale and culture of the people who are still here.

  • Leaving them to draw their own conclusions has the potential to backfire and build mistrust
  • This can establish a good precedent for junior developers by clearly communicating what not to do (in this case, give in to certain self-serving "developer temptations")
  • Reinforce the fact that this is a team, and everyone is expected to code like a team
  • Mitigate fear that they might be next (since they looked up to, and admired this developer's skills and approaches)
  • Remind the employees that there is a stable future as long as they are mindful about serving the company's needs
  • Apparently, "Bob" left under his own power, so nobody need worry about being next. Nor does it really matter what conclusions they draw. Commented Aug 14, 2018 at 15:22

Mention the positives and ignore the negatives:

We have new opportunities to introduce new patterns and enhance our architecture

if you still want to wing it... or...

We have a new opportunity to introduce coding standards and best practices

If you're looking to start cleaning up what you have and implementing best practices.

  • 5
    That makes it sound like your departed underling had some sort of power over you that prevented you from introducing whatever you wanted, thus undermining your authority with those who are left. Commented Jul 25, 2018 at 14:52

If you're using an agile programming approach, you could always bring it up during the scrum retrospective meeting once the current scrum ends. Discussing the events of the scrum, how they affected the team, and how you can use them to improve moving forward is basically the point of them, right? Discussing topics like this seems to fit right in.

  • I strongly disagree as this has barely any positive outcomes. This is an issue that should have been outlined earlier, not after the departure of this employee. Pointing out his flaws after might reflect badly on OP as the team members might feel that OP is talking behind the employee's back. Commented Jul 26, 2018 at 14:00

You must log in to answer this question.

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