What I Learned from DevRel Uni

DevRel Uni is an immersive program that runs for six weeks, welcoming a new batch of students each year. I had the privilege of being part of this program this year (2024). Passionate about the Developer Relations (DevRel) profession? This article is for you. I will outline the program’s structure, the key takeaways, and even “multipliers”.

The DevRel Uni Program permalink

Each week is packed with activities:

• Guest Speaker Sessions: A session with a DevRel pro. They would share their insights and experiences.
• Twitter Challenges: We were asked to to tweet daily about DevRel. This fostered a habit of active engagement. Many of us used this to reflect on each week’s session, and share extra materials. Some of us also used this to build/ learn in public (more on that later).
• Assignments: These need significant effort and commitment. They push us to apply what we learnt in a practical context.

The program is organised by Bianca Buzea, and boasts an impressive lineup of speakers: Steph Orpilla, Patrick Collins, Austin Griffith, Nader Dabit, and Michiel Mulders. They are seasoned pros in the web3 DevRel space, and imparted a wealth of knowledge and experience to us.

From Inspiration to Action permalink

In DevRel, there are always many things that you know you should be doing, but don’t actually get around to. I am super thankful to DevRel Uni. This program the permission + encouragement to overcome this hurdle on a few fronts.

Twitter

I have always been an occasional Twitter user. I default to spending more time writing code. See ShipTalkers + context on twitter. But that is a vestige of my being a software engineer prior. I’ve come to realise just how important being active on Twitter is for DevRel, especially in web3. DevRel Uni’s Twitter task was actually fun, and I ended up producing a mega Twitter thread. Also, here’s a Twitter list of the entire DevRel Uni 2024 batch, follow us!

Build and learn in public

Shawn Wang (a fellow Singaporean 🙌) has an amazing article, Learn in Public. I have read this years ago, but never put it into practice. DevRel Uni gave me the all-too-important push to finally get onto this. This took the form of starting a YouTube channel dedicated to Hands-on DevRel. I record myself doing everyday DevRel tasks, narrating my thought process. Plus, occasionally throw in some tips.

Cross pollinating ideas

We needed to compress a lot of information from a different set of speakers. Doing so within a short time is challenging. On the flip-side, this has a rewarding side-effect: Novel ideas through synthesis. Doing a short retrospective each week led to many a brainwave. The theme was taking idea A that I was already familiar with prior. Then “marrying” it with idea B that one of the guest speakers had just exposed me to. This would form idea C which is something novel. Then I’ve turned that idea C into actions. This took the form of messaging my DevRel team, with the intent to put it into practice. Here is one of those messages, which exemplifies this:

A Diverse Learning Environment permalink

Our batch comprised a fascinating mix. It ranged from those aspiring to start careers in DevRel, to established professionals. This diverse group created a dynamic environment conducive to peer learning. Most interactions happened in a lively Telegram group chat. These chats often overflowed onto Twitter.

There was a rather interesting moment around 2 weeks into the program. I discovered, through memes, that I had two of my batch mates that I had interacted with before! They had attended a webinar that I gave on DevRel as a profession only months before.

Best Ideas from the Speakers permalink

Throughout the program, several key ideas stood out to me from the various speakers:

Bianca Buzea

Start a new DevRel role with a bang - have a 30-60-90 day plan.

Steph Orpilla

When developers read your documentation, in doing so, they have a user experience (UX). Consider it, and improve it.

Patrick Collins

DevRel’s goal is to get developers to know, use, and love your technology. Focus on what people care about. Use edutainment (education + entertainment) to deliver your message. Formula for continuous improvement: A-B test, learn, iterate, and repeat.

Austin Griffith

Get developers tinkering with Solidity as fast as possible. The target is two minutes, so optimise like crazy till you get there. Build the tools you wish you had, and make them public; if they’re useful, they’ll get popular.

Nader Dabit

Repurpose content for maximum reuse^[1]. Turn the same thing into a demo repo, an article, a workshop, a conference talk, et cetera. Also, build in public and share your learning journey. (This validates Shawn Wang’s philosophy.)

Michiel Mulders

Design optimal learning journeys for different segments. Supplement documentation with technical videos.

Best Multiplier Ideas permalink

I have saved the best for last! Some ideas from multiple speakers resonated and revealed underlying themes:

Steph Orpilla & Michiel Mulders

Use frameworks or methodologies when planning developer documentation. Use resources like Diátaxis and The Good Docs Project.

Patrick Collins & Austin Griffith

Embed metric collection mechanisms. Include them in educational materials to measure effectiveness. If you are A-B testing, you need to know which side of the test performs better to inform your next iteration. Patrick’s example was a specific phrase in Solidity code. Austin’s example was a dedicated JSON-RPC endpoint.

Nader Dabit & Austin Griffith

Online and asynchronous resources are better than in-person events. They almost always provide better ROI .

All speakers

Developer education is the most important part of DevRel. If there is only one thing that you do in DevRel, this is it - so dedicate the majority of your effort to education.

Common Threads and Contrarian Views permalink

There was an interesting common undertone among all speakers. One which suggested that the DevRel profession often gets the above aspects wrong. Despite multiple speakers effectively saying the same thing. This supposedly contrarian viewpoint might indeed be the “secret sauce” to DevRel. One that sets apart top calibre DevRel professionals.

