Imagine you inherited a large team of developers and found out that interviewing in the past had certain slacks and some members of the team lack certain skills. It is certainly wrong idea to re-interview everyone as this will cause a lot of unnecessary distress but you need to know straight away who is good at writing code and who needs some training or should not have been hired. And you cannot afford time learning this just by looking at individual performance as it will be affected by technical debt. What would you do?
6 Answers
This is a very broad question and right on the verge of being off-topic as both too broad and an opinion poll. Having said that, I've been in this position and it is daunting.
The only advice I would give you is this- Do. Nothing.
The worst thing you can do as a new manager of an incumbent team is wade in on an obvious witch hunt making snap decisions and hasty judgements about people's skills and competencies.
Take some time. No-one's gonna die. Just leave things to run for a while. Listen and watch. See what's going on and how things are done. Talk to people about what they feel needs to be done and where they think the team is strong and weak.
After a while a picture should begin to form about where the strengths and weaknesses lie both with the team as a whole and with individuals. Then you can form a plan to mitigate these issues.
answered Feb 25, 2015 at 23:35
I am taking a different perspective from Marv and dash here. I would initially challenge your assessment of your team. First, your statement that the interview process had issues suggests a lack of understanding in predictive validity of the selection process. Second, it seems you may not understand the concept of of the performance distribution. This article--Forbes--has a nice discussion on it.
The take-away here is that, with the normal issues we have in the selection process and the distribution curve, it is not likely you would build a better team if you went through the process of firing and hiring all over again. Looking at individual performers with a hope that you might be able to replace that person with someone better will, statistically speaking, result in pretty much little to no gains.
This is not to suggest you should not have individual performance goals, put in a good training / mentoring program, or even skim the bottom performers and replace, but your focus needs to be on team performance as a whole, which not only includes the individuals doing the work but also well defined, efficient processes and procedures; documentation of policies and rules; and tools with which they do work--the entire capability. Focusing only on perceived individual performers while ignoring likely other capability inhibitors will result in pretty much nothing.
answered Feb 26, 2015 at 13:12
I agree with Marv. Listen, diagnose and eventually carefully medicate with a treatment plan.
I've been in this situation and build up a skills matrix which was split into available skills and required skills (based on current and expected future projects).
We then gradually built a training and peer mentoring plan. For skills we were entirely lacking, we focussed on these skills for new hires.
I'd be very reluctant to go for a personal improvement plan on someone who I did not interview, but there are certain tactics that you can use to encourage the relevant person to leave.
The one change I'd be keen on implementing very quickly though is a QA process for new hires, such as have them write code, ensure breadth and depth of knowledge as well as their ability to mentor and push other team members.
I see you've posted a number of questions in the past few days, so I'm going to make some assumptions that they're related - I hope that's accurate. It sounds like you have a number of Agile teams (Scrum in particular) that you've inherited and perhaps there's the general impression that they are under-performing. I can definitely sympathize with your situation.
It also sounds like you're left to identify exactly how well or poorly things are going and then make a change in the teams for the better.
My experience would tell me that relying on simple metrics or storming in with the teams, re-interviewing, or other disruptive (and frankly combative) approaches will cause you more trouble, like you mentioned in your post.
My recommendation would be to very publicly double-down on your Agile and Scrum values. Openness, self-organization, delivering value, and technical excellence are all things a team can rally behind and it puts you and the teams in the same corner. Maybe there are some bad habits either on teams or in the organization that can be challenged by looking at how they embody (or don't) those values.
This will also give you some insight into the team. When you get up and say "who's going to be committed to this with me?" you're going to get some people who are and some who aren't. Of the ones who aren't, some just need convincing. They need to see you stick to those values when it's hard and that will inspire them to do the same. Some of them might not be good programmers, by the way, but personally, I'll take a junior programmer who's committed to improvement over a senior developer who is complacent any day. Finally, you may have a few people who just aren't interested in being part of a continuously improving, high-performing team - you can address that with them as you think is appropriate.
There's no good easy answer, unless you plan to scrap the whole team and start over - and even that is only easy, not so much on the good. Establishing a good culture and relationship with the teams is definitely the most important first step though. You won't be able to do much else until that happens.
As a complement to the other opinions and experiences shared here, I would say that "interviewing" people might be a good idea, but not, in my mind, with the objective of sorting bad apples from good ones.
First a word of caution, any sort of interviewing may be very well received by some, but very badly by others. Without any relationship to you, your objectives or even how professionally you may have brought it up. It brings up fears or other strange reactions for some, people have irrational emotions (that's normal) and that needs to be taken into account before embarking on this path.
That said, and even though I have had mixed results from this technique, I believe "interviewing" with the objective to get to know your team, to get to know each one's strengths, is a laudable goal and can achieve some great results. Do not use it as a stick, it will hurt you and your credibility with the team. In fact even using it with the purest goals it may still come back and bite you hard.
It is all a matter of perception, so make sure, if you are going to do it, that you have your manager's backing on the principle, goals and manner. Also make sure to manage the message perfectly before you start, so the process is transparent and the benefits clearly stated.
A few years late, but I concur with the other contributors. Let's say it explicitly: there is no quick solution here. No switches to flick. It will take time to get to know your team - in fact the process may never be complete, because people change in their abilities and aspirations.
One way you could get to know them well is to run workshops of 5-10 people at a time, covering the practices you wish your team to follow; TDD, Continuous Delivery, refactoring, secure coding, whatever. Even if they are following them to some extent already, there is nothing wrong with a refresher to make sure everyone's still speaking the same language. Workshops will help you identify who is already capable in an area of expertise, who is a capable learner and who struggles with particular concepts. It will also help you identify who shows willingness to help others, who reaches out for help when they need it and who prefers to work alone. What better way to find your mentors?
