Notes from DevXcon SF 2018

19 min readJun 5, 2018

I am super happy to crash this year’s DevXcon. Regarding the name; “Developer Relations” is a common term that’s been around a lot longer than DevX, and in some companies DevRel been moved into a marketing type of focus. The DevXcon is named to emphasize that DevRel can have a technical and UX focus.

Here are my notes!

Erin McKean on User Research for Developer Relations

The users of your product and the users of your content are not necessarily the same folks. You want to write content for those who will read it, even if they don’t use your product or content. Remember that your developers are NOT YOU. A lot of people get into DevRel because they love the product, and it’s hard to remember that you’re not the user of your content.

As DevRel people, our superpowers are our greatest weakness:

We’re lucky that we get to go to conferences and have a lot of access to users that people back in the office. But we’re often at these events to talk, and not to listen.
We have to consciously say “who is not in the places I go to?” Consider the developers you can’t access, who are invisible to us right now.
A lot of advocates are introverts who just dress up in extrovert clothes when they get onstage, so we may not seek out developers who don’t approach us.
Don’t ask “What do you want.” You won’t get any good data from that. Ask them why they do what they’re doing.
Don’t solutionize. We want to jump straight into “Do you know what you should do?” We are in DevRel because we have opinions, but sometimes we need to listen. Don’t rush to fill the silence with answers.

You might find out things that are scary, or that you don’t want to find out. But you’ll also find out things that will make you happy, will make you a better DevRel person, and will help you make better relationships with your developers.

For more details, check out Just Enough Research by Erika Hall and these resources Erin has provided.

Peter Merholz interviewed by Tamao Nakahara

Adaptive Path was one of the first companies focused around user experience, as opposed to just UI or design. At that time most companies didn’t have internal design teams, so we’d be brought in by a marketing or IT team. (Now, every company has an internal design team.)

Understand your users, redesigning your interfaces, and iterating on that. “Where the UI lives” changes over time. It could be a command line, but my experience is through graphical interfaces. That said, the same principles apply whether you’re doing a GUI or command line interface. In fact, the way that UX developed came out of software developed in the 70s and 80s. Usability testing was rooted in command line interfaces from way back.

Users experience an emotional journey when they are onboarding to a product or platform. Airbnb did a lot of research with guests and hosts trying to review their journey, and they found a few moments of anxiety, because essentially you’re staying in a stranger’s house. The moment that it’s highest is when the guest is approaching the front door. They’ve spent a lot trying to ameliorate that anxiety. We used to call these “moments of truth,” where if you succeed you win and if you fail you lose, regardless of what happens elsewhere in the experience.

At our organization, we asked users to fill out a short survey and 30 second video of where they were in their journey and what they had been doing. This was hugely useful for us to understand the highs and lows and the emotional journey that our customers were going through. An interview is great, but with multiple snapshots over time you get a better view of their status at any point in time. (In any of these studies, we paid the users for their time. You should expect to compensate your participants.)

Peter is the author of books including Org Design for Design Orgs.

Connecting DevRel and Product, Bear Douglas from Slack

One of the key differentiator between developer evangelism and developer advocacy is how you’re changing your product. Phil Leggetter wrote a blog differentiating the two. At different organizations, the interface between dev advocacy, marketing and product can be very close or very far.

1. Create a consistent cadence of feedback.

You want the product team to know that you’re going to provide valuable product feedback. Find channels that work. At some companies, you’ll @here them any time you’d get a piece of customer feedback. At other companies, you’d roll up feedback into a weekly digest. (Readership eventually dropped off.) One thing that works well is assigning someone from the DevRel team to attend other team’s standups.
Bring good news. When you’re always the bearer of bad news, the product team won’t look forward to your feedback. Positive and neutral news is just as important. As an example, at Slack, lots of developers wanted to implement radio buttons in the platform, and would hack the platform to allow them to do that. We brought that feedback to the product team, not as a criticism, but as a data point.
Get others with you. Bring the product team to a user conference, or get them out of the office. If you can’t get them out of the office, bring your developers into the office.

2. Be both filter and funnel. Don’t be a firehose.

Dig deeper into customer requests. Ask why they want it, what they’re trying to do with it, and try to get to the need. Once you get to the need, you can bring that to the product team.
Write good bugs. They will be more likely to be fixed.
Keep perspective on urgency. Even though a problem might be urgent to a customer, you need to keep perspective when you face your product team. Customers may not see the trade-offs you have to make relative to other feature requests.

