⇥ The master conference (evil) plan
For the past four years, I have put a lot of work into executing a strategic plan that is tangentially connected with our conferences.
You see, when we started organizing conferences I noticed that there was a small core group of people—normally speakers—that tended to stick together all the time. They knew each other from the mailing lists, and conferences were a great opportunity to meet and catch up.
As a business person, this used to irk me considerably. One of the major goals of a conference should be, in my opinion, fostering the exchange of ideas, and what better people to exchange ideas with than the very experts you have come to listen to for advice?
Clearly, this particular aspect of our events needed work, but as a person I could hardly fault the speakers for wanting to sit down and have a drink with friends they only got to see once or twice a year, rather than with strangers they had no contact with.
I could have done the pointy-haired thing and come up with some stupid requirement—like, say, request that the speakers make themselves available for in-person interaction with the attendees at designated times, but we run a PHP conference, not Disneyland, and people don’t come to line up and shake Mickey’s gloved hand. Similarly, I could have tried to be sneaky about it and somehow trick the speakers into sticking around and interacting with the attendees, but, let’s face it, most of the speakers are smarter than I am anyway, and would have seen the ruse coming from a mile away.
Instead, I decided to try and slowly steer things in a direction that would have made our conferences closer to a family reunion than a dry business meetup.
It all started with a lot of community participation. You don’t see it much, perhaps, because I don’t go around parading donations and contributions like some others do, but php|architect is deeply involved in a lot of community activities. We support, directly or indirectly, a lot of different PHP-related causes, and we receive handsome dividends from it in the form of goodwill. Besides, all the principals of MTA are well known and easily accessible—Sean, Paul and I spend (far too) much time sticking around IRC, and all of us are readily reachable by e-mail (unless, that is, we happen to go delete-happy and your message gets lost in the daily antemeridian spam-purging ritual), or phone. Arbi doesn’t stick around IRC all that much (after all, someone has to get some work done), but we talk about him often enough that everybody knows him anyway.
The second step in my strategy was to create the right atmosphere at our conferences—I was going for a particular motif, somewhere in between friendship and professional relationship, that would make people want to interconnect and exchange ideas. There many small touches at our conferences that cater to this need. For example, there is no “speaker room” at our events—some people I’ve talked to seem to think that we do this to save money, but that is not the case (we hardly ever pay rental for meeting space anyway). The real reason is that there is no need for one—if you want privacy, you’re free to go back to your room. By the same token, all of us php|architect folks participate in the conference management process. If you come to one of our conferences, there’s a 50% chance that I will be the one printing out your pass and handing you your attendee bag. When was the last time you saw [insert CEO of Company X here] handing out passes at [insert name of Company X event here]?
(As a side note, this doesn’t stop people from being blissfully unaware of who I am. I always find it amusing when someone stops me in the corridors and asks me who I work for. When I reply “php|architect,” they usually say something along the lines of “Really? And what do you do for them?”—to which I invariably answer “oh, you know, a little bit of this, a little bit of that”).
The third step in my evil scheme has been to carefully attempt to involve the community itself in the presentation business at our conferences. While the process of choosing speakers remains closely-guarded, the very nature of the speaker roster has perceptibly shifted throughout the years, aided in part by the changing nature of PHP development itself. In fact, many of our speakers started out as conference attendees, came to a conference, probably told themselves, “I can do that” and decided to submit at the next CfP.
The last step is to actually lead by example and involve others through our own willingness to interact. When my colleagues decided to punish me for skipping last fall’s conference in Atlanta by allowing the audience to closed-caption my remote-link keynote without telling me first, I didn’t get mad—I got even by making them dress up as KISS and open up our evening event this year (in fact, I had little work to do, as the KISS costume idea was Paul’s. I just happened to notice a little too late that my costume didn’t fit). Once you are willing to don make up and taking the stage for a round of Rockband, it’s difficult for anyone else to feel intimidated and not want to participate.
It took me nearly four years, but php|tek came as closer as ever to my goal. Ben Ramsey summed it up in a beautiful post—and he got one all-important thing right: we couldn’t have it done it without the community continued evolution and support. After all, we’re just along for the ride—if we happen to be in the right place at the right time (and with the right tools at our disposal), I hope everyone has as much fun as I did last week.