I attended DevRelCon in San Francisco on June 6-7. It was a superb event, with great speakers and awesome community. The following are my notes (not complete sentences) and pictures from the event.

Being Better At Developer Relations with Kathy Sierra’s ‘The Kick Ass Curve’

Steve Pousty (CrunchyData)

• Steve’s talk focused on how to be better at Developer Relations. Steve demonstrated this concept using Kathy Sierra’s “The Kick Ass Curve”
• You can find his slides here
• DevRel goal
  • Make users happy and successful with your product/service
• Get users to be awesome in the least possible time

• Different companies can have different curves
  • Background knowledge and experience of users (don’t control)
  • Quality of documentation and teaching material (control)
  • The actual design of the product/API (control)
  • The size and helpfulness of your community
• We often disagree with Product Managers and Engineers because PMs and Engineers think they are at a different place on the curve. PM and Engineers are familiar with the service/product and usually don’t experience “learning” about the service/product like outside developers
• Summary
  • Think about the audience (who you are targeting and how to get the pas the suck zone ASAP)
  • If we can’t get people out o the suck zone before they give up – we will never get them to experience power
  • Remember, when “talking” to others, to think about where they are on the curve
  • Use the curve when it helps, ignore it when it is doesn’t

Building an enterprise developer marketing program from scratch

Luke Kilpatrick (Nutanix)

• 34%
  • # of opportunities are lost as direct result of developer influence
  • More and more developers now have budget
  • Didn’t use to have much budget before
• What type of developers are you trying to reach
  • Marketplace Developer
  • API consumers
  • Tools for Developers
• Developers don’t believe you – they have to try it
  • Developers don’t trust you unless they try it
  • If you don’t have a Developer Relations/Developer Marketing – your product just might fail
• Early metrics and executives buy-in
  • Metrics takes time to flow in…can get up to 12-18 months or even longer
  • Need a champion
• Developer portal
  • developer.company.com
  • Even better – company.dev
• Suggested team structure
  • Content writer
  • Labs, blogs, own portal
  • Evangelist
  • Researcher
  • Community manager
  • Support
• Events
  • External hackathons
  • Code from external hackathons is never used
  • Most people who attend hackathons are probably new. Rarely, if at all, anything happens with the projects after a hackathon
  • Much better – hands-on labs
  • Internal hackathons are very beneficial

Leading with authenticity: tips for growing and nurturing developer communities

Katie Penn (Twitch)

• Stop marketing to developers
  • Know the customer – developers are unique flower
  • Bring content and solutions — understand their needs
• Developers are
  • Builders
  • Problems solvers
  • Smartest people in the room
• Beware of bios, developers are not all the same
• Lead with solutions, not roadmaps
• Fix problems for developers instead of pushing products
• Build communication channels
  • They must be two ways
• Engagement <—> Investment
• Go under the hood
  • Knowledge involves trust
  • How did we build an open source program?
  • Share how you build something – how you scaled something
• Share your roadmap
  • Another way to open dialog and get feedback
  • Slack
  • Published their roadmap and was able to get feedback
• Admit your mistakes
  • How not to do a hackathons – Salesforce $1,000,000 hackathon
• Developers + Authenticity = new Developer Marketing approach

A shiny new developer portal

Avital Tzubeli (Kaltura)

• Avital talked about building a new developer portal and in particular how to build getting started content
• She shared this picture which I think has very good guidelines for someone who is just starting with an API
• Your getting started guide – is your hook!
• Avoid cutting “not my responsibility” corners
  • Once someone has tried your API successfully and now they want to build a client – it’s easy to say “well, that’s outside the scope of what we do”
  • Take responsibility
  • Avital suggested to help developers with these problems as well

Creating high quality communities

Gerard Sans (AWS)

• Founded the GraphQL London meetup
  • Meetups every 2 months
  • Record the event
  • Great speakers and content
• Stats
  • 2016
  • 150 members
  • 40 attendees
  • 1 organizer
  • 2019
  • 1660 members
  • 100 attendees
  • 3 organizers
• Format
  • Top speakers – get top speakers
  • Top venue – get a good venue that’s easy to access
  • Prizes – offer prizes
  • Drinks – get good drinks
  • Food – get more just pizza
  • Recording – record the event so that people who couldn’t attend can watch the recording and people who are geographically in different places can also watch
• Top 3
  • Ambition
  • Passion
  • Have fun
• Get Gerard’s slides here

Distributed developer relations

Brandon West (AWS)

• Remote —> distributed
  • Instead of remote, call your team distributed
  • Remote implies that team members are “disconnected”
• Grads are 68% more likely to be interested in remote jobs
• 39% of the employees spend some time working remotely
• Working from home grew by 140% since 2005
  • 10x faster than office work
• Look for a manager who can manage distributed teams, not just a manager
• The good
  • Lower stress, higher engagement
  • Closer to your family
