Tell us a bit about yourself.

My name is Rene Pot, 33 years old, and I live in the Netherlands. I’ve been a software developer for as long as I remember. From a young age, I’ve been exposed to BASIC, and I built my first website when I was about 12. Since then I have been obsessed. For the past 10 years, my work has been all about JavaScript, and for the past 3.5, I’ve been in developer relations. Currently, I work at Ombori as a Developer Advocate, working on the strategy for exposure and developer experience, among many other things. As probably everyone in this field, I have more to do than I have time for, but I enjoy every bit of it.

But of course, I’m not my job, in the end. I only work 40 hours and many more are spent differently. For one, I really enjoy a very good cup of coffee. So every city I visit I try to find a local roaster, a great coffee shop, and the best flavour beans. Which is also basically my number one souvenir whenever I travel for the job, a local bag of coffee beans.

And then in the evenings? Well, that very much depends on many factors, but very often I find myself deep in PC games like Factorio, Satisfactory or other simulation and strategy games. I even stream this often on Twitch as a fun side project. Though right now, as I’m in between houses, I don’t have the setup to do this.

What do you feel is the most important part of your job?

The most important thing I always focus on is improving developer experience, and the relation we have with our developers. It is incredibly important everyone involved with our company feels they know what they’re doing and they’re happy with doing it. Working with tooling shouldn’t be a struggle but should be all about enjoying the process. So whatever I do, I always keep the experience in the back of my mind. “What would a developer think when they get into this process”, and “What would potential roadblocks be in this flow”. Not only am I trying to think of these things beforehand, but also try to pry this information from those working with our tooling. They might not even know they’re encountering issues and think it’s how it is supposed to be. In the end, it is up to me to identify these roadblocks and sit together with the engineering team to resolve these issues as soon as possible, sometimes even before we go live with something.

Then there’s collaborations. Right now my main focus within Ombori is strategizing and starting with partner integrations/collaborations. This is very interesting to me as I also always get a lot of great ideas, and interest in products when I see collaborations shared online. There are so many possible collaborations it’s always hard to choose, but in the end, I try to find those collaborations where the other party is also interested in partnering with us. It is rewarding to work on a collaborative project, and hopefully we both gain experience from this process. It might help bring two companies closer together, and it might inspire many developers to pick up the tooling we’ve worked with.

That said, I’m always on the lookout for new collaborations so we can add 3rd-party (your) products into our marketplace. So if you’re reading this and are interested in a collaboration with Ombori, then do let me know. Ombori’s core product is Ombori Grid, a SaaS platform to help you manage IoT devices, deploy .net/Python/NodeJS/Web apps or containers to any connected device, and never having to worry about managing the device lifecycle and monitoring again, so anyone can focus on building apps for, for example, raspberry pi’s, and not software updates or updating the device in person. You can try this all out free of charge (3 devices, forever) on omborigrid.com, and if you use coupon code JOINGRID21 you even get $250 towards any paid feature.

What is something you’re struggling with?

One of the hardest things right now is justifying what I’m doing with my time. Everyone in the developer relations community, and what also was discussed during DevRelCon, is trying to figure out how to measure our actions, and this is something I struggle with personally as well. “What makes for good actions that have the most impact”, is the question of the day. Right now I’m a solo developer advocate, so I have to do all the work a DevRel team should be doing. This also means I need to not only work on strategy but also implement it. And with only 40 hours a week to work with that is a hard choice to make.

Luckily I have great discussions with stakeholders in our company, and everyone is giving great input in what should be done. Especially now when the transition from strategy to implementation is happening for me, it can be tough to make this switch.

How much time should I spend on a blog post, a sample application, or making a video? When I spent 2 full days on a blog post and only a handful of people read it, does that make it worth it? These questions are justified, but at the same time, blog posts are not meant to be short-term. Maybe over the course of an entire year it will bring in great leads, it might help some random developer solve an issue they’re having 2 years later, or it might help inspire a potential user to do something of their own, even if it is not with our product. In the end that is what Developer Relations is for: helping developers. Even if that turns out to be with a competitor product, if that is the best solution, then I did my job well.

Tell us about a time you were inspired by someone or something in DevRel.

I must say, there are plenty of examples of great developer relations people in the community. Joining the DevRel Collective on Slack and watching 14 hours a day of DevRelCon made me incredibly inspired.

To take an example, a lot of discussions that have been happening recently in the community, as I already mentioned earlier, is about metrics. There are so many interesting discussions about this topic, and plenty of talks during DevRelCon went into depth on this subject as well, and that makes me feel more in my place. Not only do I struggle with something, but this is a general consensus in the community as a whole. The classic Imposter Syndrome comes around the corner here as well. And thanks to all the topics discussed and the blog posts shared I feel no longer alone in my role, despite the fact I’m solo within my company. There are people to lean on, and there’s a welcoming and strong community to go along with that.

Then of course there are the bigger, more popular (on Twitter) developer relations people. I follow quite a few of them, and they always share great, fun, and interesting articles, videos, podcasts, books, and obviously memes. Twitter is a great place to follow tons of DevRel and I should be more active there! At least I often try to interact with great content there, and I read plenty of articles that are being shared to improve my job as well.

What’s one change you’d like to see in DevRel?

DevRel is still relatively new, even though it’s been around for decades. Yes, it sounds counterintuitive, but it’s true. Only in the past few years has DevRel truly been growing and public. Suddenly every open source project has DevRel, every company with public-facing APIs has DevRel, and many companies look into getting a DevRel person or team on board.

This is great! But it also means a lot of companies have no idea what DevRel is. I’d love to see a general better understanding of the role, and what it means to be in DevRel.

The line I saw, of which I lost the source (sorry if you wrote it!), “Developer Advocates are not in sales”, is important to me. I’m not trying to sell a product, I’m trying to help people use our product. The distinction between these two situations is lost on many people, and therefore many open positions for DevRel are basically marketing and sales with a different flavour. Of course, this also brings us back to the struggle of justifying my actions. So all in all, it’s quite complicated and this doesn’t help the image at all.

Thankfully a lot is already happening in this front, and many people in the DevRel community are working on improving this, so I can be very grateful to all of them. I am trying my best as well to clarify this with the limited means I have.