3. Closing the Loop

Translate feedback to tasks. We’ve had an open roadmap session at Slack, where we print out our roadmap onto a giant physical wall and gave people stickers that they were able to use to upvote or downvote ideas on our roadmap. We needed product managers to staff the wall at all times. Force users to downvote as well as upvoting, to make customers understand the tradeoffs and get information about which features were only nice-to-have.
Be transparent about feature status. Having an open roadmap is valuable. The more you can have an honest conversation about feature status, the more you’re able to have an authentic conversation that builds trust with developers, and the more you can convince your product team to release more information. Work with them to understand how transparent you can be, where you need to be vague. Slack and Twitter both put out our features on a public Trello board, and which we update quarterly.
Show internal teams their impact. Share feedback from customers, whether it was feedback from a support channel, love on twitter, or something we heard on twitter. Make your engineers and product managers understand that they have a real impact on customers’ working lives.

Bear Douglas was previously at Twitter, Facebook and smaller startups.

Building teams, goodwill, and awareness through open source engagement by Jade Wang of Cloudflare

Developers have different ways they interact with your company through the outside world. Open source can have a positive benefit on your company. Here’s how:

Recruiting

Recruiting is a great ally when it comes to open source engagement. When Sandstorm was deciding which company to join, engineers had contributed to two different languages of an open source library. They also had developers writing blog posts and giving talks about the library at conferences. This put Cloudflare at the top of the list. Positioning the organization as a good place to work by encouraging open source contribution can be very beneficial to recruiting. It’s also great for the careers of the engineers who contribute to those projects.

One way to accomplish this is what ThoughtWorks does. When their employees have downtime between projects, they can work on open source projects. This allowed a friend of mine to level up her skills, and was a compelling benefit when recruiting.

Stability

What would happen to your organization if the maintainers of open source libraries you use didn’t have the time to fix critical bugs? Your organization can help out organizations through organizations like Open Collective, by helping fix bugs, and giving project maintainers free upgrades. Your organization should help these projects out, and you should be able to find allies in your engineering organization.

Awareness

In the case of open source community engagement, developers can get familiar with particular toolchains or workflows because of open source projects. I’m much more likely to use the projects that I’m comfortable with. Giving away your product to the open source community means you’re exposing your product to a socially influenced community focused on collaboration. This is especially true for developer tools.

Methods of Support

Code contributions
QA/Testing/filing issues
Designer time/bandwidth
Community manager time
Direct support through Open Collective
Free upgrades on products
Free event space
Conference tickets to core contributors
Promotion of products for widespread adoption

Addressing Internal Concerns

There are a lot of open source companies that are VC-backed in a growth stage. How do you separate the crunchy granola from your larger enterprise story?

You can filter by non-profit or 501(c)3 status, but that doesn’t work for non-US projects or small/new projects.
Filtering by volunteer basis is good, but you tend to miss some projects.
Case-by-case basis is effective but takes a lot of time to vet each project.

Jade heads developer relations at Cloudflare and previously was at Sandstorm.io, Meteor and NASA/Ames Research Center.

Designing a delightful CLI by Nahid Samsami and Jeff Dickey, Heroku

There are two main ways that users interact with Heroku: the dashboard and the CLI. There are important differences!

Differences between Browsers and CLI Experiences

In the CLI, it’s up to the user to input and get a response. In the dashboard, there’s a huge visual experience with dropdowns and menus. It’s a lot easier to guide the user towards a particular experience.

Why build a CLI at all?

They enable developers to work really really quickly. Developers can complete repeatable, composable tasks and scripting. Additionally, they make it easy to interact with an API. Using CURL, APIs can be tricky — using a CLI, it’s easy. Building for CLI takes a fraction of the effort of a browsers.

CLI Principles

We put these into a style guide that you can find in our dev center.

1. Mission statement

Every CLI should have a mission statement of what you’re trying to do with that CLI. This can help as you make design decisions. For Heroku, it’s all about usability and humans before machines.

2. Structure and Navigation

In the CLI, your tool is words. Language and naming becomes very important. Our CLI is made up of topics (categories) and then commands. We also have rules about lowercase, single words, no special characters: this helps because we’re trying to help our users’ muscle memory. We place commands within topics and match this hierarchy with the filesystem.

