I'd put forward the proposition that not only is there no need to measure productivity of developers, but that this is a counterproductive management approach.

I'd put forward the proposition that not only is there no need to measure productivity of developers, but that this is a counterproductive management approach. 1. You have hyperproductive developers (the famous 10x ones). Everybody knows who they are and you can hire or retain them if you provide the correct incentives. 2. Then you have the disaster zones - again they are easily recognisable. 3. With everybody else, _they are going to be as productive as they are going to be_. They will be trying their hardest as much as they can - if they didn't actually want to build software they would be in the disaster zone category. You can improve this via a process of facilitation using well-known approaches to improving the working environment (plenty of info in books like Peopleware for example). As a manager, your biggest problem is stopping them working too hard and burning out because your schedules will become increasingly erratic, and the effect of late hours is always a net loss over the longer term. If your development team isn't effective, it's a management problem, not a developer one.