How should I address a popular team member leaving?

Question

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?

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

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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

Answer 6

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.

Answer 7

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.