Managing Bad Apples

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
    under his/her supervision, both for future performance reviews and for
    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.