I’m not sure how it happened, but out of the many conferences in which I’ve spoken, I’ve only submitted two talk proposals. Both were to O’Reilly’s OSCON. One was in 2003. It was not accepted. Too bad; It would have been really good. The next was in 2004. It was accepted. It wasn’t all that great.

Every other time, I’ve been asked to speak–usually to give a keynote.

So before my first keynote speech, I had only delivered one conference talk. And I didn’t think it wasn’t any good (sorry OSCON 2004!). When the organizers of this conference contacted me, I responded and said the following, “I’d love to do this and I’m thrilled to be asked. Just to avoid embarrassment, though, are you sure you didn’t mean to email Martin Fowler?” Apparently they had a nice laugh and then responded saying they really meant me.

My next feeling was not relief. It was terror. It was a great honor to be asked to keynote at anything. But, why me? What would I speak about? What the hell is a keynote anyway?

As I did with many new challenges back then, I turned to my friend Dave Thomas. “Dave, they asked me to keynote and they didn’t mean Martin. What do I do?!” Dave was kind enough to give me the single most useful piece of advice I’ve ever gotten as a keynote speaker.

He said something like “Keynotes are after-dinner entertainment. Don’t try to teach them. Just keep them entertained and leave them with something to think about.”

So I did that and I think it went well. In fact, at this particular conference, one of the other keynote speakers got snowed in at home in Chicago and couldn’t make it. So for my first keynote appearance, I actually gave two. One planned and one that I wrote while at the conference. Pretty good practice!

Since then I’ve done enough of them in enough different circumstances (conference types, countries, with and without live translation, remotely via video, etc.) that I’ve had the chance to fail and succeed in a number of different ways. Occasionally, a friend or colleague encountering their first keynote calls or writes and says “Chad, they asked me to keynote. What do I do?!”

Here are some answers:

• Dave was absolutely right. Entertain and provoke thought.
• Do not introduce yourself. If you’re a keynote speaker, they probably already know who you are anyway. If they don’t, they won’t care while you introduce yourself.
• Tell a personal story. Among other reasons, it will loosen you up and allow you to communicate better with your audience. A personal story is easier to deliver unrobotically than the programemd content you might be crafting. So use it to connect with the audience and to motivate the message of your talk.
• Be vulnerable. Subtley admitting that you’re imperfect and not completely certain about everything puts you in the right frame of mind to engage with the people listening to you and to avoid the trap of trying to appear to be right about everything.
• Don’t try to prove yourself. You’ve already been asked to keynote. If you get insecure and spend time proving why you’re the right person to be speaking on your topic it will sound like you’re arrogant, which you probably aren’t.
• Converse with the audience. I personally look into the eyes of the people listening to me in exactly the same way I would if I were having a conversation over coffee. I go on a tangent and I can see that they’re bored so I change my approach. They might not be directly speaking to you, but they communicate with their reactions, and letting the communication happen in two directions is extremely important for both you and the listener.
• Say significantly less than you think you need to. Don’t fall into the trap of trying to cram in as much as you can. Kent says this better than I will:
• Read and apply Kent Beck’s three focusing questions
• Create a story arc and apply a little drama if you can. There are many devices you can use for this. Watch your favorite speakers, and see how they use foreshadowing, repetition, rhythm, etc. Dave Thomas is amazingly gifted at this. Find some of his keynotes and watch for how he does it.
• Express your opinions unapologetically. You’re a human–not an information dispenser. People can look up facts on the internet. They’re at the conference to listen to your perspective on things.
• Leave your audience with something to wonder about. Unanswered questions are OK in a keynote.

I’m not the greatest keynote speaker to have ever lived, but I try to do them well and constantly aspire to be better. As with everything I write or speak about, I hope these tips are meaningfully helpful to at least one person.

I am one of the original organizers of both RubyConf and RailsConf. Combined, I’ve organized or been on the program committee for around 25 conferences. I’ve read hundreds of proposals and seen hundreds of conference talks.

Occasionally, a proposal or a talk stands out. Here’s one that I still think of when new would-be speakers ask how to get their first talk accepted. When preparing for RailsConf 2010 in Baltimore, we received this email from Ben Orenstein:

Ben had never spoken at a conference before, and he knew we had a lot of proposals to consider. Here’s what I like about his email (and video):

• Most important, he showed us how enthustiastic he to give the talk. Enthusiasm is one of the most sorely lacking features of technical conference talks. When someone is excited, I am more engaged.
• He reassured us that, though we might not have heard of him before, he was qualified to give the subject a good treatment.
• He told us he was going to be prepared when the conference rolled around. It’s rare that a conference presenter explicitly says “I am going to be ready”.
• He went to the trouble to make a video which showed us both what his style might be like in person and again that he really wanted this opportunity to speak.

I immediately looked up his proposal, and as you might guess it was as thoughtful and energetic as the email and video.

I then sent my conference co-chair, Ben Scofield, the following email:

And his response:

This is surely only one way to get a talk accepted, but as a new presenter, it’s a good example to consider.

