Tag Archives: work

Measuring conferences

In a normal year, I go to a lot of conferences. 10-14, typically. These events are, presumably, picked because they are in some way useful to my company, or my project.

That’s really hard to measure.

We kind of just know which events are good ones – a gut feeling – but we kind of stink at actual metrics.

One of my goals this year was to be more rigorous about measuring what benefits I got from a conference, so that my budget is spent as effectively as possible, in ways that actually produce long-term benefit. This then informs the events that we’ll do the following year.

Caveat: I am a community manager. As such I care about community metrics. Not sales. Not business cards. Not dollars or contracts. That makes these things that much trickier to track.

Here’s some of the things that I try to measure when I do a conference.

Meaningful Conversations. Most of the people that come to a conference booth are there to get the free stuff. But a precious small number are there to learn, to connect, to solve, to contribute. In past years I have kept a bit of an impression as to how many that was, as a fuzzy metric of whether a particular event was the right audience. This year, it was my goal to actually count, and keep that data from year to year.

New Community Members. This is hard, and, frankly, I don’t know how to track this. But it’s really the most important thing that I would like to track. I know, anecdotally, that lots of people, over the years, have joined, and stayed with, Apache projects because of an experience at ApacheCon. But that’s not the only factor, and it’s certainly hard to track because it requires years of events, and years of conversations, and people willing to tell those stories. I would like a better way to track this, and would love to hear your ideas.

Content. This one is easy to track. A lot of the events I run are all about content creation. When I run a CentOS Dojo, maybe 100 people attend, but then 1000 people see the videos that I record at the event, And maybe 1000 more read the blog posts that come out of those presentations. This is trickier when I am not running the event, and so don’t have control over that. At those events, I try to be very intentional about collecting stories. Stories can be interviews (video, audio, written notes), or they can be a promise of a later story, either delivered in writing, or via a video call that we schedule after the event. Here, obviously, followup is critical, and so it was my goal to be much more intentional about collecting contact info, and detailed notes about why I had that contact info. I wrote a blog post about that after FOSDEM.

As we try to be more intentional about what events we attend, sponsor, and speak at, it would be great to hear from some of you about what you measure, and how, to figure out if a conference (or other event) is a worthwhile investment of your team’s time and money.

Week Two, less exhausted

I’m completing week two of being an IT manager. Last week, I went home every day falling-down exhausted, from trying to understand a sizeable codebase (861157 lines of code – yeah, I know, that’s small beans to some of you, but we have a small team), trying to understand the business process, and trying to understand the dynamics of team interaction.

This week has been better, although I’ve had a horrible head congestion thing that has rendered me almost deaf all week, which is extremely frustrating, and tends to cause me to retreat to email rather than just going to see people and resolving confusion in person.

I think I’ve finally gotten an understanding of how the code fits together, and how the database fits together, and while I certainly would have done it differently, it appears to be largely a matter of style, rather than one of substance. It’s good code, and it works – it’s not how I would have done it.

Anyways, last night I went home and was able to have coherent conversations and not fall into a coma right away. I consider this to be progress. Any day now, I’ll be able to contribute actual functional code, rather than just stylistic tinkering.

And, Paul, if I’ve learned anything from you (I hope I’ve learned a lot, but, you know, I had to choose just one thing) it’s the Positive Power of Donuts.

Anecdotes from work

Two brief anecdotes from work for you, my loyal reader.

First, I want to share with you a sign that appears in the rest room at work. My only remark here is, well, ok, but, eww, and what am I supposed to do with *this*? Yes, gross, I know, but it makes me giggle every time I see it.

Secondly, I wanted to share with you some evidence that there are honest vendors in the world. Apart from beeping out the name of the vendor, this is untouched, and direct from voicemail.

Enjoy.