Be the Expert on Your Own Experience

There are dozens of tech conferences happening this year, and I’d like to encourage you to submit talks and proposals. Some of my colleagues have told me that they are disinclined to submit proposals because they feel like they lack expertise. This all-too-common feeling prevents people from sharing interesting and fresh perspectives at events, and I’d like that to change.

When I first began submitting proposals to conferences, I carefully crafted one very specific talk proposal. It took me about a week. I then proceeded to rewrite the same proposal over and over again as I applied to (and got rejected by) various conferences. In mid-2012, I applied to Cascadia Ruby, and for the first time ever I submitted more than one proposal. Maybe you could even call it “rage-proposing:” Here’s a proposal, here’s another proposal, how about this other random topic? Take that!

I showed my proposals (current and past) to my co-workers and the responses were all the same. I was told that they were “too vague”, “too broad”, and “unfocused”. I was told that it seemed like I was trying to cover too much stuff in a single talk.

I appreciated the honest feedback, but it was frustrating because I had worked so hard on them. And If I took the extra time narrow my proposal down to exactly what I would talk then the inevitable rejection that followed would be even worse.

So I said to myself: “I’m gonna write a proposal on something they know nothing about: surfing!”

So it came to pass that the first talk I ever gave at a tech conference had absolutely no technical content (except for a slide where I made a poor comparison between being a beginner surfer “kook” to writing a really disgusting method body).

So–what is the lesson here?

Talk about your experiences. Don’t try to reverse-engineer a talk based on what you expect people to be interested in. Propose a talk that speaks to your passions.

I felt pretty fortunate at Cascadia because I was certain I’d be the expert on surfing compared to a room full of programmers. However, I haven’t had the same luxury at subsequent talks.

Which brings me to the next lesson:

Instead of being the expert on a topic, be the expert on your own experience. That’s it. Who isn’t the expert on his or her own experience? (People with amnesia, maybe). And that’s what I’ll be doing in a few weeks when I speak at Ancient City Ruby about “How to Fail at Background Jobs”. Yep, I’ve experienced a lot of fails. To the rest of you reading this, I foolishly promise to provide feedback on your rejections to whatever extent I come in contact with your proposals as a tiny cog helping with Engine Yard’s upcoming conference, Distill.

In conclusion, prepare lots of talk proposals, submit them everywhere. Especially to Distill!

As an aside, I’d like to thank Michał Taszycki of Railsberry conference for his e-mail to me explaining why all FIVE of my talk proposals were rejected. Railsberry was the only conference ever to do this, each of those one-sentence explanations really went a long way in helping me improve future proposals.

Distill is a conference to explore the development of inspired applications. The call for papers is now open and tickets go on sale in April.