November 2015 – Jeff Clark's Blog

I like this a lot: using long-term discussions to better plan near-term work. Probably leads to better conversations overall, and a better understanding of the “why”.

When I ask people close to Zuckerberg how, exactly, he has pulled off these achievements, I don’t hear a lot of anecdotes about him swooping in and personally making genius-level decisions that suddenly changed everything. Instead, they praise his inquisitiveness, persistence, ability to deploy resources, and devotion to improving Facebook and himself. He has a knack for carving up grand plans into small, doable victories. “Most of our conversation was about long-term strategy, and then we’d backtrack from there to what we should do over the next month,”

From a great article about Mark Zuckerberg and Facebook’s long-term plan.

A friend emailed me for advice this morning:

How do you track/measure/analyse how much work you get out of your team over a given period of time (sprint/quarter/year/etc.)?

It’s an interesting question that I’ve dealt with as a designer, a developer and a product manager. It’s a question that comes up all the time, so I’m adding my response here hoping that someone else gets value out of it at some point.

How to measure your development team’s output:

Value delivered. This is the biggest way to measure team output. 2 “high-value” deliverables pushed is better than 5 “small-value” almost every single time. While this has the potential to be relatively subjective, if your team’s mission/goals are aligned with the business’s mission/goals, then it should be easy to know.It’s important to remember that this doesn’t have to be financial value: if your goal is to strengthen the reliability of your video processing pipeline, then adding the fourth or fifth 9 to the overall success rate is value delivered.Also consider non-code output as value, such as increased team learning: if the team has spent the sprint cleaning up tech debt that drive them nuts, they’re going to be more productive in the future. That’s value. If the team spent the entire sprint interviewing customers, holding a design studio to sketch next year’s 2.0 version, or having a massive grooming sprint to clear up the mess in Jira, that’s long-term value that you won’t be able to assign dollars to.
Velocity achieved. Assuming every card that your team works on has an estimate, tally up the sum of the estimates of finished, deployed work. Keep a record of how many points you ship per sprint and work to keep this increasing. This is more objective, but easier to game since the team could just start padding numbers to make it appear that their velocity is increasing. It is also a very good way to make your developers feel like code monkeys.

I would hesitate to use any of these to measure team output:

Lines of code shipped. If your team cares about succinct code, they won’t want this number to go up anyway.
Number of deploys to production. Lots of deploys could mean lots of hot fixes or prod issues.
Number of cards deployed. Easy to game: all of the sudden, 1 card with 4 sub-tasks becomes 4 cards because “now we’re shipping 4x the work!”