Good article, I've always been on the lookout for the "silver bullet" when trying to manage a development team, but there's really no concise way to get good metrics and evaluate the team's burn rate and productivity efficiently.
Congratulations, a new way to fire people quantitatively. I imagine this to actually be useful for call center owners, staffing managers and whomever that sells fixed units of activity for money.
The very first reaction from the founder at my company: "Seems a little big-brother-ish?"<p>I couldn't agree more.<p>The same thing can easily happen in all metric tracking for productivity. For instance, if you estimate points-per-story in an agile estimation process (or apples or oranges), you will naturally have an incentive to give higher point values to stories, and mark the stories complete. This puts incentive on the process, not the output.<p>The same goes for these distinct productivity applications. Peak serves as a high-level glimpse into data collected by tools that are supposed to aid in productivity; this data most certainly does not directly translate to "work being done".<p>Case in point - I've been working on a RubyMotion application. A lot of my work has been wading through StackOverflow posts to learn and overcome barriers. I don't have a problem saying that. But what tracks my "learning" metric? Absolutely nothing. Not the number of lines of code I write, not my emails, not even my web history (though that may be a better picture).<p>If you want to know what work is being done in our office, have a 2 minute conversation with the person who is doing the work. Verify what they say, and move on.<p>Productivity in web development isn't trackable by metrics. It's trackable by product goals and people sharing solutions to problems. If problems aren't being solved in a reasonably predictable and acceptable time period, that's where you can start to see cracks in productivity.<p>Don't start by looking at my inbox. Start with a conversation.