Year in DevRel by the Numbers

Today, August 30, 2022, marks the completion of my first year as Developer Advocate for KendoReact at Progress. Its been a really wonderful year, and I feel like Ive really found my place in the tech industry with developer relations work.

Before this job, I was an individual contributor Front-End Engineer on a dev team, doing (what I would consider to be) fairly standard application development work suffice to say, moving from that role into this one was a pretty big change. One of the biggest things I struggled with at first was the lack of standard measurements for success in DevRel. When I was an engineer, I could look at lines of code, PRs merged, stories completed, velocity, features launched, etc. While those were (and are) imperfect measurements in many ways, together they helped tell a story about my work. The same kind of metrics dont really exist in DevRel, but I thought it might be fun to take a look at some of the measurements that I can make re: my work over the last year.

By nature, you cant quantify a valuable conversation, an actual human connection, a depth of learning, or many other things that are inherent to the work of DevRel. However, what can be measured is content, so youll notice as you review this roundup, that a lot of these numbers are content-centric. I have intentionally left out content popularity statistics (views, clicks, etc.) because I dont feel like those paint a picture of my actual work but you can bet Ill be sending them along to my boss before our yearly review in my little brag sheet ;)

Overall, I think these numbers are interesting as a kind of Year in the Life picture of how I approach DevRel work. Its absolutely not a complete picture of what I do, but it does reflect a lot of time, effort, and learning over the last year. To try and round out the data with some actual experiences, Ive also included a Takeaways section beneath each one, where I can share some thoughts that might not fit neatly into a statistic.

Conferences

Total Conferences Attended: 11

• In-Person: 5

• Virtual: 6

Total Submissions to CFPs (Calls for Proposal): 18

• Accepted: 12 (I was accepted to 2 conferences that I ultimately couldnt attend due to schedule conflicts)

• Rejected: 6

Total Talks Given: 12 (at 2 of the conferences, multiple proposals were accepted)

Talk given the most: Learn Enough Design to be Dangerous: 5 times

Total Miles Traveled: 16,596 (flying miles approximated)

Takeaways

• Speaking at conferences is a large part of my job now, and one that I enjoy a lot especially after a couple of years where in-person conferences were completely off the table. Id made a point to speak at conferences even before this role, but usually just one or two a yeara number that pales in comparison to what I do, now. Being with the community of developers in-person is inspiring and energizing.
• Travel is really hard. Some trips were incredible experiences that let me see parts of the world Id never been to, like the amazing opportunity to speak at ReactNext in Tel Aviv. But along with those life-changing trips comes the less-glamorous parts of travel: flight delays and cancellations, lost luggage, shitty fast food meals you eat during rushed layovers, time away from your loved ones. With my POTS diagnosis, its also a physically exhausting experience Id often arrive somewhere and need lots of recovery time before I felt like my best self, the version of myself that Id want to speak at a conference. In the future, Id like to be more selective with the travel that I commit to, as well as building in more wiggle room during that travel to give myself time to rest and care for my body.
• Conference acceptance is a numbers game. Overall, I had more acceptances than rejections, which is a nice feelingbut 1/3 of my submissions still ended in (polite) rejection. I only get to see that percentage now because I have a fairly large sample size back when I was only applying to a few conferences a year, the rejection rate felt proportionately higher.
• Submit the talk, even if youre not sure about it. The talk that got accepted to conferences the most was not the one I was expecting it was a design-focused talk. When I applied, I often included multiple talk options (again, its a numbers game), and would include the design talk along with a more technical / code-focused option. More often than not, the design talk got accepted but not the technical talk. If I had been submitting based on what I assumed would get accepted, I would have been wrong quite a bit.
• Theres no shame in giving the same talk multiple times. On that same note, I went into this conference season with 3 talks prepared already, and I submitted those 3 talks to every conference where they were vaguely relevant. While I, personally, got a little tired of some talks by the end of the run, it was important to remember that the people attending those talks had never seen them before and were still getting high value from them. Creating high value content is hard work, and leveraging that hard work in multiple ways or multiple times is just good ROI.

Writing

Articles Posted to Telerik Blogs: 19

Articles Posted to Dev.to: 12

Articles Published by Online News / Magazine Companies: 5

Average Words per Article: ~1100

Total Words Written: 48,571

Takeaways

• Writing is my favorite part of this job, by a landslide. Im at my happiest when Im sitting at my desk with a cup of black coffee, 20 tabs and 5 different books open, banging away on my keyboard.
• These numbers dont include one of my biggest accomplishments of the last year, because it hasnt actually been finished yet I completed the first draft of my Design for Developers book! Thats 34,090 words not included in the above totals, because its still going through the editing process. However, it did (as you might expect) consume a significant portion of my time. I cant wait to share it with everyone, soon!
• Ive learned that writing is always the starting point, for me. Even if the end goal is a conference talk, a video, a livestream, whatever I need to start that creative process by writing everything down, word for word. This has a distinct benefit; it means I have a built-in blog post for everything I create and can easily make cross-platform content. Sometimes it feels a little like cheating to publish the same thing in two different formats, but ultimately I think its a good thing. Not everyone learns in the same way, and making the same things available in multiple ways means everyone has a chance to access my content in the way thats most accessible for them (like being able to provide a full transcript for every talk I give).
• A blog is a fantastic way to gauge interest in content. My two most popular conference talks this last season both began their lives as blog posts that did well on dev.to. From the comments and questions I got on those posts, I was able to hone the content further and create talks that were highly effective.
  • Its also very helpful to be able to include a blog post on the same topic when submitting a talk idea to a CFP it gives the reviewer a sense of the content, how you explain it, and the public interest level in the topic.
