Slashdot Mirror
At X, Failure Is Not an Option: It's a Feature (Astro Teller's 2016 TED Talk) (backchannel.com)
New submitter Evan Hansen writes: Everyone likes to pays lip service to "fail fast," but when was the last time your boss gave you a bonus when your project was killed? In his 2016 TED Talk, concluded just moments ago, Astro Teller, the head of Alphabet's X R&D lab shares some never-before revealed stories of his team's failures and iterations, and explains how "fail fast" can be more than a trite cliche. The first X project was the self-driving car, and subsequent ones include Google Glass, Project Loon's Internet service via balloon, Makani energy kites, and a drone delivery service dubbed Project Wing.
The inventor of Google Glass either left Google or was asked to leave. But, in either case, I don't see how that fits this narrative.
#DeleteChrome
I'm fairly sure your friend's project wasn't a fail-fast investigation, but rather a sure thing development.
I think the best line in the talk was "shifting perspective is more powerful than being smart, if you're coming at an established problem from an established approach, you're competing with all the other smart people who came before you, and that's a terrible place to be competitively." So, what do they do? They try unusual approaches, they fail, they try again, they fail better next time, and most importantly: they identify when they fail to free up resources to try something else.
Yes, it's a deep pockets approach, a lot like Vulture Capital investing, but without the traditional conservative threats of hellfire and damnation when you fail - as most people do most of the time in this type of R&D. VCs praise serial success stories, just like Wall Street glorifies analysts who have gotten it right the past 3 consecutive years... most of these people fail to realize that luck plays into success more than skill - not that you don't need skill to succeed, but simply that luck is a better component.
In an organization like X, they'll have other methods to identify and reward skill besides successful productization of lunatic ideas. As they stressed in the article, identifying objective evidence of failure early in an approach is a valuable skill.
The problem with firing everyone that makes a mistake is that you create a culture that just goes with IBM/Microsoft/contractor because you can just shift the blame. You spend insane amounts of money without actually innovating or doing anything that progresses your company. In the end your company goes bust because it can't compete with entities that are more agile and are innovators in their market.
Custom electronics and digital signage for your business: www.evcircuits.com
The fastest failure, is when you don't even start. And no, you're not getting a bonus for that either.
Don't waste your vote! Vote for whoever you want, unless you live in a swing state it won't matter anyways
I think part of the OP's frustration is that when you have nearly unlimited funds to pursue concepts it can be hard to differentiate between the inertia of a successful idea and the mileage you're getting just by pouring funds into something.
I'd be more interested in hearing a TED talk from a scrappy team that was successful with self or minimal funding. The information would certainly be applicable to a larger subset of teams.
This depends on the nature of the project. If you're doing yet another ERP system integration, yes, you should succeed, and there should be negative consequences if you don't, because there is nothing new involved, just lots and lots of detail-oriented grunt work. It's hard, but good planning and careful attention to detail will get you to the end of the job, and if it doesn't, it's because you did a poor job, not because the job was not doable.
Who's the "you" in this? Any computer system project that is sufficiently embedded in business process has failure modes so far outside the reach of anyone on the technical side that blaming technical people for it is incredibly myopic. They often end up failing even when the technology works right.
And almost all of this is beyond the reach any single individual who's not a senior manager and then there are still conceptual problems with where blame ought to be assigned. And once you get into "you" as a team/group, often with differentiated roles and responsibilities, where failure modes can vary widely.
I work for a small IT consultancy and I work on projects where all kinds of problems crop up. Most don't cause the project to "fail" (even when they go badly, I think there are various organizational and individual reasons for resisting declaring failure) but even when I'm the sole implementer of the project, there are failure reasons that go beyond me. Poor scoping. Client interference. Unrealistic timelines. Inadequate resources. The list is long and full of things I had no control over.