“I’m going to be a shrill and rigid idiot.
“I’m going to blindly refuse to listen to contrary opinions. I’ve already made up my mind, and will invent reasons why alternatives won’t work. Most importantly, I’m going to get this done my way, regardless of whether it’s actually the best decision, or even a good idea.”
You’ve never approached a problem that way. No one has.
But you’ve probably told yourself that story about someone else. You’ve been on the receiving end of one of these mindless and petty tyrants, in a bug or a mailing list or a standards body, and you’ve decided that you were seeing a rigid idiot in action. I know I have.
My philosophy of science prof used to talk about how the two important tests of a scientific model are whether it allows you to make accurate predictions, and how well it helps you discover new things. This matters more than its elegance or its intuitive appeal, though a really nice model has those, too.
The Rigid Idiot model does, for better or for worse, predict. It predicts more rigid idiocy, and people using that model to inform their interactions are likely to get precisely that. But it’s a pretty hollow model for generativity; it doesn’t help you make progress.
Here’s an alternate model:
Stress response pre-dates our neocortex, and outranks it. It is wired more deeply into us than language, much less rational discussion. And it has predictable effects. A person under stress (personal, professional, social, physical) will lose patience more quickly, anger easily, resist change, and consider fewer alternatives before making decisions. It’s an ancient, optimized cognitive path: less waffling when there are lions nearby. That it impairs our ability to function in this 10,000 year old thing called ‘civilization’ is evolutionary postscript.
You get to choose which model you bring to a conversation. When you assume that the person you’re dealing with is acting atypically, from point-in-time stress instead of born-in idiocy, you give yourself follow-up questions to ask about timelines, or conflicting pressures, or hidden assumptions. You give yourself ways to understand motivations, and implicit guidance about tone.
Not every asshole is a stress response waiting to be defused, but I swear to you that the single greatest improvement you can make to your success rate with these conversations is to switch models. I have seen people turn on a dime once their stressors are addressed. Suddenly there are lots of solutions, and confrontation turns to collaboration. It’s like a god damned secret decoder ring, to be honest.
With practice, you may even start to recognize the descent into idiocy in your own interactions, though it won’t make you immune. This is old, lizard-brain stuff. Like drunkenness, you can get better at detecting it, but you can’t think your way out of it. And, as with drink, my hope is that if you see someone a little worse for wear, you remember that it’s fleeting. Give them some time to sober up before assuming that’s who they really are.











26
Aug 11
Rapidity
[This is a re-post of a post that originally appeared on the Future of Firefox blog]
Last week we released a new version of Firefox. We shipped on time, 6 weeks after the last update, making it our first true rapid release milestone. There was cake. Now that we know that we’re capable of this velocity, I’d like to revisit the reasons why it’s important, and the lessons we’ve already learned.
Mission drives Mozilla. People sometimes forget that we’re a non-profit, that our only job is to make the Web a better place. Rapid release advances our mission in important ways. We get features and improvements to users faster. We get new APIs and standards out to web developers faster. We are delivering on the promise of the web at web speed.
Small, frequent releases improve quality, too. Engineers in the Mozilla community regularly say things now like “I don’t like not understanding this piece, let’s back it out and I’ll catch the next train.” We move deliberately. We don’t rush. And, even though it sounds like a contradiction, when we take our time we go faster.
There’s a great deal for us to be proud of, but we also need to be humble. This change was hard for us to make, and it’s been hard for some of our supporters, too. We have been glib or dismissive in the way we’ve communicated about parts of it. We live rapid release daily, and that makes it easier for us to see past the problems. We are also tenacious about the necessity of our new schedule, and tenacity can be mistaken for obstinacy.
We, everyone in the Mozilla community, all of us, need to communicate with clarity and sensitivity. We need to help the people who support our mission to understand why these changes are essential. We need to keep listening, and adjusting as we learn. We need to, and we will.
The push to ship faster isn’t some kind of software machismo. We push ourselves to ship faster because the web is under threat. Amazing and innovative people are doing amazing and innovative things and right now they have a choice: build for the web, or build for the walled gardens. The web can win that fight.
The open web is the most amazing, universal communication and distribution platform ever built. To win, the web needs to be agile and responsive. To help it, we need to be agile and responsive, too. That’s why rapid release matters.