(You can hear a conversation between me and Ben about this proposal and more at the Giant Robots Podcast.)

Here’s an exercise you can put into place right now which will have a lasting, significant, positive effect on your life and the lives of those you work, live, collaborate, and play with. There are two versions: an easy version and a harder version. Start with the easy version unless you’re the kind of person who has to do things the hard way.

The easy version

Whenever you have a cynical thought, keep it to yourself. Never utter, write, or otherwise convey it. Put it away. Think it to yourself all day if you have to, but never express it.

The harder version

Whenever you have a cynical thought, keep it to yourself. Analyze it. Scrutinize it. Prove it to be wrong. Discover the personal fear within you from which it grew, and make a plan to address that fear fully. Be thankful to the negative emotion for giving you the opportunity to understand your own weaknesses.

Cynicism is born of laziness and fear: It’s easy to complain about something. It’s harder to fix it. It’s both scary and liberating to trust other people to try to be their best.

Update

As @dhh pointed out on Twitter after I posted this, I worded this more absolutely than intended. I meant this to be an “exercise” (see the first sentence). Skepticism is healthy. Sometimes, cynicism is the right reaction. But, I believe most of us could use a lot less of it.

There’s a person I want to work with. I can’t find this person. I’ve literally searched the world, and I can hardly find a trace.

I’m not talking about someone specific. In fact, that’s the problem. I’m talking about a set of traits and an attitude which is more scarce than I realized until recently. I know a small handful of people who fit what I’m looking for, but they’re busy and unavailable right now.

I was talking to one of these people recently about my desire to, as I put it, “hire someone like you”, and we both realized how hard it is to name really anyone else who fits the description. Given this and the fact that there are so many bad job descriptions for developers in the world, I’m writing down what I’m looking for in hopes that this person (you?) is out there:

• Everyone knows that when you take on a task whether it’s huge and scary or tiny and boring, you’re going to see it through to the best of your ability.
• It’s obvious to everyone around you that you have fun with your work and with your co-workers.
• You care about how your work and attitude affects those around you. I mean really care. If you hurt someone, it hurts you. Everything you do runs through this filter.
• You understand that communication is the biggest responsibility of your job as a developer and the one you’re least likely to get right unless you focus on it.
• You focus on shipping software that matters to your users and that matters to the company you’re building it for.
• You’ve experimented with and survived many different types of development and project methodologies, which has left you with a healthy appreciation for what works from the so-called “agile” methodologies and those that came before (and after) them.
• You have no time for ceremony. Maybe you even hate it, but “hate” is too dogmatic a term.
• You are humble enough to bend to the will of the frameworks, technologies, constraints, and people you work with when doing so won’t have a materially negative impact. In other words, you can play by someone else’s rules when that’s the easiest and/or best thing to do.
• You make pragmatic (often boring) technology choices at work and you play in your free time. You don’t build science projects just because you are smart enough to build them.
• You are confident enough that you don’t have to prove to anyone what a great developer you are, and therefore…
• You don’t mind being the one that looks bad when you deserve it. You make mistakes sometimes, because you’re human, but rather than dwell on them you choose to fix and then learn from them.
• You love to teach and learn from your co-workers.
• You are confident with a number of programming languages, operating systems, and architectures. You probably have one of each you prefer right now, but you’re neither dogmatic nor myopic in your focus on it.

From my perspective, these are the things that matter.

I don’t care if you’re the smartest person I’ve ever met. I don’t care if you know everything about the technologies I’m deploying. I don’t want a “rock star”. I definitely don’t want a ninja. I don’t care if you write books, contribute to Open Source software, or speak at conferences. I do those things, and I know how little they predict how well I do my job.

If this describes you, I definitely want to know you. If you are interested in building scalable APIs and automated infrastructures for those APIs and would like to work with me in Berlin making beautiful productivity software, I definitely want to know you. Please get in touch.

I keep learning this lesson over and over again, so I’m writing it here in an effort to never forget again. As a manager, if some task constantly stresses me out or makes me feel uneasy, it’s probably because I’m doing someone else’s job.

I don’t mean someone’s being lazy and I’m picking up their slack. I’m talking about those nagging little annoying things you find yourself doing as infrequently as you can and do a half-assed job at every time. So you not only stress because they’re in the way of your real work but you stress because you suck at them.

Every time I allow myself to notice this feeling–every time I analyze what’s causing it, it’s because I should be delegating this work to someone else. Usually, in a mature organization, it’s even obvious who the work should go to.

The beautiful thing about being a manager of people is that your core job includes uncluttering your and everyone else’s work days by putting the work, moving tasks to a home where they can be lovingly completed.

As I mentioned recently, we’ve moved to Berlin!. We got to spend a week of down time exploring the city. We are definitely in love with Berlin so far!

I’m excited today to finally announce that I’ve joined 6Wunderkinder as CTO. In case you don’t know them by the company name, 6Wunderkinder are the creators of the extremely popular Wunderlist, which is a cross-platform, simple, and beautiful productivity application. I’m a user, and as I’ve told friends and family about my move, I’ve discovered that many of you are too.

