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.