The very first reaction from the founder at my company: "Seems a little big-brother-ish?" I couldn't agree more. The same thing can easily happen in all metri

The very first reaction from the founder at my company: "Seems a little big-brother-ish?" I couldn't agree more. 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. 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". 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). 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. 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. Don't start by looking at my inbox. Start with a conversation.