Corey Haines on growing and harvesting an audience

This post is part of our Customer Interviews series. Every now and then, I dig deep into the confines of our database to find the most interesting projects, products and companies built on top of DNSimple by our customers.

This week, I got in touch with Corey Haines, a long term customer of DNSimple and friend of Anthony. Most of you may know him from CodeRetreat – and from his exquisite fashion sense. I've got to admit, interviewing Corey was somewhat of a daunting task. Heck, the man has been involved with so many cool things that I couldn't possibly cover them all in this post. So I dug in a bit and was intrigued by his ability to grow an audience and earn a living from it. From talks, workshops, and even a book – here's Corey Haines' playbook to harvest your audience.

You're the kind of person to skip veggies and head straight to desert? Head down for some words of wisdom from a sharp-dressed-developer-speaker-writer-globetrotter.

Timeout

It all began circa 2009 when Corey called a timeout on his life and took a full year sabbatical to travel the world while meeting developers and giving talks at conferences. Throughout his journey across the programming world he noticed a recurring habit:

Developers tend to spend more time learning than doing – especially the fundamentals.

That thought kept spinning for while until later that year – while backstage at Codemash with Gary Bernhardt, Patrick Welsh and Nayan Hajratwala – the idea spawned to create a day-long event that would focus on practicing the fundamentals of software development.

Soon after, Coderetreat became a reality and a community was born. In the early days, Corey would run it in the US while Alex Bolboaca and Maria Diaconu would run it in Romania.

The shepherd

With a good initial traction and a ton of developers in tow, he felt the need to adopt a proper liberal governance. Instead of becoming the community's chief, he would become it's shepherd and offer guidance but would not dictate nor enforce his will.

Giving more freedom to the community allowed it to grow freely with more and more developers asking permission to run their own coderetreats.

Anybody could do one. Even first timers were doing it right.

They published the format and let the people do the rest.

In other words, he made himself replaceable and built a truly open community.

Give some, take some

After giving his fair share to the movement, the time came where it felt right to 'take some'. After all, he invested so much into it – he often had to cover himself the airfare and other expenses to do workshops.

He saw the opportunity for corporate workshops where he would run a coderetreat within a company.

The timing was right given his own and the movement's growing notoriety but would companies pay for something that is usually free? Moreover, could he monetize coderetreat without jeopardizing his ethics?

Unsure of how things would pan out, he gave it a shot and showed up in the lobby of a popular conference with a bulletproof plan: tweet out his offer and hope for a reply.

Out of the blue, a developer from MotleyFool responded, and just like that he began doing corporate workshops.

To protect the integrity of the movement and to address the question of ethics, he drew a line in the sand:

If it's a public workshop, I don't take money and if I can, everybody can.

He managed to turn it into a primary source of income for the next two years. But all good things must come to an end.

Let it be

In 2013, with the stoicism of Marcus Aurelius, Corey parted ways with coderetreat.

I came to a point where the community would be better off without me.

He was leaving a well oiled machine. Because he had made himself replaceable from the beginning by adopting a shepherd's attitude, there were other leaders ready to take on the challenge. Unlike many founders, he could leave without making a ripple.

He left it in good hands with Adrian, Eric Talboom and Jim Hurne (among others) who have really stepped up into leadership roles and kept the community growing.

40 hours of flight and a book

Everybody wants to have written a book but nobody wants to write a book

Himself included. However, a book from Corey Haines was inevitable:

1. He has a field of expertise.
2. He has been teaching it for years at workshops and conferences.
3. Which allowed him to grow a large audience (of potential readers).

But he did not want to write a book. He had seen friends go down that treacherous path and didn't want to follow suit.

Everything changed when he hopped on a plane to India to give a talk on the 4 rules of simple design at Agile Conference. Turns out 40 hours of flight to go back and forth is plenty to change your mind!

He'd spent the trip to India writing the script for his talk and the trip back to refine it and expand upon the examples. By the time he got back, he had the blueprint of the book.

I think I am actually writing this book!

A friend offered to do the editing and both of them kept tweaking on it until it was ready to launch.

In all, The 4 Rules of Simple Design did well reaching thousands of readers.

Bonus 10 Lessons learned from a writer who didn't want to write a book

Interviewing Corey felt more like a chat with a great mentor than a regular Q&A interview. He kept dropping knowledge bombs that couldn't go unnoticed. Here they are:

1. Make it e-book only. That way you'll avoid the costs and headaches of dealing with an inventory.
2. It doesn't need to be a brick: keep it short (< 100 pages).
3. To keep it short: limit the introductory content. Don't fill the book with… filler. ( Link to outside articles instead)
4. You don't need to be a domain expert to write a book. You'll become one by writing it.
5. You'll know it's time to start writing a book when you know the content.
6. When it comes to self-promotion: "Don't be creepy but don't be embarrassed".
7. Try to help people, it comes around, people will help you back. That's how he got an editor and plenty of free promo
8. Don't release any information about your book until you're to publish it.
9. Make it timeless and avoid the need for constant updates and maintenance.

moar Bonus For developers

1. When building your app: keep it as vanilla as possible. No neat stuff. Remember that "you have a business to run".
2. When building a company: Make sure the app has what it needs and that customers gets value. You can do the fun stuff on 'off' hours.
3. When dressing up: The stereotype that developers can't have fashion sense is bullshit! As one of the first developers to lay down code on Trunk Club, it's safe to say that Corey might have been drinking his own Koolaid™.

Share on Twitter and Facebook

Antoine Meunier

cruising through #vanlife in a '72 VW bus.