6 ms·

Let me play slight devil's advocate. I am a coder that is now starting to take on some management tasks. How much work should I ask people to do? Because it's e

Let me play slight devil's advocate. I am a coder that is now starting to take on some management tasks. How much work should I ask people to do? Because it's even harder for me to guess how long something should take a programmer than it is for them to guess themselves. So if we assume that all the programmers are honest (which I do), then I can't just say "get this done by Friday." But I can say, "So you think this might take a week? Okay, I know how hard it is to do estimates, so please make your best effort to reach that goal, but if problems crop up, let me know and we'll adjust the schedule. Or if it turns out to be easier than you thought, let me know that too, and we can find another fitting task for you to tackle." Regardless, it only seems possible to ask a certain amount of time and effort from a programmer since that is the basis on which the schedule is created. Now I fully acknowledge the ideal amount of time is likely less than 40 hours a week. But still, it's the most a person can comfortably get done in a certain amount of time that we're paying for. How else could it work? I fully acknowledge there may be better alternatives, and I'm glad to read about them. My only caveat is that such suggestions would be best if realistically applicable to full-time employees, which is short-term-unchangeable situation I'm in.

jghn 12y ago
As long as you all aren't consistently incorrect in the same direction it'll probably work out. Suppose week 1 you tell me to get X done by Friday and I finish on Thursday. Perhaps I get Friday off, slack off or whatever. Then on week 2 you tell me to get Y done by Friday and on Weds I realize that's not happening so I end up working an extra 8 hours over thurs and fri to make it happen. What's the difference? (Yes, I realize that this is an overly simplistic example, but hopefully it conveys the point)
- sopooneo 12y ago
  If things average out on week (or even month) level, then I think you are absolutely right. So far they pretty much have for me. In full disclosure, my job is effectively lead developer right now, and I am officially "manager" for only one junior level programmer. Who's been awesome so far, and my push with her has been mostly making sure she leaves on time as I worry she's working too hard.
  - jghn 12y ago
    Yeah, I'm talking about the month or even multiple month level. Also, our company's culture is similar to your last statement - get your work done, and please don't kill yourself. Work/life balance is important to us. I'm in a similar situation as you, one of an upper echelon of devs and while nothing is ever official sometimes increasingly there are people "under" me on any given project. So because of that, the tasks that I'm holding in my mind and have deadlines for tend to be longer running - not the typical 4 hour sprint ticket. If I was fresh out of college and simply pulling stickies off the queue I'd likely have a different take on things. In those situations it's literally just a matter of doing something and moving on to the next something. My personal experience these days is different, it takes a little bit to shift gears and move on to the next thing, it's not as simple as simply grabbing a sticky.
- icebraining 12y ago
  For me as a developer, the difference is huge, for the negative. An unplanned day of "slacking off" is a small gain, and they absolutely don't make up for the days when I feel like I'm doing nothing else but work, eat and sleep.
falcolas 12y ago
Focus not on the time, or the perceived effort, but on the output. After all, it's ultimately the output that matters to the business, not the process of getting to that output. Make the charitable assumption that they are willing to do work for the money you're paying them (but don't forget to follow up if they aren't). More specifically, give them a list of things to work on. Have them give estimates, silently apply the "Scotty" factor, and base their performance against that. The list means that they are never short of work to do, so our ideally motivated candidate will always be working towards the company's goals. This list should comprise of at least one easy thing "I can do that in an hour", one "less than a week" project, and one "greater than a week" project. This provides your developers with a bit of variety, so they don't get burned out on trying to grind through the tough problems. It also makes them feel like they're making progress by letting them knock out at least one project every week - this can be very motivating. The Scotty factor (development estimate * 3) will give you a more realistic idea of how long something will take. I use it on my own estimates, and it's accurate more often than it's not. You can use this to gauge both their skill at estimating, and as a measuring stick for identifying when they are underperforming (getting a second opinion on an estimate can help identify the underperforming part). This does mean that you won't be able to look at the output of a given day/week and gauge a worker's performance just on that. However, you will be able to look back on a month, six months, or more, and get real data with which to identify the exceptional performers and those who need help (and perhaps even those who need to be let go).
- k__ 12y ago
  > Focus not on the time, or the perceived effort, but on the output THIS. But I understand companies. When they won a cash cow, they want to milk it. A good dev can either slow down, till he's as fast as the others and keep chilling the rest of the time, or, get more money for getting more things done than other devs.
