After 6 weeks of regular meetings, assignments and activity challenges I’m super excited to write this wrap up. I now realise that before I arrived at DevRel Uni I didn’t really have a clue about DevRel. After these 6 weeks I feel like I learned a lot more than just what DevRel is and how I can become one myself. My personal takeaways Motivational Be warned, half of these are hard facts while the other half is motivational content. However both together make an amazing image of what DevRel and great community building is. So let’s get right into it. The two lectures that really made me jump up afterwards full with energy and ready to run a marathon were with Nader Dabit and Patrick Collins.

“Take Action: no overthinking” - Nader Dabit

“Make really fuckin good videos” - Patrick Collins

These two quotes are super inspirational to me, my last few months had been quite tough and I really enjoyed listening to these two and the energy they brought along. It took inspiration and started picking up projects that I had put aside, writing posts on X and living up to the DevRel challenges. Thanks a lot for shaking me when I needed it.

Also a shoutout to Austin Griffith here, his session on how touch launch a dApp in less than 30 min and actually have fun deploying shit was absolutely amazing. These are the types of workshops we all want to have and give. Masterclass of engaging a group on a video call.

Bianca Buzea

The focus of DevRel uni is obviously on teaching you about DevRel, so let’s look at what I learned throughout the program. The first lecture with Bianca taught me a ton about the development, strategy and general practices of DevRel and in work environments.

It was really helpful to understand the difference in perspective of Developer first and Developer Plus. The difference here is that at the developer first companies the developer is the core focus point of their business model. For developer plus companies that are usually not the same, they have a business model that works just fine without developers, but they profit from devs using their APIs hence they try to support them as well.

Also a really helpful refresher on management practices and especially effective change management practices. Interesting stats were that departments undergo a restructuring every 6 months on average, we should get really good at handling this change to stay effective at the workplace. Correct goal setting and forward communication helps work with changing stakeholders just as much as with communicating the value of the program one is working on.

And the last part I thought was really interesting were the implication from legal and other departments on the DevRel program. I knew that there were significant influences from these sides on how we can communicate, but hearing concrete examples was still memorable nonetheless.

Steph Orpilla

My best performing tweet was a summary of this lecture. https://x.com/Fabbaist/status/1793713854167588971

I had read the articles Bianca gave us as material to learn about DevRel so I was familiar with the different roles or hats devrels can have. Steph separated them into three insightful groups for me: community, content and product focused. I love this type of separation because it helps clearly identify the tasks within DevRel and helps transition between them. 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 are really in a triangle relationship.

Then obviously the best advice when it comes to writing docs is to put on your developer hat first. Think about what you’d like to see and what you would need to have a success moment as soon as possible.

And as a DevRel writing the docs from scratch follow these steps and just start writing and publishing:

• Start with an outline

• Talk to engineers, product a LOT

• Stay on top of latest updates

• Collab on the docs

Then make sure you use analytics to track the issues with your docs. In terms of code, it’s super helpful to have a boilerplate project that devs can fork and play around with. Forking something like scaffold eth (thanks a lot for this one Austin) and adding some lines can already be sufficient. Last but not least, have a clear way for people to report bugs that can be on Github, Discord or your Docs. Just make sure that it’s tuned towards your needs and makes it easy to report bugs.

Michiel Mulders

The last but certainly not least in this wrap up. Michiel had an incredible session with us diving deep into strategically setting up your docs, the tools to use for docs, making them searchable and more interaction friendly in general.

This topic is so vast that it’s hard to wrap up because there are so many things to say here. I’ll just point out that his final question from the docs section was “is it worth it to build your own docs?” and I can only say the gamified docs example he provided made me really want to go out there and actually build someones gamified docs for them or even build my own

Understanding the different types of information people need to understand the docs and learn from it was also really interesting: Tutorial, How-To Guides, explanations and references. Each of these come in at different stages of learning, seems pretty obvious now that we talk about it but recognizing this is essential when creating good docs. Follow some sort of framework for your docs.

His last tip I have yet to use. Creating videos is still a bit difficult for me for some reason. I don’t like myself on camera and think it looks and feels weird. However he advised us to actually record ourselves talking and record the slides or topics separately, then in our editing tool make the voice recording and the video material fit. This was amazing advice and because I had never recorded a video of myself talking about something it was really helpful to think about the video in this manner and not just like a presentation. Being able to work with the tools at hand and modify the video instead of having to retry every recording and then cut things together makes stuff a lot easier for me.

Final thoughts

After having attended DevRel Uni I have a much better understanding of how the attention game is played and how one can build rewarding communities. My focus has been on attending event to build real life networks because I believed that all the good conversations happen there, which is only partially true. You can pull so much weight in today's digital world without being present at in person events, by focussing on producing content and addressing the right audience online. This point was being made by Nader and Austin Griffith as well, to stop running around the globe wasting time, energy and money to be at every event. Focus on leveraging the resources we have and only go to the major ones if you really have to.