Today, August 30, 2022, marks the completion of my first year as Developer Advocate for KendoReact at Progress. It’s been a really wonderful year, and I feel like I’ve 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 don’t 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 can’t 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 you’ll 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 don’t feel like those paint a picture of my actual work – but you can bet I’ll 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. It’s 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, I’ve 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 couldn’t 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. I’d made a point to speak at conferences even before this role, but usually just one or two a year…a 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 I’d 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, it’s also a physically exhausting experience – I’d often arrive somewhere and need lots of recovery time before I felt like my best self, the version of myself that I’d want to speak at a conference. In the future, I’d 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 feeling…but 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 you’re 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, it’s 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.
- There’s 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. I’m at my happiest when I’m sitting at my desk with a cup of black coffee, 20 tabs and 5 different books open, banging away on my keyboard.
- These numbers don’t include one of my biggest accomplishments of the last year, because it hasn’t actually been finished yet – I completed the first draft of my “Design for Developers” book! That’s 34,090 words not included in the above totals, because it’s still going through the editing process. However, it did (as you might expect) consume a significant portion of my time. I can’t wait to share it with everyone, soon!
- I’ve 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 it’s 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 that’s 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.
- It’s 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 it’s 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 I’m wearing a Kendo branded t-shirt and my hair isn’t in my face, doing a ton of takes until I get the lines right and don’t stumble over a word or cause an error in my code…you get the idea. While I don’t have the data for how much time I spent creating the 1h 22m of total video content, I can tell you it’s easily many, many times that.
- I’m lucky enough to have a team of wonderful folks that handle the really hard parts – the editing, sound mixing, etc. Without them, I’ll tell you upfront, I simply would not make videos.
- I look at it this way: every job has parts you don’t 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 I’m working through the recording process. Recording scripted videos doesn’t light me up, personally, but there are enough other things I love about my job that this area isn’t 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 it’s been fantastic! I had never livestreamed before and was incredibly nervous starting out, but it’s a medium I’ve 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. It’s 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 isn’t 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 aren’t indicators of poor programming skill, they’re just a part of the job. I hope that, when I livestream, I’m also communicating to the viewers that it’s normal to hit snags.
- It’s 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. Just…what??
The Big Picture Thoughts
- DevRel is hard work. There have been a handful of times over the past year when I’ve made the “I can’t 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 event…but 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 didn’t know something. I’ve since learned that, while it’s important to be the expert at the one thing you’re representing (in my case, KendoReact), that doesn’t mean I need to be the expert at everything vaguely related. I won’t know the answer to every single React question, and that’s okay. “I don’t 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 that’s just not where the real value is. If that number is what’s important, it’s not hard to grow it – as long as you’re okay with lots of bots, trolls, inactive accounts, etc. But I’d 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 – it’s 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.
Top comments (2)
And a great 12 DEV posts those were!
"they’re just a part of the job"?
there is a wealth of evidence that already tells us that organizational complexity is the leading predictor of software defects. conway's 4 laws are documented. campbell's law is well documented.
there is absolutely more to say if you theorize beyond the horizon of irreversibility in the patriarchy. we should want to stop talking about how we are not perfect and shift our focus to why the open source "ecosystem", or social ecology, is plagued by toxic sexual racism.
Some comments have been hidden by the post's author - find out more