to ship on time

I wrote this a year and a half ago and it's been languishing in my drafts since then, forgotten. Please enjoy the learnings of past-ello.

I was contemplating how we create stuff today — more specifically, how we decide stuff is done. I've been reading Play Nice by @jasonschreier@mastodon.social, a book about #Blizzard Entertainment. Blizzard leadership was once famous for organizing themselves around it's done when it's done: They shipped when they were convinced their players would have the best possible experience with their games. Player value was more important to them than any deadline, or KPI, or quarterly burn-down. Are they delivering the experience they wanted to deliver? No? Then they don't ship.

Late in a product cycle, a couple weeks before release, a senior leader once explained to me and the rest of the engineering department that the reason we were scrambling to make a tight deadline was to prove to ourselves and to our potential investors that we could go from idea to delivery in a single quarter. He explained it was important to show that it was possible, so that's why the 50+-hour weeks we were pulling would be worth it. The deadline was how we proved we had value, and we would cut scope — user value — from every possible nook and cranny to hit it. We compromised the experience because the deadline was more important. Demonstrating our value was more important.

I understand the calculus that dumped him there, but it was a demoralizing moment. The goal wasn't the product; it was the deadline.

We hit that deadline, but the product was slow because all the performance improvements had been de-prioritized, and it was buggy because we didn't have time to do anything more than keep the regression suite running, and it was brittle because tech debt only compounds if you don't pay it down. The engineers were burned out. There were some obvious-in-hindsight use cases that we completely missed because we were so focused on the few we'd hastily decided would be most important, and even those were unpolished.

Is that really what gets investors excited? “Look at this mediocre thing we did! It only took us three months”?

I'm not arguing that deadlines are bad. As a pathological procrastinator and perfectionist, I need 'em. Even Blizzard's when it's done ethos imploded spectacularly when Project Titan crumbled into Overwatch. The Titan team was Blizzard's best of the best, and they'd been given unbounded time and resources to build an in-house WoW-killer. In Play Nice, one unnamed artist from that team said

There was a feeling that Blizzard had essentially written a blank check to fund this game and that bred a sense of complacency within the team. We were not working with any kind of urgency.

Software process engineering is just applied behavioral science. People work better with stakes, and deadlines give us stakes. Scheduling a deadline at a software company means multiple teams are coordinating across multiple dimensions, and (assuming a generally healthy culture) nobody wants to be the reason that coordination falls apart, so delivering on time matters to everybody. That's a good thing. It's good to have hard discussions about vision and value, it's good to refine goals into something unambiguous and worthy. That's all good.

Once you've done that hard work, don't throw it away to preserve the thing that only exists⁰ to help get the work done in the first place, is all I'm saying. The deadline gave you stakes, and the stakes gave you a clear vision. When you learn later that your deadline is no longer serving your vision, change the deadline.

If you find that you're constantly changing your vision to meet a deadline: No, you aren't¹.

⁰ This is tech; we're not replacing lungs or yeeting people across oceans in tin cans. Deadlines are always at least a little bit arbitrary. ¹ POSIWID

from @ello@void.ello.tech