What Should Have Been Covered permalink

While the program was comprehensive, I felt a few areas had room for improvement:

DevRel Strategy

How do you design a DevRel program, and structure a team and processes to deliver it? That is the top line question in DevRel strategy. I speculate that these aspects weren’t emphasised as much due to the focus on newcomers to DevRel. Understandably so.

Developer Success and Tooling

Let us say that you have done a good job of developer marketing and developer education. Next, developers begin to build using your tech. How do you maximise the chances that they will be able to complete their task? There is an entire practice area within DevRel that focuses on this. The program touched on this aspect a little. However, it was not truly explored with the rigour I felt it deserved.

Navigating DevRel Within Organisations

DevRel exists as a team within a tech company. As a relatively new function, DevRel is less well understood by the rest of the company. It may even be considered to niche by some. This poses unique challenges ^[2]. However, these were only briefly touched upon.

Consider time zones

If you’re in Singapore or a similar time zone, the weekly sessions happened at around 3am. This made it quite challenging. I hope that future sessions will be held around 9pm to midnight (which is 9am to noon in EST). Alternatively, make asynchronous attendance options available.

Top 3 Takeaways permalink

Condensing all the learnings, here are my top three takeaways:

1. Dev Education is the Primary Focus: Devote at least half of your DevRel resources to it. Plan a systematic, comprehensive approach to documentation.
2. Async Over Sync for Events: Emphasise webinars with recordings over in-person events. This nets you a much higher ROI. ^[3]
3. A-B Test and Iterate: Choose good metrics. Ensure you have mechanisms to measure them effectively.

Takeaways of others permalink

I’d like to link to the work of the others in this year’s cohort of DevRel uni as well. I’ve added my own bullet points to highlight something new that I learnt, which I missed/ glossed over from the same sessions. (Hive-mind, FTW!)

• Mónica Talan (in Spanish) + their summary in English
  • Los miembros de mi cohort no solo estaban comprometidos con el aprendizaje, sino también con ayudar a otros dentro del cohort. Trajeron una variedad excepcional de habilidades a la mesa, lo que ayudó a elevar a todos, incluyéndome a mí.
    • ➡️ Translation: My cohort members were not only learning themselves, but also helping others within the cohort. They brought an exceptional range of skills to the table, which helped to elevate everyone.
• Khushi Panwar
  • This is a small community of DevRel enthusiasts who initiated very meaningful conversations, shared valuable insights and spread positivity.
• Aye Chan
  • From Patrick Collins’ session: Give developers a reason to not hate your docs, by giving them a challenge. Something that pushes them to think and explore your tech. Imagine if video games had an instruction booklet for what buttons to press, instead of a tutorial section.
  • From Austin Griffith’s session: Give people money. If developers build with your tech and are rewarded, more will build with your tech.
• Saúl Garcia
  • From Austin Griffith’s session: One of the most valuable takeaways was his approach to building apps and tutorials quickly.
• Sofia Sukhinina
  • From Michiel Mulder’s session: Good docs is a like a roadmap to your project. It tells you where you have been, and where you are going. It helps you avoid getting lost along the way.
• Peter Novel
  • Ultimately, a DevRel’s success depends on their ability to empathise with developers and provide a great developer experience. This includes recognising the issues that developers encounter, predicting their needs, and providing the resources and support they require to succeed.
• Genesis Hernandez + their Tweet thread From Nader Dabit’s session: It is crucial to maintain a steady and consistent approach to both personal and professional development.
• Fabian Weber
  • From Steph Orpilla’s session: Three groups of DevRel focus: Community, content, and product. Things happening in product have to become content and go to the community. THings reflected in the community should become memes/ content and ideally influence the product if needed. These form a triangular relationship.
• Ania Shestakova
  • Focus on what you love, but keep learning everyday. One of the reasons I’m working in tech is the community of smart people who are efficient.
  • Also their article Advice from Nader is a must read
• Ovia Seshadri
  • There is a planning and execution process, not only in the content and teaching but also in convincing the business of what you want to create.
  • It is difficult to define a metric for a DevRel’s work. Create awareness about this problem, and constantly work on tuning your metrics. DevRel should have visibility and support at the company’s executive level.
• Progress Ochuko Eyaadah
  • A documentation search feature is essential for a developer’s learning journey while using a docs.
• Insha Ramin
  • From Patrick Collins’ session: Coming from a web2 background … The next day, I explored blockchain fundamentals on Cyfrin Updraft and made my first transaction. One thing led to another, and after a week, I completed a Solidity course.
• Steven Pham
  • Quick starts are among the first things that a dev looks at, and where you make or break your developer experience (DX). Ensure that devs can achieve something with your tech in 5 minutes.

Are you keen? permalink

Reading my summary of DevRel Uni, or those of others, cannot fully capture the true experience of being part of it. I strongly recommend enrolling in the next batch of DevRel Uni. Whether you are starting your career in DevRel or seeking to sharpen your skills.

Also, do follow me on Twitter and subscribe to my Hands-on DevRel channel, where I will be posting a lot about DevRel.