Rob Garrett - Blogs

Continuing on with my theme about managing software developers, and getting ahead in your career as a software developer, this post discusses poor performing developers and what steps can be taken to protect the project.

It is a sad fact that the software IT industry is awash with many individuals that claim to be expert developers in the field in which they practice, but in fact, they lack the skills required for the simplest of software development positions.  Often is the case that these individuals will appear to have the necessary skills on paper to secure them a job on a development project and the only thing to stand in their way is a good interview screening process. Therefore, what can be done to avoid jeopardizing a project if, as a project manager, you find yourself with a bad apple on the team?

• Recognizing a bad apple - Most managers can spot a duff developer on the team, however poor performing individuals can often go unnoticed on software development projects, especially large enterprise projects involving more than a handful of developers.  It is the responsibility of a good project manager to have an accurate understanding of every team members past and present performance metrics.  The typical approach taken by many project managers is to maintain a project plan containing project tasks assigned to each developer, along with original estimates and current percentage of work complete. Project planning tools, such as Microsoft Project, can provide project managers with an indication of where the bottlenecks exist in a project and which developers are failing to meet the quota. A good project manager should always maintain a history of all staff under his/her supervision, both for future performance reviews and for a comparison of previous accomplishments with the present.  Regular design and code reviews and peer-to-peer staff meetings can also indicate a problem brewing.
  
  
• Cauterize the wound - Once established that a developer is lacking performance on the team it is important to isolate them from any tasks deemed critical to the success of the project. The developer will work on less important tasks until the proof of increased performance and understanding of the more crucial tasks is evident. It is important not to chastise the developer for their poor performance at this stage. However, the developer should be aware of their failure to meet the project expectations.
  
  
• Establish a cause - There are many reasons why a team member may fail to meet required project expectations. Failure to complete one or many tasks in a designated time period is not necessary an indication that the individual is incompetent in their role. Other factors, such as lack of training for the task in hand, lack of motivation, failure to apply talent in the correct area, bad planning, or a long number of hours etc, can influence the ability in completing a task. External factors such as a stressful home life, lack of sleep, a difficult commute etc, are other reasons.The project manager should invite the developer to share an explanation of inability to complete tasks assigned before concluding lack of professionalism.
  
  
• Provide an opportunity to make amends - Once all external factors have been ruled out or addressed, the developer can show promise and future worth to the project when provided with an opportunity to gain the confidence of the project manager.  A good way to provide this opportunity is to assign an obtainable task, which both matches the skill set of the developer and occupies a short time period.  It is the duty of the project manager to monitor the task progress to determine if the developer is showing progress.  The project manager must define the expectations up front and the developer should be clear on what objectives they must meet to complete the task.  This “hand-holding” technique requires extra time from an otherwise busy project manager, but secures the project manager with an understanding of the ability of the developer before any drastic action is required.
  
  
• Cut your losses - If the developer continues to show little or no promise of becoming an asset to the project and continues to be a liability, the time has come to cut them loose.  It is a sad day when a project manager has to fire a member of his/her development staff, but necessary for the good of the project.  Stale developers that do not provide useful input to the project can drag a project and impede the efforts of other useful developers on the team.  Never terminate developer (or any other team member) for personal reasons.  Plenty of guidelines exist for terminating an employee.  In a future post, I list some of the ways to fire a member of staff, whilst retaining professionalism and avoiding uncomfortable conflict.