

Built to Fail: What Google, Ideo, and 37signals have in common - andrew_null
http://andrewchenblog.com/2009/07/13/built-to-fail-how-companies-like-google-ideo-and-37signals-build-failure-tolerant-systems-for-anything/

======
sriramk
The standout there is Apple. Apple builds great products, doesn't do focus
groups. They probably do multiple iterations but without large betas, the
audience of those iterations is probably very limited.

Their releases are not cheap - once you announce a new iPhone, you cannot
change the hardware before release so you really need to get it right. The
soonest you can update it is a year or so.

Most of all,Apple is the canonical example of the 'great man theory'. Apple
has several of them - Jobs, Ive and several others whose names generally don't
get publicity.

Now, this is not to say the original posts points aren't valid - most people
don't have the talent or expertise that Apple do. But I just couldn't resist
throwing in the obvious counter-example.

~~~
marcusbooster
Doesn't do focus groups on products designed and designed again from the
bottom to the top?

They even say so in their jobs faq: _Apple hires quality assurance engineers
for internal product testing...We also create focus groups to provide feedback
on our products._

<http://www.apple.com/jobs/us/pro/inside/questions.html>

~~~
sriramk
I'm going by Ive's interview plus off-hand comments I've heard from ex-Apple
employees

[http://apple20.blogs.fortune.cnn.com/2009/07/01/a-fireside-c...](http://apple20.blogs.fortune.cnn.com/2009/07/01/a-fireside-
chat-with-apples-jonathan-ive/)

~~~
jmtulloss
When you have 10,000 employees (or however many they have now), it's very
possible to do focus groups and usability testing completely internally. A
startup with 3 guys, not nearly as easy.

~~~
DannoHung
Hmm.. maybe, expert focus groups for a non-expert product. That's actually
sort of interesting.

~~~
DrJokepu
Surely Apple must have shazillions af accountants, lawyers, logistics
professionals, etc., that is people who are neither technology nor marketing
experts.

------
joez
There is a difference between planning to fail and failure-tolerant.

People and companies still need to have long term vision of what to do "in
case" your product is actually good, your startup actually gets funded, and of
success in general. This turns you into a proactive player.

If all one does is have a system in place that reacts when something goes
wrong, then this is really being reactive.

I believe Andrew is missing the bigger picture.

------
russell
The unanswered questions at the end are interesting.

"This area of thinking started out with the hiring process, and the idea that
maybe interviews don’t work at all – there’s a bunch of academic research that
implies that, actually. So if how would you build a failure-tolerant system
around the hiring process, if you assume that good interview candidates
actually have no correlation to successful employees?"

I have been partial to contract to hire. You still have to do interviews, but
you have a fallback position.

~~~
aditya
The problem with contract to hire is that it sounds great (atleast on paper),
for the company but for the employee - most people interviewing take it to
mean that the company wasn't super impressed with their interview and wants to
test them out, and they could get kicked out at any time.

Think about interviewing for a job (not from an entrepreneurial mindset) -
what you're looking for is the safety and security of a job and what the
company is giving you is a contract position that can be terminated at any
time without severance or notice.

It is a great idea but there is stigma (possibly unsubstantiated) associated
with it.

~~~
lief79
There is a strong risk of losing out to anyone offering full time employment.
In practice, the full time employment doesn't have much more of a guarantee
with it.

This is especially true for computer programming and Business Analysts. The
normal 3 month span will show you a minimum of competence, but it doesn't show
anyone's final working level. The exceptional individuals will still stand
out, but most companies don't have that kind of draw or the salaries to focus
on them.

------
lil_cain
This reads like a text book architecture astronaut...

------
rimantas
Where all these companies just put there for their names? Article just doesn't
make sense. There is the talk by Jason from 37signals, where he specifically
talks how he does not get this obsession with failing:
[http://www.37signals.com/svn/posts/1798-jasons-talk-at-
big-o...](http://www.37signals.com/svn/posts/1798-jasons-talk-at-big-
omaha-2009)

~~~
ahoyhere
I have to agree, seems like a HN-tailored puff piece.

------
gits_tokyo
Speaking of failure, my mantra on a personal entrepreneurial level has always
been "build to fail" seriously. 0 risk = 0 reward. Don't have the guts to
fail, and fail terribly... stick to a 9-5.

Be ruthless, and whatever you do, make sure it passes the deer-stuck-in-the-
headlights-of-an-oncoming-car test. If it doesn't stir emotions to spread
life, stick it out until you get that polished diamond in the ruff.

iPhone wasn't an overnight success, there's no such thing. Plan accordingly.

\---

And there's one thing missing from that comic strip. "I see... well laugh as
you may. Eventually I'll be laughing all the way to the bank."

------
gchucky
But these are three companies that are doing well enough that they can afford
to take on failures. So something doesn't work at Google; the company's got
enough revenue that they can absorb the failure without a huge problem. If
you're running a small startup and it doesn't work, taking a hit is a lot more
costly.

------
udekaf
I think the author is confused with three different concepts: fault tolerant
system, idea generation and agile development.

A system being fault tolerant, like googke, just means that it can
rollforward/rollback when an error occurs. It is nothing more than a technical
concept.

People in design industry often use brainstorming to generate and screen
ideas. IDEO is just one of them. Brainstorming is not an explaination of
either how they succeed or why they succeed.

And the framework Ruby on Rails characterizing convention over configuration
and don't repeat yourself even has nothing to do with "failure-tolerance",
thought it emphasizes fast iteration in development.

The over generalization in the article make its conclusion very unconvincing.

------
jimmyjazz14
"Of course, every web project requires lots of lines of code which can easily
break at any moment" wtf?