• The downside
  • Peer to peer relationship is not as good
• The good of travel
  • If you like to travel
  • Rewards/points
• The downside of travel
  • Eating poorly
  • Sleep deprivation
  • Burnout risk
  • Strains personal/family relationships
• If company allows, let your team members pay for travel using their personal credit card so they can earn miles/points
• Put things into logical groups to reduce travel:
  • Regional teams / geography
  • Channels
  • Live streaming
  • Writing content
  • Lead by example
  • Make sure everyone is using PTO
  • Find other channels
  • Find people to do work without getting on an airplane
  • Face-to-face time cannot be replaced
  • Get everyone into the same room (at least one or more times a year)
  • Slow yes
  • We always willing to help people —> leads to overcommit
  • Take time to decide to what to commit
  • Share experiences
  • If you travel with a co-worker, take some time off to go sightseeing in a new city

Fireside chat

Kelsey Hightower (Google)

Some key points from Q&A with Kelsey:

• I don’t forget what it’s like being a beginner
• When you have confidence – you make people around you confident as well, you make people more successful around you
• Kelsey put together a training for Google GKE engineers and asked them to just install Kubernetes
  • Customer empathy session
  • Most engineers couldn’t install Kubernetes. This lead to a number of software improvements when installing Kubernetes
• When you ask a question, first tell what you tried
  • I tried 1, 2 and 3 and only then ask the question
• Don’t be afraid to apologize

From start-up to enterprise

Phil Leggetter (Nexmo)

Phil had super awesome slides that are easy to follow. So, instead of my notes, check out his slides to learn what he covered in his talk

Towards a more inclusive developer portal

Adam DuVander (EveryDeveloper)

• Rethink your audience
• Find out what they want
• Make it easier to get it
• Find out what they want
  • Talk to them
  • Email
  • Realtime chat
  • Video chat
  • Feedback form
  • Quick surveys
• Make it easier get started
  • Tutorials
  • User cases
  • Blog posts
  • Sample apps
• How to add low code tools into your portal
  • Great article by Adam: API’s Dirty Little Secret
• One one my all time favorite DevRel resources:
  • Share Knowledge, Not Features — The Secret of Marketing to Developers is to Not Use Marketing

Sustainable developer relations

Matthew Revell (Hoopy)

Thank you to Peter Moskovits for sharing his notes from this talk

• DevRel is stressful – for some people, at some time mismatches of expectations
  • Many of us approach DevRel in an unsustainable fashion
• Why do we do DevRel?
• Three stakeholders need to be in balance:
  • You
  • The Developer
  • Business
• You (as an individual, as a DevRel contributor) – exhaustion
• The Developer: Indifference
• Business: ROI
• “DevRel folks get sick in December because it’s the only time they can.”

• #devrellife – humble brag
• Status on an airline is not a benefit, it’s a trap!
• DevRel is a job, not a lifestyle
• DevRel is a process, take one step at a time, it’s not magic
• Over-fishing the same developers is a challenge
• T-shirt: it’s hard to stand out if you’re using the same techniques as others
• What does a developer look like?
  • We need to be open to reach where people are
• Only a small subset of people are easy to reach. The majority is very hard to reach.

Why Target needed DevRel to attract and retain engineers

Ana Bahr (Target)

• Why did Target need DevRel
  • Support that things that Target engineers care about
  • Empower our engineer teams to collaborate
  • Challenges
  • Target it 70% contractors
  • No incentive to innovate
  • Waterfall project management
  • Need funds to create a new space for engineers
  • New computers
  • New space for engineers
  • Can we use some of the budget to sponsor community organizations
  • Hosting meetups
• CIO directive: build a culture around engineers
• Target is transformed into a product-based organization
• Sponsor conferences
• How did we start DevRel
  • Problems
  • No budget
  • Gaps and inefficiencies
  • Main point of contact has another job (speaker!)
• Questions
  • What are we doing?
  • What should we actually doing?
  • How can I figure this out
