The better you are, the faster you go. That's a basic truism of just about any field, and programming is no different. But competence isn't the only input to pace. Risk tolerance is just as important, if not more so. You can't go quickly if you treat every problem with the diligence required for rocket surgery.
If your work can directly kill people, think guided missiles or pacemakers, you damn well better put all your emphasis on safety. Speed of execution is a distance priority at this ultimate level of criticality.
If your work can result directly in the loss of millions or billions of dollars, you also better approach it with an unusually high level of care. And yet, it's clearly still nowhere near as bad as dealing with the direct loss of human life, if you get it wrong.
The criticality ladder keeps going down from there. Loss of important data. Loss of critical access to data. Loss of replicated data. Imposed inconvenience.
And that's when it starts getting interesting. Once you're far enough down the ladder that it isn't obvious which step you're on, and how much care is appropriate.
I'm no fan of Zuckerberg in general, but I think he got it right by making "move fast and break things" the development slogan in the early days of Facebook. A nascent social network is exactly where understanding what's critical (very few things) and what's not (most things) is crucial. A startup struggling to find market fit in that domain should indeed favor pace over prudence.
You can argue at what point that slogan should have been retired, once Facebook was no longer a startup. But that's separate from the fact that this is fundamentally a good posture of almost any early startup – when the key criticality to worry about is going out of business.
At more mundane levels of importance, we deal with this question at our company every day. We're constantly, implicitly or explicitly, deciding how much care to take when engaging with the issues. Not in the sense that we can get away with doing a shoddy job, because that rarely if ever works. The price you pay for making a mess is an instant surcharge on both quality and productivity. But in the sense that there's a wide spectrum from mess to good enough to worthy of running a human heart.
And this is where organizational expectations come in. Zuckerberg set those clearly: It's OK if some things break, as long as we're moving forward, we can fix them. I have a lot of sympathy for that approach, especially in the beginning.
In the early days of Basecamp, we explicitly chose to involve our initial customers as part of the Q&A process. We'd put out something pretty good, but then let our customers tell us where the edge cases were, because there weren't that many customers, and the edge cases usually weren't of that high criticality.
These days we have a lot more rigor in the process, including actual Q&A personnel reviewing most new features and major fixes before they ship. Simply because shipping something obviously broken, and then hearing from 1,000 people in five minutes, who all need a human reply, would be a bad deal at our current scale.
And yet still we have to make the determination: Is this worthy of the bigger process? Our could we just ship it, and see what happens? Knowing when to accept the risk of the latter is part of how you prevent getting bogged down in process for things that just don't merit it.
And sometimes you'll get that wrong! Something that looked innocuous will be consequential, and you have to clean it up. That's the nature of the criticality bet. You need to have the stomach to keep playing, even if you occasionally lose a hand. You're playing anyway unless you're doing the crazy multiple-teams-doing-adversarial-solutions stuff that I've heard of in pacemaker development. So don't sweat it, calibrate it!
That calibration comes best from the top, though. If executive wrath bears down upon you after any little mistake, you'll naturally just stop taking the appropriate risk, lest you tempt a small chance of getting chewed out. Organizations that work like this in the face of criticality that does not warrant it become lethargic.
It's perhaps somewhat ironic that Zuckerberg should be the poster for an appropriate level of criticality setting from the early days of Facebook, because by the testimony of John Carmack, it sounds like they've since totally lost the plot with VR. A domain that's almost as void of criticality as a game of Doom. But it illustrates how just because you had it right once won't mean you keep it so. Especially as you grow. It takes effort to keep gauging the right criticality, and it only becomes harder once you've lost a few crucial hands in your career.
Maybe that's why there's a specific charm about young entrepreneurs. Free of scars from past losses, they can push in a way that grizzled veterans might not. This often gets turned into a caricature for derision, like Tech Bros. But the world needs a mix. We need youngsters blessed with the bliss of ignorance to push the envelope where the stakes are lower. And then some old-timers weathered by wisdom to pull the envelope when the stakes tip large.
Regardless of what the mix looks like at your company, you ought to think about what is actually critical, and where you can get away with running with scissors. Speed of execution is one of the most important organizational features in most areas of competition. Something that's doable in a week might be a great investment, but if you spend six doing the same thing, with excess care, you're wasting your time.
The natural tendency is to start slowing down, too. We used to release a new product every year at 37signals. But then suddenly there was a huge business, orders of magnitude more customers, and a perceived general increase in criticality. Some of that real, some of it imagined. Trick is to tell the difference.
But if you must err, I contend that most companies, even us – two decades in and hundreds of millions in revenue later – are closer to Zuckerberg's sweet spot of moving fast and breaking things than we are to the rocket surgery.
Take the bet.
If your work can directly kill people, think guided missiles or pacemakers, you damn well better put all your emphasis on safety. Speed of execution is a distance priority at this ultimate level of criticality.
If your work can result directly in the loss of millions or billions of dollars, you also better approach it with an unusually high level of care. And yet, it's clearly still nowhere near as bad as dealing with the direct loss of human life, if you get it wrong.
The criticality ladder keeps going down from there. Loss of important data. Loss of critical access to data. Loss of replicated data. Imposed inconvenience.
And that's when it starts getting interesting. Once you're far enough down the ladder that it isn't obvious which step you're on, and how much care is appropriate.
I'm no fan of Zuckerberg in general, but I think he got it right by making "move fast and break things" the development slogan in the early days of Facebook. A nascent social network is exactly where understanding what's critical (very few things) and what's not (most things) is crucial. A startup struggling to find market fit in that domain should indeed favor pace over prudence.
You can argue at what point that slogan should have been retired, once Facebook was no longer a startup. But that's separate from the fact that this is fundamentally a good posture of almost any early startup – when the key criticality to worry about is going out of business.
At more mundane levels of importance, we deal with this question at our company every day. We're constantly, implicitly or explicitly, deciding how much care to take when engaging with the issues. Not in the sense that we can get away with doing a shoddy job, because that rarely if ever works. The price you pay for making a mess is an instant surcharge on both quality and productivity. But in the sense that there's a wide spectrum from mess to good enough to worthy of running a human heart.
And this is where organizational expectations come in. Zuckerberg set those clearly: It's OK if some things break, as long as we're moving forward, we can fix them. I have a lot of sympathy for that approach, especially in the beginning.
In the early days of Basecamp, we explicitly chose to involve our initial customers as part of the Q&A process. We'd put out something pretty good, but then let our customers tell us where the edge cases were, because there weren't that many customers, and the edge cases usually weren't of that high criticality.
These days we have a lot more rigor in the process, including actual Q&A personnel reviewing most new features and major fixes before they ship. Simply because shipping something obviously broken, and then hearing from 1,000 people in five minutes, who all need a human reply, would be a bad deal at our current scale.
And yet still we have to make the determination: Is this worthy of the bigger process? Our could we just ship it, and see what happens? Knowing when to accept the risk of the latter is part of how you prevent getting bogged down in process for things that just don't merit it.
And sometimes you'll get that wrong! Something that looked innocuous will be consequential, and you have to clean it up. That's the nature of the criticality bet. You need to have the stomach to keep playing, even if you occasionally lose a hand. You're playing anyway unless you're doing the crazy multiple-teams-doing-adversarial-solutions stuff that I've heard of in pacemaker development. So don't sweat it, calibrate it!
That calibration comes best from the top, though. If executive wrath bears down upon you after any little mistake, you'll naturally just stop taking the appropriate risk, lest you tempt a small chance of getting chewed out. Organizations that work like this in the face of criticality that does not warrant it become lethargic.
It's perhaps somewhat ironic that Zuckerberg should be the poster for an appropriate level of criticality setting from the early days of Facebook, because by the testimony of John Carmack, it sounds like they've since totally lost the plot with VR. A domain that's almost as void of criticality as a game of Doom. But it illustrates how just because you had it right once won't mean you keep it so. Especially as you grow. It takes effort to keep gauging the right criticality, and it only becomes harder once you've lost a few crucial hands in your career.
Maybe that's why there's a specific charm about young entrepreneurs. Free of scars from past losses, they can push in a way that grizzled veterans might not. This often gets turned into a caricature for derision, like Tech Bros. But the world needs a mix. We need youngsters blessed with the bliss of ignorance to push the envelope where the stakes are lower. And then some old-timers weathered by wisdom to pull the envelope when the stakes tip large.
Regardless of what the mix looks like at your company, you ought to think about what is actually critical, and where you can get away with running with scissors. Speed of execution is one of the most important organizational features in most areas of competition. Something that's doable in a week might be a great investment, but if you spend six doing the same thing, with excess care, you're wasting your time.
The natural tendency is to start slowing down, too. We used to release a new product every year at 37signals. But then suddenly there was a huge business, orders of magnitude more customers, and a perceived general increase in criticality. Some of that real, some of it imagined. Trick is to tell the difference.
But if you must err, I contend that most companies, even us – two decades in and hundreds of millions in revenue later – are closer to Zuckerberg's sweet spot of moving fast and breaking things than we are to the rocket surgery.
Take the bet.