Anyone can throw together developer communities, right?

…well, yeah, and suck at it.

Clarissa San Diego shares her first event management experience as the newly minted lead of Developer Engagement at Particle. Tom Fifield (Community Manager for Open Stack) and I take a stab at providing some reflections and insight on this great case study.

Creating authentic connections within the developer community while representing the interests of your company is more akin to the skill sets of a diplomat than a software engineer, and god forbid, a marketer. Here’s Clarissa’s experience taking her ideals into reality:

It was December when I decided to host my first event as the lead of Developer Engagement at Particle. At that point, I’d been in the position for only one month but I thought it was perfect timing to host a holiday party. Many of the other San Francisco startups were doing it. A social networking event would be a great way to say “thank you” to our community.

I knew my timeline of a little over three weeks was aggressive but organizing events was my jam. After all, it’s what I was doing for the past couple years for other IoT related organizations. I ended up collaborating with two other startups not only expand our reach but to also help manage time, costs and responsibilities. Nearly a week before the date of the event we had the venue, food, drinks, prizes, and even a live band in place.

Unlikely Heroes playing live at Holiday Connect 2015

Come day of the event we handled the typical issues one may encounter when hosting any event. At the end of it all, I considered it a net success as we had received over 200 email addresses, increased brand awareness in person and on social media, and most importantly all of the hardware I had given out was registered onto our platform within a couple days. So when I found out my reporting manager thought the event was a failure, I was perturbed.

Getting the news that the power went out in the kitchen. Food delayed at least 30 min.


How did my manager come to this conclusion? I spent some time identifying these pitfalls and challenges during my post mortem:


The end of the year is always a stressful time for any company. Everyone is trying to wrap things up before the holiday. We also had team building events the entire week prior which limited our productivity.

What I learned: Allow for additional planning time if your event happens during a busy time of the year. If you are a still green at your company, do not feel pressured to host an event.

Expectations from Leadership

Though I had communicated my success metrics, I failed to communicate how these actions affected our company’s long term goals.

What I learned: Create a high level plan that includes a timeline with actionable tasks so you can show your team how each task contributes to the company’s goals. Most importantly, agree on what those goals are.

Event Duration and Start Time

The event lasted much longer than it should have at approximately four hours. Not only were the organizers exhausted, we also ended up receiving two big rushes.

What I learned: Networking events should only last about 2 to 2.5 hours. Anything longer may give guests a reason to check out another event scheduled at the same time. Be cognizant of your start time. Are you hosting a happy hour? Start at 4:30PM so your guests are likely to join right after work.

Working with other host companies

We saved a money and time but we were not well orchestrated. Duties were being duplicated and some were forgotten.

What I learned: Make sure to identify an event lead. Even when tasks are assigned, you should have a seasoned organizer to facilitate the process and make decisions when issues arise.

Getting the rest of the team involved

I didn’t communicate the event goals enough to my fellow team members.

What I learned: Get the your team excited about the events you’re hosting. Make sure they understand how they affect the company’s goals and what they can do to make a positive impact. It’s also good to get them involved to gain different perspectives from other disciplines.

Loosely defined definition of Developer Relations position

My title of “Developer Engagement and Marketing” is intentionally broad. Though we agreed on my objective, priorities were not in line.

What I learned: Revisit this conversation with your manager regularly. Communities changed over time and you’ll need to adapt with it. If the company is new to Developer Relations, help them create a plan.

How to do it better? It’s like dating. Really.

Communication is key

The dev community manager needs to possess special skills that go beyond translation. What are some of these skills? Assessing the needs of the company and the needs of the community and finding the common thread. Using the right medium of communication to deliver the corporate message. It’s not a direct feed channel. It’s certainly not about just showing the product and expecting the community to run with it. Creating an integrated plan helps your team understand the “why” component of your actions. Breaking this down into actionable items showing incremental progress can help manage expectations. Use a portfolio approach. As community managers, we’re continuously multitasking. Try having a portfolio that includes a range of activities from quick wins to some large/important projects and many in-between. Know that some of them will fail, but focus on the overall win. Also, report your progress regularly to make sure your manager and team knows what you are working on.

Names and labels do matter

What you call your team, how you identify your role can be a critical component. Knowing when to ‘do’ and know when to ‘wrangle’ will guide you through the process and implementation. Ask yourself, are you the lead organizers, a mentor, or just a support person? Does your company, your community, and especially your manager, understand your role and responsibilities?

And finally, make sure your strategy fits your targeted audience which may change with your company’s growth

You can have a totally different audience from the one you first built as your company adapts and evolves. Learn to recognize the change and how to work best to fit the change into your plans. Some communities have a natural “refresh” rate. For example, in OpenStack, if you pick a point in time then fast-forward 18 months, there will be more “new” people than people that existed at the beginning. How do you keep the same “spirit” alive as the community introduces new people? In this case you always need to ensure that you and others in the community keep up the “beginner”, or “on-boarding” process up to date even if most members feel familiar.

And finally, for now…

Deepen your engagement strategy by continuing to offer useful information and solutions to the community. Be an attentive community manager. And do postmortems, regularly and consistently. Boring, practical things like event postmortems that get fed into a checklist and even better, event kits, will help you and your team manage the next opportunity better.

Where to go for help?

CMXHub is a great online and community resource that compiles experience and knowledge from multiple members of the tech community. Jono Bacon’s book, Art of Community documents how communities are created and what managers should do to nurture and grow it. There are Slack channels like #webtalktips for advocates and evangelists to talk openly about their activities. And so many more. The resource pool is rich and deep. I am currently working on creating a dev rel operations playbook that collects the wisdom and lessons learned from my amazing colleagues. What resources do you look at for help? Who are your success influencers?