Depends on your role. Assuming you are their direct supervisor, simply give more tasks. Slacking off is usually due to not enough to do. Follow the tasks at a high level, make sure he knows he’s being tracked. This has even the effect of increasing motivation, as most people value attention.<p>If slack off means he’s not showing up at team meetings, constantly missing deadlines, low quality of work, etc.. just give feedback on a case-by-case basis, ask how he would make it better next time.<p>If he fails to improve and the examples pile up, time to make hard decisions. I have to say, in my experience as a direct supervisor, only 1 out of like 4 people fail to improve, if you are willing to invest your time and effort.
The Ludovico’s Technique worked for us.<p>When you can measure and compare productivity and “slacking off” objectively and fairly, for everyone, let us know. Until then read Ed Zitron and stop worrying about how other people work.
Assuming you have objective performance metrics, and consistent criteria, the appropriate course of action would be to warn them, re-evaluate after a trial period, and fire if nothing changes.
The best signal to gauge Eng performance is their impact against business objectives. Money saved, UX improved, costs reduced, modules deleted, etc.<p>Collect weekly bite-sized updates to know how your team is doing.
I’ve had to deal with this a few times now. After asking around the greybeards I really respect this is my current run book.<p>First: Talk to them about it. This is the hardest part. The aim of this conversation is to let them know you’ve noticed a change in performance and you want to know what you can do to help. It’s an open conversation but there are two possible outcomes.<p>1. They’re bored of their work. This is more common than you think. Give them a big problem. Maybe a bug no one can figure out. Maybe move them to a different project for a while. Check in with them every day/2 days. They don’t have to solve/finish it instantly but they do have to demonstrate engagement.<p>2. They’re burnt out. This is coming for all of us one day so be kind. The solution to burnout is give them micro tasks. If there are no micro tasks take an existing task and break it down into micro tasks. Something that would take you an hour to do. You want to get them into the habit of moving tickets across the board again. There’s no time pressure here but you do want to start tracking their productivity.<p>If you suspect they are slacking off/have problems at home/have a full time second job solution 2 also applies.<p>Think of this period as like hiring an intern/junior developer. Your job is to support them & build them up. If they were once productive you’re trying to get that guy back. This takes time and don’t rush it.<p>Keep a close eye on their velocity. Expect them to be slowly building up. If you use ticket points track their points.<p>If after the first 2 weeks you get the feeling they are not engaging now is the time to notify your manager/ HR (depending on your country firing someone may be a long process)<p>The aim is to get them back to being productive again. Whatever caused this issue. don’t expect to get them back for 2-3 months. This is okay remember how much it costs in time and money to get in a replacement.<p>What we want to see over that time is a gradual improvement in velocity. Slowly start giving larger tasks. Check in with them at standup every day and have a half hour call with them once/twice a week.<p>Over these 2/3 months if you see no improvement bring in HR and initiate a formal PIP or whatever process you have for firing someone. If they’re taking the piss they’ve been found out. If they’re burnt out and are not engaging with this process maybe their time as a software developer has come to an end. At the very least their time at your company has.<p>Every single person is different. One person I took though the process fully embraced it and has since been promoted. Turns out he just needed more responsibility.