5 ms·

A manager must be able to answer the question "Are we on time? Do we need additional resources?". This happens to help a project, not to delay it. If a good tea

A manager must be able to answer the question "Are we on time? Do we need additional resources?". This happens to help a project, not to delay it. If a good team of developers estimates the effort needed for anyone task with a 20% accuracy (which would be very good indeed), that can make a 9 month project being 2 months late, which might or might not be acceptable. If developer teams would be treated like the blackbox they apparently want to be treated as would mean that whoever is managing procuesses would fly blind just hoping for the best - but the organization as a whole needs to be understanding what is going on right now. Time tracking can be a surveilling tool, but it can also be a tool to improve things - someone could find out that a team is running over capacity, and consequently assign more resources to the task at hand or redefine the task. And, well, for morning standups: when done right they are a valuable tool for efficient communication, and probably better than having people chasing each other for hours on end. IMHO an organisation should agree on a communication strategy that is the most efficient and helpful for it. It is not a religious belief that a standup meeting must be done first thing in the morning, I think that tends to conflict w/the teams personal schedules the least.

steve_taylor 7y ago
> "Are we on time? Do we need additional resources?". This happens to help a project, not to delay it. If, by “resources”, you mean people, then Fred Brooks might have something else to say about that.
coldtea 7y ago
>A manager must be able to answer the question "Are we on time? Do we need additional resources?" This happens to help a project, not to delay it. If we know anything in IT, it's Brook's law: "Adding manpower to a late software project makes it later". So if the manager asks that for a late project, they are probably incompetent. >If a good team of developers estimates the effort needed for anyone task with a 20% accuracy (which would be very good indeed), that can make a 9 month project being 2 months late, which might or might not be acceptable. For a small (a few days) project, 20% accuracy doesn't make any difference. For a large one, 20% accuracy is science fiction stuff compared to the actual accuracy rates of big projects, especially the kind with changing requirements, new issues discovered en route, etc (which is most of them). >If developer teams would be treated like the blackbox they apparently want to be treated as would mean that whoever is managing procuesses would fly blind just hoping for the best - but the organization as a whole needs to be understanding what is going on right now. If the manager is not part of the team / actively involved (and thus he is inside the "black box") then any numbers they get is bogus, time tracking or not. Software is a qualitative process, not a quantitative. "5 hours spent on X" mean nothing at all without knowing what was done for X.
- ghaff 7y ago
  Brooks' law is not actually a law of physics though. There is a lot of wisdom to it. But there are good ways to add resources and bad ways. Perhaps a team isn't getting help from another group. Perhaps there are some tasks that others could offload in a way that doesn't distract the team on the critical path, etc. It's a good adage but it doesn't mean that you can never take steps to accelerate project delivery.
  - delusional 7y ago
    > Perhaps a team isn't getting help from another group Then the team should communicate that to the other team themselves. > Perhaps there are some tasks that others could offload in a way that doesn't distract the team on the critical path That should be the decision of the team. If they need to cut down in order to stay on the critical path, then they should do so.
    - ghaff 7y ago
      You seem to have a rather negative view of managers. In my experience, good managers can be quite valuable negotiating with other organizations in the company and with getting needed resources. In fact, I'd say that's a pretty significant part of their job.
- marcosdumay 7y ago
  What you get from Brooks Law is really that one should never put more people on a project? (Late or whatever?) That's an insane idea (it does lead to the conclusion that the optimal team is zero sized), and not an answer to the GP's claim that a good manager must know when more people will/won't help.
  - Nasrudith 7y ago
    The point of Brook's law isn't that extra people won't aid conclusion but that the overhead isn't free and unless the date is grossly overambitious (like 10% done) adding more people will add more tasks in "creating infastructure". Lets take say Civilizations for example and say you need to build a spearman in 7 turns to not lose - but it would take 9 right now you already have production maximized without adding new buildings. Technically building a forge could speed it up to 6 turns but it takes 20 to build it. Even if it would help adding it right now would only make an intolerable delay even worse. To get away from the geeky metaphor bottleneck and chokepoint management are a crucial part of making projects parallelizible across many developers and even then there are expenses to making them interoperate. Unless you are grossly behind it is unlikely adding more people will help unless you are vastly overambitious and try to do something with one person that requires a team of thousands. In which case you have probably already failed too massively to help.