• For me, personally, blogs provide the highest ROI because I find them to be relatively low effort to create and they have high shareability. This will obviously differ, person-to-person, but its been a valuable thing to learn about myself.

Videos

Total Videos Posted on the KendoUI YouTube Channel: 8

Average Length per Video: 6-8min

Total Time of Video Content Created: 1 hour, 22 minutes

Takeaways

• Scripted videos require an extremely high upfront investment of time: setting up the lights, the green screen, the camera, making sure Im wearing a Kendo branded t-shirt and my hair isnt in my face, doing a ton of takes until I get the lines right and dont stumble over a word or cause an error in my codeyou get the idea. While I dont have the data for how much time I spent creating the 1h 22m of total video content, I can tell you its easily many, many times that.
• Im lucky enough to have a team of wonderful folks that handle the really hard parts the editing, sound mixing, etc. Without them, Ill tell you upfront, I simply would not make videos.
• I look at it this way: every job has parts you dont enjoy. In my last role, there were parts of the codebase that I hated to touch but, I did it anyway because it needed doing. I know there are people that strongly prefer video content, and I keep those folks in mind when Im working through the recording process. Recording scripted videos doesnt light me up, personally, but there are enough other things I love about my job that this area isnt a deal breaker. Win some, lose some.
• Because I know this about myself, I intentionally give myself lots of time in my schedule when I know I need to record scripted videos. I plan to do as many as possible in one sitting, and then block out a whole day (declining or rescheduling meetings) and plan accordingly so I can start that day with everything I need already accounted for (scripts written, code written, outfit planned, lights set up, etc.). That means I can take my time to get things right without feeling rushed or frustrated and take advantage of being in the zone to knock out 2-3 videos in one go.

Livestreams

Total Livestream Episodes on the CodeItLive Channel: 34

• Dev by Design Episodes: 12

• UI Mondays Episodes: 11

• Various One-off Livestream Events: 9

Total Time Spent Live on Stream: 1 day, 21 hours, 41 minutes (or ~46 hours)

Takeaways

• As someone who started their DevRel career in the middle of a pandemic, livestreaming was the first place I really got to jump into interacting with the community and its been fantastic! I had never livestreamed before and was incredibly nervous starting out, but its a medium Ive come to really enjoy.
• My favorite aspect of livestreaming is the chance to have conversations with people smarter than me and/or use our platform to highlight the work of talented individuals. Its a fantastic way to both learn something and build a relationship, virtually. Of the 34 total livestream episodes, 12 included another person outside the Progress team.
• Coding live isnt nearly as scary as you might think at first. When I get nervous or feel embarrassed about something, I try to remember that some of my favorite parts of pair programming at my old jobs was actually seeing the more senior developers troubleshoot and work through something it helped me remember that nobody is perfect at this; bugs and errors arent indicators of poor programming skill, theyre just a part of the job. I hope that, when I livestream, Im also communicating to the viewers that its normal to hit snags.
• Its absolutely mind-blowing to think that of the last 365 days of my life, roughly 2 of them were spent live on camera with an audience. Justwhat??

The Big Picture Thoughts

• DevRel is hard work. There have been a handful of times over the past year when Ive made the I cant believe I get paid to do this joke. On one hand, that can feel true when you get to travel to a fun location or plan a cool eventbut 95% of the time the job is, ya know, a job. One that I enjoy, but also one that requires a lot of effort, care, and work.
• Part of the job is learning in public. When I first started, I always wanted to be the expert in the room and I had a hard time admitting when I didnt know something. Ive since learned that, while its important to be the expert at the one thing youre representing (in my case, KendoReact), that doesnt mean I need to be the expert at everything vaguely related. I wont know the answer to every single React question, and thats okay. I dont know, but I bet I can figure it out is a perfectly viable answer.
• Authenticity is king. In this role, I encounter a lot of the dev twitter grifters, if you will the folks always looking to up their follower count, say something that will go viral, etc. There are perks that come with a large number of followers, but ultimately thats just not where the real value is. If that number is whats important, its not hard to grow it as long as youre okay with lots of bots, trolls, inactive accounts, etc. But Id rather thoughtfully engage with a small group of people than have that posting into the void feeling. A livestream with 20 people and an active chat is infinitely more fun and valuable than one with 200 people and no participation.
• Nothing can replace an actual conversation with a human. Data, content creation, conversions its all important and it all plays a part, but nothing has been so helpful as actually sitting down and talking to the people who use your stuff (and, just as helpful, the people who are considering using your stuff).
• This is what I want to do for the rest of my career.