I’m Sorry…

Standard

Some of you may have noticed that I was absent from several events over the last month, specifically, DrupalCon Dublin, PHPNW, and BulgariaPHP.

I had intended to fly from my home to Dublin, before hopping over to Manchester, and then finally on to Sofia before coming back home again.

I was stoked to attend my first ever DrupalCon, to be going back home for the excellent PHPNW, and ending my trip with my favorite conference of 2015, BgPHP. It was going to be amazing.

And I couldn’t do it.

I did a lot of travel last year, and it was amazing. And tiring. I decided this year to do less travel, and I think that objectively, I have. However, this year is the first time my son has also cried when I’ve left, and my travel has been bunched up such that I’ve been away on several long trips.

I had just completed an unexpected West-East-West-East-West (SEA (Home) -> BUF (CodeDaze) -> SEA (PNWPHP) -> JFK (Velocity) -> SEA (Home)) and it was exhausting.

So, as I got up, said goodbye to my family, and loaded my stuff in my cab to the airport, I was anxious about being away for yet another extended period of time.

We started our drive to the airport, and I used my time to share my feelings with some friends via Twitter… and it became clear to me that I was either experiencing, or close to burnout.

Despite my embarrassment, I had my driver turn around and take me home. I cancelled my flights, my hotels, and told my boss. I contacted DrupalCon and went to bed. After I got up again, I contacted PNWPHP, and yet… I still hoped to make BgPHP. I thought maybe I could get my shit together in 5 days or so and still make the event I’d been looking forward to all year. But no… I couldn’t. And so, a few days later I told them too.

For those wondering, my emails were something like this:

Hi Ramelina (and the rest of the BgPHP crew),