ImprovedSilence 7y ago
You bring good points to the table. I’ve seen time tracking used extensively, but never to (intentionally)gut morale, more for metrics, ie project x took 10,000 man hours, and project y is sorta like that if you squint a bit and tilt your head to the left, so it should probably take us 11000 hours. It’s helps large organizations project staffing needs and keep everybody gainfully employed. Managers don’t like laying off people and usually do want everyone to be productive.
- jlokier 7y ago
  I'm not convinced that managers want everyone to be productive, because so many managers act to undermine and disincentivise their subordinates. When the drag is unintentional, I think many managers would rather not think about how to compensate for it. And sometimes it's intentional. I think the biggest risk introduced by time tracking is well illustrated by a sibling comment: > My boss knew how long particular task took and asked if I need some help afterwards. It was great support and mentoring. But I now experience exact the opposite. My managers come to me if it took me longer second time than first time to complain about me being to slow. It produces a misalignment of incentives: If you do a great job one week getting visible things out the door, then you're punished for the rest of your time in that job, rather than rewarded for doing great. So you know in advance, it's better to deliver slower all the time. I think a lot of people have in the back of their mind an instinctive trepidation for detailed time reporting, because of fears it will invite that sort of paradoxical push, preventing them from doing the best work they know they could be doing. "To speed you up we need you to attend more meetings." I've also witnessed a different kind of time-tracking problem. Someone logs into a reporting system that, say, they worked 200 hours on a project so far, since the last 3 month report. Some people don't take the person's word for it. I've seen bosses, peers, coworkers say "I don't believe you, no way that took 200 hours! You've done maybe 10 hours at best. I could do it in a weekend, if only I had the free time. Anyone competent could! If only I had the time to organise someone to replace you. You're lucky to work here, your job should be given to someone else who doesn't lie about what they've been doing. (etc.)" What's really happening is the person has put in 250 hours (350 if you count that unpaid overtime they did on their holiday and weekends), but reduced it to 200 in the report because they know what their boss/peer/coworker is likely to say. If freelancing, they only bill for 200 hours, feeling like in a just world they would bill 350, but it's not a just world, and if their client is unhappy, maybe their work doesn't deserve full rate. Often, boss/peer/coworker is quite incompetent, and wouldn't be able to implement the thing in 200 hours, let alone 10 - their lack of ability or familiarity with the job is what's making them estimate such a low figure. And no surprise to anyone, they can't find a replacement who will do the same thing in less time - although they sometimes find replacements who say they will, and then don't. The cycle continues, rinse and repeat. So unlucky time-reporting worker is forced to do things to "prove" they are telling the truth about the time they've put in at least, while feeling a heavy dose of imposter syndrome. Things like ass-on-seat, make sure screen is visible to others at work (to prove not using social media), timing of repo commits designed around reputation rather than problem solving, participate in social chats/IMs just the right amount (too much = slacker, too little = slacker), same with meetings. And weirdly, it works. Because visibility matters a lot more than results. If the above sounds a bit like I might be talking about myself... not really. I've had those sorts of accusations a few times, but it's outweighed by the rather pleasant discovery that I've worked for people who are surprised that the hours I bill for (I often freelance) are lower than they expected. However, the few times it's happened, I took from that the importance of not doing it to other people, even if I'm unhappy with their work. Because it's so undermining at a rather fundemantal level.

steve_taylor 7y ago

> "Are we on time? Do we need additional resources?". This happens to help a project, not to delay it. If, by “resources”, you mean people, then Fred Brooks might have something else to say about that.

coldtea 7y ago

>A manager must be able to answer the question "Are we on time? Do we need additional resources?" This happens to help a project, not to delay it. If we know anything in IT, it's Brook's law: "Adding manpower to a late software project makes it later". So if the manager asks that for a late project, they are probably incompetent. >If a good team of developers estimates the effort needed for anyone task with a 20% accuracy (which would be very good indeed), that can make a 9 month project being 2 months late, which might or might not be acceptable. For a small (a few days) project, 20% accuracy doesn't make any difference. For a large one, 20% accuracy is science fiction stuff compared to the actual accuracy rates of big projects, especially the kind with changing requirements, new issues discovered en route, etc (which is most of them). >If developer teams would be treated like the blackbox they apparently want to be treated as would mean that whoever is managing procuesses would fly blind just hoping for the best - but the organization as a whole needs to be understanding what is going on right now. If the manager is not part of the team / actively involved (and thus he is inside the "black box") then any numbers they get is bogus, time tracking or not. Software is a qualitative process, not a quantitative. "5 hours spent on X" mean nothing at all without knowing what was done for X.

ghaff 7y ago
Brooks' law is not actually a law of physics though. There is a lot of wisdom to it. But there are good ways to add resources and bad ways. Perhaps a team isn't getting help from another group. Perhaps there are some tasks that others could offload in a way that doesn't distract the team on the critical path, etc. It's a good adage but it doesn't mean that you can never take steps to accelerate project delivery.
- delusional 7y ago
  > Perhaps a team isn't getting help from another group Then the team should communicate that to the other team themselves. > Perhaps there are some tasks that others could offload in a way that doesn't distract the team on the critical path That should be the decision of the team. If they need to cut down in order to stay on the critical path, then they should do so.
  - ghaff 7y ago
    You seem to have a rather negative view of managers. In my experience, good managers can be quite valuable negotiating with other organizations in the company and with getting needed resources. In fact, I'd say that's a pretty significant part of their job.
