6 Months as a Developer Advocate
It’s been 6 months since I started working in Developer Relations at Vercel and I’m happy to share I was recently promoted to Senior Developer Advocate.
I wanted to take the time to reflect on the past few months and answer some commonly asked questions. This became rather long so feel free to jump to topics you’re more interested in:
- My journey into DevRel
- How to break into DevRel
- What it is like working at Vercel
- Lessons from the last 6 months
- What’s next
I had the opportunity of interviewing with a few people at Vercel about available roles and one of them was Lee, who had just been promoted to Head of Developer Relations. Back then, I was looking for a job as a developer and DevRel was not a career path I had considered until I started to prepare for the interview.
I was so nervous about it, mainly because I had followed Lee’s journey into Vercel, admired his work, and was worried he’d see my lack of DevRel experience or audience as a negative.
To help me prepare, I purchased Sam Julien’s ebook ‘Getting Started in Developer Relations’ and read it in one sitting. Then, armed with my newfound expertise 😂 and Sam’s reassurance that anyone could learn the skills to work in DevRel, I jumped into the call.
“I like your background” I blurted out, like a total fangirl. 🤦🏻♀️
Lee was cool about it. He shared a bit of his journey, what it was like to work at Vercel, and how he was able to combine his hobby as a videographer with his work.
Then it clicked, I’ve always loved making videos, but never saw it as a viable career path. Could I possibly combine a hobby and technical skills in my job too?
After our call, I sat down and put myself in Vercel's position. I didn't have experience in DevRel, an audience, or even a public creative track record. Any decision to hire me would be a gamble between risk and perceived potential. How could I reduce any misgivings and make their hiring decision easier to make?
I immediately reached for my camera and set to work recording a video that walked through a Next.js feature.
It took me 4 hours to produce a 2-minute video. And to be honest, it wasn’t great... I was over-exposed and out of focus, the sound was way too low and my camera manner can best be described as a mixture of awkward and surprised.
But I sent it to Lee anyway. My reasoning was to show the quality floor and give Vercel more information to help with their decision. Even if it wasn't perfect, it would be better to show something and trust they could sift through the flaws and see potential than miss the opportunity because I was being a perfectionist.
Lee’s response was charitably positive and he offered to help me with recording setups and editing strategies. “This guy seems like a good manager,” I thought, “I’d like to work with him”.
To cut a long story short, both proved to be true. Over the next few months, Lee became my manager and mentor. He worked on a comprehensive onboarding plan, made himself available to answer questions, and took the time to provide actionable feedback on my work. I soon learned that two of the operating principles of our team were to hone your skills and elevate your work, and for the first few months, those became my focus.
I took a technical writing course, learned how to record and edit videos, how to use Figma to create assets, how to prep conference talks, how to collaborate with developers in the industry, how to work with other creative folks such as design and marketing. I even painted my wall black, bought a plant named Frederico, and ended up making a playlist for Next.js Conf.
Speaking at Next.js Conf about getting started with React and Next.js:
Speaking at React Conf about Interactive Playgrounds:
Traveling to Paris to chat with the charming folks at Prismic about becoming a developer, what’s new in Next.js, and their slice machine feature (more videos coming soon):
This is probably the most common question in my DMs.
Now that I’ve had some experience of what DevRel is and what skills are involved, I feel I can more confidently answer this question.
The short answer: you should start creating content that helps demonstrate you can already do the work.
The long answer: be strategic by consistently producing content around a focused topic. The topic should be an intersection of what you’re interested in, what you’re good at (or would like to improve on), and what is useful to the target user of the companies you’d like to work for.
Either a company will notice your content, or you will have a really strong case when you apply, or learning in public will create opportunities that weren’t there before.
Looking at my team, none of them (except Hassan briefly) had specific DevRel experience before joining Vercel. What they all had in common is that they did something applicable to DevRel in public. Lee made Next.js courses, Hassan grew communities, Steph made Vue videos, Steven built startups. The key was they all demonstrated competency in a focused niche before they were hired.
As someone starting out, the best way to grow is by doing the work. By creating content, you’re demonstrating your competence to companies, solving their problems by helping their users, developing your skills, and building a relevant audience. All things that will greatly benefit you in your DevRel career. Narrowing your focus reduces your scope and helps you stand out.
One way to help you narrow down your focus is to break down your content strategy into three steps:
Where you want to work
Tech is extremely broad. Choose a category of tech to focus on. If your focus is too broad, it’s not immediately obvious to companies how you can help them in particular. I personally picked companies I wanted to work for, looked at their stack and products, and started creating projects around their tools.
What area of DevRel do you want to work in
In his book, Sam Julien breaks DevRel into 2 main areas:
- Awareness & Education - creating awareness about the product through conference talks, collaborations, workshops, and meet-ups. Enabling developers to use your product through educational content (video, articles, courses, etc) and examples.
- Community & Feedback - setting up and managing spaces for your community, answering community questions; understanding how the community is using your products, and bringing that feedback back to your company to help steer the product’s direction.
My colleague, Hassan, similarly breaks it down into three pillars: Content, Community, and Product.
I think at this stage, the most productive area to focus on is producing educational content and providing value to the community. This type of work is much easier to publicly prove and is the area most new DevRel teams begin with.
At the very least, even if you don’t immediately land a DevRel role, learning and building in public is rocket fuel for your career.
What skills do you want to grow?
DevRel is a multidisciplinary role, there are many new skills you could learn. I like to break them into three main categories: creative, technical, and communication. Good content will have aspects of all three but it might be easier at the start to focus on one so you stand out from the crowd in that capacity.
- Creative skills help you raise the quality of your work (writing, filming, editing, etc.). For example, this video on creating a portfolio with Next.js is over an hour long and the author doesn’t speak at all but is popular because it is highly creative. It demonstrates creative ability.
- Technical skills give you credibility, help you empathize with users, and create technical resources that help developers use your tools well. For example, this article on Next.js middleware helps people use a new feature. It demonstrates technical competence.
- Communication skills help you deliver your message in a clear, concise, and effective way. Developer Advocates are communicators. They need to be able to find the best way to deliver their message through the medium they are using and adapt their style to different audiences and skill levels. Whether that’s through public speaking, writing emails, or giving feedback. For example, this thread resonated with our community because it broke down the features announced at Next.js Conf into simple digestible pieces. It demonstrates effective communication.
Once you get past the initial feelings of inadequacy, it is a great place to work. As Lee put it in his Hypergrowth blog post:
“When you’re in an environment with exponential company growth, you’re also likely to have exponential personal growth.”
No company is perfect but something I admire about Vercel is that it is incredibly transparent.
Most day-to-day discussion happens in a company-wide public project or team channels. It’s great to be able to see ideas take shape in real-time, keep tabs on the development of new features, celebrate each other’s wins, and give and receive cross-team feedback.
When an idea is crystallized, it’s moved to a more permanent and appropriate tool. Everything is documented and made available company-wide, from company values and long-term vision to departmental strategies, processes, and guides, to individual project summaries and roadmaps.
This wealth of information is extremely valuable to hybrid teams like DevRel that need a high-level overview of the direction of multiple teams. And extremely cool to watch each world-class department in action.
As I mentioned before, the first six months at Vercel were about learning — learning the skills that would help me be successful in my role, learning about Vercel and its products, establishing systems, and figuring out my unique take on DevRel.
Here are some lessons I’m learning:
As a Developer Advocate, your personal brand and reputation are closely coupled with your role.
With this in mind, building and maintaining trust is important. Here are some guidelines I’ve set for myself:
- Empathize with user's frustrations and concerns
- Focus on helping developers make informed decisions
- Give balanced views
- Acknowledge drawbacks and what can be improved
- Compete with integrity
Behind every talk, video, article, and collab, there are hours of learning, coding, planning, writing, editing, and polishing. People are attracted to the public-facing side of DevRel, but most of the work happens in the background. Most of the time you’re just a conduit between two groups. Making sure users’ struggles are heard and helping product communicate to users.
To work in DevRel, you need to enjoy the work that goes on behind the scenes; the work that most people often don’t see.
As a new Developer Advocate, you inevitably have to choose between quality and speed. It can be tempting to want to prove yourself by producing lots of work but it shouldn’t be at the cost of quality. One thing that I quickly learned about creative work is that takes time.
When I started, I unconsciously chose quality because I wanted to produce quality work for Vercel. Looking back, quality helped me build a foundation to produce better, faster work.
So how can you improve your work?
- Embrace feedback - ask your manager for feedback, ask your peers for feedback, ask trusted community members for feedback, and take time to give feedback. An extra pair of eyes on your work always helps raise the quality bar.
- Iterate - As James Clear so eloquently puts it:
"The difference between good and great is often an extra round of revision. The person who looks things over a second time will appear smarter or more talented, but actually is just polishing things a bit more. Take the time to get it right. Revise it one extra time." — James Clear
- Step away from it - if you’re stuck trying to find the right way to communicate something, take a break.
- Set aside time to learn - Practice helps you become better. But for faster results, practice alone isn’t enough, you need to know how & what to learn.
- Ship at 90% - there’s likely going to be something you’re not happy with, choose what to sacrifice and add it as an improvement for your next project. Build a system that keeps improving.
- Do self-retrospectives - after finishing a project, ask yourself: what went well? what could be improved? what will I do differently next time?
There were many things that scared me going into DevRel, the biggest ones were conference talks. I’m an introvert, so being in the spotlight in front of thousands of people (even if it’s virtually) terrified me.
Instead of letting that fear consume me, I spoke at Next.js Conf and React Conf. I wasn’t happy with either of my talks. But, as Mahmoud once told me:
“Once you do the hard thing once, that becomes the baseline for you.”
And I’ll add that once you know where the baseline is, you know what you can improve on.
Being aware of where you are and where you need to be is the key to growing in DevRel (or any career really). So growing in this new role was not just a perk, but a necessity. As Julien puts it in his book:
New skills mean new opportunities for creativity, new ways of looking at things, and new relationships. And that feeling of discomfort and discontent? That's growth as a human. Growth is good!
Lastly, DevRel is about engaging with developers trying to solve real problems. Even the most negative or non-constructive feedback is generally not a personal attack on you, your company, or your products, but a genuine frustration with not being able to do want they want.
All feedback is a gift (even if it comes in a rude or non-constructive package). If someone is struggling, most likely others are too. Being able to isolate the cause of frustration from the expression of frustration requires social maturity, empathy, and keeping your emotions, biases, and ego in check.
At the end of the day, it’s about people. A nice personal example was when I recorded an interview with the Prismic team. The Prismic team was incredibly hospitable and my host, Sam Littlefair, did a great job at easing both of our nerves. I left their office thinking about how I wanted to make people feel after an interaction.
Now that I feel confident that I can produce quality work, I want to focus on the results I want to create: shipping impactful projects that truly help users of our tools build great products and doing my part to help them make the web. Faster.