It's been a year since I first published thoughts on the hiring process for a first devrel person at a startup. By far the most common follow-up question has been from both hiring managers/founders and the new hires themselves, on how best to start their new journey together.
Having a plan for "the first 90 days" is ideally mapped out when a job posting is put up, as it can help in giving both recruiter and candidate more clarity in what the hiring manager is looking for. However, things can change a lot based on the natural strengths of the candidate (whether they are inclined towards content vs community vs product) and what the company perceives to be its most immediate needs (see the Radiating Circles/Developer Journey diagram) and there should be an ongoing discussion as the best-laid plans from both sides encounter their actual reality check - the developers they serve.
Treat this as a menu, not a checklist. Everything below is just one way of sequencing a 90 day plan, and of course should be tweaked and done out of order based on extenuating circumstances.
Edit: Alex Trost writes in with his list of questions to answer during your onboarding, which I would recommend as a complement to this time based sequence! https://trost.codes/posts/starting-strong-in-devrel/
Week 1-2: Onboarding
Try out every part of the existing product (including CLI, docs, examples, tutorials, and paid features)
- Success metric: Find at least 3 specific and easy things to improve — if you can't, you're not looking hard enough — and personally fix them (get help if needed - part of the exercise here is learning who to go to when you need to get stuff done in future)
Build a personal working demo of the company product from scratch (it doesn't have to be anything groundbreaking but should try to demonstrate as many core features as possible working in one realistic project. You might use this in future talks, or you might throw it away, don't put too high expectations on it as it is just a learning tool)
- Bonus: record a video demo and post on public channels. Low expectations please.
Meet all internal counterparts in engineering, product/design, and docs/support
- Bonus: Set up regular checkins every 1-4 weeks, ending after 90 days
Write and (optionally) publish a "why I joined/why [company] is the future" post
- This is as much for posterity as for checking alignment in expectations with hiring managers/founders
Get access to all tools of the trade, including: permissions to manage company social media & YouTube, posting to company blog, creating example repos on company GitHub, product telemetry, website analytics, community analytics (either Discord/Discourse/Slack analytics, or aggregators like CommonRoom or Crowd.dev).
- Don't worry about being comprehensive - more important to ship stuff and figure this out on a just-in-time basis rather than spend time setting stuff up just-in-case.
(optional, but recommend for remote new joiners) Coworking in person with founders/hiring managers for 1-2 weeks
Month 1: Mastery of Product
Understand the Roadmap - be able to explain what the company is prioritizing next and why (including reading all related documents, and what has been harder to do than anticipated)
- Bonus: help to ship something small that you want to see in the product. You'll gain a personal connection to it, and engineers/PMs/users/customers will respect your technical chops.
Understand paying customers - a core failure of devrel is only talking to free tier/beginner users. Efforts targeting this audience tend to show the largest numbers, but are the least loyal/technical/deep users.
Fix this by setting up/shadowing sales calls with paying customer champions, or reviewing "game tape" (eg Gong recordings) of conversations with each and taking extensive notes on the words they use to describe their pain points, evaluation criteria, and ultimately the product.
Bonus: produce a company case study based on a customer interview
Also note what is not being said by them - things the company thinks is important but that customers don't yet recognize; one side will be wrong and it's helpful to figure out which, as early as possible
Study the core codebase - understand how the most important pieces work under the hood
- Bonus: implement a minimalist toy version yourself (in Build Your Own X) to explain the important key concepts to others, but also to list out the long tail of details that are NOT handled by a minimalist implementation, that users should just pay your company to do for them. Example - ScrapingBee teaches you to do Web Scraping so that you give up on doing it yourself.
Develop a "stump speech" presentation - a 5-10 min talk/demo track you will use to pitch the product in your own words - and present it internally to get feedback
Be able to do this with and without slides
Bonus: have a two word, 1 sentence, 2 minute public narrative, and 25 minute version that founders are happy with and that sounds authentically like you rather than marketing website or investor pitch deck copy.
Studying great DevTools pitches helps but yours doesn't have to be perfect, or even complete; just be interesting/intriguing/inspiring.
Understand your current users: look at top support requests from users, and assist in answering support/community tickets (if Support owns Discourse, you can help on Twitter/Slack/Stackoverflow/Reddit etc - be careful not to commit to permanent support load, but dabbling in occasional support really helps increase your empathy with users, as their concerns are usually far more mundane/practical than what PMs/Founders want to pitch)
- One lightweight way to do this is to commit to regular weekly/biweekly community calls, or monthly meetups (in person meetups are good if you have the resources to do it, but you always need to have good online game since the TAM is so much larger)
Continue studying code - including non-core code, exploring deployment strategy, testing/CI/CD, community plugins, CLIs, any other products that are commonly used together with your company's product
- Bonus: Spin off demos and reference implementations as you go, seeking specifically to fill in gaps where people often get lost. Success is having your stuff continually referenced by others (your coworkers, community, whatever) when relevant.
Understand ecosystem: Go thru the competitive landscape with founders/hiring managers and agree on who are strategic partners, potential customers, and mortal enemies (having a Big Bad that your company is counterpositioned against is very very helpful for benefiting whenever they screw up).
- Bonus: Be able to explain your relationship/positioning with each to external parties in a way that founders would agree with. This basically is your self driven course to becoming a spokesperson the company can fully trust.
Understand trends: a core source of your power as DevRel is understanding what hot-button topics ignite debate, and drive attendance at your events and viewership for your content. Review the past 1-3 years of top trending talks, product launches and articles, building a thesis for what your core audience is interested in (ignoring your company/product).
- Bonus: Publish your research for others to follow along/correct you. Learn in Public!
Start building DevRel Infrastructure:
Agree on the important conferences, surveys, newsletters, podcasts, YouTube channels, and key influencers in your domain, and keep them on a watchlist with a plan to engage all of them at least once per year
See my list of Elements of DevRel Infrastructure
Month 3: Mastery of Content
By now you've done most of the prep work you need to be a great advocate for the developer both externally and internally. You should have a good mental picture of your user base, the various buckets of your customer profile, and what interests them/how to best represent the company to them. Month 3 is a great target period for you to make your mark with the confidence that you've done your homework.
Schedule talks: If you wish to be known as a speaker on the "conference circuit" in your industry, you will mostly need to start by applying to speak at conferences (until you are a known speaker and unlock inbound invitations) for your first few years. I have written more CFP advice in my book, but also you can "practice" by speaking at meetups and going on podcasts, all of which you can start reaching out with hopefully mutually beneficial topic ideas.
Work on a launch: Hopefully, your product and eng team are shipping something noteworthy every quarter. Find something you can gradually take ownership of and help drive the launch for, including: prelaunch beta testing/gathering user feedback, ghostwriting/writing the launch post, building and recording demos, scheduling media appearances, drafting HN/Reddit/Social posts, running post launch webinars.
- You do NOT have to do ALL of these - responsibilities will vary based on your company resources around product management/product marketing. Especially if the company is still small, beware of taking all responsibility from founders. Help augment/organize/cover their bases, but founders being too disconnected from their users/community early on is less a sign of your awesomeness and more a red flag. At the end of the day, founders are part of the devrel team too.
Own a channel: During the "off season" when there isn't a big launch on the horizon, you'll want to have a primary content "channel" that you own, where you produce content and listen to a large developer audience. This can be sliced various ways:
Communities: YouTube/TikTok/Reddit/Twitter/LinkedIn/Slack/Discord
Languages/Frameworks: JS/Python/Go/Java or React/Vue/Angular/Svelte etc
Primary Medium: Company Blog, Newsletter, YouTube, Twitch, Twitter, etc
Within each channel you should try to develop 1-2 "formats" that work. (I will write a fuller piece on this in future but basically think about how SNL and other TV talk shows/variety shows experiment with different "segments" and some "segments" become popular recurring formats - this is how you will reduce the cost of content creation and improve the chance of success.)
Most dev advocates will come in with a natural tendency toward communities they already belong to, and usually it is a good idea to stay there because they will understand some implicit cultural norms that help them connect better. However, it's not unheard of to switch or experiment, as the metagame is always changing.
The ideal sustainable full time dev content creator output is one substantial "unit of work" per week, whether it be a blogpost or video. You can bunch up "units of work" to deliver bigger lifts, for example, take 2-3 weeks to write and deliver a quality conference talk or take 2 months to make a longform workshop to deliver on LinkedIn Learning/YouTube.
To deliver one "unit" per week, you usually you also want to be multitracking several content idea candidates for each week. Sometimes this is tracked as a content calendar, or brainstorm list; whatever it is, don't be held captive to your backlog, act on what inspires you, what you can ship, and what will hold interest/attention based on what you are seeing in the community.
Most devrel overcommit to too many projects early on and output falls accordingly. Spreading yourself thin is usually not as good as finding one format/channel combo that works for you and hammering on it for 6-12 months to be known first before branching out.
This will approximately coincide with your first OKR cycle where you will be forced to come to terms with which devrel metrics you will own/be accountable for (all of them are flawed, but something is better than nothing).
- Own an initiative: If launches are done to support product/engineering-goals, and content channels are for business-as-usual type steady state content creation, then devrel initiatives are larger projects driven purely by devrel, for example workshops, hackathons, community surveys/meetups/conferences, books/university programs, and so on. I don't recommend tackling these in your third month but it's worth starting to think about this as you settle in to your first year.
These are just quick thoughts I often give to friends, and I likely have missed something important to do earlier rather than later in a devrel journey. Please let me know if there's something I missed!
