The problem with Peak: Activity ≠ productivity

Daily stand-ups were the best thing I ever did for this. We had our task list on big post-it notes on the wall. We talked about which ones we were going to accomplish, what we had done the day before, and what we expected to do that day.

That way, when I looked at their check-ins and their project updates, I had context for that.

Thanks! When humans are involved, things get way more complicated than expected, that's true. It's all about finding a good balance and a set of metrics that makes sense for your business & team.

Even more so when you're working on extremely complex systems like software.

Consider a simple example of two developers, Alice and Bob.

Alice spends 4 hours a day, at work, on reddit and pinterest, but she does excellent work. When she writes code it is of the highest quality. Her code very rarely has defects and is often extremely extensible and easy to use or modify. She only completes about 2 or 3 work items in a given week but usually they are very critical, core functionality components.

Bob, on the other hand, is very different. He works 12 hours a day and is often in the office on Saturdays. Unlike Alice he doesn't goof off at work, he's got too much on his plate. He usually cranks out 3 or 4 work items a day. However, his code isn't nearly as good as Alice's, often he'll have little design errors or implementation defects that creep into his work, but overall his code is still pretty good.

On paper Bob seems like a vastly more productive employee than Alice, and thus vastly more worthwhile having around. And in terms of naive measures those facts are abundantly clear. Bob puts in more hours. Bob completes more work items. Bob checks in more lines of code.

But none of those metrics matter, what matters is the improvement in the quality and capability of the product. And in those aspects Alice beats the crap out of Bob. Alice's checkins may have fewer lines but they are better designed and they are often in more crucial systems than Bob's. Moreover, a lot of Bob's checkins and work items are just bug fixes for defects that he himself introduced in earlier checkins.

Imagine two wood workers. One takes a single block of wood and spends a week laying out a plan and then meticulously carves out various pieces from the block then assembles them into an incredibly well made chair. The other takes half a dozen blocks of wood and cuts them down into pieces that vaguely resemble the parts of a chair using a chainsaw, leaving a giant pile of sawdust in his wake. Then he assembles the pieces into a chair-like structure and uses duct tape to hold it together. After repeated instances of the chair falling apart when used he applies more and more duct tape to certain parts of the chair until finally it stops falling apart and mostly works as a chair.

Again, if you were incapable of understanding the actual work that either worker did you may end up with a false impression of who is a more valuable worker based on the simplistic observable evidence. One worker spent a week to build a chair and most of the time they weren't even doing anything with the wood. The other worker built the chair in much less time, they started working almost immediately, and there was a flurry of activity related to chair making relative to the almost sedate minimalism of effort the first worker put in.

This is why it's absolutely vital that management has to have the technical chops to be able to tell the difference between an Alice and a Bob, and between high quality craftsmanship and duct-tape run-and-gun enthusiasm. If you end up promoting the Bobs and firing the Alices you end up in a very sad place indeed.