We recently released command autocompletion, which lets you tab to complete a command based on text already entered. We also complete values, such as app names.

For documentation, you want consistent information in the CLI and the browser. Some developers will find information about the CLI by doing a search, not necessarily using the CLI autocomplete or help. We created a mirror of CLI documentation in our dev center, so everything is now searchable. We’ve abstracted this into our open CLI framework.

3. Input and Output

Safeguard against risky actions with a confirmation step. Some actions are pretty destructive, for example deleting your app or database. If a regular browser experience would include a confirmation popup, replicate this on the command line. Ask a user to confirm either by entering the app name when prompted, or run the command with a “confirm” flag and the app name.

We use spinners to convey state, similar to the way you’d see these in the browser — some with states that change to a check mark or x mark depending on success or failure. We’ve received so much positive feedback on these animations and status indicators. It makes the CLI really come alive for the user.

However, if something will take a little longer to complete, we use notifications to provide status updates. The user may be using a different terminal than the one for their long-running process. We provide an OS-level popup. We received mixed feedback on this, so we provided an option to turn this off. If something feels intrusive to a user, it’s important that the user be able to turn that off.

4. Making best use of CLI Superpowers

Enable machine output judiciously. It’s difficult to create specific output in the dashboard, but in the CLI using command line tools developers can get custom information displayed in their preferred format easily.

Going to infinity and beyond documentation with OpenAPI by Taylor Barnett, Stoplight

As much as we’d like them to, self-documenting APIs do not exist. We’re at a bridge of humans of machines, and that’s where API specifications sit.

OpenAPI is a sandard, structured approach for describing APIs that is both human and machine readable. Initially it was called Swagger, now it’s more a vendor-neutral spec and Swagger is more the tooling.

OpenAPI is a bridge to understanding and being able to communicate around using HTTP is a transport.

Everyone loves something that writes your docs for you! But OpenAPI is not just for API references. When you implement a new feature you need to update the server, client libraries, documentation, and coordinate between the client side and backend team. OpenAPI fulfills a lot of these problems. It’s a bridge between teams and removes silos that develop around the API development process.

Development contract
Prototyping and mocking
Client SDKs and libraries
Testing
Server stubs

OpenAPI is a tool for collaboration. It simplifies describing an API, standardizes terminology enabling discussions to happen between teams with less friction. There’s also this term of “API Fastness,” or developing an API quickly while still focusing on the overall developer experience.

Design First

Typically people get their spec one of three ways: automating it from the code, creating it from design first principles, or starting from scratch. Let’s focus on the second way, because it’s embracing what OpenAPI stands for. It leads to a consistent, standardized API. It makes users happier and less confused.

If you maintain client libraries or SDKs, you can have more options, create libraries and SDKs faster, and have libraries ready at time of release. How many times have you seen “We’ve released a new feature, and the Python library is coming soon.” You just lost a bunch of Python developers!

If you care about developer experiences, API design or you’re an advocate for users, you can power feedback loops with mocking, put real endpoints in front of users, and create “Experimental APIs.” See also this post by Lorinda Brandon.

With mocking, you start with humans, ask what tasks do they want to accomplish, ask if the API will help them achieve these tasks, and then look to make sure the endpoints are not confusing.

Making sponsorship work for new developer conferences Chris Neugebauer of North Bay Python

Chris runs a small Python conference in the North Bay. Commercial events and volunteer-run events are different, and he’ll be talking about volunteer events because volunteers cost less. Sponsors know this. AWS charges $350k for their top-tier sponsorship, but our conference only charges $6k. Despite, this, sponsor benefits look similar at most conferences. We’ll look at why traditional approaches to event sponsorship can be difficult when your conference is based on volunteers.

When dealing with volunteer events, you have to understand that different types of people are running them. Volunteers are not paid staff. The main difference is that maintaining a consistent team of volunteers on a project, you need to give them a higher level of emotional upkeep than paid staff. You need to actively work on keeping them happy.

Shared vision of the event
Want to work with the rest of the team
Be empowered in the roles they have been given and tasks

“ Your team must be motivated about the conference as a whole, and past the threshold of wanting to work for free. If they fall below that threshold, they will suffer from burnout.”

