| >Curious how you would measure whether they are "performing the tasks for their jobs". First the product manager should have some tasks in mind (e.g. get the new product X to ship), and an idea of a realistic workload to be done in X time. No task should be given without a timeframe (which can be flexible or less flexible) for its completion in mind. When tasks are done give the next task+timeframes bunch. This can include new features, refactoring, and code-debt fixup tasks. As long as those conditions are met, it should be no problem to see if they're "doing their job" or are getting behind etc. If what they want is: "let's keep this person occypied to 100% capacity, giving them arbitrary new tasks or even busywork in a constant feed where everything has to be done ASAP with no timeframe in mind", it wouldn't work. But that's a slave ship, not a software planning process. Even factory production lines have specific quota to hit. >I think most folks would say that measuring SE output is very difficult to do and as such, most managers give their team the benefit of the doubt that they are working at a reasonable but sustainable pace. Well, they shouldn't measure SE output with anything expect whether their targets are met. If they find those targets are too lax, it's not them that they agreed to them. If targets slip, the developer should have a reason -- specific issues preventing it, waiting for other part to complet, an unexepected hard problem, etc. |