So you’re starting a new DevRel Job…

cover photo by Tim Marshall on Unsplash

It’s not uncommon to start a new Developer Relations or Community job at a company and either be their first hire, or you’re coming in after someone else (or a group) has left, or you’re coming in to take over the team (or any variety of these and others not mentioned). Usually during your initial onboarding you’re asked to provide a 30/60/90 plan along with a strategy for the next year. This may seem daunting, but it’s something you should be prepared to do.

I’ve personally spent over 10 years in the official “DevRel/Community” space, and done devrel-adjacent activities pretty much all of my career. What follows are the questions and steps I’ve learned to apply which are by no means complete list - I’ve added to this list after each role change - but should be a good starting point for you. In addition, I’ll include at the bottom suggestions from others in the industry.

Before I get too far into this, I do want to make sure you take some time to go over the great resources that Rizèl Scarlett put together in her DevRel Journey Series, with a specific call out to her Tips to Succeed in your First DevRel Job.

Before joining

One of the first steps is to make sure you fully understand everything you can about the job you’re potentially taking. Making sure you ask some of these questions will help you to be a bit more informed about what you might expect before you start.

1. How does the company make, and lose, money?
2. What area of the company is the DevRel team a part of? Who would you report to?
3. What are the “big rocks” the department and company are tackling this quarter/year?
4. How are objectives identified and handled?
5. What is expected over the first 30/60/90 days?
6. Why do they want or need a DevRel team?

These will help to give you an idea of the company and how it’s structured and what you might be faced with on Day 1. All of the above come with the caveat that businesses can, and do, change from the time you receive the answers above to the time you start. However, this will give you a foundation to build off of.

photo by Tim Marshall on Unsplash

When you start

That first day, or week(s) in some cases, is usually full of all of the onboarding tasks which will occupy your time. That is, however, a good time to start your own personal onboarding to the team and company with some of the below steps:

1. If you’re onboarding with more than just yourself, build relationships with your fellow “first day-ers” - you never know when your paths might cross again and it’s good to have a frame of reference.
2. Meet with your manager and clarify the job as you understood it when you took the position to make sure you’re both on the same page. Also,
   • Make sure you understand the timeframe they have for the first deliverables for the position (30/60/90 day plan, strategy, etc.) and how they would like to receive it.
   • What is the budget that I have for the team? What was last year’s budget? What amount of discretionary spending do I have?
   • Identify how they would like to receive information like metrics, status, objectives, etc.
   • Identify who they would like you to meet with. This will likely be a high-level list, and you will want to drill down with each person when you meet with them.

After the onboarding

Once you’ve gotten through the “administrative” pieces of joining the company, you want to get started with the “roadshow”. This involves meeting with those identified by your manager, along with leaders in the following areas:

• Product Managers, Owners, etc.
• Product Marketing, Content, Demand Gen, etc.
• Engineering, Sales Engineering, etc.
• C-Level
• Customer Success

In those conversations, make sure to ask “Who else should I talk to?” and setup those meetings soon after. Below I will provide the questions that I use for the respective areas, some of which are duplicated across different teams. If you use any of these, it’s important that you customize them to your respective company.

Questions for everyone

1. What is the mission, vision, and values for the company? What are they for ?
2. What are your priorities and goals? What wins do you need? How can DevRel help you accomplish those? How can I help you?
3. What are your biggest concerns about working with developers?
4. Do you have any concerns about the Developer Relations team and the way they’ve worked cross-functionally in the past?

Questions for Product teams

1. What are the pillars of our product?
2. What is our threshold for a new account for them having successfully “onboarded”?
3. What are the things we are currently hearing from users about our product?
4. Do we know when developers make the transition from checking us out, to “swiping the card”? Do we know why?
5. Do we know why developers do / do not choose us?

Questions for Marketing teams

1. [Demand Gen] What is our process for identifying developers at conferences/trade shows/events? How do we decide what to send to them? Any examples?
2. [Demand Gen] What is our current process around swag? Who is responsible?
3. [Demand Gen] What is the process for attending/sponsoring conferences?
4. [Demand Gen] Where in the funnel do you see DevRel helping?
5. [Demand Gen] What are our currently targeted developer communities? Regions?
6. [Demand Gen] Do we know when developers make the transition from checking us out, to “swiping the card”? Do we know why?
7. [Demand Gen] What is the current geographic customer breakdown, and what are the goals for this year and beyond? Any regions we’re avoiding specifically?
8. [Demand Gen] Where are our current, target markets? What are our current, targeted technologies?
9. [Product Marketing] Do we know why developers do / do not choose us?

Questions for Customer Success teams

1. What are the customer pain points that your teams are currently hearing about?
2. Are there any identified users who are already passionate about us?
3. Is there a space where we collect and share common issues or FAQ with the community?

If there is already a community….

1. What is the current community forum process? Who owns what?
   • The system?
   • Answering questions?
   • Outreach activities?
   • Any current processes to get an answer from someone in the company?
2. What metrics are currently collecting about the community? Programming languages? Functions/roles? Geographic locations?

What now?

Once you’ve gathered all of the answers, it’s time to look for common themes from each which can help you identify potential opportunities as you build your strategy and program. In theory, you should be able to have the beginnings of a strategy and program to present within the first 60 days to the key stakeholders who you identified during your “roadshow” in order to get their feedback, and then modify as needed by the 90th day.
Over the next 3 months (equal to the first 6 months on the job), start to implement the first steps of your strategy and tweak it as needed, with a mind to seeing results within the first year. This doesn’t mean that everything would be done and yielding results in the first year, but rather that you should start to see progress around your strategy, and that you’re hitting specific milestones that were identified. Then rinse and repeat.

Insight from others in the community

As I prepared to write this blog post, after thinking about it for a long time, I reached out to the DevRel community on Twitter and Mastodon to see what other insights they had to share, which you can find below.

(Note: I hadn’t heard of the Likert scale before, though I had used it in other activities, so it’s worth a good read and implementation. Thanks Tristan!!!)

And some additional thoughts from Mimmis on LinkedIn

Great pragmatic advice around process and types of questions for anyone starting a new job, not just in DevRel, where you are tasked with coming up with plans and recommendations (certainly works for developer marketing and B2B marketing as well).

Ask about and try to understand overall company strategies and objectives, take an interest in not only your own job function but adjacent depts and roles and how they contribute to those objectives, don't be afraid to ask questions, take notes and put two and two together from different meetings, summarize your observations and findings as you go along.

I think it's helpful to organize the findings as a Gap Analysis in different areas. This can be done as a mindmap for yourself or with bullet points in a table with three different columns: Current Situation, Desired State, Gaps to Address.

You can then identify necessary actions to address those gaps and depending on budget, competence and resources available slot them into your plan. What can you do yourself = short-term plan. Actions that require budget, competencies or resources that you currently don't have = long-term plan. Discuss your findings with your manager and agree on priorities, alter the plan accordingly.