(You also need to keep yourself happy as an organizer, BTW.)

Make sure that every goal a volunteer has leads to effectively delivering the conference. The most effective goals are ones that lead to the success of the conference.

There are many goals where delayed gratification leads to delayed motivation. Sponsor sign-ups are one example, it can take 10 months from first contact to payment.

New Conferences

Past conferences have a track record, budgets, relationships, and profits from previous years to bootstrap your funds for this year. New conferences do not have this luxury.

First commitment: Be able to run the conference. Cancelling is a really poor move for a first year event. We wanted our sponsorship dollars to go toward seed funding to ensure that we can put the event on. Being able to cut benefits is important to new conferences if revenue isn’t up to goals.

Align Goals with Sponsors. Behind the scenes, organizers have to think about alignment, and you have to start with the budget. Frame your budget in terms of “what can make the conference viable?” and “what else can we do to make the conference thrive?” We itemized the budget to individual transactions, which allowed us to cut things that didn’t align with our vision.

Separate lines into “behind the scenes” and “audience facing.” Anything audience facing can be monetized into a sponsor benefit. Once you’ve identified these branding opportunities, you can align them with sponsors who fit. As an example:

Lanyards co-branded by sponsors
Live captions
Lunch recommendations
Childcare
Coffee
Wi-fi branding
Bay area public transit bridge
PyLadies Lunch

In 2017, this approach delivered $19k of our total sponsorship amount of $49k, which is about 40%. These exclusive branding items tend to be higher in dollar amount, and fund more of the stretch goals we have as organizers.

It’s also easy for volunteers to see the benefit. It provides the immediate motivation that volunteers need to run your event.

How to apply UX principles and methods to API usability by Tao Dong, Google

Tao is a Senior UX Researcher at Google, with a focus on developer experience, programming tools and API usability. This talk will focus on Flutter, a mobile app SDK for crafting high quality native experiences on iOS and Android. Flutter’s three product pillars are high-velocity development, Expressive and flexible designs, and High-quality experiences.

In this talk, I hope you’ll understand what DX can learn from UX.

What is API usability?

The usability of an API is much different than its shape or functionality, it’s about the full interaction of using the API in a realistic setting. We need to include the tooling and documentation into the API into how we assess an API’s usability.

We don’t want developers to write buggy code, or feel frustrated/confused, when they use your API.

API Usability Lessons from Flutter

Reduce context switching. Avoid switching to other applications to get information when a programmer is using your API. A developer will often look for information and documentation in the source code of your API as opposed to the web documentation, because they won’t be distracted by switching contexts to the web browser. We have to consider where developers will be looking for information when we create documentation.
Help Build Mental Models. Identify how users will understand your product and design your API to allow them to learn faster.
Speak your User’s Language. Name your endpoints and other functionality so that developers can find them. E.g. ListView was previously called Block, and renamed when developers could not find it.
Enable Programming by Example. Merely having a ton of example available is not enough; but it’s difficult to choose which call you want to use. Instead we started to provide highly curated code samples as well as screenshots and diagrams to illustrate the output of each snippet. This helps developers to identify whether the example is relevant.
Promote recognition rather than recall. For the human brain, recognizing the correct option from a group is “cheaper” mentally than creating a solution from scratch. We used to have an API called Colors, which stored all the colors in a map, and the developer had to remember a specific key. This key would not autocomplete in the IDE. We redesigned the API to surface all the shades of color as properties. We even show a preview of the color on the margin of the IDE.

4 steps to conduct an API usability study

Prepare the API you want to test. This will help you specify the task you want to use for this study.
Ask the developer to solve the task with your API.
Moderate and observe programmers attempting to accomplish this task. You need to remind the participant it’s a test of the product, not a test of how they code. You want to remind the participant to think aloud as they program so that you can understand what’s going on in your head.
Evaluate the results. Decide if changes to API, tooling or documentation are needed. This is the time to let the data speak. Be careful about what data you take into consideration and how much weight you give them. Pay the most attention to behavioral data, which is what the developer actually did. You can also use the verbal reports, but put a grain of salt into statements about their future behavior (humans are not very good at predicting their future behavior.) People will also try to rationalize their actions by inferring what they were thinking instead of giving you an accurate account.

Design approaches for developer experience by Oana Mangiurea, Ownzones

Oana is a Senior UX/UI designer.

