Both Adam Culp and Cal Evans had some slightly related thoughts about what is “wrong” with conference talks recently and how they intend to fix them.

For Adam, neither novices nor veterans are getting content sufficient to justify their attendance to the Big Mean Boss back home. He attributes this at least in part to “laziness” in preparing talks without sufficient preparation and hard technical code examples. Cal similarly self-diagnoses simply submitting to be accepted rather than submitting to speak to his passions.

If both were simply going to change how they pitched talks and encourage others to do the same, starting a conversation about why veteran speakers speak and what the focus of talks should be, I’d be all for it. Unfortunately both of them threw in their positions as conference organizers into the mix, including specific vows.

From Cal:

I am privileged enough to be asked to help score talks for several of different PHP conferences. in 2015, I will start be a lot more picky in the talks for which I vote. I will look for – and up vote – talks where the presenter makes a note that they have given this talk at a local event already.

Adam’s resolutions include:

Be tougher when rating talks I attend at conferences. I should walk out of a talk feeling like I truly learned something.

I attend at conferences. I should walk out of a talk feeling like I truly learned something. Be more critical when selecting talks to be presented at conferences. I owe it to the attendees, and to the conference organizers to ensure the best talks are chosen.

to be presented at conferences. I owe it to the attendees, and to the conference organizers to ensure the best talks are chosen. Ask to see slides and code for talks in advance if available, and at a minimum set a deadline of when these should be ready if the talk is selected. To ensure the talk lives up to the abstract.

There are a few problems I see in these proposals that warrant further discussion.

Both proposals suffer from something similar to Keynes’s (alleged) Paradox of Thrift: this is fine if a few speakers tailor their talks to these criteria, but if most or even many speakers do so, it could cause problems.

Take Cal’s proposal that talks should only be accepted if they have been previously given at a local venue. In North America alone, there are now several PHP conferences. There are many more web conferences that can include PHP talks or other talks that might appear at a PHP conference (Jenkins, Ansible, Selenium, etc.). Even if there’s heavy overlap in speakers and talks, that means something like 60-70 talks will need to be previewed at user group meetings. And that’s just assuming that pretty much everybody who submits is accepted. Recent ratios seem to be more like 5 or 6 speakers submitting for every 1 selected. So that means 300 to 420 (heh) talks that have to be given at local venues. That fills up every monthly meeting of 35 user groups.

But Cal goes further: he pledges to speak at 5 local user group meetings this year. Assuming every speaker makes the same pledge, just 40 speakers would fill every monthly meeting for 16 user groups. There are roughly 60 PHP user groups in the US and Canada. Assuming each one meets every month without fail (they don’t, not by a long shot), that means there’s room for 144 speakers who speak at 5 user group meetings each in the US and Canada. Reality is likely a lot lower, and that’s assuming local groups don’t insist on local talent that’s not going on to speak at conferences, or have panels, lightning talks, or genius bars.

That’s not web scale.

Adam’s proposal increases the PITA quotient for creating new talks considerably. Simple microeconomics tells us that if you raise the cost of something while keeping the price constant (e.g., the number of 2 nights and a flights available for each talk), you’ll get fewer. It also means you’ll get fewer new speakers willing to risk creation of new content just to have the possibility of being selected. Existing speakers will pare theirs down to what Adam says he does: a couple of talks that they submit to every conference.

That means attending one conference a year is all you’ll likely ever need to do, let alone be able to do. You’ll have the same exact experience with the same exact set of speakers you’ll see at every other conference. Furthermore, there will be no need to go back next year. Once every three or four years will be enough to get any new talks created by that same set of speakers or the handful that manage to break in. The hallway track, far from being a secondary benefit as Adam sees it, will become the only thing a repeat attendee values.

This will hurt diversity. Not just identity-politics-laden diversity, but diversity of experience, thought, approach, and, if Adam were to have his way for even more code-centric, hands-on, immediate-takeaway talks, style of presentation. The same PHP people saying the same PHP things. Not to mention that impostor syndrome is hard enough to overcome without creating new barriers to entry just to be considered.