- sopooneo 12y ago
  This all sounds like very good advice and like you know what you're doing. So I take it all to heart. But when you say to not focus on time, I have to assume we mean time for a given person to complete a given task? Because time-to-project-completion can not be ignored completely.

jghn 12y ago

As long as you all aren't consistently incorrect in the same direction it'll probably work out. Suppose week 1 you tell me to get X done by Friday and I finish on Thursday. Perhaps I get Friday off, slack off or whatever. Then on week 2 you tell me to get Y done by Friday and on Weds I realize that's not happening so I end up working an extra 8 hours over thurs and fri to make it happen. What's the difference? (Yes, I realize that this is an overly simplistic example, but hopefully it conveys the point)

sopooneo 12y ago
If things average out on week (or even month) level, then I think you are absolutely right. So far they pretty much have for me. In full disclosure, my job is effectively lead developer right now, and I am officially "manager" for only one junior level programmer. Who's been awesome so far, and my push with her has been mostly making sure she leaves on time as I worry she's working too hard.
- jghn 12y ago
  Yeah, I'm talking about the month or even multiple month level. Also, our company's culture is similar to your last statement - get your work done, and please don't kill yourself. Work/life balance is important to us. I'm in a similar situation as you, one of an upper echelon of devs and while nothing is ever official sometimes increasingly there are people "under" me on any given project. So because of that, the tasks that I'm holding in my mind and have deadlines for tend to be longer running - not the typical 4 hour sprint ticket. If I was fresh out of college and simply pulling stickies off the queue I'd likely have a different take on things. In those situations it's literally just a matter of doing something and moving on to the next something. My personal experience these days is different, it takes a little bit to shift gears and move on to the next thing, it's not as simple as simply grabbing a sticky.
icebraining 12y ago
For me as a developer, the difference is huge, for the negative. An unplanned day of "slacking off" is a small gain, and they absolutely don't make up for the days when I feel like I'm doing nothing else but work, eat and sleep.

falcolas 12y ago

Focus not on the time, or the perceived effort, but on the output. After all, it's ultimately the output that matters to the business, not the process of getting to that output. Make the charitable assumption that they are willing to do work for the money you're paying them (but don't forget to follow up if they aren't). More specifically, give them a list of things to work on. Have them give estimates, silently apply the "Scotty" factor, and base their performance against that. The list means that they are never short of work to do, so our ideally motivated candidate will always be working towards the company's goals. This list should comprise of at least one easy thing "I can do that in an hour", one "less than a week" project, and one "greater than a week" project. This provides your developers with a bit of variety, so they don't get burned out on trying to grind through the tough problems. It also makes them feel like they're making progress by letting them knock out at least one project every week - this can be very motivating. The Scotty factor (development estimate * 3) will give you a more realistic idea of how long something will take. I use it on my own estimates, and it's accurate more often than it's not. You can use this to gauge both their skill at estimating, and as a measuring stick for identifying when they are underperforming (getting a second opinion on an estimate can help identify the underperforming part). This does mean that you won't be able to look at the output of a given day/week and gauge a worker's performance just on that. However, you will be able to look back on a month, six months, or more, and get real data with which to identify the exceptional performers and those who need help (and perhaps even those who need to be let go).

k__ 12y ago
> Focus not on the time, or the perceived effort, but on the output THIS. But I understand companies. When they won a cash cow, they want to milk it. A good dev can either slow down, till he's as fast as the others and keep chilling the rest of the time, or, get more money for getting more things done than other devs.
sopooneo 12y ago
This all sounds like very good advice and like you know what you're doing. So I take it all to heart. But when you say to not focus on time, I have to assume we mean time for a given person to complete a given task? Because time-to-project-completion can not be ignored completely.