So Good They Can't Ignore You: Why Skills Trump Passion in the Quest for Work You Love

Job Went to India: 52 Ways to
Save Your Job.
3
The book was
written by Chad Fowler, a well-
known Ruby programmer who also
dabbles in career advice for
software developers. Featured
among Fowler’s fifty-two strategies
is the idea that the job seeker

---

should leverage the open-source
software movement. This
movement brings together
computer programmers who
volunteer their time to build
software that’s freely available and
modifiable. Fowler argued that this
community is well respected and
highly visible. If you want to make
a name for yourself in software
development—the type of name
that can help you secure
employment—focus your attention
on making quality contributions to
open-source projects. This is where
the people who matter look for

---

talent.
“At this point I basically just put
two and two together,” Giles told
me. “The synthesis of Purple Cow
and My Job Went to India is that
the best way to market yourself as a
programmer is to create remarkable
open-source software. So I did.”
Following Godin’s advice, Giles
came up with the idea for
Archaeopteryx, his AI-driven music
creator. “I don’t think there was
anybody else with my combined
background,” he said. “Plenty of
Ruby programmers love dance
music, but I don’t think any of

---

them has sacrificed the same
ridiculous number of hours to
tweaking breakbeats and synth
patches over and over again,
releasing white-label records that
never made a dime, and studying
music theory.” In other words,
Giles’s ability to produce a Ruby
program that produced real music
was unique: If he could pull it off,
it would be a purple cow.
Drawing from Fowler’s advice,
Giles then decided that the open-
source community was the perfect
place to introduce this purple cow
to the world. In addition to

---

releasing the Archaeopteryx code as
open source, he took to the road to
spread the word. “I basically took
Chad Fowler’s advice way too far
and went to speak at almost every
user group and conference that I
could—at least fifteen in 2008,”
Giles recalled. This hybrid
Godin/Fowler strategy worked. “I
got offers from all over the place,”
Giles recalled. “I got to work with
stars in my industry, I got
approached to write a book on
Archaeopteryx, I could charge a lot
more money than I used to.” It was,
in other words, a strategy that made

---

his mission into a success.

---

The Law of Remarkability
Reflecting on Giles’s story, I kept
coming back to the same adjective:
“remarkable.” What Giles
discovered, I decided, is that a good
mission-driven project must be
remarkable in two different ways.
First, it should be remarkable in the
literal sense of compelling people to
remark about it. To understand this
trait, let’s first look at something
that lacks it. Before releasing
Archaeopteryx, Giles had worked
on another open-source project. He
collected popular command-line
tools for Ruby and combined them

---

into one package with consistent
documentation. If you asked a
Ruby programmer about this
project, he would tell you that this
is solid, quality, useful work. But
it’s not the type of achievement that
would compel this same Ruby
programmer to write his friends and
tell them, “You have to see this!”
In the words of Seth Godin, this
early project was a “brown cow.”
By contrast, teaching your computer
to write its own complex music is a
purple cow; it inspires people to
take notice and spread the word.
What’s nice about this first

---

notion of remarkability is that it can
be applied to any field. Take book
writing: If I published a book of
solid advice for helping recent
graduates transition to the job
market, you might find this a useful
contribution, but probably wouldn’t
find yourself whipping out your
iPhone and Tweeting its praises. On
the other hand, if I publish a book
that says “follow your passion” is
bad advice, (hopefully) this would
compel you to spread the word.
That is, the book you’re holding
was conceived from the very early
stages with the hope of being seen

---

as “remarkable.”
There’s also, however, a second
type of remarkability at play. Giles
didn’t just find a project that
compels remarks, but he also
spread the word about the project in
a venue that supports these
remarks. In his case, this venue was
the open-source software
community. As he learned from
Chad Fowler, there’s an established
infrastructure in this community for
noticing and spreading the word
about interesting projects. Without
this conduciveness to chatter, a
purple cow, though striking, may

---

never be seen. To be more
concrete, if Giles had instead
released Archaeopteryx as a closed-
source piece of commercial
software, perhaps trying to sell it
from a slick website or at music
conventions, it probably wouldn’t
have caught fire as it did.
Once again, this notion of
remarkability applies beyond just
Giles’s world of Ruby
programming. If we return to my
example of writing career-advice
books, I realized early on in my
process that blogging was a
remarkable venue for introducing

---

my ideas. Blogs are visible and the
infrastructure is in place for good
ideas to quickly spread, through,
for example, linking, Tweets, and
Facebook. Because of this
conduciveness to remarking, by the
time I pitched this book to
publishers, I not only had a large
audience who appreciated my views
on passion and skill, but the meme
had spread: Newspapers and major
websites around the world had
begun to quote my thoughts on the
topic, while the articles had been
cited online and Tweeted thousands
of times. If I had instead decided to

---

confine my ideas to paid speaking
gigs, for example, my mission to
change the way we think about
careers would have likely stagnated
—the venue would not have been
sufficiently remarkable.
To help organize our thinking,
I’ll summarize these ideas in a
succinct law: