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 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
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.