It’s also not accurate that everyone can get two or three talks accepted in many venues. There are dozens of variables that go into talk selection: conferences like people to give two talks because it cuts down on travel and hotel costs and keeps tickets more affordable. Just having two great talks isn’t enough, though. They must be great talks that meet the demand that’s out there. One year Puppet is all the rage, the next year Ansible. What if you have one talk that’s unique but your second talk is the umpteenth proposal on that topic? Another guy with a slightly less unique approach but a second talk that isn’t as common may fit better. I’ve had to watch many of my favorite talk submissions rejected because we just couldn’t work them into the schedule for sometimes arcane reasons.

Obviously, I’ve taken these issues to task by extending them to an extreme. But had both gentlemen not emphasized that they select or help select talks for multiple conferences and urged others to do the same, I’d applaud. Let a hundred flowers bloom, and all that. Sunshine PHP can become where you go for veteran speakers giving advanced, hands-on talks chock full of code samples. Another conference can have a mix, another lean more toward skills talks, another toward career development, etc.

I’d find Adam’s preferred talks kind of boring if I wasn’t interested in the given technology. I’m a sucker for soft talks. I love talks about the principles of OO design and honing software development as a craft. Thirty slides of 12-point code and watching someone type into the command line to do the same thing as another tool with slightly different (no doubt superior!) syntax put me to sleep. Sure, a good technical talk can have tons of code samples at a readable length and size as well as be entertaining with a smoothly-practiced WOW factor demo, but I’ve seen enough veteran speakers giving talks to know that even for well-honed and -practiced talks, the ideal is rarely met. Plus my ideal is not everybody else’s ideal (see what I said above re: having a diversity of opinions in rating talks at php[architect]). However, there are lots of other people like me.

One of the things I’ve learned as I’ve taken on the training curriculum here is that people don’t learn the same way. You encounter perfectly intelligent people who have to hear things said, others who learn by watching videos, others who need diagrams, others who need to type things out, and others who need to read dead-tree books. Too much homogeny across our conferences will leave a significant portion of people behind.

Furthermore, it’s not a surprise to me that developer advocates and evangelists are the ones behind these proposals. When you literally get paid to network with developers, put on demos, and get speaking engagements, you have lots of time to craft a just-so presentation with lots of hands-on application. But for those of us who move from client to client on old hosting solutions, or are frantically building out the next feature before the upcoming investor meeting, or simply value family time because we learned a long time ago that all work and no play leads to burnout and strife, doing all this on top of our existing commitments is just not realistic, or we’re forced to slowly develop a couple of talks we’ll be giving for the next five years. That violate’s Cal’s stricture to be passionate about what you present.

Finally, I’m not sure why either one says he will be more strict about selecting talks. Unless they are actually planning on reducing the number of speaking slots, they are going to be just as selective as they have been every other year. Their criteria may change slightly, but it’s not actually stricter. They’re just proposing criteria that put a larger burden on speakers. If fewer people submit to their conferences as a result, they’ll actually be less selective, as they’ll be forced to go with the talks they have, rather than the talks they want.

Now, the good

After all that slagging, I want to emphasize that they do identify some key things that speakers should heed as a matter of course: too many speakers do wrap things up five minutes before they start their presentation. Talks do evolve and benefit from feedback, which means in ideal cases giving them 3-4 times. However, the more experienced the speaker, the more a new talk can be exciting and valuable from the first time it’s given. In fact, I’ve noticed recently that veterans giving a brand new talk have been better than when they give that same old talk. Cal addresses this with his insistence that speakers talk on their passions, not just what will get them that next slot.

But if you’re just starting out? I’m pretty confident in my Regex talk, because I’ve given it a few times now. But I’m giving a brand-new talk that was accepted without me writing it first, and yes, I’m going to practice it at my local user group. I’ve also let other speakers trial run their talks.

I’ve also let lots and lots of people who’ve never given a talk before try their hand at it. And I’ve given entry to people who are accomplished speakers, but not in the PHP community.

Now my experience in conference organizing is different, since it’s exclusively for larger conferences (in breadth and length, if not always attendance). While it’s a huge effort to comb through 600+ submissions to fill 40 speaker slots, we’ve had a few people new to the PHP community hit the ball out of the park, as well as first-time talks from old PHP hands that blew people away.

If either Adam or Cal want to road-test new talks at DCPHP, they are more than welcome! There are still lots of people who come to user groups who never get to conferences. Well-rehearsed technical talks with great code samples and actionable content are great. All I want to ensure is that we don’t correct one set of deficiencies with another.