In this conversation with Brianne Kimmel and Netlify Developer Experience Engineer Cassidy Williams you'll learn: - When to hire your first DevRel?- The difference between developer relations, advocacy, evangelism, and experience? - Should a DevRel report to marketing, engineering, or its own team? - The first 30/60/90 days for the first DevRel at your company.
Brianne:
I'm excited to host our workshop this week and really looking forward to learning more about DevRel since it's such a hot topic for startups that are ready to make the first DevRel hire and determine the objectives and goals for the programs that this person should run when they join.
Background on Cassidy’s journey
Cassidy:
Well, thank you for having me, and for those watching, those listening, I'm currently at Netlify doing DevRel stuff.
I'm a principal developer experience engineer at Netlify, and it's been a journey getting here. I've done various types of DevRel roles throughout my career where I've done really large companies like Amazon where I was on developer voice programs for Alexa and then smaller ones where Venmo... before Venmo was a part of PayPal and Clarify which was a very small AI startup.
And so, doing this role across different things, teaching full-time, and then coming back to it, it's been a fun journey, and it's been fun to see how the space has evolved over time.
Brianne Kimmel:
And you've become such a strong voice for the ecosystem with the videos you create and with your own community efforts through streaming and advising startups.
The last time we had a conversation, you also mentioned hosting workshops as well, and so how did some of the workshops come about, and what was your initial desire to get into developer education?
Cassidy:
Devel was my first role out of college. I was doing DevRel and software engineering, a hybrid role.
And then after a while, I admit I kind of burnt out because I did just too many events and stuff, and I went just to the straight software engineering side and did that for a while, went back to DevRel, then went back to software engineering again.
And then from that other software engineering role, I was starting to realize I did really miss the developer community, and I was starting to teach online. I had done some online courses and stuff myself just for fun.
I started talking to Ryan Florence who's over at React Training, and he wrote React Router. A lot of developers know him, for those who don't. He basically was just like, "I'd like you to teach some workshops with me. Maybe we could do this on a contract basis," and then kind of just said, "What if I did this full time?"
Cassidy:
It was Fall 2019 when I started teaching full-time and just teaching dev workshops.
And it was a blast getting to interact with devs, figuring out their pain points, figuring out how I could teach better.
And then the pandemic happened. And unfortunately, we had to lay off all staff, cancel workshops and stuff, and that led me to Netlify.
Netlify has been awesome because I've still been able to teach stuff on the side and at work while also getting back to my DevRel roots.
Brianne Kimmel:
That's great. How fun. Well, as you know, Worklife, we're an early stage firm.
We invest in a lot of developer friendly infrastructure, tools for designers, data scientists.
Many of the companies that we partner with are exploring at what point they should hire their first DevRel. We're also starting to see even outside of developer tools, many of the tools for data scientists want to hire a DataRel.
There’s a lot of momentum behind starting with a community to build a better product and thoughtfully monetize vs. launching with a paid plan and trying to find users.
Brianne Kimmel:
There are all of these new roles that are being created.
I'd love to just catch up and ask you a few questions and learn more about your experience because I feel like you were so early in this much bigger trend.
So many companies are thinking about what type of person they should hire for the role, and more importantly, how do you set someone up for success when they join an early stage company.
How early do you think a company should make that first DevRel hire?
Cassidy:
I think the answer is it depends, depending on your customers because if your customers are developers and that's your core customer, then it's never too early.
I think that could be your first hire.
That could be one of your first five hires. I think that's really, really vital.
And that being said, if your customers who are also... it's B2B or B2C and then developers just happen to have access to the API, you don't need to hire one right away.
But as soon as you do, you're going to be so happy you did because this is the kind of person who, depending on their specialty, can help work on docs, can work on tutorials, can work on content, video and promotions and stuff.
I hate to answer with an, "It depends," but it does kind of depend on who your customers are and how you want to prioritize connecting with them.
For someone that's interested in joining as the first DevRel at a startup, what are some things that they should expect?
To what extent have you been involved in writing documentation, jumping into customer support… How does the role vary depending on the company size and stage?
Cassidy:
Varies a lot.
The way we have it structured at Netlify is one that, I think, it was designed by a DevRel person.
When I joined the team, I was like, "This is how it should be." And I've been trying to evangelize our evangelism and see it spread across other organizations.
Netlify has a dedicated developer experience org and in developer experience, we have it split up into three pillars:
1. Technical writing: documentation, writing tutorials, and blog posts.
2. Integrations: building tools, it’s 100% engineering but building tools that make it easier for external developers to use our platform.
3. Advocacy: 50% engineering, 50% marketing
Developer advocates build the demos, write tutorials, make content, and serve as the bridge between integrations and docs, but also work on content.
This structure is really useful because we're a bigger team now, I think we're eight people, nine people, and so we can spread ourselves out that way.
But for really small teams, it might be one person doing all three of those and then slowly as you grow, you can kind of split up that way.
Brianne Kimmel:
I find when a company hires the first DevRel hire, that person becomes so influential across the company where once you start to scale and you add in a Head of Customer Support or a Head of Marketing or any of these functions that touch DevRel, that person has so much knowledge about the customer base and programs that have worked and what haven't worked.
As a company scales where should DevRel sit?
Cassidy:
And so I've seen at various companies, DevRel ends up under certain buckets.
Sometimes it's under engineering, and they're kind of the marketing people on the engineering team.
Sometimes it's under Marketing, and they're the engineers on the marketing team. Sometimes it's under Customer Support.
And then at Netlify and other developer tools what I'm seeing more and more is it's just its own separate org.
We have a VP of developer experience at the same level as all of the other ones.
What goals matter for a DevRel team?
Because DevRel touches so many different things, we have our own goals set aside from other teams and programs.
We focus specifically on monthly active users and top of funnel type programs to generate demand and support the ecosystem. It’s helpful to have our own goals and structure.
How are DevRel goals different from other teams?
For example, engineering for performance, a lot of times it's like, "How many lines of code did you write? How many issues did you close?
How many this and that," and that doesn't always apply to advocacy, and same with marketing. Sometimes, it's how many people did we reach at this mass amount, and how many people converted to paid users and stuff?
We don't care about that as much. We're trying to get active users and trying to measure just how simple the platform can be, how we can improve that experience.
How can we improve the speed for developers? And so that kind of organization, I think, is particularly helpful.
What are some considerations for companies making their first DevRel hire?
When you hire this first DevRel person, and you're figuring that out, they will be wearing a lot of different hats.
When you scale and hire a Head Director of Support or Director of Marketing, trust is critical for every person they can interact with.
Accountability with authority, not just accountability to do whatever all of these other teams are telling you to do.
Brianne Kimmel:
What would the first 30, 60, 90 days for the first DevRel look like?
It’s easy to be pulled in so many different directions and because the role is quite different at each company, are there a standard set of programs that are really impactful that the first DevRel can do in their first few months of work?
Cassidy:
It varies from person to person, I encourage companies to start with the 90 day goals and then work backwards.
Because DevRel has a different set of skills, it’s important to align goals with their superpowers.
One of my coworkers, he's amazing at videos and live streaming and live coding and stuff, and that is his jam.
But his blog posts are very, very lengthy. And so he doesn't want to write a blog post a week because they're 3000 words.
He focuses on doing a couple videos a week instead, and then meanwhile, other people, they don't like doing any sort of content where they speak or make videos, but they love writing, and so they just focused on that.
When I joined Netlify, I wanted to have a weekly live stream going by the end of my first 90 days. I wanted a tangible community activation that generates downloads for a certain package, in addition to blog posts.
I set goals as very, very high level, but then going back to 60 days and going back to 30 days, it got a lot more granular where I would say, "Because I want to have this many blog posts out, I need to figure out what that content is going to look like?
Do we want it to be tutorial types, or do we want it to be more white paper style? Do we want it to be, I don't know, documentation style things?"
Cassidy:
And, for example, one of my goals that I ended up setting at the 30-day mark was to get on a sales call and just be a fly on the wall listening to what the sales calls look like and then saying, "Based on this, I know what customers are looking for. I can refine some blogging decisions and stuff." And so then the more I learned about the company, the more I can get to those goals and beyond them.
Being able to set "This is the general cadence that I want at the 90-day mark" is what you want, but then get granular on how you want to get there in those 30 and 60 days.
Brianne Kimmel:
Going back to the Sales piece, I think that's really interesting there's a difference between joining a very early stage company as a DevRel or joining a growth stage or even public company.
It’s great to hear how influential a DevRel can be when it comes to early go to market strategies: working closely with the sales team, working closely with marketing, and customer success to ensure that each function is a champion for users.
Have there been specific programs that you've implemented that have worked really closely with other teams in different orgs?
Cassidy:
I find things like lunch and learns for sales enablement where we create some structure: lectures on a specific framework or a deepdive on a topic for Sales is helpful.
Because DevRels are so in touch with the dev community and the trends and what people want, we can all kind of educate each other.
For example, I do regular office hours with our support team.
And a lot of times, for example, I do a lot of React and XJS. They come to me saying, "What do developers like about this? I've noticed we get these questions a lot. Is there anything that you can do to improve that?"
And so I'll say, "Well I can write a blog post about this. Great. And I could do this. And here's actually what they're asking. It's confusing how they worded it." And so I can clarify things, and they can give me content ideas and stuff.
For the Sales team, I’ll say "Developers who work on this particular technology want to hear this.”
And so here's all the things that you need to know. Here's what we do as a company. You go sell it," and then sometimes it'll involve a solutions engineer or something partnering up with me so they can be on the sales side, I'll be on the DevRel side, and we can educate both customers as well as our team.
At what point does a DevRel work on original documentation, and how do you think about at what point should a startup actually start hiring more technical writers and building a little bit more of a team around it?
Cassidy:
I think that really varies, but it's something that you'll want to do before your DevRel person burns out because it's always nice to have the DevRel person be able to write the docs and stuff, and especially once you do have a technical writer, they can work together a lot on that, but we have specialties for a reason, and docs writers are very good at being clear and to the point and not injecting opinions into stuff. DevRels have a lot of opinions, and so it's something that... it can be beneficial. And so I would say once a DevRel's work is at 40% just writing docs, that's when you have to start considering you should have another human doing this so they can focus on other content.
Brianne Kimmel:
That's great. It's awesome to hear you talking about DevRel burnout because I find, especially with early stage, you are wearing so many hats, and there are so many jobs to be done. What would be some advice that you would give to DevRels that are just getting started, and how they should think about their day to day, but also I think you've done such an amazing job of picking the right startups and really building a career in this whole new space.
Brianne Kimmel:
How should they think about ways to set themselves up for success both internally and for future roles?
Cassidy:
So first of all, I have burnt out many times in this role, so just don't do what I do, but also listen to me. So first of all, I think one of the things that pretty much every DevRel person and honestly, especially women, it's very hard to say no. And setting those boundaries and saying no to certain things is very, very key. And it's very easy to want to say yes because you're just like, "It's on me to get the word out there about my content and about my company and about all of that." And the company will survive if you say no, and you do only two events a month instead of four. And being able to set those kinds of boundaries... boundaries are life's mute button, and it's healthy to have one of those.
Cassidy:
The best DevRels are people who are just engineers who happen to really like writing and understand developer experience really well.
And I've hired a few people where they were engineers who were just really good at articulating stuff and were really good communicators and brought them on, and they've been amazing DevRel folks.
Cassidy:
For people wanting to get in and for people who are wanting to hire, finding someone who can communicate clearly, whether it's via writing, via video, via something is very, very key and almost more important than someone who is... actually, it's a lot more important than someone who might be popular on Twitter or something like that.
And being able to set those boundaries when you're hired and before you're hired is really key because then, for example, your Twitter will always be yours after you leave the company, and your Twitter will always be yours on the weekends when you're not necessarily working. And so setting those boundaries while also being genuine to the community is really vital for success.
Brianne Kimmel:
Have there been certain mentors or people in your life that have been helpful as far as helping you establish those boundaries, or who do you look to learn more about the space and to really think about next steps for your career?
Cassidy:
So there have been various people that have been my mentors, both in DevRel and outside of DevRel. And so the first person who really helped me get my foot in the door is Rob Spectre, who was over at Twilio. He was kind of the originator of the role. And he was able to kind of give me some tips on how to put myself out there and then start writing content and that sort of thing, and he was really great.
Cassidy:
And then also, another person who's not technical is Kelly Hoey. I'm not sure if you know her. She's a awesome investor, mentor of mine, and friend of mine, and she's been really great for kind of just helping me figure out how to get to the next step in my career, remembering that it's a journey, not a sprint and not trying to burn the candle at both ends too many times.
Cassidy:
And then also, honestly, my current manager, Sarah Drasner, is awesome. And she set up this really great team with a good culture that focuses on people's individual strengths and collectively going towards certain goals, and she's just been really, really helpful and has written a lot of really good content about DevRel.
Brianne Kimmel:
Happy International Women's Day, by the way. I know that we've talked about burnout and all of these things, and it's been awesome to see just the number of women in DevRel. I know that we've seen each other at quite a few conferences and virtual events in 2020, and it's just great to see all of the momentum that's happening in the ecosystem. And I always appreciate all the content that you're creating as well. It just invites more people to the space, and I think you've done such an amazing job balancing both building your own voice and personal brand and great content plus doing all the work that you're doing at Netlify.
Cassidy:
It's such a great field, and I love seeing how inclusive it's been and how much more inclusive it's getting, and I think DevRel is kind of an enigma to a lot of people, but really, it's a technical person who is a good communicator, and that's it. And remembering that they are technical and remembering that they also communicate is really, really key because I think before, this is starting to get into social commentary, but before it became such a welcoming space, it was kind of a boys club, and it was kind of a thing where people were just like, "Dang, they are really good king of technical because they can really communicate ideas well."
Cassidy:
As soon as more underrepresented people got involved, people started kind of downplaying the role because they're just like, "They don't know how real code works." And it's very important to nip that kind of communication in the bud because having a really good technical person who can communicate ideas is hard to find, but the people who do it are amazing. And I've had the privilege of getting to meet so many interesting people from such a wide variety of backgrounds, as a result, because it's such an inclusive space now, and I love being a part of it.
Brianne Kimmel:
I agree. I also feel like there's been such a shift even over the last year with more people working from home, and there's less of a dependence on speaking at conferences and doing things that are a little bit more sort of thought leadership and keynote style speaking.
I love the fact that now we're seeing so many interesting communities that are starting to emerge and great content pieces and podcasts. And I just think really, it's a great step in the right direction, I would say, for tech culture where now it's so easy to learn about the role of a DevRel or to learn how exactly things work.
Brianne Kimmel:
I'm reminded of Justin Gage's newsletter, Technically, which serves a really awesome purpose where it's like, "Let's take really technical concepts and make it as easy to understand as possible" because there are many people that have worked in tech for maybe even a decade, but aren't quite sure exactly how something works.
And so I love seeing all of the new content that's being created, and a lot of it is more inviting and really giving the ecosystem a nice boost in terms of everyone learning how things work and especially kind of the building blocks for new technologies and for new companies too.
Cassidy:
Absolutely. Again, it's really great to be a part of it, and I think just seeing more and more people making more content, you never know who you might be helping.
And a lot of times, I see so many people where they're just like, "Well, there's already so much content about React, about View, about this particular space, authentication, security and stuff."
But there can always be a different voice. There can always be your voice. And so whether you're in the role professionally or you're interested in the role or you're hiring for the role, your voice is unique and could be reaching people that have never been reached before because of that.
Brianne Kimmel:
One final question, and then I'll let you go. I know we have our workshop later this week, but for companies that are early and starting to develop that voice, do you have any best practices or how should companies think about what their developer-facing positioning look like?
Cassidy:
And so I think that's something that it's worth bringing up relatively early and figuring out what is our voice because a lot of times, companies, they kind of have some people who are kind of snarky in the company, some people who are not and would rather be straight to the point, and you end up kind of getting inconsistent messaging on social media and in the blogs and stuff, and it's good to have the individuals who do that. But I think figuring out what your company voice is is something that is really, really helpful for your communication going forward because, for example, at Netlify, we decided our Twitter was going to be kind of silly, but also useful. And our blog was going to have some snark in the posts there while also being as useful as possible.
Cassidy:
And so by establishing that we're not afraid to crack a joke here and there, but then we also are kind of quick to the point. We don't let it completely overtake it. I've seen some companies where their entire shtick is just being snarky and funny. And it works for them. It's great, but to the point where you just go in expecting, "I will find some maybe technical gem amongst all the jokes. I kind of go to their posts to laugh." Meanwhile, you might go to another company where you're just like, "I just want to be cut and dry, to the point, how do I solve this?"
Cassidy:
And so there's no winning or losing, but you have to be consistent. And I think figuring out that consistent voice and doing that is very important without just taking over your employees Twitter accounts.
Brianne Kimmel:
That makes a ton of sense. Well, thanks so much for your time today. It was awesome catching up, and I look forward to our workshop this week.
Cassidy:
Me too. Thanks for having me.
.jpg)
.png)
