Co-workers taking work home for the weekend - how to approach this?

Question

Recently I noticed that some of my co-workers take work home for the weekend to finish and have a time buffer in the next week. Although I can see the good intention in that I can't help to think that this actually goes against themselves and the team.

These are my arguments:

• They do not put their time in their time-sheet meaning that no-one will get to know about it (ultimately the company can't bill for it).
• If they do resolve the problem it means that the original time estimations will be incorrect and the problem will be seen as less difficult.
• They will get the perception that they are able to finish everything on time.
• My guess would be that they will be less rested for the next week and one step on the way to burn out.

Is my view of the problem correct? How to deal with this situation? I talked to one of them but it is not in my responsibility to tell anyone to stop anything (the next step would be probably to talk to our manager).

Answer 1

Is my view of the problem correct?

Kind of. Essentially these people are donating their time to the client. At some point they'll figure out that this is not in their favor.

How to deal with this situation?

You don't. As long as this is not impacting your ability to perform your job then it's simply not your place.

I talked to one of them but it is not in my responsibility to tell anyone to stop anything (the next step would be probably to talk to our manager).

No, that is not the next step. What do you really think going to management to say that your coworker is working for free is going to accomplish? At best management will ignore you; at worst they'll tell the coworker to make sure they bill for that time then wonder why you aren't billing 60 hours a week as well. Point is, this is between the client, management and the coworker.

If at some point management asks why it takes you 3 days to accomplish what your coworker does in "1" then feel free to bring up how you don't work for free. Until then, stop worrying about what people who do not report to you are doing and focus on accomplishing your tasks.

Answer 2

Maybe they would miss the fun.

A workplace is not ideal for focussed work. Telephones ring, coworkers talk with each other, the boss or colleagues looking for help interrupt work whenever they want - now contrast this with working on the sofa on the weekend. If I have a hard bug to fix, I leave this for the evening hours or the weekend.

You might now say that it is the fault of the employer to not provide suitable workplace conditions for keeping your concentration focussed. But maybe I am overly sensitive and easily distracted, and besides, I do private stuff from my desk, too, so it evens out.

And I like my work. A lot.

Answer 3

I tend to call this "first job syndrome" where someone is so eager to please / perform that they take their work with them and tend to work on a project 24/7 until it is completed. I have never seen this behaviour with anyone who has moved onto a second or third software job, hence why I have given it this title.

What happens over time is that the person starts to "burn out" usually rather quickly, which leads to mistakes and sloppy work .

More often than not this will lead commit logs to source control having messages such as " committing to get my work home" , and a blurred line between what should and should not be committed to the repository. Debug code gets committed , half implemented features get committed , things get treated as "complete" when the code works ( and not when a clean maintainable solution is finished ) I tend to find that this practice lingers the longest with the less competent programmers, and in some cases the "first job" lasts for a decade and this is another topic in itself .

Over time a resentment starts to build up with people that take a more disciplined approach, being constantly tired due to chasing a bug until 3am the night before leads to daytime grumpiness and reduced productivity.

I have found that the optimum time for productivity tends to be somewhere between 30 and 40 hours a week. Too much less than that and you don't get decent sprints, too much more and you tend to start to make mistakes which in turn cause more work to be created.

I am not saying that one should completely avoid "crunch time" prior to releases , but one ( and most importantly management ) should understand that for every hour spent past a certain threshold will cost 3 or 4 in the longer term productivity wise, ( so 3 weeks of 60 hour crunch balances itself out with 4 weeks of effective zero productivity afterwards )

At a worst case scenario this could even be seen as a norm or even have a less competent programmer appear to be more competent than they really are due to the fact that they are more likely than not brute forcing solutions )

The only advice I can offer is to call it out for what it is, make sure management know what's going on ( and from their perspective they will be rightly pissed that there are hours of work which could be customer billable which are not being billed )