marcosdumay 7y ago
What you get from Brooks Law is really that one should never put more people on a project? (Late or whatever?) That's an insane idea (it does lead to the conclusion that the optimal team is zero sized), and not an answer to the GP's claim that a good manager must know when more people will/won't help.
- Nasrudith 7y ago
  The point of Brook's law isn't that extra people won't aid conclusion but that the overhead isn't free and unless the date is grossly overambitious (like 10% done) adding more people will add more tasks in "creating infastructure". Lets take say Civilizations for example and say you need to build a spearman in 7 turns to not lose - but it would take 9 right now you already have production maximized without adding new buildings. Technically building a forge could speed it up to 6 turns but it takes 20 to build it. Even if it would help adding it right now would only make an intolerable delay even worse. To get away from the geeky metaphor bottleneck and chokepoint management are a crucial part of making projects parallelizible across many developers and even then there are expenses to making them interoperate. Unless you are grossly behind it is unlikely adding more people will help unless you are vastly overambitious and try to do something with one person that requires a team of thousands. In which case you have probably already failed too massively to help.

ImprovedSilence 7y ago

You bring good points to the table. I’ve seen time tracking used extensively, but never to (intentionally)gut morale, more for metrics, ie project x took 10,000 man hours, and project y is sorta like that if you squint a bit and tilt your head to the left, so it should probably take us 11000 hours. It’s helps large organizations project staffing needs and keep everybody gainfully employed. Managers don’t like laying off people and usually do want everyone to be productive.

jlokier 7y ago
I'm not convinced that managers want everyone to be productive, because so many managers act to undermine and disincentivise their subordinates. When the drag is unintentional, I think many managers would rather not think about how to compensate for it. And sometimes it's intentional. I think the biggest risk introduced by time tracking is well illustrated by a sibling comment: > My boss knew how long particular task took and asked if I need some help afterwards. It was great support and mentoring. But I now experience exact the opposite. My managers come to me if it took me longer second time than first time to complain about me being to slow. It produces a misalignment of incentives: If you do a great job one week getting visible things out the door, then you're punished for the rest of your time in that job, rather than rewarded for doing great. So you know in advance, it's better to deliver slower all the time. I think a lot of people have in the back of their mind an instinctive trepidation for detailed time reporting, because of fears it will invite that sort of paradoxical push, preventing them from doing the best work they know they could be doing. "To speed you up we need you to attend more meetings." I've also witnessed a different kind of time-tracking problem. Someone logs into a reporting system that, say, they worked 200 hours on a project so far, since the last 3 month report. Some people don't take the person's word for it. I've seen bosses, peers, coworkers say "I don't believe you, no way that took 200 hours! You've done maybe 10 hours at best. I could do it in a weekend, if only I had the free time. Anyone competent could! If only I had the time to organise someone to replace you. You're lucky to work here, your job should be given to someone else who doesn't lie about what they've been doing. (etc.)" What's really happening is the person has put in 250 hours (350 if you count that unpaid overtime they did on their holiday and weekends), but reduced it to 200 in the report because they know what their boss/peer/coworker is likely to say. If freelancing, they only bill for 200 hours, feeling like in a just world they would bill 350, but it's not a just world, and if their client is unhappy, maybe their work doesn't deserve full rate. Often, boss/peer/coworker is quite incompetent, and wouldn't be able to implement the thing in 200 hours, let alone 10 - their lack of ability or familiarity with the job is what's making them estimate such a low figure. And no surprise to anyone, they can't find a replacement who will do the same thing in less time - although they sometimes find replacements who say they will, and then don't. The cycle continues, rinse and repeat. So unlucky time-reporting worker is forced to do things to "prove" they are telling the truth about the time they've put in at least, while feeling a heavy dose of imposter syndrome. Things like ass-on-seat, make sure screen is visible to others at work (to prove not using social media), timing of repo commits designed around reputation rather than problem solving, participate in social chats/IMs just the right amount (too much = slacker, too little = slacker), same with meetings. And weirdly, it works. Because visibility matters a lot more than results. If the above sounds a bit like I might be talking about myself... not really. I've had those sorts of accusations a few times, but it's outweighed by the rather pleasant discovery that I've worked for people who are surprised that the hours I bill for (I often freelance) are lower than they expected. However, the few times it's happened, I took from that the importance of not doing it to other people, even if I'm unhappy with their work. Because it's so undermining at a rather fundemantal level.