As you know BgPHP is my absolute favorite conference in the entire world… however, I won’t be able to make it this year :(

After scaling back my travel due to mental health reasons I’m no longer able to attend :(

I understand that this is less than ideal for you and the wonderful attendees, and I’d like to do anything possible to make it easier for you.

Please let me know if I can be of any help, and if there any costs (such as hotel) that I need to cover.

I’m really sorry :(

And you know what? Everyone was fantastic. Nobody got mad, nobody was upset, they all just wished me well, and I’m sure scrambled to fix the mess I had made. And I am eternally grateful.

And dreadfully sorry.

I am sorry to the organizers, of course, but also to the attendees and wider community. As a Developer Advocate, I would like to be relied on by conference organizers and the community, as a known entity of stability. This is why, for example, I always let organizers know I have other talks I can give if someone else can’t speak for any reason. This is why I try to always get in early, and I work so hard on my slides.

I’m currently writing this from Berlin, and in truth, there was still a bit of anxiety leaving for this trip (with Akamai Edge in San Francisco first) — but, I’m glad I did it, if only to prove to myself that I still can.

Thank you, to every one who reached out to me when they heard I wasn’t going to make it, and in person this week, it meant a lot to me.

I will try to do better.


Update: 28 Oct, 2016

The Lead DrupalCon Coordinator (Amanda Gonser sent me this (published with permission):

Hey Davey,

Just saw your blog and wanted to say that I am happy you took care of yourself. I am glad to hear you’re doing better but still getting out there! We look forward to having you at another DrupalCon in the future if you’re up for it.

Cheers,

Amanda Gonser

Thank you so much Amanda, I still hope to attend my first DrupalCon soon!


Photo by GPS, used under a CC-BY-SA 2.0 License.

Community Relations: Not Just a Megaphone

Standard
This post is over 1 year old and is probably out of date.

In my last post on Building a Community Presence I went over some of the approaches for engaging communities. This time I want to talk about what the actual job of a community builder is.

On Selling

The role of the Community Builder is to sell you on the idea of the company and the product. Not necessarily to sell you the product. Often times what we’re selling are not bought without some decision making process behind them, so a sale is not going to happen then and there anyway. Provide the education, and build the trust, and the sale will happen.

Why I Hate Evangelists

I personally have a visceral reaction to the title “Evangelist”, which is unfortunate because it’s on my business cards.

The issue I have with the title is that when I think of Evangelist, I think of a fanatic who will use whatever methods they can to convert you to their way of thinking. And yes, there are Developer Evangelists who will do this. They are bad community members in my opinion, and I don’t trust their opinions.

The truth of the matter is that there is no single solution to any technical problem, and anyone who tells you differently is lying.

I prefer the “Advocate” title, or better yet, the one I chose for myself at Engine Yard, “Community Engineer”.

Advocating For The Company/Product

Being an Advocate is important, advocating for something in my mind means to put its best foot forward. This meant that while at Engine Yard, I probably sent more potential customers to our competitors, because I knew that had they tried our service they would’ve been disappointed for their current needs. Engine Yard is an amazing platform, but it’s complex (due to its customizability), it often requires some changes to “cloudify” your apps, and it can be comparatively expensive if you’re at the small end of the scale.

If you fall into the segment of the audience that doesn’t need the customization and support, then you’ll find the product over-complicated, and probably, over-priced. That is not a positive experience, go use Heroku instead (for now). If you fall into the other segment, then you’ll find Heroku to be constraining and expensive instead, go use Engine Yard and you’ll find it to be the right product for you.

I believe that honesty plays a big role in advocacy. If people are to trust what you say, you must be able to not only point out the flaws in your competitors, but your own as well. If you fail to do so, and you knowingly “sell” a customer a product that isn’t a good fit, they will have a negative experience and that’s what they will broadcast to their peers — that, to me, is an anti-sale. You stand to lose far more business that way.

If you instead sell them on the right product, even if it’s not your own, while at the same time educating on both products, in the future they will seek you out, and self-select into being a customer. At the very least, they will seek your advice again.

This still falls under the megaphone part of the role. And is probably the less valuable part of the role to your employer. They, realistically, can have similar results using traditional, informed marketing channels. And those flights are expensive.

Advocating For The [Potential] Customer

The most important part of the role is advocating for the customer, or potential customer. This is why I like the title “Advocate”, it cuts both ways. You are an advocate both to, and for, your customers and potential customers.

As an advocate, you are the person (or one of the people) closest to your customers. You attend the same events, you go out to eat and drink together, you attend the after parties together, and you commiserate the early morning afters. You also have conversations, about life, news, the weather, and work.

You hear their gripes and you are the conduit for upcoming news that affects them, negatively or positively.

I firmly believe that the most vital part of the role is creating a feedback loop, directly from your customers to your product team. Your job is to aggregate requests (“I’ve been 14 events so far this year and every time someone has asked about X”), spot trends (“Lots of people are starting to talk about Y, here’s what it might mean for us”), and raise concerns (“People find this part of our product confusing because Z”).

If your community team does not have a direct line back to your product team you are missing out on the most valuable information they are collecting.

Advocating For The Community

As mentioned in the previous post, as part of your role building relationships, and as the person most entrenched in the community, you should be working directly with marketing on messaging and interactions.

You should have the power to veto any messaging your company puts out to your community — after all, your knowledge of the community is one of the reasons they hired you. It’s in the companies best interests to have you invested in their messaging: you are the one on the ground who has to deliver it after all.

Advocating For Yourself

At the end of the day, being a community builder is a job. I personally won’t take on the role unless I believe in the product, because I want to enjoy my job, I want to help people do their jobs better, and I can’t do either of those things with something I don’t use, or don’t care for.

This is also part of the reason I didn’t look for new roles in the same space when switching jobs, it feels disingenuous to the community to “sell” them on one product one week, and then on a competitor the next. My paycheck doesn’t buy my loyalty, the company values and a product I believe in do.

I hope this is obvious when I interact with people, and I believe it’s a necessity to be good at this job. We must maintain our intellectual honesty and community integrity. Your reputation is your true value, for your company, for your community, and most importantly, for yourself.


Thanks to Tessa Mero, Austin Gunter, Margaret Staples, Katie McLaughlin, and Amanda Folson for reviewing this post.

Image courtesy of Chris Combe

Building A Community Presence

Standard
This post is over 1 year old and is probably out of date.

Your company has decided it needs to “do community”, whatever that means, you’re community manager 1 number one, what now? From my time as a developer advocate/evangelist under both marketing and engineering teams, I have come to some conclusions about how to build community presence. Though my experience is mostly with technical communities, this should apply pretty well to any community building.

Identify Your Products Potential Audience(s)

You’ve probably already done this to some degree, after all, to build a successful product you need to know — and understand — who you are building it for. But, if your target audience is “developers” that’s marginally better than saying your audience is “humans”.

Chances are your product is going to fall into one of two categories: a tool built for use with a specific language (e.g. the excellent greenkeeper.io for keeping your node.js npm dependencies up-to-date), or one built for most every language (e.g. Travis CI for continuous integration).

If you fall into the former category then you’ll have a much easier time narrowing down the identity of your audience, your product itself defines it. For the latter, you need to recognize that you have multiple (albeit similar) audiences, and working with, say, the PHP community will be different to the Ruby and Java communities for example.

There are, in my mind, three approaches to building your community team:

Breadth First Evangelism

If you have multiple communities you wish to target, you may decide that the most important thing to do is to get your name and your product out there in front of as many appropriate eyeballs as possible.

In this case, you do not have the bandwidth to forge deep, meaningful relationships with every community in which you want a presence. You cannot physically be everywhere at once!

These kind of superficial touches will be things like conference sponsorships that involve little more than plunking down some cash and getting your logo/booth at an event, maybe you sponsor an open bar, or an unconference track. You give away the pens and the t-shirts, and the other branded swag, and you leave.

You write a bunch of high level blog posts, you make sure you have docs that have examples in a multitude languages, and you go home, job done.

This is a great way to start, but mostly superficial. You will not identify your community advisors, you will not create long lasting relationships, and you will get less valuable/actionable feedback.

What you should be doing is trying to identify communities in which you want to foster deeper relationships. Which communities you either want to pay special care too because they need more of your time to understand your product, or better yet, the ones that are getting traction and starting to provide interesting insights, use cases, and feedback. This leads to the next stage:

Depth First Evangelism

If you have the second type of product (i.e. specific to one community), or, you’re ready to start deepening the relationships you have started to cultivate through your breadth first evangelism efforts, it’s now time to start concentrating your efforts – and expanding your team.

This is when you will want targeted evangelists: a PHP Evangelist, a Ruby Evangelist, a Python Evangelist. These people bring their knowledge of a particular community to bear in determining what your messaging should be and how your interactions are orchestrated to achieve the community relationships your product needs.

Now you will start to do things like working with a conference organizer to create a sponsorship that provides much more value to the attendees, and can actually shape the feel of an event. You will start to sponsor open source work that is relevant to your company, and you will sponsor initiatives like diversity groups, and scholarships. You will make meaningful contributions to the community.

In return, you will get the insights in to your product that help your improve it, you will find your most hardcore users, your beta testers, and your contributors.

You will continue the blog posts, but they will be much more in-depth and targeted, based on feedback from the community about what they need to know, rather than what you think you want to tell them. Your documentation too will follow suit – perhaps you put together a book around using your product as members of that specific community.

There is an alternative to depth first and breadth first, which is to localize your efforts:

Localized Evangelism

By constraining your geographic area, you are reducing your audience in the same way as in depth first evangelism, but you can still hit many different communities within that geographic area. To be clear here, I’m talking about an area which can be traversed within a day.

This allows the kind of deep relationships that add real value, but across a broader section of your audience.

This hybrid is potentially easier to scale, it certainly cuts down on travel costs, but, you are less able to take advantage of your existing community presence (which is likely limited to one or sometimes two communities) or your breadth will be biased in those directions.

It’s Just The Megaphone

This is what I call the megaphone part of the role, the evangelistic, outward pushing part. But it’s just one part of the role. While it’s the most visible, I’d argue it’s not the most important. In the next post, I will cover the other aspects of the role that make community engagement invaluable.


Thanks to Margaret Staples and Jonas Rosland for their feedback on this post.

Image courtesy of The Greater Southwestern Exploration Company, used under a CC-BY 2.0 License.


  1. there are many job titles, community engineer, developer advocate, developer evangelist, etc., but they all involve some level of community presence 

The Syntax of Tech Communities

Project
This post is over 1 year old and is probably out of date.

Just like the programming languages that are the centers of our communities, each community has its own set of rules and idioms — they have a real life syntax.

In my (almost) three years of being in a developer relations type role I have attended events in several communities and have observed how they differ from my primary community (PHP). As I’ve tried to understand those differences and the reasons behind them, I have had many discussions with members of many more communities also.

After attending my first PyCon (US) I was struck by just how welcoming and diverse the community is and had many conversations trying to understand why this is. This is not what this post is about. This post is about conferences specifically, and how communities place different priorities on different things when it comes to how they run, organize, speak at, and attend events.

PHP

The first thing I found that was unique about the PHP community is that every event which has an open CFP (e.g. not a local community day, hackathon, etc.) will reimburse at least some travel and lodging costs.

Larger community and for profit events will typically cover all flight costs and at least (number of talks)+1 nights hotel. Some will limit the number of international speakers to keep costs manageable, while others will have a fixed amount of costs they can cover, and the rest is up to the speaker.

In fact, the reason I started speaking at conferences was because of this, I would never have been able to afford to attend otherwise.

These may be paid up front with the conference booking the flights on your behalf, or they may be a refund after the fact.

In the last few years the smaller community events have (probably because it’s a default in OpenCFP) added checkboxes to their CFP which allow you request help for travel and/or accommodation. I think this change has come about as the number of speakers whose jobs are willing to pay their way has increased.

Additionally, you would get a full ticket to the event. Speakers do not get paid anything additional such as an honorarium.

Due to these costs incurred by events, ticket prices are usually somewhere from $150-350 with tutorial days at additional cost. A few events are much more expensive (~$1000+), but are typically not aimed at the community crowd.

Another thing I’ve noted is that it’s common for speakers to submit multiple talks to conferences and this is highly encouraged to people who wish to get a talk accepted: never submit just one!

As for the talks themselves, they are usually minimum 40 minutes (which is rare) and maximum 60 minutes. 50 minutes is the most common format.

Ruby

The community which I spend the most time comparing (mostly with PJ) is Ruby. The first major difference I noticed was that there were no speaker packages. I was outraged by this, it felt like the equivalent of “it’ll be good for your portfolio”.

Then I found out why this was: the ruby community values accessible ticket prices, and wants to have a low price point to make the event feasible for as many people as possible, including students, single parents, etc.

This would be impossible if speakers travel/hotel were paid for by the event.

Speakers are given a ticket to the event, and I’m sure for some its reason enough to speak, while others do it for the exposure and networking opportunities. But additionally they seem to do it to contribute back to the community as well.

Also, when it comes to CFPs, numerous people I spoke to early on were aghast to learn that in the PHP community we submit multiple talks. However it seems that this is changing, and it is becoming more common to do so.

Talks are usually 25 minutes, with the max being 35 minutes. Some are as little as 20 minutes.

Python

The Python community seems to be somewhere in the middle. While Python events do not cover a speakers flight and hotel, the PSF has a formal grant program which allows for those unable to afford to attend to request financial support to do so.

And while ticket prices are not as cheap as ruby events, they do have multiple levels of ticket prices, for example students, regular, and business tickets. For PyCon US, those were $125, $300, and $600 respectively. And everyone buys a ticket, including the event chairs, volunteers, and speakers. Again the PSF grant program can help here.

Submitting multiple talks seems to be the norm. And talks are 35-40 minutes long.

Perl

I have only recently started discussing this topic with members of the Perl community, but they seem to also value low cost tickets, speaker costs not covered, and 35-40 minute talk slots. I may be wrong on this but that’s what I understand to be the case. I am unsure if tickets to the event are given to speakers, or how CFPs are typically done.

There’s No Right Answer

It is obvious to me that community is hugely important to everyone I’ve spoken to about this, and I find it interesting how different communities have different priorities resulting in different conference experiences.

I will say that the Python way seems like a much more democratic and inclusive way to handle things, but that it depends on the PSF which is a core part of its community and requires monumental effort, oversight, and tons of volunteers. As an aside, the PSF also seems instrumental in the inclusiveness and diversity exhibited by the Python community.

At the end of the day, I think we all have valid motivations. The PHP way ensures that regardless of your financial situation, if you have something valuable to share then you can do so, while the Ruby way ensures that the most possible people can attend to hear what is being shared, and the Python way tries to strike a middle ground.

I do find it interesting how consistent things seem to be within communities, perhaps simply through early leaders setting the expectations, but it does show some of the differences of opinion on how to build a thriving community — and yet even with these differences, they are all large, thriving communities.


Image courtesy of Benjamin Horn, used under a CC-BY 2.0 License.

Thanks to PJ and Rae for reviewing this post.

Speaking Out on the PHP Code of Conduct

Standard
This post is over 2 years old and is probably out of date.

Please see the updates below

This was going to just be a tweet, but I felt it needed more than 140 characters.

If you know me in person, you’ve probably met me at a conference or user group. It should be immediately apparent that I am a confident, outspoken person (at least publicly).

I’m a former PHPWomen US Lead, as well as co-organizer for Prompt, raising awareness about mental health in technology, I’m no stranger to speaking out on tough subjects.

Furthermore, I’ve been a contributor to the PHP community for 15 years, and an internals contributor for half of that (since PHP 5.3.0).

The fact that I — as that person, and as a member of the majority makeup of the PHP community — don’t feel safe contributing back to the Code of Conduct discussion in favor of it — should tell you everything you need to know about why we need one. This is due in part to the hostility from some people involved, and to possible backlash from the wider community.

So let me state here, for the record, in unequivocal terms:

I fully support a Code of Conduct, and a reporting infrastructure in which we can act to remove those who are unable to abide by the Code of Conduct from our community.

This should be applied to all mailing lists, all websites (e.g. comments in the manual, news items, etc.), and all social media put out by the PHP project itself.

It should also apply anywhere a contributor is using their @php.net email address — whether thats a private email conversation, or at a conference/user group where you put it on your contact slide. Obviously while the person could not be removed from the event, they can be restricted from contributing based on their behavior.

Also: thank you Anthony for bringing this RFC to the table.

Update

This has gotten quite a bit of support and a couple of questions, so I wanted to add one specific thing:

To clarify, I don’t support the Contributor Covenant as it stands as the CoC for PHP; I think it is a good starting point, but it is just that, a starting point. Additionally, regardless of the content of the CoC, what matters more is documented procedures for handling reported violations.

Learning Rails (and Ruby)

Standard
This post is over 4 years old and is probably out of date.

A few days ago I had a new blog post published on the Engine Yard Blog. The post was actually written, before my last blog post here, and is really more on the same subject; get out there and cross-pollinate. Learn, and share with other tech communities.

You can read the post here: Learning Rails (and Ruby) on the Engine Yard Blog.

I’ve had a lot of positive feedback (on reddit), and surprisingly the only negative feedback I got was via the PHP sub-reddit. I think some people choose to defend their choices simply because they don’t want to have made the wrong ones. But really, there’s no right and wrong answer, and it mostly comes down to preference and little else.

That’s enough meta-commentary from me, read it already!