Where do you begin when designing for developers? Ask yourself:

What’s the purpose of your application?
What issues do you want to address? What do you hope to improve?
Are there any similar apps on the market?
What are your main features?
How well do you know your users?

You need to start somewhere. If your team’s contention is that developers are power users, remind them that “developer” is not a single persona. There are front-end, back-end, app developers, devops engineers… each has their own purpose for using your application.

Personas are your best friend. Identify their goals and frustrations. Emotions lead to frustrations, and all users will become frustrated with a product at some point. This also helps us realize that we are not our users. Step back and put yourself in the position of “I don’t know anything.”

Let’s say you’ve built up some personas and designed an interface that works for one of your personas, e.g. content operations team. You’ll have to add more features for the different personas.

Example bad assumption: “We only focus on power users, they always figure a way to work with any software.”

Example good assumptions (testable:)

The DevOps team needs a monitoring tool.
The download button will get more clicks if it has a different color.

Focus! Make one feature at a time work great. Iterate and keep making it better.

Eventually we ended up with an adaptive UI based on user roles.

For testing your assumptions, you can use questionnaires, usability testing, A/B tests, and beta testing. As your project progresses from start to mid to end, the tools you use for testing will probably change.

Avoid common mistakes:

Designing for yourself, e.g. using a download button when your users use a package manager.
Not testing for accessibility, “where did all the content go?”
Hidden actions, e.g. “where is my save button?”

Open source events and business strategy by Leslie Hawthorn of Red Hat & Laura Czajkowski of Couchbase

Leslie and Laura of leslielauralive gave a talk about a use-case driven tour of successful community engagement.

They talked about their discovery and experiences in the Ubuntu community, and how Canonical dropped Ubuntu on a community of Linux user groups which had lost some steam after being excited about standing up to Microsoft, and expanded the community to include people who were coming into the LAMP stack right when there was a huge demand of web developers.

Key takeaways:

Get a deep read on the landscape. Understand how you can effectively target your market with an MVP.
Megabudgets don’t exist. Target that market cost-effectively, because if you can’t provide ROI you’ll see that budget shrink.
Spend wide and shallow. Spend your money wisely, thinking about your company goals. One strategy is to target key cities, arrange user groups in each city arranged in advanced.
Use existing structures. Find groups and audiences who are already out there and receptive to your audience. Ansible is one project that has done this well by targeting groups friendly to their message but outside their existing customer base.
Your first DevRel hire is critical. Ubuntu hired key people who were respected in the community, and by doing that they gathered a bunch of momentum. Find somebody who has the community’s respect and can relate to them.
Sync regularly with company leaders. Are you achieving their goals? Understand what they want to learn from the community, and what the DevRel team needs to learn from them. This also keeps them up to speed with the value your team is providing.
Iterate quickly and thoughtfully. It’s difficult to do these at the same time. Change your strategy quickly at the beginning, but not in such a way that later you’ll have messaging conflicts about product direction.

Activating developers to drive your advocacy programs by Brian Douglas, GitHub

We need people outside GitHub to be just as excited about our product as we are about our own content. When I worked at Netlify previously, I was hired because I was engaged and excited about the product.

Developer advocates build communities that generate more advocates.

Your advocates can help push your product. When something happens, good or bad, you need your advocates to surface in the community and back you up. You can think of developer advocates as a specific type of superfan. There are a few things you can do to activate your developers:

Product Interactions

Find out what metric your advocates will judge you on, and minimize/maximize as much as possible. This could be in onboarding, using the CLI, or finding reasons to return to your product. Great experiences lead to great engagement.

Diving into onboarding: specifically, we want to help users get started quickly. How long does it take developers to use your product? 1 minute? 1 week? The longer it takes, the less likely someone is to use the product. Onboarding should not stop at signup, it needs to continue with education.

Encourage better interactions within the product. Identify key places where the product can be improved. As an example, inside GitHub there’s an educational “Styling with markdown is supported” note to help people who may not know markdown.

At GitHub, we use the SCOOP acronym:

Support (provide assistance to developers)
Content (generated from support)
Outreach (talks at conferences sharing that content)
Operation (educational program at GitHub, 1M users)
Programs

At this point, I had to take off for the airport. I hope you enjoyed the notes! If you enjoyed these notes, I appreciate your claps (up to 50!)