[addcn]

I've found that you have to pick results (output) OR time. You can't manage both and trying to do so sends the wrong message to your team. They'll question your motives and start to assume they can substitute output for time or vice versa.

Pick one and stop thinking about the other. Worried people aren't working enough? Is one guy only working a day a week? If you have team members like that they don't have enough work and you need to set better goals with/for them.

So save yourself the eternal headache and pick your poison, people will respect you a lot more for doing so.

[hackerstyle]

Thanks for comment, it makes sense. Do you do anything to increase people productivity? for example: I hate to see people playing games in the office, but I know at the same time that it might be healthy to have this kind of freedom.

[addcn]

Again you have to pick one. If they get results, why does it matter if they play games? I have a guy who plays Warcraft on breaks, he says it pissed all his old bosses off, but this guy writes incredible code. He'll spend half his time not coding, but doing mindless tasks as he thinks. Then he writes code without running it for an hour right before leaving and hits run at the end and it all works. Never seen anything like it.

Everyone's different. I only intervene if they aren't getting results and a lot of the time when they are having issues it's never because of the surface things you'd notice if you were managing time.

[hackerstyle]

Thanks for the great feedback, much appreciate it.

Managing output alone is hard, how do you do it without setting unrealistic goals? Do you have a place where I can read more about this?

Usually everyone in the team knows what's required, and we have the tools, and the reports to measure things but usually things might take less or more than expected and the question here is really the actual software challenges that delayed the work or the actual time and effort spent on a problem?

[taway_1212]

I think programming as a full-time job is hard enough on the brain, and the manager's instinct of trying to squeeze extra productivity out of people should not be applied. Let people work at their own pace, if you see someone who seems to be consistently slow (say over 6 months), have a talk with him. Maybe he can put in some extra effort and the talk will make him do so - or maybe he's already at max capacity (max capacity over long term is very different than max capacity over 2-4 weeks) in which case you either accept it or fire him.

Also, if you evaluate people on speed only, ignoring quality of their work, people will eventually figure it out and the quality will of course suffer. To prevent this from happening, you'll need to pay attention to quality too, which in practice is probably even harder than tracking speed.

To summarize, IMO software development (like many other white collar jobs) is a ripe for exploitation by slackers. This cannot be entirely prevented, and can only be combated by being in the trenches with the team and careful observation of each team member's performance over the long run.

[addcn]

Check out the classic Andy Grove "High Output Management" https://www.amazon.com/High-Output-Management-Andrew-Grove/d...

And Google's work with OKRs is a good practical model to follow. Also, humans being human, I find that my programmers like using practices that Google follows/pioneered. If you start using OKRs milk that "we're gonna do what Google does" mantra as a way to get buy in. https://library.gv.com/how-google-sets-goals-okrs-a1f69b0b72...