Some people come into a developer advocacy role after a career as a software engineer, others come from another adjacent field like marketing or technical writing. Lizzie Siegle (@lizziepika) jumped into DevRel during college, landed a full-time job after graduation and never looked back. Lizzie and I worked together when she interned at PubNub, a realtime messaging startup, although her focus now is Machine Learning (ML). After four years in the industry, Lizzie spoke to me about her experiences balancing metrics and passion, finding your niche, and getting more students interested in developer relations.
Table of Contents
- Q: How did you get into developer relations?
- Q: How has DevRel met/challenged your expectations?
- Q: How did you make the jump to ML DevRel?
- Q: What's different about Machine Learning DevRel?
- Q: Can you predict success in developer relations?
- Q: What advice would you give to students?
- Q: Who in DevRel would you like to call out?
Q: How did you get into developer relations as a career?
As a student, I loved going to college hackathons, where it was the DevRel representatives who did the demos, ran workshops, and mentored attendees. I asked one Braintree developer advocate, Justin Woo for help and we ended up talking for hours about Braintree, hackathons, iOS, DevRel, and life. At one point I remember exclaiming, “You mean you get paid to help me?” Before studying computer science I had wanted to be a teacher, so once I learned this job existed I knew right away that it was meant for me and I wanted it.
I got my start as a developer advocate because I was a college ambassador for a program called She++, and I was given resources to organize events for students like a Code Day with workshops, a panel, and speakers. With that experience under my belt I applied for and got an internship at PubNub (after talking on Twitter with Tomomi Imura (@girlie_mac)) I spent three months in the summer as a DevRel intern at PubNub and then continued to blog and mentor at hackathons during the school year. The following summer, I interned at Twilio for three months before converting to full-time upon graduation!
Q: You've been working in DevRel for over four years now. How does your work compare with what you expected before you started?
When I started in my first DevRel position, I never really knew about the content side of the job — I had only been exposed to the more visible side of DevRel where people were paid to travel and mentor and speak at events. I didn’t expect that the role would include making creative projects, not unlike what I did at hackathons as an attendee. I also didn’t realize how much DevRel would vary across companies. It’s wild how every day is different, every team at each company is different, and everyone on my team has different focuses in terms of languages, content, and events. As an example, some people focus on Twitch streaming, and they don’t even do events! Some do blog posts, and some might want to do more events. My teammate Dominik is more focused on open source now, and I’m focusing more on machine learning in terms of contents and events coming up. I also did not expect social media to play such a large role in the job--I would not have expected I’d spend so much time on Twitter!
Q: Twilio and PubNub are both known for their messaging products. How and why did you make the switch to machine learning?
Twilio recently came out with a new product called Autopilot. It’s a machine learning platform that makes it easy to build bots once and then deploy across different channels like SMS, voice, Slack, Messenger, and more. I realized that there wasn’t much machine learning blog content so I started to write some, slowly and inadvertently becoming the go-to Autopilot person. The time I spent working with the Autopilot product team and engineering team meant that I naturally started to become a resource for that product inside and outside the company.
However, there's a catch: I didn’t want to be known as the Autopilot person. With Autopilot, you can write code, of course, to make a bot more complex, but the nature of the product is to make it easy to build bots with minimal code. As someone who only held one software engineering internship (during my junior spring semester), I aim to be as technical as possible and wanted to focus on a product involving writing more code. Talking with my manager, we agreed that I would focus on Machine Learning as a discipline, which I like because it’s broader and it doesn’t require me to narrow my scope to one product.
Other DevRel professionals have told me that I should work as an engineer before getting a developer relations job. Clearly, I didn't listen to them! As much as I like coding, I don’t want that to be the only thing that I do. I like that I’m able to teach, write, code, and just do all these different things, even if I don’t like to do all of them cough email cough.
Q: What’s different about being a developer advocate for a Machine Learning product or technology?
One difference is how it is explained to your audience. I’ve been trying to combine communication and machine learning to show, for instance, how communication can be improved with different ML libraries such as TensorFlow. Ultimately, I don’t want to be an ML engineer--many go to grad school for that--but I do want to help show everyday developers, like myself, that they can build machine learning into their applications, and make ML more accessible through education.
Speaking of TensorFlow, one surprising aspect to that project is the steep learning curve. I took some artificial intelligence courses in college, so I have background from the programming side as well as the theoretical side. When I first started looking at the TensorFlow API documentation, I was surprised at the vocabulary and the sheer number of parameters and optional functions. I made my goal to craft content to make that more accessible. That can be hard: some people in DevRel focus on the more advanced developers, but personally I try to make my content for all different skill levels.
Something that Tomomi taught me in my first internship is to make technical content relevant to current events or something fun. I recently had a post that performs text classification, putting texts into one of two categories: “loves me” and “loves me not”. It was fun, silly, and attention-grabbing. I’m currently playing around with Olympics data, trying to predict who will win based on countries and events.
Something that has stumped me in DevRel is how you can spend a lot of time on something and it doesn’t work out. You’ll have a great idea, play around with it, see where it goes— and sometimes it turns into a talk, blog post, or workshop, and sometimes it doesn't.
Q: Metrics, and measuring success, is a big deal in DevRel these days. Is there any way to predict the success of your efforts beforehand?
It depends on your definition of success. When I'm writing a blog post, my goal may be to get "X number of blog hits," but that’s just a number, and it won't determine the success of the post from my perspective. Even more valuable than that number: getting feedback that a post helped someone, or made a new concept accessible to them. Whether that feedback comes through Dev.to or Reddit or Twitter, it's incredibly valuable to collect feedback about the posts you write and find out what parts helped your audience learn. That’s our ultimate goal in DevRel: to teach. Twilio’s DevRel motto is "to inspire and equip," and that’s right on the money.
Q: Your first exposure to developer relations came as a student. What advice would you give to students today who are interested in developer relations as a career path?
If you want to get into DevRel, try doing the job even before you’re hired. You can get started right now! Write an article on Medium and Dev.to. If you make a cool side project, teach others how to build that project themselves. Give a talk or workshop at a local meetup on the project you built, or a recent library you learned about. Use social media to find your tribe and mentors -- these are people you admire who you can go to with questions.
For managers who are hiring for DevRel: find somebody who feels really lucky. If you feel lucky, you’ll work hard, because you’ll want to prove that the success you've made was because of hard work and not pure luck. I believe that’s another more positive side of impostor syndrome: it can make you work harder. Just make sure the people you hire don’t overwork themselves, because that’s a natural tendency.
Q: Who in DevRel is doing things well?
- Jason Mayes of the TensorFlow.js team is doing some cool open source projects, libraries, and ML stuff on the web in general, like this real-time person removal. Check it and him out!
- Tomomi Imura of course. She has great energy and I love her content and sketchnotes. I wouldn’t have gotten my start without her guidance and management, and I’m lucky to still have her in my life.
-
Bear Douglas, now at Slack, taught me Android as part of a college summer program 4 years ago. She is calm, poised, soothing, patient, and generous, and I am lucky to have her in my corner. This tweet below still holds true.
- Kim Noel and Amy Dickens are two hardworking, creative, and passionate I met because of the college hackathon community.
- My Twilio team. I’m pretty sure my friends and family know most of them by name by now and are getting annoyed by how much I talk about them. The team’s been around for over a decade, has a lot of fun while working hard and trying new hard things, and really understand developers, education, and evangelism.
Conclusion
There's a famous quote from Walt Disney: “I only hope that we don't lose sight of one thing - that it was all started by a mouse.” As developer advocates, it can be easy to get carried away with all that is happening and all that we do--and we do a lot of weird stuff sometimes. We must not lose sight of the fact that it’s all about the developers. We teach, talk to, work with, and represent developers both internally and externally, and that is honestly what gets me up in the morning.
Top comments (1)
Lizzie is a joy to work with!