A few weeks ago I attended DevXCon in San Francisco with a colleague of mine. Since my previous role was as a systems engineer, with community outreach being more of a hobby, I’d never attended an event like this. Since it was local I figured it would be a great opportunity.

The event began with a talk by Donnie Berkholz on “(How much) do developers really influence? Reset/reality check” (slides). Setting the stage for the value of developers and how to reach them, the talk quickly cited the Microsoft Hosting and Cloud Study 2015 where he highlighted page 42 of the report, on Stakeholder Decision Making Authority. The several of the top Influencers and Primary Decision Makers, according to the report, were IT Infrastructure Managers, IT Architects and Software Developers. While CEOs and CIO/CTOs had similar numbers, it was clear that the individual contributor had a say in what software was being used. He then cited 451 Research’s Q1 2014 DevOps Study which showed that the top two ways that developers learned about new tooling were word of mouth and trade and blog articles.

The rest of his talk went over various successful examples of companies meeting developers where they are and systems that worked for engagement including:

• Rewards to high performing members of their communities
• Prioritization of high quality documentation so developers could succeed
• Making changes in the product as you notice your user base moving to a new base technology

He then sketched out a story around the tooling that developers used, stressing that while most open source projects unintentionally silo their tooling, developers use all kinds of programming languages and frameworks, operating systems, automation techniques, and more. As a result, the most effective evangelism and advocacy work tends to be done when you’re going to broad spectrum conferences where you’re meeting with developers working on various technologies.

Grace Francisco then gave a talk titled “Gloriously Global!” where she offered various tips for working with a global team and effectively scaling your team when working with a global community, including:

• Daily individual stand ups that are shared across the team asynchronously (record, share)
• Two team-wide syncs scheduled so no one is left out timezone-wise
• Host team off-sites, actual face time from time to time is essential
• Having firm, clear rationalization for all travel (your team will be scrutinized more due to the nature of the work)
• Make sure work you do and share is syndicated across platforms (blog, social media, where ever your community is)
• Build a program to support external champions which includes swag, training, recognition, tools they need to succeed

She also spoke some about how you go about finding developer advocates and evangelists, explaining that the skill set may be challenging to find (technical, able to work externally and openly, speak, write, and do community relations). She suggested asking internally first to see if there are engineers looking for a career change, and then looking to post-sales engineers who are accustom to public-facing, technical work with customers.

After the keynotes, I went to a couple talks on APIs. The first, by Tristan Sokol, dove into the use of Swagger Codegen to create SDKs against APIs from reference files, after reviewing the challenges of SDK creation by a small team. He admitted the downsides of using an automated tool that, by its nature, can’t do a great job of catering to the specifics of every language it provides an SDK for, but argued that it’s better than nothing. The next talk, by Romain Huet, provided a series of things to consider when building an API for developers to build against, including making sure the business case is clear. He also advised that a quick on-ramp, good documentation, and perhaps even on-site demonstrations of usage were valuable to adoption, and talked about making sure error messages for incorrect use are helpful to getting the developer on the right track. Finally, a status page about your API to keep users informed about outages is important.

Continuing in the API theme, Erin McKean gave the first afternoon keynote, talking about “Supporting new developers and your API” where she drew experience from the successful API that Wordnik provides. She mentioned that early on they learned a lot of students were using the API, many of whom were part of university classes, so they made some decisions based on supporting those students where they were. Other tips for supporting them included providing a simple, documented, sandbox where people could play with the API without doing any damage and reviewing error logs to see where people are struggling so you can make improvements to documentation as needed. Like others at the conference, she talked about champions in your community and suggested seeking them out to write blog posts, share workarounds, and even talk about other products when yours doesn’t have a goal of supporting something that some customers want.

