Last week I headed to London for my first DevRelCon. Hosted by our friends at Hoopy, the event has become a bit of an institution in the developer relations community. I was excited to see what the buzz was about and opted to attend both days – the unconference and conference. Over the last three years it’s been running, DevRelCon has expanded to London, San Francisco, China and Tokyo, but the unconference in London was the first of its kind. Both days proved to be insightful and our two-part blog posts will cover the highlights and key takeaways from all the talks I attended.
As I arrived at the Microsoft Reactor in East London for the unconference, I was unsure about what to expect. The day kicked off with an opening talk from Matthew, CEO at Hoopy. The proposed agenda – sessions in the morning and afternoon, with some lunch and networking in between. The difference about attending an unconference is you don’t actually know what you’re going to be learning and participating in until the day. Matthew explained that we, the delegates would be proposing the topics for the day and we’d all get to vote for our favourites. The unconference was split into two tracks, the main room which would be hosting slightly more formal talks where those suggesting the topics would be presenting them to the group. The other room was for ‘birds of feather’ sessions, a much more informal and participatory setting.
Birds of feather topics and votes
Main room topics and votes
Creating content, when you’re not a writer
After grabbing a cup of coffee and wandering between rooms voting for my favourite topics, I headed back to the main room for the first session. Lorna, a Developer Advocate at Nexmo kicked off the talk explaining that although she comes from an engineering background she does write a lot. Lorna’s view was that everyone can get better at writing content, but it needs to become part of your working day, something that has to be learnt and become a habit. This is something I completely agree with, even for a seasoned writer getting focused time and somewhere you can concentrate without distractions or interruptions can be challenging.
I can completely understand how for developer relations folk, finding the creative energy when you’re on the road a lot must have its challenges. Where do you find your quiet space and where do you find your creativity when you’ve been a long journey and you’ve got another ahead of you? Lorna’s top tip was to always write down your content ideas – even if they aren’t very good. Her belief is that capturing them is key, as when you come back to write a piece of content like a blog post you can just look back on your ideas list and pick something.
Lorna’s key questions you should ask yourself before you start writing your content:
- Who is this post for?
- Are they familiar with the product?
- Do they already have an account?
- Is it for newbies?
- Are they onboarding?
- What are you giving the reader? e.g. the ability to build something
Once you’ve established the answer to these questions, Lorna’s top tips for content writing for technical audiences were:
- Write an outline, it will help give you structure. Where are you going? Where are you taking them? What else do you want to tell them? What steps does the reader need to take?
- Don’t be afraid to split your content into a series
- When you come to write the actual words keep the subheadings in the text, which will form landmarks for your narrative
- Break it up with images – screenshots, diagrams, flows (this can help the reader)
- A code sample is really important and will really show developers what it will look like for them
- Use some lists (bullet points)
- Consider different types of content – What does the user know or not know?
- Ensure the reader knows how to move forward and what the action is for them
- Think about the different audiences you are writing for
- Don’t get hung up on the word count for online, the only time it matters is for print
- Do pay attention to reviews and feedback from peers. If you’re on your own, ask for feedback from users (tweet etc). The questions that come back will help your output. It’s about how you communicate with all sorts of people from all sorts of places (internal/external). Find someone to help you
- There aren’t really any shortcuts. Build an example that showcases what you want them to build.
- Set yourself up for success by planning ahead and setting yourself time
The session closes with a Q&A which provides some more insight from other DevRelCon delegates. A key point raised from an audience member was about having your own writing style and sticking to it. Dev rel folk have their own professional brands and it’s important to try and demonstrate that in your writing and communication style. Stickmen, funny titles – whatever works for you.
Lessons learned creating a DevRel program, strategy and roadmap
It was then time to head to the next session by Manil and Ben, Developer Advocates at Invision, who have been building a developer program from scratch. The talk opens with them discussing how they were searching online for dev program best practices and found advice was generally scattered across the web making it difficult to know what the best practices actually were. What better place to discover developer program best practice advice than at DevRelCon? Ben and Manil split the room into a few groups and everyone broke off to discuss best practice approaches from their previous experiences.
- Knowing your audience
- Get out in the community
- Content is king – but you need a community who values you
- Transcribe talks – not everyone has time to watch the video
- The core of the community is curiosity
- Talks need to be catered for the audience
- Story driven talks work better than data talks, but story talks need data!
- Tangible shared experiences within the DevRel team – tell a story and come back to a core value and tangible output
- Building communities
- Important to deliver the same message. Everyone on the team should be saying the same message but consider using different channels/outputs – e.g. same message but over youtube, blog etc
There was actually a fire alarm that disrupted the session and everyone got evacuated, luckily I managed to capture the final comments written on the whiteboard:
- Be direct and focused on driving behaviour. Measure and know what results you want
- Be transparent to your developer audience about what you know and what you don’t know
- Get to know your developers and tracking what they are using, reading and engaging with
- Step outside your comfort zone and don’t be afraid to fail, you can always pivot
Stickers, stickers, stickers
After everyone was back in the building it was time for lunch. It was nice to have the opportunity to chat to other delegates and discover the sticker pile which had been started by one of the delegates and grew very quickly. It’s safe to say stickers are a fairly emotive subject in developer relations – developers love stickers and so do we! My laptop is now even more covered than it was before (sorry boss). I think there’s definitely some research that could be done into what makes a successful sticker in developer relations, judging by how excited everyone was at the sight of stickers i’m sure there would be lots of contributions.
Showing the business value of developer relations
After spending the morning in the main room, I decided to go for the more participatory sessions in the afternoon. The first birds of feather session were about showing the business value of developer relations. One of the first points that was raised, which is key – is that there is definitely a big difference between companies that depend on developers and companies that do not. Ultimately, if a business model directly involves developers to enhance, grow and innovate the business value, strategic strength and opportunity of a developer relations team is pretty much business critical.
Challenges & why it’s hard
- There can be a long lead time
- When the product is not dev focussed it’s much more difficult
- Measuring monetary value. A lot of devs use free tier products, so it’s hard to justify how ‘successful’ it is. A dev might build a really good app with a free product, but how can you track back and justify that?
- How do you maximise monetary value?
- Attribution to activities
- Understanding what success looks like, as it can be different for different companies and departments
- It’s not just about developers being happy. It always has to come back to money, growth, revenue – strategic value
What it could be
- Real value exchange – There should be a consideration around the ‘developer economy’ as a whole, rather than a metric or KPI. Business leaders and sales teams need to be educated in the differences between developers and normal leads. e.g. don’t sell to the them
- Positive perception of developer relations
- Collaboration with business development
- Trust from business senior leaders that there is value in the DevRel team and sometimes a monetary value cannot be attributed to a specific activity
When it works
- Senior stakeholders believing in your value are essential to DevRel team success
- Being able to ‘step outside’ normal metrics and experiment with different approaches without having to justify to senior leaders
- Foster change from those who execute the change
Running effective workshops
Onto the next birds of feather session and an essential part to most developer relation roles – events. This session shared struggled and best practice advice about how to successfully and effectively run workshops with developers.
- Listen in vs. Hands-on
- Devs tend to want to jump straight in, although this isn’t always possible with some technologies
- Devs progress at totally different rates, so throughout a workshop, there will be different task completion rates at different times
- There is sometimes too much content and it’s impossible to get through it all
- Getting delegates to complete pre-workshop tasks – downloading software etc
- Devs registering but not turning up
- Listen and apply
- ‘What can we build in 45-60 minutes’ that can showcase the ability of platform/product
- Let people work through themselves and tie questions back into the whole group
- Break repositories down into smaller chunks
- Use MVP’s in workshops to help facilitate technical queries, community helping the community
- If there are 10 tasks, label them 1-6 and tasks 7-10 are optional. That way everyone gets to 6, and the devs that do more than that feel like they’ve done a super good job
- Test workshops out internally before delivering them to your dev community
- Use Glitch to minimise browser/download issues with prerequisite tasks
- Charge nominal amount ($5-10) for a workshop and donate money to charity
- Pop up banners to promote workshops/meetups. Geo-targeting for website visitors
- Social media promo
- Piggyback on bigger communities and amplify message through those communities e.g. partner ecosystems
- Try to understand the audience and how you can effectively communicate with them. e.g. where do your developers go and what’s their day so you can target them without them going out of their way
- Get valuable product feedback from workshops and take back to engineering teams to fix
What is the actual developer relations job?
A question that developer relations get asked a lot – ‘what do you actually do?’. When companies get their first developer relations team (sometimes just one person), there can be a misunderstanding about what they actually do, the remit of their role and their value. The group shared their opinion about the role, struggles and best practices:
- Free rein and no direction of what dev rel should be
- There’s no guidance on what’s good/bad in dev rel
- 50/50 split on people having a roadmap they are meant to be following for next 3/6/12 months and others who are reactive to the community
- Sometimes the dev-rel team isn’t responsible for all tasks, therefore roadmaps play an important part by getting feedback from developers sorted. e.g. documents need to be improved > dev rel > document team roadmap
- Track roadmap vs reactive activities. If the same reactive tasks keep coming up they can be looked at for repeat offenders
- Important to understand from product team when products are being released, so that dev rel teams can plan all surrounding activities for the product. Especially when it comes to launching products at events/conferences
- Making product accessible – allowed to make mistakes and fail
- ‘Internal evangelism’ – training internally
- Inter-team conflict resolution e.g. two teams doing something similar but siloed then there are difficult convos. Dev rel sometimes gets in the middle to resolve
- Dealing with PM”s a lot to get product improvements made
- MVP management, some with the loudest voices are very vocal and demanding about changes
- A lot of work comes from the community, what they are talking about on forums, twitter etc
- Dev-rel should see beyond the product. What do the products and tools actually mean for devs – bigger picture, where is design going? Where is the language going?
- Trust from senior leaders that the dev-rel team have interpreted feedback from community and priorities correctly to build their own roadmaps
- Events are time-consuming – planning, attending
- If developer relations teams had more time, some would like to build better relationships with internal teams so that it is easier to get resources/activities done
Breaking into DevRel
The final session of the day was back in the main room, with Alex a Developer Advocate at Nexmo who wanted to share his story about getting into developer relations.
Previously working for Mozilla reps and Tech Speakers, Alex’s role at Nexmo is his first job in dev relations. Friends kept asking him, how do I get a job like yours? Alex decided the best way to find out was a survey and the results (so far) have shown that everyone’s journeys have been different, but similar in some aspects. That might be partly due to ‘labels’ dev rel are given, but generally speaking the role covers:
- Developer community building
- Public speaking
- Technical writing
- Event organising
- Building stuff
Alex’s top tips for breaking into developer relations were:
- Public speaking – Mozilla Tech Speakers, Toastmasters
- Technical writing – start blogging, document all the things, join a writers club
- Community building – Mozilla reps, Fedora Ambassadors, Codebar, Champions program
- Event organising – meetup.com
- Build stuff – build and share on Github
Alex then opened the question out to the floor, how did you get here? It seems DevRelCon delegates progression into developer relations was fairly typical – technical backgrounds, some from engineering/developer roles and it was a natural step into developer relations from there.
DevRelCon Awards 2018
At 7pm everyone was back at the Microsoft Reactor for of drinks, networking and of course, the DevRelCon awards.
Congratulations to all the winners:
- Best new DevRel program award: Sentry
- Most Welcoming Developer Community Award: GitHub Education Campus Experts
- Best DevRel Program Overall goes to Nexmo
Stay tuned for part two of our DevRelCon recap, where we talk about the key takeaways from the main conference.