4 ms·

Programmers aren't the only people in an office and there are social norms which affect general productivity. I don't give people deathmarches and don't ask peo

Programmers aren't the only people in an office and there are social norms which affect general productivity. I don't give people deathmarches and don't ask people to work overtime (a social norm!). But I will get rid of someone if their behavior leads the rest of the team to slack off or miss targets. Personally, I think the poster is wrong to complain about not being allowed to work 30 hours a week when he has a fulltime job, but that's his issue with his employer. In my experience, if you want to rock the boat, you've got to be able to manage the communication and signaling problems that creates in the workplace. This guy is offloading that problem to his manager and doesn't seem to understand the issues he might be creating. So it isn't that I don't understand his point. It's that I don't think his sarcasm offers any practical advice for the people he's complaining about other than "let me do it my way".

mattm 17y ago
"I will get rid of someone if their behavior leads the rest of the team to slack off or miss targets." If I understand you correctly, you're saying that you allow the team to use an individual as a scapegoat and not take responsibility for their own actions. Could you elaborate on this? Why do you think this is the best course of action rather than dealing with the people that are not being responsible for their own work? If you let people get away with not taking responsibility once, won't they continue to do it in the future?
- mmt 17y ago
  If I understand you correctly, you're saying that you allow the team to use an individual as a scapegoat and not take responsibility for their own actions. Despite disagreeing in principle with the OC, I don't think this is at all what he was suggesting. Rather, he was presenting a "view from the top," where if he were to perceive a negative influence (whether or not the influenced parties were, themselves, aware), he would eliminate it.
- trevelyan 17y ago
  > I could easily imagine a situation, however, where this is not the > desired outcome, such as in a company where software is only a > minor component. Perceptive point by mmt - I do most of the programming work myself. I don't know if I'd feel the same way if a critical employee doing coding for a major system behaved this way. I wouldn't knowingly hire someone like that though, and unless someone was truly critical, I'd rather send them on their way than have them create a situation in which their behavior negatively affected office norms, yes. My business is quite small and doesn't have professional managers, so mmt's expectation that there is a level there to deal with this stuff is wrong. Problems are just more work on my plate and distract from the things that people pay us for.
mmt 17y ago
I think you're still missing the OP's point: if you, as a manager, think in this way, you'll end up with what he calls "crappy" programmers. I didn't find him to be complaining about anything per se, nor mentioning "fulltime job": Never mind that a good programmer can produce more valuable work in a 30-hour workweek from home than a crappy programmer can toiling 60 hours in the office. Rather, he's pointing out a contrast between two extreme, but plausible, situations. This guy is offloading that problem to his manager What's the manager's job if not, as you put it, to manage the communication and signaling problems that creates in the workplace? Still, I come back to the impression that you're thinking about this out of context: doesn't seem to understand the problems he might be creating. Again, I allege that's not the programmer's job. The programmer's job is to create, and the manager's job is to maximize the creativity while minimizing problems. It's that I don't think his sarcasm offers any practical advice. I agree that the practical advice may be masked by the tone or form. This is the advice as I interpret it: If you want to maximize the productivity of your programmers and ensure the most talented and most producive ones stay, avoid the listed behaviors, even if there are some negative consequences. If your business is software, I have a hard time believing that "general productivity" among the others in the office would improve enough to offset getting rid of someone working on the core competency. On the other hand, I could easily imagine a situation, however, where this is not the desired outcome, such as in a company where software is only a minor component. In that case, your firmer hand on scheduling seems far more beneficial.
- roundsquare 17y ago
  On the other hand, I could easily imagine a situation, however, where this is not the desired outcome, such as in a company where software is only a minor component. In that case, your firmer hand on scheduling seems far more beneficial. The problem I think people will have with this article is that he doesn't acknowledge this point.

mattm 17y ago

"I will get rid of someone if their behavior leads the rest of the team to slack off or miss targets." If I understand you correctly, you're saying that you allow the team to use an individual as a scapegoat and not take responsibility for their own actions. Could you elaborate on this? Why do you think this is the best course of action rather than dealing with the people that are not being responsible for their own work? If you let people get away with not taking responsibility once, won't they continue to do it in the future?

mmt 17y ago
If I understand you correctly, you're saying that you allow the team to use an individual as a scapegoat and not take responsibility for their own actions. Despite disagreeing in principle with the OC, I don't think this is at all what he was suggesting. Rather, he was presenting a "view from the top," where if he were to perceive a negative influence (whether or not the influenced parties were, themselves, aware), he would eliminate it.
trevelyan 17y ago
> I could easily imagine a situation, however, where this is not the > desired outcome, such as in a company where software is only a > minor component. Perceptive point by mmt - I do most of the programming work myself. I don't know if I'd feel the same way if a critical employee doing coding for a major system behaved this way. I wouldn't knowingly hire someone like that though, and unless someone was truly critical, I'd rather send them on their way than have them create a situation in which their behavior negatively affected office norms, yes. My business is quite small and doesn't have professional managers, so mmt's expectation that there is a level there to deal with this stuff is wrong. Problems are just more work on my plate and distract from the things that people pay us for.

mmt 17y ago

I think you're still missing the OP's point: if you, as a manager, think in this way, you'll end up with what he calls "crappy" programmers. I didn't find him to be complaining about anything per se, nor mentioning "fulltime job": Never mind that a good programmer can produce more valuable work in a 30-hour workweek from home than a crappy programmer can toiling 60 hours in the office. Rather, he's pointing out a contrast between two extreme, but plausible, situations. This guy is offloading that problem to his manager What's the manager's job if not, as you put it, to manage the communication and signaling problems that creates in the workplace? Still, I come back to the impression that you're thinking about this out of context: doesn't seem to understand the problems he might be creating. Again, I allege that's not the programmer's job. The programmer's job is to create, and the manager's job is to maximize the creativity while minimizing problems. It's that I don't think his sarcasm offers any practical advice. I agree that the practical advice may be masked by the tone or form. This is the advice as I interpret it: If you want to maximize the productivity of your programmers and ensure the most talented and most producive ones stay, avoid the listed behaviors, even if there are some negative consequences. If your business is software, I have a hard time believing that "general productivity" among the others in the office would improve enough to offset getting rid of someone working on the core competency. On the other hand, I could easily imagine a situation, however, where this is not the desired outcome, such as in a company where software is only a minor component. In that case, your firmer hand on scheduling seems far more beneficial.

roundsquare 17y ago
On the other hand, I could easily imagine a situation, however, where this is not the desired outcome, such as in a company where software is only a minor component. In that case, your firmer hand on scheduling seems far more beneficial. The problem I think people will have with this article is that he doesn't acknowledge this point.