In the last video, I mentioned my Developer
Relations experiment And in this video, I want to share some of
the details. My favorite definition is that Developer Relations
is building relationships with the developer community. Building genuine, authentic, mutually beneficial
relationships with your users. And building a relationship with your users
kind of involves the same principles of any relationship. Which is genuinely caring for the other person
and understanding their pain points and then figuring out how you can best help them achieve
their goals and resolve their pain points. So this sounds really good in the abstract
but my goal with the Developer Relations experiment was to figure out if I would actually like
doing it as a job. And so I needed a concrete, measurable framework
that I could devise my experiment and projects around. So that I could figure out what parts of the
Developer Relations job I actually like and which parts are like, not that appealing to
me. So I started reading a bit more and I came
across this excellent framework by Eddie Zaneski and he talks about Developer Relations as
having three areas or three components: Code, Content, and Community. So Code involves creating sample applications
and sample repositories and plug-and-play applications that will help your developers
get productive with your product faster and reduce the barrier to entry or the friction
of onboarding. And the reason for this is that you have to
remember that the developers who come to you for your product don't actually care about
your product as much as they care about achieving their goals. For example, the users of CockroachDB don't
really care about databases (although some of them are like, database nerds, as they
like to call themselves). But most of the developers or application
developers actually want to build an application and they are looking for a database that'll
help them build that application. So as a Developer Relations person or Developer
Advocate, my job would be to not only explain how CockroachDB works but also to help the
users build their application end-to-end and help them figure out how CockroachDB fits
into the whole tech stack and how to optimize it for performance. So basically help the users reach their end
goal by minimizing the friction for your product which is a small part of their overall tech
stack. The second part of the framework is content
which involves technical documentation, technical blog posts, Twitter content or social media
content, slide decks for conference presentations, or tech videos. All of that fits in like the big umbrella
of Content. And then the final part of the framework is
Community. And this means developing one-on-one personal
relationships with your users in the form of online forums or again, social media, or
meeting with them in person at conferences and meetups, or organizing and participating
in events like hackathons. So the first time I heard of the framework
and I realized what each of the areas mean and the activities that are part of each of
the areas, it was super overwhelming. So I was kind of confused about how one person
would do all of these things. So I asked a couple of experienced developer
advocates about how do they manage all of these activities and they told me that they
don't! So the expectation is not that one person
would be an expert in all of these areas. The expectation is that you choose one area
to be an expert in and then be reasonably good enough in the other two areas. So I was thinking about how do I figure out
which area do I want to be an expert in. Content seems like the most logical area for
me but I was really curious about Code and Community as well. So I decided to devise projects for each of
these areas and then prototype and experiment. So here's the experiment plan I came up with: So for Code, I enrolled in Udacity's nanodegree
program for Full Stack Web Development. And the reason for that is that I wanted to
go back to the beginner mindset. I feel like I have been so focused on CockroachDB
for the past two years that I have kind of lost touch with the end-to-end tech stack
and the pain points that the users go through at each of the user journey of which CockroachDB
is just one part. And I hope this course will help me get back
to the Code Newbie beginner mindset that'll help me understand my users better. Also as part of the course, I will end up
building five applications that I can then offer up as open source sample repositories
for my users. For the content part of the experiment, I
started live-tweeting tech events that I went to. And I do make tech videos but I want to make
more of them. And I want to experiment with tech doodles
and tech zines. And for the community part of the experiment,
I have been attending a LOT of tech events. And I mean a LOT. Like, I think I have attended an event almost
every week for the past two months. And I have been traveling a lot for the events
as well. Because developer relations involves a lot
of travel, I wanted to see if I actually like traveling as much as is needed or do I just
like it in theory. So I have been traveling to San Francisco
and Orlando, and I am again going back to San Francisco in October, so, we'll see. So that is my Developer Relations experiment. I will keep sharing the results and my observations
and the things I learn on this channel. And if you are thinking of making a career
change to Developer Relations, I highly recommend that you come up with your own experiment
and prototype your career as a DevRel person before making the leap. And if you do that experiment, I would love
to know about it, so please let me know in the comments down below. And if you are an experienced Developer Advocate,
I would love to know your opinion or your feedback on my experiment, so again, please
comment down below and let me know. I'll see you in the next video. Bye!
