Comment by koboll | Hacker News Reader

Comment by koboll | Hacker News Reader

Parent Full thread

Let me provide an alternative perspective.

I've been on a team with someone who basically does this -- spent half the day not working, usually selected a single low-difficulty task at a time from Jira to drag out over a couple days or a week, and often went home having put 30-45 minutes less time in per day than others on the team.

There was an unspoken but very palpable dissatisfaction from everyone else on the team. No one wanted to be the Bad Guy that calls them out on it, but the manager was unwilling to push them to do more, and a result they were able to get away with slacking off while others were actually putting in effort.

It was tremendously bad for morale. That's the biggest effect it had. All the other team members were bitter about the manager's unwillingness to keep the team on a level playing field. If you let this slide, you're ultimately letting everyone else on the team down.

The point absolutely shouldn't be to police someone's time; it should be to ensure that, if they have time to slack off, they should be pushed to take on more tasks during sprint planning. "That seems like it won't take too long, can you take on these two tasks as well?" is really all it takes.

This is actually a difficult problem, because there are two kinds of slackers: (1) the kind that work less but produce roughly the same as, or sometimes even more than, everyone else (i.e., smart but lazy), and (2) the kind that don't work or produce.

Dealing with (2) is absolutely the manager's job and such a person should be fired if attempts to identify and fix an underlying problem fail.

But (1) is really difficult. We have one of those right now, let's call him Bill. Our manager is hesitant to do anything about him, because the manager wants to incentivize productivity, not butt-in-chair time (we're all salaried, with no set hours). But Bill comes in 4 hours a day, seemingly works 1 of them, and spends the other 3 trying to distract everyone else with off-topic conversations. If he comes in at all.

Amazingly Bill does get work done, somehow. But it is terrible for morale. Worse, some of the junior members are starting to think they can get away with the same thing Bill is doing, and they can't. As the senior dev, the "big brother" to our manager's "dad", it falls to me to do something about it, but I have no idea what, if anything.

Manager fears that if he rewards finishing tasks quickly with more work, it will also harm morale and productivity. And there is a decent argument to be made for that. Having experienced that firsthand, it is highly irritating and incentivizes people to work slowly.

Additionally, in reply to GP, a manager that has great technical skills (10) and good managerial skills (1-9) must be as rare as a unicorn. Even a manager who started with good technical chops inevitably will lose them over time when they are an Outlook jockey all day. OTOH, I have seen plenty of otherwise decent managers who think their technical chops are good when they aren't. Pretty much the whole premise of Dilbert. The best realistic alternative seems to be managers who know their technical limits, delegate, and seek advice from their subordinates.

simple, let Bill work remote. he still gets his work done, no one sees how much time his butt is in a chair and it improves morale on all sides.

This. A person that gets their work done is not a slacker. I mean when I was in university there was a lad that did nothing, doodled in his notebook, smoked a lot of weed every day. And then aced every exam. He didn't need to appear "busy" to accomplish what he needed in his mind.

Likewise a lot of people work obliquely, letting problems percolate in their subconscious until it comes together and they can put together a solution quickly. These people may drive others crazy with how they work but that is not the profile of a slacker.

> Amazingly Bill does get work done, somehow.

How do you define what "get work done" means? Everywhere I worked (as a developer) there has never been a situation where you can say "OK, there is nothing else useful to do today". So it obviously can't be that.

Is it related to seniority? Or even salary? As in, "we expect our senior/highly paid people do accomplish 2X (or whatever multiplier) amount of work that the junior members of the team do".

Or is it just related to how much work the developer estimates they can do? You say you will take these 4 tasks this week, everyone agrees that it's a reasonable amount (for your level/role) and then if you complete them your work is considered done.

Or is it something else completely? I'm interested in anyone's thoughts on this.

What I mean is that he produces an amount and quality of work that is comparable to other people at his experience and title level. In some ways better, in other ways worse, but on average, he is producing at least as much as his peers are. He's quite talented but lazy.

Obviously there is never a situation where you are out of work to do but some would say it is unfair to expect a talented person to produce more for the same salary and title as less talented people (I have no clear opinion on that, I'm only concerned about the morale issues). After all, the whole premise of being salaried rather than hourly is that you are paid to produce a certain amount of work, not work a certain amount of hours.

Normally a solution could be promotion but that is not an option right now.

This is a real problem on your team and it needs to be fixed, likely from several angles.

For Bill, at a minimum he needs an honest conversation regarding his impact on the rest of the team. If he's accomplishing his work but dragging everyone else down then he's not really being a net-positive member of the team. Bill needs to understand his impact and either work more, work remotely, or pick some side projects / technical investigations to keep himself busy. If he's that good, then part of his job is teaching and setting and example for others on the team.

Second, everyone else on the team needs to know the score. I've found that it's tremendously helpful for junior devs to understand that people on the team are not treated equally. "See Bill? He turns in great work and thus gets to work remotely / leave early / etc. He's been super consistent for a long time. You don't get to do that, because you haven't proven yourself yet. I expect X, Y, and Z from you. If you start turning in super-star work like Bill over a period of time, then you get special consideration too." I've had this conversation a number of times before, and the recipients were always very receptive because now they understand the rules.

Reply on news.ycombinator.com