Jono Bacon spoke next on “Measuring the Health of your OSS Community” where he worked to dispel the myths around flashy dashboards that seek to measure communities. He reviewed tangible (easy to track in a dashboard) and intangible types of contributions, noting that intangible things like happiness, personal development, relationships and having a rewarding experience are the things that frequently keep people engaged with a community. He shared some strategies for “measuring” these things, including: engagement in person (how many people have their laptops open? are sitting in front?), engagement on social media, and constructive participation during open Q&A sessions. He also explained that it’s important to track the path of a contributor in your community when looking for general trends, but also making sure it’s always easy for new contributors to gain status and recognition, including reputation “points” decay when involvement decreases so that older community members don’t have an unfair advantage.

He also made several key points:

• Focus on the outcome rather than the process
• Review on-boarding complexity
• Identify, track and try to improve failure states
• Follow retention of community members
• Keep an eye out for grown stagnation

This talk led nicely into the next, from Bear Douglas on “Building positive developer support experiences” where she outlined a similar series of things you want to keep an eye on:

• Adoption of your product/project
• Success rate of integration
• Customer Satisfaction (CSAT)
• Willingness to promote (Net promoter score)
• Retention over time

She reminded us that when a new person comes to your community, it’s often best to assume something has gone wrong. They are frequently coming to the community to solve a problem or get a question answered, and they may be stumped or frustrated. She stressed the importance of keeping that in mind when working with new community members and to cultivate real empathy on the team supporting them (not just a playbook). Listen to what they’re struggling with, engage in real dialog, and make sure you follow up and follow through so they don’t feel patronized or forgotten. She also stressed the importance of a public road map so community members can understand where a feature they’re eager to see or contribute to is in the priorities of the team and aren’t left frustrated by what they see as lack of, or delayed, progress.

What I really liked about this talk is that she also talked about the energy required to be this supportive. No one is happy, supportive and empathetic all the time. Don’t let your team members feel isolated, make sure there are team stand ups, lunches that remind them they’re not alone. Avoid trash-talk style venting, since it can easily spiral out of control and create a negative atmosphere (in spite of how good it may feel to the frustrated person at the moment!). Conversely, when there is good feedback, make sure that gets back to the product team so they know where they are succeeding. Back to team care, making sure there is a mechanism for handing off support when you’re too spent or upset to handle it, someone with fresh perspective can help and turn things around, turning a bad situation into a celebration-worthy success. She also suggested making sure high points are recognized and highlighted, and goodies are sent out to great community members, which makes everyone feel good.

Some more tips gleaned throughout talks as the day progressed included:

• Make sure support is as public as possible (private email threads expend time and energy, and are only valuable to the individual you’re working with)
• Keep an eye on the percentage of questions being answered by the community outside your company vs. inside
• Make it an on-boarding task for new engineers in your company to introduce themselves to the community, not just the company
• Encourage employees to be open first, share things externally as much as possible
• Be pro-active about pairing up community members asking questions with community members who have expertise (question gets answered, experts feel valued, everyone wins!)
• Define a path for a contributor to become a more serious, recognized contributor (reminded me of the value of Ubuntu Membership) and give them the tools to succeed in that path
• Uncover obstacles that community members encounter and work specifically to get people unstuck and reward them for success
• Communicate your work internally, sharing successes and failures so those inside the company feel included in the community
• If you have a Code of Conduct (and you probably should!), build, use and enforce it properly

I think one of the over-reaching themes of the talks, especially later in the afternoon, was a focus on what to measure and how. While broad ideas like those from Jono and Bear can be a guiding force, there is no blanket solution for everyone to use, and you can’t just copy what others have done. You need to be attentive to your business, community and product to know where it makes sense to focus. The path from new user to paying customer is rarely a straight road, so work through collected data to learn your most successful outlets and make sure the time, money and effort is put in those diverse places (events, blog posts, support engagement), tailored for your particular community.

It was a fun event and I’m glad I went. I hope as I’m moving forward in my relatively new efforts as a formal developer advocate I can continue to learn from the practitioners who have come before me and work to implement them in communities I’m working in. Thanks to the organizers and everyone who came to lend their expertise to this event, and in their communities every day.

More photos from the event can be found here: https://www.flickr.com/photos/pleia2/albums/72157681120795004