php[architect] November 2018

26 \ November 2018 \ http://www.phparch.com

The Talk

The Dev Lead Trenches

A PIP should have three parts: what
outcome you want to see, how long the
employee has to complete the PIP, and
what the consequences are if the PIP
is not followed. Most of the time that
consequence is termination, but there
should be some sort of consequence.

A PIP should have clear goals the
employee needs to meet, and a time
frame to do that. If we take Bob above,
we may want to say that we want to see
at least 80 percent of the issues closed
follow the proper process. You may
shoot for 100 percent, but the idea is you
want to try and work with the employee
to improve. With a completed PIP, the
employee should be improving without
the fear of an unreachable goal.

Do not set the employee up to fail.
PIPs have been used as a shield to get
rid of someone by setting completely
unrealistic goals. I find this cowardly,
and any leader that does this does not
deserve to be a leader. PIPs are not a
stick to beat the employee with. They
are meant to help the employee.

Support the Employee

Work with the employee to make sure
the goals can be completed. If it requires
extra training, make sure they get that
training. If it means checking on them
every day or having one-on-ones with
them weekly, do that. You both should
want to improve the situation.

This belays a bit of the problem with
PIPs. Many of the issues may not have
a quantifiable fix, but in the business
world, you (or more likely HR) want
to have a specific metric someone can
point to if termination is needed. If it is
an issue with the tone of code reviews,
and you want Bob to be less of an...
well, less aggressive, that can be hard to
qu ant i f y.

This will not be an easy talk, but you
can do it.

Following Through

If you set up a formal PIP or come
up with something else, you need to
check up on the employee regularly. Do
not say, “Complete this in 90 days or
else!” and then circle back around on

day 89 to find nothing was improved.

If you do not want someone on a team

anymore, just find out what it takes to

terminate an employee. Don’t drag it

out as it causes further issues for every-

one involved, such as decreased morale,

loss of respect for leadership, and even

resentment among employees and

higher-ups.

Part of the PIP or plan should be

regular check-ins. This can be weekly

or daily, but keep track of what the

employee is doing. If you see signs of

improvement, let them know! This

period should be the time where the

carrot is the focus, not the threat of the

stick it is attached to. We should want

to give the employee the ability and the

tools to do better.

If they complete the PIP, then this is

a success and should hopefully correct

any future problems. If someone is

constantly falling back into needing a

PIP, then they are not a good fit for the

team. For example, if you cannot follow

my simple issue workflow in GitHub

or ensure your work has tests and after

constant work still cannot do it, then

I have no recourse but to remove you

from the team.

If the PIP cannot be completed, then

the consequence part of the PIP comes

into play. As I mentioned above, this

is usually termination. If it comes to it,

work with your company and HR on

what termination policies are. For most

companies, this means termination is

probably scheduled for Friday after-

noon (or whatever the end of the week

is) or possibly the next morning. Just

follow through whatever that process

is, knowing you tried to make the situ-

ation better. You cannot win every time.

It Sucks

It is never easy when it comes to

having The Talk. I should know, I just

had to have this talk recently with a

few members of my team. We have had

a consistent workflow for more than

a year, with just minor changes like

the code reviews. Things have gotten

better, but we are still having problems

with people not working on the issues

assigned to them and going cowboy.

That means having The Talk, and

now I have to report to my manager

on each of those employees’ status. If it

comes down to it, I have the authority

to recommend their termination. I do

not want that to happen, but it is a real

possibility.

And it sucks, and it is one part of

being a team lead I hate. Try to pay

attention to performance and don’t let

issues fester or spiral out of control. It’s

only harder to deal with if you put this

off.

Chris Tankersley is a husband, father, author, speaker,

podcast host, and PHP developer. He works for InQuest, a

network security company out of Washington, DC, but lives in

Northwest Ohio. Chris has worked with many different

frameworks and languages throughout his twelve years of

programming but spends most of his day working in PHP and

Python. He is the author of Docker for Developers and works

with companies and developers for integrating containers into

their workflows. @dragonmantank

Related Reading

• The Dev Lead Trenches: Measuring Success by Chris Tankersley. December
  2017. https://phparch.com/magazine/2017-2/december/


• finally{}: On Change by Eli White. September 2017.
  https://phparch.com/magazine/2017-2/september/


• More Than Just an “OK” Dev by Gabriel Somoza. August 2017.
  https://phparch.com/magazine/2016-2/august/