Performance Issues - The Needy Team Member

Developers who make up for a shortfall in their own experience, or don't have the confidence to tackle development tasks on their own are a performance problem that you need to address before the problem affects the performance and morale of the entire team. A certain amount of help should be expected from the more seasoned members of your team. The job definition of a senior programmer should include a certain amount of coaching and mentoring of the junior programmers on the team. It's when a team member who shouldn't need coaching requires constant help from other team members that you have a problem. The problem begins with the impact on the productivity of the team member who's being asked for help, but if left unchecked, could have a negative impact on morale and the entire team's productivity. If the help detracts from the time spent on producing a deliverable, that's a productivity issue. If the senior programmer makes up for this by working extra time, that's a morale issue.
 
There are several ways in which you may detect a problem in this area. The most obvious is a complaint from a senior member on your team that their time is being wasted in helping a more junior member. Keep in mind that we're not referring to a situation where a senior member has been assigned to coach or mentor a more junior member; we're talking about someone who shouldn't need constant guidance, burdening the senior team member with requests for help. Get the details of these requests from the senior member. How many times a day do they ask for help? What are the issues they need help resolving? How many hours a day are being wasted? The one-on-one conversation becomes a little trickier when the development team is remote. You'll need to ensure that each member of your team has the means to contact you by telephone and is encouraged to do so should they encounter a problem they think you can solve.
 
Observing the behavior yourself is another way in which this problem can come to light. This is usually an outcome of the "walk about" approach to management and requires you to be physically present among the development team. If you observe one team member frequenting another's work place, observe the behavior of both team members. You've spotted a problem if one is clearly asking the other for help. Signs to look for include: paper copies of code to be debugged, the visiting team member directing the host team member's attention to their code on the computer monitor, and body language - does the visiting team member lean in to the host? Do they receive an answer, nod their head, and then walk away? A development team that is performing as a cohesive unit will provide you with numerous opportunities to observe this behavior as team members provide help to one another as its needed. Your job is to observe situations where the traffic is all one way.
 
The deterioration of a senior team members productivity is another (and the least desirable) way to identify this problem. A senior team member who has proven in the past that they are capable of a high level of productivity that begins to miss deadlines, or produce poor quality code is the warning sign. Use the "walk around" technique to gather more information on this situation, paying particular attention to the team member whose productivity has suffered. Spotting another team member at their work station is an indication that productivity is suffering from an excessive amount of help being provided to the visiting team member. If you don't have an opportunity to observe the team member, take them aside to get to the root cause of the problem. Start the conversation by citing the team member's accomplishments and contributions in the past then tell them you've noticed that their productivity or quality has been suffering lately and ask them to provide you with a reason. One-on-one conversations with your team require deft handling and cultural sensitivity. There are some team members who will never allow the situation to get to this point and there are others who would rather swallow their tongues than complain about a team member. If you are dealing with the latter, you may have to ask closed-ended questions to get to the root cause of the problem. Don't hesitate to force a yes or no answer to your question (i.e. "Is another team member coming to you for help all the time?", "Who is that team member?").
 
You need to take corrective action now that you've verified that you have this problem. The first step is to evaluate the needy team member's skill and experience. You may need to re-evaluate the team member's status if they joined the team as a senior programmer and constantly need help. You have a different problem when the team member is described as a junior programmer. More on this situation later in this article. A programmer who is described as a senior programmer may not necessarily be a fraud because they are asking for an excessive amount of help. You need to compare the skill set and areas of experience in this person's resume against the type of work you have assigned to them. If their experience and skill set does not align with the work, you need to re-evaluate your planned work assignments and training. For example, training and experience in .jsp programming won't provide a programmer with the ability to design database structures to store information. Examine your plan to determine if there is an opportunity to train this resource in the areas they are deficient in. Alternatively, you can re-distribute the work so that someone with more experience is assigned the work and the needy programmer is assigned work more in line with their strengths. By the way, the other side of this coin is the programmer who is weak in an area and takes action to strengthen the area without burdening other team members. Where this happens, and the programmer manages to deliver quality code on time without burdening their team mates, recognize their accomplishment and do what you need to do to retain them for your team!

 
You can strengthen the needy programmer's skills by either providing them with formal training or providing them with the coaching or mentoring they need. Both these solutions will necessitate a change to your plans. Formal training will require an increase to the budget and additional resources to make up for the training time. Of course you may choose to address the shortfall with overtime or simply extend the schedule, if there is slack time in the activities assigned to the needy programmer. Establish a formal coach/student relationship when you choose that action. Both the coach and needy student need to be on board for this approach to work but if the needy programmer is already asking for the help you shouldn't have a problem on that end of the relationship. Make sure that the coach is allowed the time required to adequately coach the needy programmer. You will also need to provide adequate time for the work assigned to the needy programmer; the amount of time originally assigned for the work was based on a false assumption and the work needs to be re-estimated with the new information. Your new plan must provide extra budget for extra resourcing to make up the shortfall, an allowance for overtime to make up the shortfall, or new end dates for the work packages where there is slack in your schedule.
 
So far all of our corrective actions have been benign. There has been no need to address behavior problems. That doesn't mean the "needy programmer" problem is never due to behavior problems. The most common of these is what I call "false advertising" which means that you have acquired a senior programmer who isn't really a senior programmer. I'm not referring to the situation where the programmer has been assigned work that doesn't align with their skill set, I'm talking about the programmer who has misrepresented their skill set in their resume and in any interviews you've had. The resolution of this problem will differ depending on the source of the programmer. You should consider replacing this person if they are a contract resource. Go to the head hunter who sourced the programmer and let them know the reasons for the change. You may also want to change head hunters if you feel they mislead you. Make sure there are valid senior programmers available, with the skill set you need, before making this move. Don't make a bad situation worse by dumping a programmer who was able to make some contributions to the team without a replacement. You should also perform a "Lessons Learned" exercise where you or your team was responsible for interviewing the needy programmer. How did this lack of experience escape your notice? What questions could you have asked that would have exposed this lack of experience?
 
You will need to approach the problem from a different angle when the resource comes to you from an internal organization, either your own or another in your company. Tread very carefully here as someone in a position of authority in your company has assessed this person's skill set and described them as a senior programmer. Approach the needy programmer's manager about the problem. Explain the problem to them citing the facts you gathered from your observations and point out the gap between your expectations and the needy programmer's abilities. Please keep in mind that a good deal of what appears in a resume is subjective, even when it comes from a manager. You may be dealing with a situation where the needy programmer is a protégé of the manager in which case you should expect opposition. Focus the conversation on the needs of your project, rather than the deficiencies of the programmer. Arranging for a replacement of the needy programmer with another possessing the required skill set is the most desirable outcome of this meeting. Failing that outcome, you may be able to return the needy programmer to the bench and replace them with a contractor. Again, be careful that you don't make a bad situation worse by losing a programmer capable of contributing at a reduced level with no-one.
 
You need to engage a Human Reso