Measuring Engineering Productivity

37 points by can


mccd

I thought I'd be more hostile to this post, mostly because I think my understanding of the word "measure" is more loaded than the author, but I think the article's advice is sound for a remote team. I've self-reported on progress async, but instead by posting on Slack then I would post in the tickets themselves, which was really appreciated. Over time my manager stopped asking me for updates and just looked directly in the tickets.

hoistbypetard

I like this. I think I'd call it "Evaluating..." or "Assessing..." instead of "Measuring...", because it really is more wholistic than what I usually associate with "measuring", but it feels like a smart counter to Goodhart's Law in service of a useful goal.

rangz

I love how you kept the manager as an important piece of the loop. Measuring by metrics misses so much of the impact that an engineer has. But, if a manager is going through these hoops, I'd expect they have a pretty strong pulse on their team.

ducdetronquito

I really enjoyed reading your article and I shared it in the slack of my company.

Some people, me included, are very tempted to try a variant of what you suggest for deploy verifications :)

typesanitizer

Well-written. Curious if you have thoughts on issue labeling/tracking in a similar vein and how to balance the work on ICs and managers there? E.g. for doing aggregations having labels on things is useful after a period of a few months, but I've found it hard to have ICs do consistent labeling.