• What are we doing today
  • Weekly tech lunch
  • Inner conference (internal conference, 900 attendees, talks, workshops, lighting talks
  • CodeRED hackathon (2x a year)
  • Demo day (1000 people attend)
  • Volunteer events team
  • Communicate
  • Internal slack channel
  • Team t-shirts
  • External
  • External tech comm. engagement
  • Large number of external comm. organization target support
  • http://tech.target.com
    • Post a week
  • Open source
    • http://opensource.target.com
  • Target tech speakers
    • Go to various conferences
• What’s the value
  • Retention
  • What engineers care about
  • What does it mean for you
  • Today, no company can make, deliver or market its product

Passion … like magnets, it can attract or repel

Tamao Nakahara (Weaveworks), Baruch Sadogursky (JFrog)

This was one of my favorite talks. Tamao and Baruch did a role-playing talk (that’s why I don’t have notes) where Tamao is a conference attendee (Receiver) at the exhibit floor and Baruch is staffing the booth (Passionate person).

In the scenario 1, 2 and 3 they showed how not to behave. In scenario 4 they showed best practices of interaction between a conference attendee and booth staff. I highly recommend to watch the video of this talk when published.

Breaking down barriers to ‘Hello World’

Taylor Barnett (Stoplight)

• First ‘Hello World’ was written in 1978
• We have been using this program for decades
• Why ‘Hello World’ is important
  • Put the software to immediate use
  • Activation – one of the most important meters
  • Early WINS
  • Really great feeling – beginners and advanced developers
  • Beginners have less access mentors, more self doubt
  • Help people create better api experiences
  • Barriers to people getting started using words like this in content
  • “That’s all”
  • “Simple steps”
  • “Straightforward:”
  • “Easy”
  • #1 oversimplification
  • Types of failure
  • Empathy failure
  • Beginners Mind Failure
  • Wasted Energy
  • Bad docs
  • Developer environment
    • Don’t want to spend al day to setup it up
  • Strategies – how do we fix these?
  • Basics First
    • Getting started guides – don’t overcomplicate, learn how to do the simplest thing (Twilio)
    • How to setup with different code editors (Spring framework)
  • Working code
    • Users really want more examples (Auth0)
    • Make it easy to copy and paste
  • Common error library
    • Include a url in the error message with more information (Twilio)
    • Show possible solutions
  • More user testing
    • Pathways to empathy
    • Have someone with less familiarity review the content
    • Meet developers where they are
    • Find ways to feel their pain
    • Drive change based on those pains

You can find Taylor’s slides here.

How Twilio leveled-up developer training with TwilioQuest

Andrew Baker (Twilio)

• Path to training program (TwilioQuest), started in 2013
• Traditional training
  • Hotel conference room
  • Follow the instruction
  • People fall behind
  • Way to fast or way too slow
  • Self-directed and hands-on training
• TwilioQuest
  • Online, game-based
  • What’s working
  • 1200 students
  • NPS 64
  • On-boarding experience
• New (standard) Twilio account creation vs TwilioQuest account creation
  • 10% more likely to achieve 10 api calls
  • Threshold – 10 API calls – then on-board
• TwilioQuest starter pack
• Finish getting started – get a t-shirt
• What can do better
  • Usage
  • Drop with second exercise
  • Integrating TwilioQuest into other parts of Twilio
  • Only 1.6% of traffic to TwilioQuest from docs
• Gamification and self-directed training is effective
• TwilioQuest version 3
  • Downloadable version
  • Will developers download?
  • Will the video-game UX limit our audience?
  • Some devs don’t enjoy games

From the pulpit to developer relations: how being a rabbi prepared me for DevRel

Ben Greenberg (Nexmo)

• Ben’s talk started with a story
  • Someone’s loved one was in the hospital and upset that the Rabbi (the speaker) didn’t visit them. However, the family made no effort to inform anyone that their loved one was in the hospital, so therefore expected some level of super-power intuition to occur
• Community
  • A group of people who came together to impact their life
• “People will forget what you said, will forget what you did, but people will never forget the way you made them fee” – Dr. Maya Angelou
• Servant leadership
  • “Servant leadership is all about making the goals clear and then rolling your sleeves up and doing whatever it takes to help people win. In that situation, they don’t work for you; you work for them” – Ken Blanchard
• Teaching != Preaching
• Sharing != Selling
• Your success is bound up in the success of your community
• Technical problem is not always solved by a technical solution

Public Speaking and Storytelling, breakout session

Moderated by Jen Sable Lopez (Outsystems)

Thank you to Peter Moskovits for sharing his notes from this session

• Your personal story is often boring. Your professional story is often boring, too. Combine the two; it makes it unique, special, exciting.
• Presentation tools:
  • http://gitpitch
  • http://slides.com
  • Trello/index cards to move things around
• Work on the emotional (not intellectual) journey with the audience
• Consider to tell a story on a curve
  • happy note – negative/controversial part – happy note again
• Start your presentation without saying hi, intro, bio, boring stuff. Catch the attention of your audience, shock them. 2-3 minutes into the presentation; curve back to the intro, context; why you’re the one giving the talk
• Women often feel that they have to establish their credibility up-front to get the audience’s attention in the first place – gender bias
• Empty slides are powerful – the audience pays attention to you (PowerPoint: press “B” for black)
• When the audience is reading the slides, they don’t hear what you’re saying
• Practice
  • Transitions are critical; practice them to death; that’s where you lose (or impress) people
  • Film/record yourself
  • Last slide: display your 3 key points + your contact info; invite attendees to take a picture of that

DevRelCon SF 2019 was a truly amazing community conference. Thank you to Matthew Revel, Tamao Nakahara and Nilay Yener for organizing this event.

To end this blog post, here is a picture of IBM Developer Advocates who attended the conference (but not everyone):