Particularly after Sanders — and DOD-STD-2167A — game development was a breath of fresh air. Resource limitations combined with a hit-driven business meant game developers had to be fast and flexible. Little-a agile.

As a baby programmer, I imprinted on these core values. They’ve been core to my thinking ever since.

A’s and O’s

At Linden, I brought a management tool that we used at PCP&L and that has been invented and re-invented dozens of times. Our particular flavor came from Atari Games via Dennis: Accomplishments and Objectives, aka A’s and O’s.

Each week, everyone would send an email around with:

Every significant task they planned to complete this week (the “Objectives” section)
A cut-and-paste of last week’s objectives with annotation for “DONE” and “NOT DONE” (the “Accomplishments” section)
A separate block in the accomplishments section for unexpected tasks you ended up doing

That was it. (Turns out, when I joined Facebook, they were still using something pretty similar at 1500 people.)

We ended up looking at this data a lot, for many years. Nearly everyone got about 60% of their previous week’s objectives done that week and small deltas between people didn’t mean anything. What was super predictive was that if you were either above 80% or below 40% something was wrong.

On the upper end, just getting everything done every week probably meant you weren’t taking on enough. It’s like 50%-likelihood goal setting (picking targets you are only 50% likely to hit) — it keeps teams from sandbagging and not being ambitious enough. On the low end, whether you were getting too distracted, had tooling or code issues, or were genuinely struggling with the tasks, early detection made it easier to help.

My 1/n rule

A’s and O’s also formed one my foundational rules of software development:

The likelihood of a developer being right about about what they’re working on is 1/n, where n is the estimated completion time in weeks

nota bene: I sometimes think it’s 1/(n^2), but that seems too depressing

I know. Lots of important projects, tasks, strategies take more than a week. Duh. But here’s the thing: until the people working on them can talk about them through the lens of what’s getting in a week, you don’t really understand the problem, so assume massive estimation error and plan accordingly.

Figure out how to increase raw development speed. Simplify. Decouple. Plan to be wrong a lot and make it completely acceptable for mistakes to be made. Hold people accountable for too many mistakes — are they in the wrong role? wrong tooling? a bad manager? — but focus accountability on the right levels. Don’t punish L4 engineers for working on the wrong thing when it was a pack of directors who made a decision while packed in a clown car.

To me, all of this comes out of the 1/n estimation.