After a lovely evening at the DevRelCon awards and dinner with a few new dev rel buddies, the second day at DevRelCon had arrived. I headed over to Westminster, to the QEII Centre for breakfast, coffee and the welcoming speech. Upon arriving it was clear the conference was much bigger, with at least double the number of participants than the previous day and a more formal setting. The day was split into three tracks – the GitHub Auditorium, IBM Room and GitHub Lounge – with a whopping 35 talks and workshops throughout the day. I was looking forward to getting stuck in and seeing what additional insights the day had to offer.
If I can do it, so can you
The opening talk from Dr Sue Black was an inspiring account of her life and career to date. Dr Black reminisced about her childhood, always spending pocket money on maths textbooks and in her words being ‘geeky’. As she progressed into adulthood, she found herself in an abusive relationship and then as a young single mother in a women’s refuge. Wanting to pursue her dreams, Dr Black went back into education as a mature student at 26 years old – first completing a polymaths evening course at Southwark College. Dr Black then went on to attend London South Bank University, achieving a degree in computing followed by a PhD in Software Engineering. Dr Black’s career since then has been impressive to say the least – recently appointed Professor of Computer Science and Technology Evangelist at Durham University, Dr Black’s other posts include Government advisor, technology columnist for The Guardian, founder of #techmums, mentor for Google Campus for Mums, author of Saving Bletchley Park and so much more. The talk was a truly amazing account of Dr Black’s achievements and continuing contribution to the tech space – a great way to open the main conference. To read more about Dr Black’s story – check out this recent article.
The next talk from Leslie Hawthorne, Senior Principal Technical Program Manager at Red Hat focused on the theme of cultivating empathy. Leslie opened her talk by discussing why empathy matters. Aside from the obvious (you’re a nicer person), there are personal benefits. Did you know that empathetic people are better negotiators and also better compromisers? Leslie goes on to explain “Empathy is a choice we make every day in our interactions” and actually it’s not an innate skill. So how can you cultivate empathy?
- Introspection and self-awareness, a bullet journal is a great place to start
- Practice active listening – communication techniques: listen, concentrate, respond and remember. The dev rel community is often in transmit mode and active listening can help dev rel teams get developers what they actually need
- Observe body language and power phrase what they have said to you back to them to indicate you have understood them
- Read fiction – it is key to the cultivation of empathy and activates the brain
- Be curious and avoid assumptions. When we make assumptions we are shutting down and narrowing the trajectory of dialogue
- Be explicit and be inclusive in your values – dev rel is an ‘approval economy’. The key strength is in the values of the company, community etc
- Discourage hippoing. ‘Highest paid person’s opinion is the only one that matters’
- Don’t flip the BOZO bit. From Dynamics of Software Development book, everyone has a bad day and people make mistakes. Don’t assume one mistake means that person will always make mistakes. We need to make room for people to make mistakes, learn from them
- Make it truly ok to fail
- It’s about you too
Leslie ends the talk by raising the point that everyone in the room has the ability to cultivate empathy and that it’s not just about dev rel. Empathy is much wider reaching than your work life, it should be something you can implement in your community, your personal life – everywhere. Try to be effect positive change by sharing your skills wider than the developer relations community.
Dev rel and enterprise sales – an unlikely partnership
It was then time for everyone to split off and go to their chosen talk. I opted to stay and listen to JJ Kass, Head of Developer Programs at Dropbox. JJ is from a sales background and from her previous experiences she could clearly identify the strength and strategic value in linking sales to dev rel.
Historically, Dropbox has always been known as a cloud storage company although in recent years this has changed. Dropbox understood that the release of APIs increased developer activity and leveraged this. They also understood the key aspects of the developer ecosystem for customers:
- Use of 3rd party apps and partners connected with Dropbox. Content-centric
- Build custom integrations in-house to solve internal workflows
- Adding Dropbox to external facing solutions to enhance the customer experience
JJ then went on to explain how Dropbox got dev rel and sales working together:
- Sales sell the vision to customers and prospects (open ecosystem > simplify workflows > scale and size)
- Dev rel evangelises and enables technical sales teams:
- Host internal technical training for sales teams:
- Build apps and learn how to communicate with customers
- Use the opportunity to test workshops and upload as a guide
- API office houses – led by an evangelist to come and talk about technical queries
- Solve common workflows – business scripts library available on GitHub
- Dev rel and sales feedback loop about integration requests and API feature requests
- Partner to engage customers in community and events – events, onsite training, enablement (business code samples and scripts in Github repo), marketing (case studies)
Building your internal army
Amara Graham, Developer Advocate at IBM took to the stage next, discussing her personal experience, of dev rel. After transitioning from a full-time developer role to the developer relations space two years ago, her advice was about building an internal army. It’s definitely not about colleagues that are going to go and fight for you, more an army of collaborators and advocates of advocacy. Amara explains that the best armies have a group of people with complementary skills. These might be all different to each other but work in sync and harmony. In dev rel, individuals and teams should be able to work cross-functionally and be their own internal advocates.
How to build an army:
- Build an internal brand and an external brand
- Use tools like LinkedIn, Twitter, company directory etc
- Ask a lot of questions – be present and involved
- Give back – incentivise and educate
- Let people know what you do
- Post internal blogs
- Know your limits and when to ask for help – technical knowledge limitations, time/bandwidth
- Know where to get help – business development, engineering, product, marketing/partner marketing, sales
- Introduce yourself – think a modified elevator pitch. Share metrics, intentions, goals specific to this engagement. Often with dev rel, your colleagues in other departments might not know what you do
- Be a team player – lead the engagement. Understand there is a healthy tension here, but everyone should be working to a common goal
Surviving 1,000+ PRs from Hacktoberfest
It was then onto Elmer Thomas, Developer Experience Engineer at Sendgrid who gave his honest account of being involved in Hacktoberfest. Elmer explains there were many things to consider when planning for the ‘Hackening’, such as swag, internal and external marketing, issues, dashboards and reporting. At first glance, it sounds easy, but the work involved is clearly very detailed and precise in execution.
It’s not just about distribution. There needs to be consideration given to how developers qualify for swag. Sendgrid’s qualification model was: 5 easy PRs, 2 mediums or 1 hard, which was put in place to raise the quality of submissions. Each developer who qualified received a shirt and sticker. When Sendgrid first started, swag was being managed from a spreadsheet, but this process clearly needed automating. This is when they decided to outsource swag and partner with Kotis to deliver swag fulfilment in an easier to manage way – through their API. A key point Elmer explained, was that you need to be very clear about with developers about what the criteria is, how many shirts are available and how they get one – otherwise, you’ll have a bunch of unhappy developers.
Internal and External marketing
Internal and external marketing is an important part of organising for Hacktoberfest. Internal marketing considerations include email, as you’ll need to let everyone know what you’re organising. The next big thing to watch out for is how to handle code reviews, which for Sendgrid became a problem when they were receiving so many submissions. They found the best way to handle these was to get buy-in from the internal engineering team and do an internal hackathon. Sendgrid provided swag and food for their team to incentivise the team and it clearly worked with 20 participants this year. External marketing should be done through social media but targeted at the developer community – Twitter, LinkedIn and Facebook all being key as well as their own blog.
The next biggie to tackle – issues. Sendgrid found the best approach was to ensure these had a clear title. When someone contributes they’ll see all the issues, so they should have a clear and catchy title, a brief description and intuitive labels for discoverability and reporting.
It goes without saying that for any event you host, aside from thorough planning, flawless execution is a must. This is especially true when dealing with a developer audience. Sendgrid suggest a labelling strategy, this should be three different types of labels so developers can easily understand the difficulty level (easy, medium, hard). There should also be status information (approved etc), the type of issue, and an identifier such as beginner labels, so new developers can pick those best suited to them. A dashboard and internal and external leaderboards are essential. There should also be up-to-date information on code reviews during the event.
A key component of any event. Sendgrid suggest the following as a minimum:
- Valid, opened PRs
- Number of contributors
- Number of story points per PR, including code reviews
- Swag recipients
Elmer assures us that there is nothing to fear with the proper planning, but to start planning today and it takes time and resources.
Cultivating community through events
Laura Czajkowski, Senior Developer Community Manager at Couchbase is up next to give her best practice advice on developer event planning. Again, planning is an important and critical element to Laura’s approach to developer events, saying that there is so much prep to do before any event. There are also challenges you might face, such as your finance and marketing teams not understanding why you have chosen a specific event. It can be difficult to choose the right event in the dev rel space, there are so many and it’s important to opt for the ones that yield the best results. Therefore, there needs to be an event strategy and plan, so that it’s easier to explain to internal stakeholders. Laura goes on to say that you’re likely to always get pushback internally, but it’s easier if you can show your decision criteria. Here are Laura’s top tips to running events:
- Do your homework – decide which ones are going to work for you, your developers and your strategy
- Share event attendance with your team so you’re not always on your own
- Keep in mind that events can make it difficult to get buy-in
- Create a conference playbook. Define the event owner, core team, extended team, key stakeholders and purpose
- Create an event strategy with key KPIs
- Create a list of events for selection – once you’ve decided on the events that satisfy your conference playbook and metrics reach out to vendors
- Use the EvMan tool to help you manage your events easier
- Create and event logistics and strategy document, which covers all the key event details – theme, event date, location, URL, booth, portal, expo hall hours, staffing times, tables, set up, tear down, hours, who is at the booth, objectives, event staff, attire and more
- Event pre-briefing meeting – review booth duties, go over the event strategy doc in detail the morning of the event
- Complete an event run through after your briefing
- During the event always have a backup plan in place and refer to your schedule
- Reflect on the event outcomes, as this will influence future events and event strategy. Track everything and complete a post-mortem – what was the event actually about, key convos, number of demos, leads scanned, was the event as expected, should you go back next year, did you reach goals
- Complete a post-event checklist – send a debrief to the team, post on internal social sites, give product feedback that you’ve received at the event, create follow up emails using marketing tools
- Ensure you follow up with the community – post-event community engagement, future champions, use cases, collaboration
ROI is a trap
It’s then downstairs to the IBM Room for the next talk from Steve Pousty, Developer Relations Lead at DigitalGlobe. After 14 years experience in dev rel, Steve clearly has a lot of first-hand knowledge about internal buy-in and managing senior stakeholders. It was also the funniest and most NSFW talk of the day.
First Steve sets the scenario – you and your team know you should do an event and you come up with a great swag idea. You’ve gone to share this internally and THE question is posed ‘what’s the ROI on that?’. The idea then dies. Steve’s view is that ROI is a passive aggressive ‘i don’t agree’, a good way of shutting down ideas that can’t easily be attributed to ROI.
In dev rel it’s going to take trust and good intentions on everyone’s part and there should be three overall goals:
- Make developers excited and successful on our product or platform
- Grow companies likeability, visibility and thought leadership
- Grow your own personal brand
Steve said these should be used to guide all discussions in dev rel. If you are putting on an event, how does the event fit into one of those goals? Not everything of value can be measured (and Steve has come from a data background, he’s loves data). Sometimes we just need to accept that it can be extremely difficult to get accurate numbers, sometimes we cannot attribute a specific activity to ROI because:
- We have a suspicious audience
- We have little control over our user’s behaviour (we need them more than they need us)
- Most of our outcomes are not direct – it’s hard to attribute especially in events
Steve closes by reminding us to keep the phase of our company/product in mind and to always look back on those three objectives.
Design your content strategy with data
After a spot of lunch and a couple of interesting micro-talks from Dr Mo Haghigni, Head of Developer Ecosystems Group at IBM, Simon Phipps, President at Open Source Initiative and Don Goodman-Wilson, Developer Advocate at GitHub it was time to head back downstairs to the IBM room.
Martyn Davies, Senior Developer Advocate at Nexmo takes the stage to discuss content strategy saying “Write all the things” is typically content strategy, but without data, you won’t know what is actually working. Martyn explains that you should have a content strategy in place and should understand:
- Who is the content for?
- What problem(s) does it solve readers?
- Which channels to publish on?
- Who is going to write it?
- How do you get people reading it?
Martyn then breaks down his approach to content strategy.
Who the content is for?
- 1 API or many?
- Are the APIs your product or do they support the product?
- Do you have client libraries?
- What level of developer is ready it’?
Where to look for the answers
- Who is the content for? – Which client library is used the most (check logs)
- Which API is the most popular? Which is the least popular? (Generate tutorials, blog content etc)
- Do people talk about you on Stack Overflow? What tags are they using?
- What problems can you solve for the readers? – Regular issues that come through support (add to the future content list)
- If your documentation SEO ranking is lower than you’d like, find out how developers are actually searching for your documentation e.g. how to do x with y
- Know what people are searching for by using Google Analytics on your site and forums
What channels to publish/promote on?
- Look back at how much traffic you’ve had and where traffic has come from – Referrals, UTM codes
- Experiment with publishing where your audience ‘is’
- Don’t fear paid placements there are some good sites
Who is going to write it?
- Check incoming traffic for external writers (who has written about you in the past?)
- Look for super helpful members of your Slack community
How to get people to read it?
- Build lists of newsletters and external outlets
- Was it asked on Stack Overflow or another forum?
- Use it as part of onboarding emails
- Link it from your docs as additional reading/tutorials
Where can you find data to generate ideas?
- API logs, stack overflow, support tickets, slack community, search queries, site traffic and click tracking
Once you’ve done all of that, what’s next? Martyn suggests creating a dashboard to distil all your information and use that to grow your developer content strategy.
Dev experience empowering marketing
Tamao Nakahara, Head of Developer Experience at Weaveworks was on next to discuss how the dev experience can empower marketing. Tamao starts her talk by outlining some assumptions about dev rel – the goal of the team is to collaborate, build community and partnerships. She then goes on to give her key takeaways from this talk, which are:
- Dedicate 10% to internal teaching
- Set goals for collaboration, innovation and sharing the load
- Encourage imposter syndrome
This is closely followed by her best practice approaches for empowering marketing through the developer experience. This talk is really about getting your internal teams to understand who you are, what you do and to ultimately end up collaborating.
The first step – create an internal site and FAQ about the dev rel team and explain what you do, who you are and how to reach you. The site should also give broad definitions, goals and responsibilities so it’s clear what other teams can expect from you. It’s also a great idea to show some concrete examples from other fields – such as community programs, word of mouth marketing, champion programs and dev branding. Tamao’s go-to examples from outside dev rel are:
- Sephora – makeup community
- Instant Pot – food tech community
- Liquor brands – brand ambassadors
Next, you’ll need to get out and about doing internal introductions and evangelising. Think about all the people in your company, as some might be really interested in what you’re doing. Get a pitch prepared and leave it open-ended, presenting your ideas and then see where it goes. Once you’re finished with all of that it’s time to repeat and reinforce, as you may find you’re explaining the same thing multiple times to the same people.
Finally, you’ll want to try and collaborate. A good way to do this is through internal education such as a speaking series, talks, getting external people in to present talks. Remember who your audience is though, with marketing and business colleagues you’ll want to make it more accessible and not overly technical.
Developer content marketing
To wrap up the day Adam DuVander, Developer Marketing at Zapier talks about developer content marketing and give his five-step plan to publishing developing content:
- Create a content calendar
- Generate ideas
- Seek help
The first step is to create a content calendar:
- How many blog post per day, week, year?
- Get some sort of tool, for example, Trello, Google Spreadsheet, Asana, Text file
- Your calendar should be visible and specific, make sure there’s no placeholder text for titles
- Create templates for post types
Then it’s on to idea generation:
- Share knowledge, not features
- Use cases/problem solving
- Frameworks / Technologies
- Partners/other evangelists
- Internal/external chat
- Support tickets
Next up writing:
- Skimmers make your life easier
- Outline with subheadings
- Set aside time (just enough)
- Don’t edit – it doesn’t need to be perfect
- Start with people in your own company
- Promote – internal before external
- Externally – Hacker News, Reddit, Slashdot
- Tell your friends
- Internally – intranet, Slack, email footer
- Talk about it everywhere
Finally, seek help:
- Avoid burnout
- Show people the value of writing content to engage stakeholders internally
- Ghostwrite for colleagues
- Look outside your company
- Hire freelancers
- Hire editors / producers / automation
Adams final comments are that you shouldn’t over-engineer your process, as the goal is to write content and share it with your developer community.
Final thoughts on DevRelCon
I had a great time at DevRelCon, finding both days packed with knowledge and insight. Over the two days I identified these key themes and topics which cropped up several times:
- KPI’s and attribution
- Content writing
- Best practice advice
DevRelCon is clearly a popular and well-respected event in the dev rel space and it was really nice to see the community mindset of ‘we’re all in it together’. It doesn’t matter if you’ve been in dev rel 15 years, or you’re just beginning your career – those at DevRelCon were welcoming and happy to chat and share knowledge with everyone.
A lot of the people I met over the two days were either the only person on their dev rel team, or had been in that position in the past. There were, of course, those who are part of a much bigger team of dev rel colleagues, but almost all I spoke to spent a lot of time of the road alone. That’s why dev rel events like DevRelCon are so important to the community, it’s the chance to get together, share stories, best practice advice and be amongst other people that get it. There’s little guidance about what makes dev rel good, measuring success can be hard and it’s a unique experience for every team – events like this are what brings the community together and progresses dev rel for not only those working it but the developers they are doing it for.