As I’ve said previously,, I’ll miss my LivingSocial team and look forward to watching them from here in Berlin, but I’m extremely excited to get back to hands-on software development with the small, focused, team of brilliant product engineers here at 6Wunderkinder.

For those in the Berlin tech scene, if you happen to see me around at Sankt Oberholz, please do stop by and say hi :)

Thanks to Lynn Wallenstein, I have a new web site design. If you see problems with the layout, it’s almost definitely because I screwed something up after Lynn gave me the code. Sorry, Lynn. :(

I have also used this as a chance to move from my own server (which I’ve been screwing with for over a decade) to Octopress hosted on Github Pages. I’m glad to be done with that phase of my life.

Anyway, with Octopress I feel like I’m stepping back to the simple, productive environment I had ten years ago with Rublog.

It’s hard to believe it’s been almost two years since InfoEther was acquired by LivingSocial. Since then, we’ve built the strongest development team I’ve ever known. We’ve set records for e-commerce transaction volume. We’ve grown at an incredible pace, both as a business and as technology team. We’ve shipped a lot of software, and made millions of people’s lives more interesting in the process.  I’ve had the privilege to work with some of the most admired engineers in on industry. I’m proud of the team Aaron Batalion (from whom I’ve learned a ton about running a consumer internet product) had assembled before InfoEther arrived and of the team that ultimately grew from that foundation.

As I mentioned when I announced our Hungry Academy program, for me personally the experience at LivingSocial has been intense. As I said in that post, “These last 8 months at LivingSocial have been the best 4 years of my career.” That holds true today.

Playing the role of Senior Vice President of Technology and serving on the senior executive team at LivingSocial has been a rewarding learning experience.  I’m humbled by the talent and experience of every member of that team, and since my first day have been awed by Tim O’Shaughnessy’s business sense and natural leadership ability.  I look back on my career, and a handful of teachers and mentors stand out that have had a significant impact on me. Tim is now in that very short list.

All the while, though, I’ve known that I would eventually go back to a more hands-on role, personally building products and solving technical problems. I am, after all, a Passionate Programmer.

Kelly and I have also had  a goal to (before we get too old to fully enjoy it) live overseas again.  Our time in India, was a huge influence on both of us, both personally and professionally, and we’ve long since hoped to gain a similar experience in a different part of the world, specifically Europe.

So that’s what we’re going to do.  I’m taking a role as CTO of a technology startup in one of our favorite cities: Berlin.  I’ll be working hands-on to develop cross-platform software with a small, talented team of engineers, designers, and product managers. I’ll be transitioning from my role at LivingSocial for the remainder of January and will be relocated to Berlin and starting the new job in mid February.

As excited as I am to move to the next adventure, it’s always sad leaving a great company like LivingSocial.  I’ve made some friendships that will last forever, and I’ll miss the team immensely. I know, however, that they’re in good hands and that 2013 is going to be a fantastic year for the business. 

Early last year, I posted about how we’ve unfortunately turned the word “legacy” into a bad word in the software industry.

At Nordic Ruby and again at Aloha Ruby Conf this year I turned this idea into an exploratory presentation. I think it turned out pretty well and is an important topic. Watch it and let me know what you think!

When you create art, the purpose is self-expression.

When you create software, the purpose is rarely self-expression.

When you create software, someone somewhere wants it to perform a set of functions and has a stake in how well those functions are implemented. The definition of “well” is up to the stakeholder.

When you create art, you want it to be beautiful, or beautifully ugly, or ornate, or plain. You, the creator, are the stakeholder. You may hope that others find it beautiful, but if they don’t, it’s art—who’s to say what’s good and bad?

When you attempt to judge the quality of a commodity good solely in terms of its aesthetic appeal, you ignore the objective evaluation of how well that product meets the needs of its stakeholders.

When you attempt to judge the quality of a piece of art solely on some objective measure, you miss the point of the object as an expression of art.

Craft falls somewhere between commodity and art. Craft items have both subjective, aesthetic appeal and objective function.

This is a beautiful Christian Dior dress:

Beautiful but largely impractical. Try to wear this on the subway or even in your car. Try to fit it through a standard door. It’s a beautiful piece of art, but it fails as a useful article of clothing for most people.

This is a Paul Smith suit. It’s practical, extremely well made, creatively designed, and probably very expensive:

This is a pair of pants on sale at Wal-Mart:

Beautiful? I don’t know many people who would call this beautiful. Completely unremarkable.

And so it goes…from art to craft to commodity.

Now consider yourself as the customer here. My guess is that most of my readers, even with an appreciation of the quality of the Paul Smith suit, would be much more comfortable in the Wal-Mart pants.

When we create an item for another person, we have to consider whether that person is looking for art, craft, or commodity. We may wish to always be creating art. Or craft. But sometimes our customers want commodity. Not only is commodity cheaper but it’s what they prefer.