A Year in DevRel

A year ago today, I started my first job in DevRel. Before I started, I was chatting with the CEO of a consultancy, and one of the things he told me was to document publicly the work I was doing in DevRel to be transparent and have a clear record of the things I was working on. That advice has proven to be really useful over the last year, and it was one of the reasons I started the Technical Community Building Series on Dev. It’s also helped me to think through the things I’ve learned over the last year, including the challenges I’ve faced, the successes and failures I’ve had, and my takeaways for the next year.

Challenges

Metrics.

Although I had been doing DevRel-y things the past couple of years, I hadn't been doing the DevRel thing of tracking everything, spreadsheets, numbers, target goals, etc. Look, I hate spreadsheets. Someone opens a spreadsheet and my eyes start to glaze over. However, it turns out that spreadsheets are super important in the DevRel world to help measure if things we're doing are working, planning for the future, and breaking down projects.

Another part of this I found really challenging was figuring out the right numbers to include. "What do you think we'll get for participation for this event?" "I have no idea, I've never done this before." I've had to dig a lot deeper into what I know and try to make my best guesses.

Burnout

At the end of the year, I took two weeks off. I hoped to do some light work with planning, drafting some blog posts, etc. What did I do instead? I got my second stomach virus in a month, and I was totally exhausted. I didn't want to move off the couch exhausted--and that never happens to me. Strategy. Writing. Speaking. Event organizing. Twitter spaces. Social media. Planning. Meetings. Meetings. Meetings. I didn't take breaks when I needed to during the year. I kept pushing through. And then I was so exhausting. I am happy to report that the two weeks were enough time to bring me back to life.

Successes

Technical Writing Blog Posts

One of my favorite things I did during the year was write a series on Technical Writing for the Deepgram blog, starting with Technical Writing: A Beginners Guide. The series was well recieved and combined my background as an English teacher with my new life in DevRel.

Internal Community Documentation

Over the last couple of years, I've learned a lot about the importance of internal documentation. As one co-founder said to me, "you always have to be prepared if someone is in a car crash". I know, it's morbid, but it's a common expression used to demonstrate the idea that there should be clear paths of communication and documentation created in case something happens to a person, myself included. If I'm no longer at Deepgram, it's important that the processes I've created still live their to support their DevRel team. This includes hackathons, Twitter Spaces, Small Group Meetups, Community Discovery, and more. It's thorough and a pretty big time investment, but it's also an investment in the future and part of the evaluation process. What went well with this event? How can we maximize that next time? Add it to the docs.

Community Engagement

Whether it's been in our own Deepgram properties or in other communities or at conferences, I've talked to a lot of people about what we do at Deepgram and how we do a really great job. One of the phrases I've heard repeated quite a few times is, "I wouldn't have known about Deepgram if you didn't work there." That reach is hard to quantify, but getting random DMs from folks I know asking about our product has helped me know that I'm on the right track with building trust and support in the tech community.

Failures

Yes, I failed sometimes and I'm willing to admit it. This is how you grow. Look at the failures and examine why they're happening.

Hackathons

We didn't get the return we wanted with the hackathons we participated in while I was on the team. I don't think it was due to lack of opportunities, as we provided guides, resources, and live events. I underestimated a couple of things: general interest, skill level, and product interest. It can be nerve wracking to participate in a hackathon, especially one that focuses on participants working alone or maybe in pairs. Whether it's one week or a month, there needs to be clear interest in participating in a hackathon in general. I think there's a sweet spot for a certain skill level. Often, folks who are newer to tech hesitate a little more when getting involved, and those who have been in tech for a while on the platforms we engaged with seem to have less interest in participating in a hackathon. Finding the right audience is key to success. Lastly, as a speech-to-text API, there are very specific or limited usecases for using DG. That's not to say that you can't do something interesting or creative. It's just to say that there's a more limited use, which leads to limited user interaction as well. The key to hackathons is finding an audience who wants to use the product first. Or, like the LEGO community, having an ongoing project submission that gets voted on.

Small Group Conversations

I'm not going to lie. I really thought the series of three small group conversations that were followed by a Twitter Space would be popular. There are a lot of people who are asking for 1:1 meetings to talk about breaking into tech, or want to explore different parts of tech. Hundreds of people expressed interest in the topics, sign-ups were lower than that but decent, and then only a handful showed up. I think part of the problem here is that over the pandemic, we've gotten used to signing up for everything and then going if we feel like it. It's kind of a bummer as an organizer, because it becomes hard to predict what attendace will look like and make something a meaningful experience. Every Tuesday and Thursday we have small group conversations at Virtual Coffee, so it fulfills my need, but I'd love to find a way to extend that experience outside of our community.

Takeaways

1. Find your community. I say this all the time about everything. But being able to talk to other DevRel folks really helped me get through the last year. To hear about their struggles, to learn from them, and to find more ways to grow has been invaluable to my experience.
2. Set boundaries. That's one of my goals for this year. Community and DevRel never stop. It's always onto the next thing, which is one of the reasons I love it. But I frequently load up my plate a little too high and keep taking on more things. This is not good. I've created a Trello board to both track what I'm doing, and to give me a visual of the things I've taken on to decrease the chances of me overcommitting myself.
3. Experiment. Sometimes you get it right, sometimes you get it wrong. But what ensures success is examining what experiments worked and why and what didn't and why. Don't just move on to the next thing. Understand what you've done and the outcomes.

There were a lot of growing pains last year, but that means I grew a lot. I learned more about what it means to be in DevRel, what my strengths are and where my weaknesses are. I learned about working on a team, asking for help, and being more vocal about the things that I think matter. Because at the end of the day, it's people that matter. And I'm here to make sure that we see everyone as the complex and beautiful person they are.