php[architect] November 2018

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

The Dev Lead Trenches

The Talk

Chris Tankersley

About the only thing that makes me upset as a lead developer is people that do

not play ball. I am completely for questioning authority, asking questions about

workflows, and having ideas on making what we do work for everyone, but it really

bugs me when someone doesn’t even try to work with the team.

I have spent the last year and a half

sharing my workflows, my ideas on

how to run a team, and other topics

when it comes to making sure your

team is working well. I am not pulling

these ideas out of thin air just for the

sake of a column, but base these notes,

tips, and tricks on what I have come up

with other the last five years I have been

a team lead.

There will come a time when you are

going to have to have The Talk—the

talk where you have to explain to some-

one (or a group of people) that there is

a rhyme and a reason for the way you,

as the lead developer, have laid things

out. Whether they like it or not, your

company has hired you to run the team,

and you are responsible for the output

of the team. If something is not work-

ing, you need to fix it.

The Talk is never a fun talk. I am the

kind of manager I want to have. I do not

like to micro-manage people because

we are all adults, and we should be able

to manage our time. If you are a junior

developer on my team, it is expected

that you will need more hand-holding

on different things, but as developers

move up the ladder, I expect more out

of them. If you want to be a mid or

senior developer, you need to act like it.

Before The Talk

I try not to assume people are specif-

ically going out of their way to do a bad

job. Coming up with a workflow for a

team is a balancing act, and everyone’s

input should be taken into consider-

ation. A good leader listens to their

team, with the understanding everyone

is working toward the same goal. You

need to balance letting everyone work

the way they want with making sure

you can keep track of progress and

communicate effectively.

When you have someone on your

team who’s not pulling their weight,

outwardly or passively ignoring estab-

lished workflows, or not doing the work

they are assigned, the first thing is to

find out why. Last month I wrote about

burnout, and that can be a very real

possibility. Maybe they have been stuck

working on maintenance tickets and

want to do something new. Maybe they

are working with a technology stack

that is just not in their wheelhouse. It

could be something at home.

Find the Root Cause

First, find out what the real issue

is. Talk to the coworker and see if you

can find out what’s going on. It will

only breed resentment on the team if

you immediately go on the offensive

and start threatening people. I know

if a manager were that way with me, I

would start looking for a new job.

Take a Break

Take a mental health day. Sometimes

all someone needs is a day to recharge

their batteries, especially in the startup

pace that many companies foster. If

they have not had a vacation in a while,

have the person take some time off. It

may be as simple as just moving them

to a new area of the code to get them

out of the rut they are in.

Ask for Feedback

If it is an issue with the workflows

themselves, try and get feedback. I

regularly let my team know to come to

me with any complaints about things. I

recently introduced a new rule that all

pull requests will need to have docu-

mentation and tests, which can be both

unit tests and integration or behavioral

tests. I made this a formal rule because

we have been having quality issues

recently, and I also want to reduce “my

code” syndrome.

This is a change to our workflow, but

not a major one. I will fully work with

my team to make sure it is followed

before needing to feel the need to

punish anyone for not following the

rules. That being said, I would expect

everyone to remember this new rule

after a short while. If I get a pull request

in three months without any documen-

tation, I will be less forgiving then than

I am right now.

Write It Down

When you start to notice a pattern

and are worried a coworker may need

something more forceful, start to docu-

ment these talks. I hate to say this, but

part of it is for the Cover Your Ass

portion of this job, but also because you

want evidence of things getting better

or worse. Your employee handbook, or

even Human Resources, should be able

to help determine what you may need

to do. If things start to get better, that

can easily turn into examples of how

they are doing better.

Having The Talk

If you have tried to work with the

problematic coworker and nothing is

working, you need to talk about their

performance. This talk is intended

to make it known that the cowork-

er’s actions are no longer tolerated.

It’s a direct acknowledgment their