[
  {
    "path": "LICENSE",
    "content": "MIT License\n\nCopyright (c) 2019 Naomi Pentrel\n\nPermission is hereby granted, free of charge, to any person obtaining a copy\nof this software and associated documentation files (the \"Software\"), to deal\nin the Software without restriction, including without limitation the rights\nto use, copy, modify, merge, publish, distribute, sublicense, and/or sell\ncopies of the Software, and to permit persons to whom the Software is\nfurnished to do so, subject to the following conditions:\n\nThe above copyright notice and this permission notice shall be included in all\ncopies or substantial portions of the Software.\n\nTHE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\nIMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\nFITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE\nAUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\nLIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,\nOUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE\nSOFTWARE.\n"
  },
  {
    "path": "README.md",
    "content": "Developer Relations Strategy - *Step By Step*\n----------------------------------------------\n\nYou have stumbled upon the guide to creating a strategy for your (team's) developer relations work.\n\n## The summary\nA strategy is a framework for understanding what the right thing to do is and a tool for knowing roughly how you are going to achieve your goals.\nIn this guide I will take you through multiple steps. The first step will be the creation of an **analysis of your current situation**. From there we will discuss what your **overarching goals** and themes for the upcoming quarter(s) will be. Finally we will guide you through **setting SMART goals**.\n\n## What will I get out of it?\nYou will get a concise set of documents that document your team's focus areas, strategy, and goals. These documents will be a valuable resource for the team and other stakeholders.\n\n- **Written assessments of your products.** This includes target audiences, the product landscape, competitors etc.\n- **Written documentation and analysis of your current initiatives.** This includes short summaries, goals, who is involved and responsible, and how well things are going.\n- **Defined themes for the upcoming months.**\n- **Defined strategies and goals on a per initiative level.**\n- **A written overview of where your team sits in the company.** This will detail stakeholders as well as teams that you closely work with along with their goals.\n- [optional] **Better knowledge of how your team likes to work together.**\n\n## Structure\n\nThis guide is set up for the person leading the training. Within each step you will find a readme that contains outcomes, an introduction, preparation todos, the tasks, as well as some helpful notes. Below you will find a brief overview of each section. You can also find helpful notes on the schedule, ideas for energizers etc. in the [Schedule, Energizers, etc. folder](/Schedule%2C%20Energizers%2C%20etc.).\n\n##### [Step 0: Communicate well 🎤 [30 min] [_optional_]](/Step%200:%20Communicate%20well)\n_While this is optional it is strongly recommended, especially if you have new people on the team!_\n\nThis exercise focuses on the team getting to know one another and outlining how they like to be communicated with. Each team member will create an instruction manual for themselves outlining preferred communication platforms, languages, project types, etc. This aims to help the team effectively work with one another and to give you a better idea what work your team members enjoy doing.\n\n##### [Step 1: Know your org & products 🧐 [30 min + 60 min * number of products]](/Step%201:%20Know%20your%20org%20&%20products)\nTo start, your team will examine the org and teams around you, including their target areas. This will allow you to see and avoid overlaps in the following steps. Next, you will get to know your products more intimately. You will perform segmentation exercises for each product. Finally, you will document the findings to ensure a common understanding of each products target audience. You may find during this step that you start having ideas around new initiatives for certain products - write these down!\n\n##### [Step 2: Know your team & initiatives 🙌 [180 min + 45 min * number of initiatives]](/Step%202:%20Know%20your%20team%20&%20initiatives)\nIn the previous step you got to know your org and products. Now, you will focus on the team. As part of this you will review _all_ current initiatives. These current initiatives will be documented to ensure a common understanding of current initiatives. You will also do a retrospective for each initiative and for the team's work as a whole.\n\n##### [Step 3: Define themes 🧞‍♀️ [160 min]](/Step%203:%20Define%20themes)\nYou may have many current initiatives or many ideas for new initiatives. In this section you will define overarching goals or themes. These will in the next steps allow you to set more concrete goals. Best of all, this will give you a framework to decide whether you should spend time on X or not!\n\n##### [Step 4: Define an event strategy 💃 [80 min]](/Step%204:%20Define%20event%20strategy)\nIf your team does a lot of event work, it is advisable to create an event strategy. In this section you will analyze some events across different criteria and then work towards identifying the selection criteria that make sense for your team.\n\n##### [Step 5: Set SMART goals 🏃‍♀️ [15 min * number of initiatives]](/Step%205:%20Set%20SMART%20goals)\nSpecific, Measurable, Achievable, Relevant, Timely. Those are the keywords that you need to keep in mind for this section. These SMART goals will describe what your team is planning to do in the coming quarter(s). Each project/initiative the team is undertaking should have some goals attached to it. You will also consider metrics in this section.\n\n##### [Step 6: Documentation 📜 [2h]](/Step%206:%20Documentation)\nPull everything together. This is the last task for the person leading this workshop. In this, you will create an overall reference document/folder where your team's strategy is clearly defined. This will be invaluable throughout the next quarter's in keeping you goal-oriented. It will also be a good resource to have at hand when doing your yearly review!\n\n### Preparation 👈\n\nIf you are planning to use this for a team planning workshop, I suggest you go through the entire step by step guide _before_ you start the workshop.\n\nI suggest creating a team repository or a Google Drive folder for this session. This will allow you to keep all materials/documentation that you produce in one place.\n\n##### Materials 🗝\n- post-its & felt pens\n- tape\n- print outs of the materials for each section\n- a small plush animal\n\n### FAQ 🤔\n**⏳ How long does the entire step by step process take?**\nHere's a nifty formula that should give you an idea:\n\n**`Time in hours = 8h + 1h * Number of Products + 1 * Number of Initiatives + break time + lunch time`**\n\n**`break time = for every 4h calculate 1h as break time or buffer`**\n\n**`lunch time = for every 7h add 1h for lunch`**\n\nOr if you prefer a python 🐍 program:\n```python\nimport math\n\ndef time_to_complete(num_products, num_initiatives):\n  time_in_hours = 8.0 + 1.0 * num_products + 1.0 * num_initiatives\n  # for every 4h calculate 1h as break time or buffer\n  time_in_hours += time_in_hours/4\n  # for every 7h add 1h for lunch\n  time_in_hours += math.ceil(time_in_hours/7.0)+1\n  return \"{} days, {} hours\".format(time_in_hours//8, time_in_hours % 8)\n\n> time_to_complete(3, 9)\n'3.0 days, 5.75 hours'\n```\n\n**👋 Can I contribute?**\nYes! Contributions are very welcome. Please create an issue to discuss what you would like to contribute first and then create a PR.\n\n**💼 Can I use this in my company?**\nYes! Please note the `license.md` file. If you would like a professional dev rel consultant to help you I suggest you reach out to the fantastic [Matthew Revell](https://matthewrevell.com/), [Cristiano Betta](https://betta.io/), or [Mary Thengvall](https://www.marythengvall.com/about/).\n\n**Is this for me?**\nThis guide features information and multiple exercises designed to help you define your (team's) strategy. You may find that some exercises fit better than others and that you need to add/change content for your team's needs.\n\n**😳 Do we really need this?** Yes. Defining your strategy will help your team and your stakeholders understand what you are doing. It will give you the tools to see whether you are reaching goals and having the impact you want to see. On top of that, it gives your superiors a chance to understand what you are doing and why you are doing it. Hopefully this will ensure your team's value will be obvious (and avoid people thinking of dev rel as a sinkhole for monetary resources).\n\n**👩🏼‍💻 Who are you?**\nI'm [Naomi](https://twitter.com/naomi_pen) and I love thinking about processes and strategy. Personally, I think I do my best work when I see how my work aligns with strategic goals and when I can justify to myself and others why I am spending time doing X. To help with that, I created this guide for my team and for other teams to create a methodical approach to defining your developer relations strategy. Strategy is, of course, not the only thing I love. I also _love_ ✨ emoji ✨, [samoyeds](https://weheartit.com/entry/307342706), my niblings, and [writing](http://blog.naomi.codes/).\n\n**Credits**\nA lot of this content is drawn from resources the phenomenal DevRel community has provided. The training is based on training I received from [hoopy](http://hoopy.io) during DevRelCon.\n"
  },
  {
    "path": "Schedule, Energizers, etc./README.md",
    "content": "# Schedule, Energizers, etc. 🗓 ✨\n\n## Introduction\n\nThis section covers:\n- an example schedule\n- energizer ideas\n- 6 thinking hats\n- other tips\n- conclusion\n  - feedback\n  - thank yous\n\n## Example Schedule\n\n**Day 1: Analysis of the Situation**\n\n| Time | | Time | |\n|--|--|--|--|\n| 09:00 - 09:30 | Breakfast | 12:00 - 12:45 | Lunch |\n| 09:30 - 09:50 | Intro today| 12:45 - 13:00 | Energizer |\n| 09:55 - 10:25 | [Step 0] Instruction Manuals | 13:00 - 14:30 | [Step 1] Product Analyses Part 2 |\n| 10:30 - 11:00 | [Step 1] The Org | 14:45 - 15:15 | [Step 2] History of Dev Rel|\n| 11:15 - 12:00 | [Step 1] Product Analyses Part 1 | 15:15 - 17:00 | [Step 2] Initiative Review|\n\n**Day 2: Retrospective, Ideation, and Setting the Destination**\n\n| Time | | Time | |\n|--|--|--|--|\n| 09:00 - 09:30 | Breakfast | 13:40 - 14:10 | [Step 3] Company Goals |\n| 09:30 - 09:50 | Summary of previous day & Intro to today | 14:15 - 14:45 | [Step 3] The Funnel |\n| 09:55 - 11:25 | [Step 2] Initiative Retro | 15:00 - 15:30 | Articulating Themes |\n| 11:40 - 12:40 | [Step 2] New Ideas | 15:30 - 16:00 | [Step 3] Mission Statement |\n| 12:40 - 13:25 | Lunch  | 16:00 - 17:00 | [Step 3] Alignment |\n| 13:25 - 13:40 | Energizer |\n\n**Day 3: Event Strategy & Setting Goals**\n\n| Time | | Time | |\n|--|--|--|--|\n| 09:00 - 09:30 | Breakfast | 11:30 - 12:00 | [Step 5] Intro to SMART Goals |\n| 09:30 - 09:50 | Summary of previous day & Intro to today | 12:00 - 12:45 | Lunch |\n| 09:55 - 10:25 | [Step 4] Events Intro | 12:45 - 13:00 | Energizer |\n| 10:30 - 10:50 | [Step 4] Events & Team  | 13:00 - 17:00 | [Step 5] Setting SMART goals |\n| 11:00 - 11:30 | [Step 4] Event Strategy | | ** ** |\n\n**Day 4: Buffer time & Conclusion**\n\n| Time | | Time | |\n|--|--|--|--|\n| 09:00 - 09:30 | Breakfast | 12:00 - 12:45 | Lunch |\n| 09:30 - 09:50 | Summary of previous day & Intro to today | 12:45 - 13:30 | Conclusion & End |\n| 09:55 - 12:00 | Team Retro & Buffer | 13:15 - 14:45 | ** ** |\n\nNotes:\n- the first intro should cover\n  - the current state of the team,\n  - the current strategy\n  - the schedule for the next days\n  - expectations from the team\n- while this schedule has some breaks planned in, you could extend those and plan in more buffer time. Alternatively you can keep buffer time on the last day and be flexible with the schedule.\n\n## Energizers\n\n_“The energizers helped lighten the mood of the room.” - Anonymous_\n\n_“As a team building exercise I loved the energizers” - Anonymous_\n\nThere's a lot of content throughout this planning session. Energizers can help lighten the mood and get everyone ready to continue working. They also offer an opportunity for different team members to get involved. Below are some examples of what you could do.\n\n### Cup Stacking 🥤\n\nYou'll need plastic cups about 100 per team. The teams try to build the highest stack of cups they can within a minute. The team with the highest stack wins. Watch [this video](https://www.youtube.com/watch?v=Rgka9_-WfEc) if you want to see an example. You can do this two or three times.\n\n### 🎶 Cups Song 🎶\n\nWatch [this](https://www.youtube.com/watch?v=6y1aOg_UO_A) if you don't know the cups song. It's actually something you can learn within about 5-10 minutes and it's incredibly fun to do as a group. One person will have to learn this beforehand [[here's a tutorial](https://www.youtube.com/watch?v=RZf_joR1Srk) and can then lead the group through the steps slowly. Once everyone can follow along, you can practice it as a group and slowly speed up. You'll need hard plastic cups (as many as you have team members).\n\n### Balloon Animals\n\nEver wanted to make a balloon animal? The basic ones are not too difficult. You can buy a starter set fairly cheaply online and then have the team follow printed out [instructions to make a dog](https://www.thesprucecrafts.com/make-a-dog-balloon-animal-2266439).\n\n## 6 Thinking hats\n[Edward De Bono's 6 thinking hats](http://www.debonogroup.com/six_thinking_hats.php), can help your team get through the retrospective parts of the planning much faster. If you're not familiar with the framework, the basic idea is that you ask the team to put on different colored hats (white - facts, yellow - optimism, red - emotions, green - ideas, blue - process, black - criticism) and have everyone think about the topic at hand with one hat on. If you're wearing a white hat, you're all just talking about facts. With green, everyone thinks about ideas, etc. The book is fairly short but a youtube intro video is also enough to get the idea. It does really help get everyone think about topics from all angles and it works a lot faster than discussing general feedback.\n\n## Other tips\n\n### Share beforehand and ask for input\nWhen planning the planning session, make sure others are aware of what you are planning, share an outline/schedule early and reach out to each person to get their input on whether they think anything is missing or should be done differently. That way everyone is engaged and can contribute.\n\n### Expectations from team members\nIt can be useful to mention in the beginning of the planning session how you expect team members to conduct themselves during the planning. Certain parts of the planning may get emotional and you want to ensure that everyone acts professionally and that no one is seeking to blame anyone but that you are all working towards a better future as a team.\n\n### Mascot\n_“Passing the monkey to indicate whose turn it was to talk seemed like a silly idea, but it was super effective in making sure that everyone had a chance to speak.”_\n\nTo moderate who is talking and ensure the quieter folks get heard, I recommend using a small plush animal (e.g. a monkey) that can be thrown around to indicate who is currently speaking. Be strict about this rule.\n\n### Knocking\n\nOften people like to rephrase what others have already said to essentially say they agree. Ask in the beginning of the planning that if this is the case, people should knock on the table to express agreement.\n\n### Time keeping\n\nDesignate one person as a time keeper (you can designate different people over the course of the planning). If you have the budget you can buy that person a small gong :).\n\n## Conclusion\n\nAt the end of each day you may want to summarize what you've accomplished. **If at all possible you should end each day on a good note.** If your team feels that, for example, a retrospective brought up a lot of criticism you'll want to make sure they see the good parts and see this state as an opportunity to improve things. At each start of the day you can again recap what has happened so far and outline what the goals for the day are. On the final day you will want to make sure to ask your team for feedback and to thank them for their participation.\n\n### Feedback\n\nAt the end of the planning session you should have a feedback form ready (anonymous ideally). These are the open ended questions you may want to ask:\n- What do you think could be improved?\n- What do you think went well?\n- Anything else?\n\nI'd love to hear your feedback. If you are willing to share this feedback, please [reach out to me](https://naomi.codes/).\n\n### Thank yous\n\nDuring the planning session it is nice to pay attention and note down good things that each person contributed. After the planning session this will allow you to write everyone a personalized thank you note which will be a nice touch.\n"
  },
  {
    "path": "Step 0: Communicate well/Readme.md",
    "content": "# Step 0: [30 min] Communicate well 🎤\n\n## Outcomes\n\n- Increase productivity by allowing team members to define how they want to be worked with.\n- Avoid miscommunication and other communication problems.\n- Decrease potential feeling of anxiousness in teams.\n\n## Introduction\n\nMost of us spend more time with our colleagues than with our significant others. It follows that we should ensure that our work relationships are as good as they can be. On top of that, it has been found that [writing user manuals for team members can make teams less anxious and more productive](https://qz.com/1046131/writing-a-user-manual-at-work-makes-teams-less-anxious-and-more-productive/). This exercise allows team members to define a manual for others who they work with.\n\n## Preparation\n\n- [ ] Decide where the instruction manuals should live (GitHub/Google Drive/...) and ensure this is accessible to the team.\n- [ ] Create your own instruction manual.\n- [ ] Notify team of this exercise beforehand so that they can prepare their manual in advance if they want to.   \n\n## Tasks\n\n### 1. Create the manuals [30 min]\n\nEach team member should take 30 minutes to create an instruction manual for themselves given the template in [`instruction-manual-template.md`](instruction-manual-template.md). This template is based on [Abby Falik's](https://www.linkedin.com/pulse/leaders-need-user-manuals-what-i-learned-writing-mine-abby-falik/).\n\nAfter each person completes their manual, take a break (so that people can finish the manual and collect their thoughts). Now have people share their manuals in your team's Google Drive or GitHub repository. Give team members time to read through each other's user guides. If your team feels comfortable with it, you can have them present their manuals to each other.\n\n## Notes\n\n- Take this seriously. You are asking people to open up about themselves and to reflect on their personalities. This can be difficult for people and make them feel vulnerable.\n- Be honest. Lead by example: Have your own instruction manual prepared and ready to share. Seeing you open up will encourage others to do the same.\n- Be careful with feedback. This is probably not the right setting to give others feedback about their user manual. If you have questions, feel free to voice them but save feedback for a separate occasion (you can see their user manual to see how the person would prefer to receive feedback!).\n"
  },
  {
    "path": "Step 0: Communicate well/instruction-manual-template.md",
    "content": "_Instructions are in cursive. Remove these and replace with 3-5 bullet points._\n\n\n## _Name_'s User Manual\n\n\n### My style\n_What makes you tick? Where are you most comfortable? What energizes you? What do you believe in?_\n\n### What I value\n_How do you want people to behave? How do you like to work?_\n\n### What I don’t have patience for\n_What drives you up the wall?_\n\n### How to best communicate with me\n_What medium? (e.g. Slack, email, calls, video) Do you prefer to receive all the information? Be cc'd on all communication? Long emails? Short updates? Information readily available in a document you can check at your own time? How do you like to receive feedback?_\n\n### How to help me\n_What are things that you know you don't do well at that you'd like help on?_\n\n### What people misunderstand about me\n_Is there anything you worry/know people misunderstand about you? This is your chance to preempt misunderstandings_\n"
  },
  {
    "path": "Step 0: Communicate well/naomi-pentrel-instruction-manual.md",
    "content": "## Naomi's User Manual\n\n### My style\n- I tend to have lots of ideas. I jot ideas down in a Kanban-like board that I then use to organize myself. If there is something I want to do, I will either find a path or make one.\n\n- I enjoy strategizing and ensuring everything is on track. I like documented and efficient processes. If I find things that seem broken I will try to fix them.\n\n- I believe in direct communication. If I notice problems or hear of problems I will address them and occasionally pass aggregated feedback of others on (generally without mentioning names).\n\n- I am not a fan of following a rule for the rule's sake. I tend to question both the status quo and rules. If rules are not self explanatory, I will question them.\n\n### What I value\n- I value trust, honesty, and loyalty. If someone proves dishonest, breaks my trust, or behaves disrespectfully it will be very hard to rebuild that.\n\n- I like to be included. CC me on everything that relates to me or what I work on. Invite me to meetings - if they are optional, tell me and I will decide whether to attend or not. I do not like to hear from third parties about what is going on, especially when it pertains to me or my work.\n\n- Small things make me happy. That can be a well-made balloon animal, meeting a good dog, and various other random things.\n\n### What I don’t have patience for\n- People who do things just because they've _always been done that way_ and who reject discussion around changing the status quo.\n\n- Meetings that have no agenda. Every meeting should come with a description. If your meeting could be an email, then make it an email.\n\n- Being told not to worry about it instead of having my questions answered. If I asked, it means I care.\n\n- Privilege and isms. We are a product of our surroundings.\n\n- Being asked questions you don't really want to know the answer to. We can skip the small talk about our families and our weekends.\n\n### How to best communicate with me\n- I like emails and slack. Emails will get my attention quicker generally. CC me on anything that relates to me.\n\n- I avoid phone calls where possible. Video calls are marginally better.\n\n- I use emoji often. They help get emotion across and that leads to more effective communication.  \n\n- If you need something from me I would prefer you got straight to the point instead of going through 5 minutes of \"Hi, how are you?\".\n\n- I like to receive feedback in person. If you schedule a meeting with me, please let me know what it will be about. This avoids me spending time thinking about what the meeting will be about.\n\n### How to help me\n- I will often question whether I am doing the right work/getting enough done. Communicating expectations clearly helps me know where I am at.\n\n- Help me find the people who I need to talk to to get things done.\n\n- Be straight-forward with me.\n\n### What people misunderstand about me\n- People sometimes think I am intimidating. Please never feel you cannot talk to me. I'd love to get to know you and explore ideas and things we can work on together!\n\n- I need time to think things through. It will sometimes take me a few days before I provide feedback. That is not because I didn't want to address the subject in the moment but because I needed time to digest the information.\n\n- I am an introvert. I gain energy from being alone.\n"
  },
  {
    "path": "Step 1: Know your org & products/README.md",
    "content": "# Step 1: [30 min + 60 min * number of products] Know your org & products 🧐\n\n## Outcomes\n\n- An analysis of how the team fits into the organization along with a general idea of the division of responsibilities.\n- A written analysis of where your products are at, how your competitors compare, what your target audience looks like etc.\n\n## Introduction\n\nBeing aware of your product(s) on it's own is a start. Generally your product(s) will not exist in a vacuum though. You will deal with direct and indirect competition. On top of that your company will hold a certain position in the market and there will be a certain climate that you function well in. Being aware of these corner stones allows you and your team to more clearly see segments of the market that you should be targeting.\n\nIn this set of exercises, your team will explore how it fits into your broader organization and then perform an analysis of your products to reach a common and deepened understanding of your products within their environment(s).\n\n## Preparation\n\n- [ ] Decide where information gathered in this section should live (GitHub/Google Drive/...) and ensure this is accessible to the team.\n- [ ] Ensure everyone has post-its and pens.\n- [ ] Try to get a whiteboard for exercise 1.\n- [ ] Prepare the org chart. It has value to have the team draw up the org chart from scratch as they may draw it differently. Keep your solution close by so you can refer to it and use it as guidance if the team struggles.\n- [ ] Create segmentation analyses for the products beforehand. As with other exercises, it is recommended to let the team draw up their own solutions without pre-imposing solutions. However, there is value in having your own solutions nearby if they're needed.\n\n\n## Tasks\n\n### 1. The org [30 min]\n\nInvite your team to draw your organization overview on a whiteboard (or paper). It does not have to be the entire org but it should include all teams that interface with you or perform developer relations or developer advocacy functions. With each team, note down their target area(s)/goals.\n\n**Take a photo of the finished org chart! If possible, leave this chart up for the rest of the training.**\n\n### 2. Product Analyses [60 min * number of products]\n\nIn groups of 2-3, fill in the [segmentation-template.md](segmentation-template.md)[1] for each of your products. Once you have finished the segmentation exercise for a product, discuss with your team. The outcome of this exercise should be a clear definition of your target audience and how you can best address them.\n\n## Notes\n\n## Resources\n\n[1] The segmentation template is based on a training by [hoopy](https://hoopy.io/).\n"
  },
  {
    "path": "Step 1: Know your org & products/segmentation-template.md",
    "content": "# Segmentation Exercise: _PRODUCT NAME_\n\n_Instructions are in cursive. Fill in each section._\n\n## Product\n- **The good: How does this product change the world?**\n\n- **The bad: What do we have to be honest about?**\n\n- **Core use cases:**\n\n## Competition\n- [COMPETITOR]\n  - **The good: How does this product change the world?**\n  - **The bad: What do they have to be honest about?**\n  - **Core use cases:**\n  - Notes:\n- [COMPETITOR]\n  - **The good:How does this product change the world?**\n  - **The bad: What do they have to be honest about?**\n  - **Core use cases:**\n  - Notes:\n- [COMPETITOR]\n  - **The good: How does this product change the world?**\n  - **The bad: What do they have to be honest about?**\n  - **Core use cases:**\n  - Notes:\n\n## Company\n- Role in the market (Market Leader/Challenger/Niche Player/Shooting Star):\n\n- Assets:\n  - who is a particular asset for this product? whom can we help with what they're good at?\n\n- Liabilities\n  - whom do we need to keep an eye on?\n\n- Legacy:\n  - past relationships, products, acts that could be a problem or a liability?\n\n## Climate\n_You cannot target all developers. There are (probably many) more than 80 million developers. You need to be aware of the factors that drive people to and from your product._\n\n- Technical\n  - Does our product only make sense at a particular scale?\n  - particular language?\n  - particular platform?\n  - certain use cases?\n- Developer\n  - how much commitment do you need from devs?\n  - how much experience do devs need to have?\n  - do developers need to be decision makers?\n  - what motivates developers?\n- Operational\n  - what types of organizations can afford our product?\n  - who makes the decision to buy it in an org?\n  - who needs us?\n- Market drivers\n  - what's the competition\n  - which verticals have the most cash to spare\n\n## Interesting segments?\n\n_This is the important part where you filter our learnings from the above answers and identify target segments._\n\n### Target Audience\n\n_Once you have identified interesting segments you will want to ask yourselves:_\n- _Is there enough relevance to the business?_\n- _Is the size big enough?_\n- _Is enough money involved?_\n- _Will we be able to reach our target audience? How?_\n\n\n- Primary:\n- Secondary:\n\n### Strategy\n(A framework for understanding what the right thing to do is)\n\nGoals:\n_e.g. Increase brand and product awareness for primary target audience, or show ourselves as caring & supportive_\n\nHow?\n_e.g. produce tutorials and quality content that will make it easy for beginners in our target audience, or produce quality content on new features with good SEO_\n\nMeasurements:\n\n## Credits\nThis segmentation template is based on a training by [hoopy](https://hoopy.io/).\n"
  },
  {
    "path": "Step 2: Know your team & initiatives/README.md",
    "content": "# Step 2: [120 min + 45 min * number of initiatives] Know your team & initiatives 🙌\n\n## Outcomes\n\n- A folder with reusable introductions of the entire team.\n- A presentation or document of the history of DevRel at your company.\n- An organized overview of current initiatives/projects that allows all stakeholders to understand current/past projects including feedback and ideas for improvements.\n\n## Introduction\n\nBefore you can plan a strategy, you need to understand your team and your current situation. To this end, the first exercise will ensure team members get to know each other and meanwhile create information that can be reused for conference biographies etc. Questions answered will include:\n- Who does what?\n- Where is everyone based?\n- Which languages do they know (human and programming)?\n- What work do they enjoy?\n\nThe next exercise will be an exploration of the history of DevRel at the company. The last exercises will have your team create an overview and an analysis of current initiatives.\n\n## Preparation\n\n- [ ] Decide where information about the team and its initiatives should live (GitHub/Google Drive/...) and ensure this is accessible to the team.\n- [ ] Ensure everyone has post-its and pens.\n- [ ] Create your personal introduction.\n- [ ] Notify team of the personal introduction exercise beforehand so that they can prepare theirs in advance if they want to.   \n- [ ] Research & create a presentation of the history of DevRel at your company (or designate this to another team member)\n- [ ] Create a list of current initiatives and fill in the templates for them along with any comments/ideas/feedback. This will serve as a help to you in the session. It is recommended that you let the team create these from scratch to ensure that the outcomes are from the team's perspective (and not only from yours).\n\n## Tasks\n\n### 1. Team map [30 min]\n\nHave everyone create a brief introduction on themselves of the form [personal-intro-template.md](personal-intro-template.md) and collect these in the team Repository/Jira/Google Drive.\n\n### 2. History of DevRel at your company [30min]\n\nThis can be in the form of a presentation by a member of the team who knows about the history of the company and the DevRel team in particular. Alternatively this can take the form of a pre-prepared Q&A or something completely different. People should have pen and paper to jot down notes and ideas. You may find it useful to record this presentation for future usage (for new team members or for creating a written version).\n\n### 3. Initiative review [30min * number of initiatives]\n\nChances are there are many initiatives/projects that are going on in your team. These may or may not be documented and you may or may not know about them and they may or may not be currently active. This exercise aims to create a common understanding of the initiatives that are owned by your team.\n\n1. Give everyone a stack of post-its and brainstorm for 10 minutes. Instruct team members to write down an initiative per post it (e.g. the blog, student hackathons, student ambassador program etc.)\n\n2. Take the next 10 minutes to create a list of all initiatives from the gathered post its with your team.\n\n3. Take each item on the initiative list and create an initiative overview for it as a team. A template for this can be found in [initiative-template.md](initiative-template.md). If your team is big you can split into subgroups and draft overviews in parallel. Ensure that everyone has a chance to read and comment on each overview. The goal is to achieve a common ground for each initiative.\n\n### 4. Initiative retro 🧢 [15min * number of initiatives]\n\nNow that we have an overview of all initiatives, discuss them as a team one by one. Questions to keep in mind are:\n\n- Is this initiative healthy?\n- Are there any known issues?\n- Could this be improved?\n- Is someone responsible for this initiative?\n- Are all processes around this initiative documented?\n- Are there any road blocks?\n- ...\n\nGather all feedback in the respective team initiative documents in the _notes_ section. To structure the retro, you may find it useful to adopt (Edward De Bono's Six Thinking Hats](https://en.wikipedia.org/wiki/Six_Thinking_Hats] approach.\n\n### 5. New ideas [1h]\n\nIt is likely that during this process the team has come up with many new ides and hopefully those were noted down in a `new ideas` section. Now is the time to speak through those.\n\n### 6. Team retro [60 min]\n\nAfter gathering feedback about each initiative, you may find it useful to also talk about other topics (team communication, processes, etc). Note that this should _not_ be things about the initiatives. To this end, pass out post-its and ask team members to note down things that:\n- they like/are grateful for\n- things that they think could be improved, as well as\n- thank you's they'd like voiced.\n\nOnce you have gathered post-its for a few minutes, put these on a wall and combine topics if applicable. Now ask your team to get up and mark the three topics they'd like to discuss with a dot.\n\nPick the topics with the most votes and discuss them as a team. Gather feedback and note down action items. You may not have time to discuss all issues but you should be able to discuss the ones your team deems most important.\n\n_You may also want to do this all the way in the end of the planning to see whether there are other things the team needs to talk about._\n\n## Notes\n\n- Throughout this and subsequent steps, participants might have loads of ideas. Ensure that they have the materials to note these down. Try not to discuss anything that goes beyond the goals of each section as this may cause you to lose focus. For example, any ideas for new initiatives or changes should be noted down but not necessary discussed at this stage. Ensure team members are aware that their ideas are valued and that there will be time for these discussions in a later exercise.\n- If the initiative documents are left incomplete, don't worry, these will be completed in later sections.\n- Any action items on the initiative document notes should be followed up on.\n- The initiative retro should focus on the initiative itself, not on actions of any current team members. It should not become a blame game.\n- Discussions can easily get out of hand, ensure that everyone's voice is heard.\n- Any action items and feedback from the team retro should be noted down and followed up on.\n"
  },
  {
    "path": "Step 2: Know your team & initiatives/initiative-template.md",
    "content": "_Instructions are in cursive. If you cannot fill something in, please leave it blank._\n\n# _Initiative Name_\n\n## Summary\n_Fill in description._\n\n## Contacts\n- **Primary Contact:** [_Name_](name@email.com)\n- **Secondary Contact:** [_Name_](name@email.com)\n\n## Stakeholders\n- _List involved groups (internal and external)_\n\n## Goals\n- _If your initiative does not have concrete/known goals, leave this blank._\n\n## Processes:\n_Link to documentation about this initiative (e.g. how to get involved). If no such documentation exists and you think it should, add this here (or create an action item in the notes below)._\n\n**Metrics:**\n- _If your initiative does not have any currently measured metrics, leave this blank._\n\n**Budget:**\n_Add budget information if known/relevant._\n\n**Status:** _Active/Inactive_\n\n**Notes:**\n_Place for any additional thoughts, ideas, feedback, action items, etc._\n"
  },
  {
    "path": "Step 2: Know your team & initiatives/naomi-pentrel-personal-intro.md",
    "content": "# Naomi Pentrel\n\n<img src=\"https://user-images.githubusercontent.com/5212232/47457283-89600f00-d78b-11e8-8fc2-487d36564805.png\" width=\"200\"/>\n\n**Location:** Amsterdam, Netherlands\n\n**Conference bio:**\nNaomi Pentrel is Developer content professional, occasional blogger, crocheter, and hacker with an affinity for Python and some web dev. Before her current role, Naomi worked as a Software Engineer at companies such as Mongodb, Google, Microsoft, and Bloomberg. Throughout her career she has worked on infrastructure automation, microservice architectures, and widely used applications such as Google Chrome and Skype. She also used to organize a lot of hackathons.\n\n\n**What I work on at Viam:**\n- docs, blogposts, tutorials, and other developer content\n\n**Countries lived:** Germany, UK, USA, Netherlands\n\n**Human languages:** German, English, Dutch, and a bit of Spanish, French, and Latin\n\n**Programming languages:** Python 🐍, some JavaScript, C++, Java\n\n**Work I enjoy:**\n- Strategy\n- Documentation\n- Writing\n- Being given time to researching topics well\n- Design\n\n**Family:**\n- My partner is Joe\n- My dog is Ernie - a small rescue toy poodle (possibly a poochon)\n- My sister, her partner, and my two lovely niblings all live in Germany\n\n**Biggest dream:**\n- having a samoyed\n- seeing the northern lights\n"
  },
  {
    "path": "Step 2: Know your team & initiatives/personal-intro-template.md",
    "content": "# _Name_\n\n<img src=\"https://octodex.github.com/images/motherhubbertocat.png\" width=\"200\"/>\n\n**Conference bio:**\n\n**What I work on at _COMPANY_:**\n\n**Location:**\n\n**Countries lived:**\n\n**Human languages:**\n\n**Programming languages:**\n\n**Work I enjoy:**\n\nOptional:\n- **Family:**\n- **Biggest dream:**\n- **?**\n"
  },
  {
    "path": "Step 3: Define themes/README.md",
    "content": "# Step 3: [160 min] Define themes 🧞‍♀️\n\n## Outcomes\n\n- A common understanding/reminder of the company goals.\n- An understanding of the general activities that you should and should not be pursuing.\n- A common understanding of your team's purpose and values.\n- Alignment between current initiatives and themes.\n- A list of current initiatives that clearly identifies the themes that they accomplish.\n\n## Introduction\n\nDeveloper Relations teams generally have limited resources, be that time, money, people, or anything else. Therefore it makes sense to ensure that you spend your limited resources wisely. Having a good understanding of your company and your audience will help you maximize your impact and ensure that your efforts stay focused. In this section we will be examining your company's goals and how they align with your team. We will use this as a basis to understand the team's purpose and overall goals which will then allow you to align your initiatives.\n\nFirst let's dive into some background information on the DevRel funnel:\n\n```\n\"A handshake is worth more than a click\" - Tim Falls\n```\nThere are many reasons to engage in developer relations. Some of these are listed here:\n- build awareness\n- get usage\n- trust\n- credibility\n- nurture long-term relationships\n- explain complicated tech to people who know more than you\n- encourage peer support & recommendation\n- value customers even if the person's company cannot pay for your product right now\n\nThese reasons all align with some part of the DevRel funnel. This DevRel funnel is closely related to Dave McClure's AARRR metrics which has been extended by [Phil Leggetter](https://www.leggetter.co.uk/2016/02/03/defining-developer-relations.html) to work better for your purposes. [[1]](https://www.leggetter.co.uk/2016/02/03/defining-developer-relations.html) [[2]](https://hoopy.io/).\n\n```\n\\                /- Awareness (of the platform and what it does)\n \\              /- Acquisition (e.g. registration, sign-up, download, install)\n  \\            /- Activation  (e.g. first API call, active usage in app)\n   \\          /- Retention (e.g. active users after 30/60/90 days, use of new features)\n    \\        /- Revenue (e.g. users that pay to use the platform)\n     \\      /- Referral (rare but valuable -> community champions)\n      \\    /- Product (involvement in building and getting feedback on product)\n```\n\nNote that at each stage of the funnel some drop off occurs. People that are in the late stages of the funnel are generally heavily invested. Those are the people that you can bug more with questions and who will likely want to give you feedback on your product.\n\nTo help with the understanding of where typical initiatives fall Phil provides a handy disambiguation:\n\n|  | Awareness  | Acquisition | Activation | Retention | Revenue | Referral | Product |\n|-|-|-|-|-|-|-|-|\n| Docs & Reference Guides / How tos | | x | x | | | | x |  \n| Library development | | | x | | | | x |  \n| Quick start apps | | | x | | | | x |  \n| Blog posts, Tutorials, Hacks | x | x | x | x | | | |  \n| Webinars | x | x | x | x | | | |  \n| Event/Meetup Sponsorship | x | x | | | | | |  \n| Talks, Meetups, Conferences | x | x | | | | | |  \n| Support, Zendesk, StackOverflow, Forums| | | x | x | | | x |  \n| Pre-sales technical discussion| | x | x | | | | | |\n| Alpha/Beta Programs | | | | x | | | | x |\n| Office Hours | | | x | x | | | | |\n| Capture developer feedback | | | | x | | | | x |\n| Help company recruitment | x | | | | | | | |\n\nOutreach activities like blogging, conference and meet-up talks, as well as hosting meet-ups and peer commentary can cause developers to become aware of your product. **Awareness** can be broad or deep, depending on, for example, what type of blog posts are written, what you do when you attend conferences, and what kind of talks you give at meet-ups.\n\n**Acquisition** comes from activities like blogging, personal interaction, or meetups. It is important to meet developers where they are. On top of that, marketing should never be obnoxious to developers. When talking about the competition, it is best to stay graceful. If the competition is the better choice for your user, tell them that. Misleading developers causes more harm in the long run to your numbers and your reputation.\n\nFrom acquisition, the next step is **activation**. This can be helped with documentation, quick-start apps, great SDKs and good support. The focus here should be to make developers successful. If the drop off between acquisition and activation can be measured and seems too high, this can be an indicator of problems in the onboarding user experience. Cristiano Betta has produced many resources that are helpful in evaluating and improving your product's developer experience [[3]](https://www.youtube.com/watch?v=G6QsYtjVJbY).\n\nOnce your developers are on your platform and have made their first API calls, you want to make sure they stay for a while. **Retention** can be achieved by providing a community around the products and, of course, great documentation. Keeping track of users' activities can indicate user experience issues, documentation issues, or community issues.\n\nIdeally DevRel's should not be measured on making money but rather focus on bringing developers through the door. Your goal should not be to sell but to help and lead. Aggressive selling may cause damage to your and your company's reputation. However, depending on where you work, **revenue** may be something you are measured on and you may be expected to demonstrate a Return on Investment (ROI). In this case it is important that you strive for an agreement about the impact you can achieve.\n\nOne of the last stages in the funnel is the **referral** stage. This is where you want to ensure that staying in your community is worthwhile for users. Champion programs are more and more popular in the DevRel community. The [DevRel Award-winning](https://devrel.net/dev-rel/devrel-awards-2018) Joe Nash talks about [how to build scalable champion programs](https://www.youtube.com/watch?v=udghlNP13is) [[4]](https://www.youtube.com/watch?v=udghlNP13is).\n\nThe last stage is **product**, where developers contribute back to your product development. In this stage there is general quite a bit of personal interaction and community work. Acknowledging people for their contributions can go a long way.\n\nIf you locate any significant drop offs, these are areas that you can work on improving. Note that some drop off is normal and you should not expect every user to advance through to the referral or product stages.\n\nTo conclude this section, let us look at the 4 general overarching themes that team's tend to go for. Here are a few examples of people that do well in those curated by hoopy [[2]](https://hoopy.io/) :\n\n| Theme | Company |\n|-|-|\n| Awareness | Glitch | Virtually ubiquitous |\n| Engagement | Outsystems | Community members|  \n| Conversion | redislabs | |\n| Perception Change | Microsoft | They showed the world their new face, instead of just proclaiming it. The devs are now in charge! See: visual studio code being on all platforms etc. |\n\nAll of these campaigns are examples of very well done DevRel work. They are also examples of very focused work towards a goal. No company does the best at everything or even aims to do that.\n\n## Preparation\n\n- [ ] Decide where the created resources should live (GitHub/Google Drive/...) and ensure this is accessible to the team.\n- [ ] Find your company goals and ensure you are familiar with it. You may want to print a few copies so that your team can work with them without their laptops.\n- [ ] Prepare a presentation of the DevRel funnel (or print out the above section for your team).\n\n## Tasks\n\n### 1. Company goals? [30 min]\n\nLook at your company goals for the year (if applicable). This will give you a better idea of where you are headed overall and how your team fits into the broader landscape. It may come in handy to jot down a summary of the company's goals.\n\n### 2. Where in this funnel should our team be? [20 min]\n\nHere the organization overview chart from [Step 2](../Step\\ 2:\\ Know\\ your\\ team\\ \\&\\ initiatives) will come in handy. You should not focus on the entire funnel. If you have many teams that are in this space, ensure that any overlap makes sense. This may be different for the different products. It may stretch over multiple parts of the funnel.\n\nBonus: If you have metrics for different parts of the funnel, this will help you figure out where your focus should be. Look for obvious drop offs that you could address.\n\n### 3. Articulate concrete themes [25 min]\n\nWhich part of the funnel will you work on for which product? Will you be increasing awareness for your product? Should you be working on increasing retention? Themes that work for one company will not work for other companies so make sure to base your choices on your situation. Do not choose more than 2 overall themes to avoid stretching yourselves too thin.\n\n### 4. Articulate mission statement [25 min]\n\n\"What developer relations should mean to a company really depends on what the company's goals are.\" - Phil Leggeter [1]\n\nWhat is our DevRel mission statement?\n\n### 5. Alignment [30 min]\n\nGo through the list of initiatives and discuss whether or not the initiative fits with your mission and your themes for the year. Add the theme and how the initiative aligns to it to the document.\n\nIf an initiative does not have owners assigned to it or has other missing parts, this is a good time to fill in the gaps.\n\nYou may find that this process shrinks your list of current initiatives which will make you more focused. For these _dormant initiatives_, keep the documentation around but mark it clearly as dormant. Make sure to note down any actions that need to be taken to leave the initiative in a good dormant place (e.g. informing stakeholders).\n\n### 6. Prioritization [30 min]\n\nToo much on your plate? Decide how to priotitize with the [Allthethings Prioritization Matrix](https://www.atlassian.com/team-playbook/plays/prioritization-matrix).\n\n## Notes\n- Working through these exercises beforehand will help you in the actual planning meeting. Ensure, however, that you let the team take the lead as they may have other ideas.\n\n## Resources\n\n[1] [Phil Leggeter](https://www.leggetter.co.uk) on [the AAARRRP funnel](https://www.leggetter.co.uk/2016/02/03/defining-developer-relations.html).\n\n[2] The content of this section is based on a training by [hoopy](https://hoopy.io/).\n\n[3] [Cristiano Betta](https://betta.io/talks/) has multiple very good talks on [Deadly Sins in Developer Onboarding](https://www.youtube.com/watch?v=G6QsYtjVJbY) and [Live API teardowns](https://betta.io/blog/2018/03/22/devrelcon-london-2017-a-live-api-teardown/) which are incredibly valuable in teaching you how to approach developer experience.\n\n[4] [Joe Nash](https://twitter.com/jna_sh) speaks about [_scaling external advocacy without losing your soul_](https://www.youtube.com/watch?v=udghlNP13is).\n"
  },
  {
    "path": "Step 4: Define event strategy/README.md",
    "content": "# Step 4: [70 min] Define event strategy 💃\n\n## Outcomes\n\n- A strategy for events that gives criteria to decide which events to attend/sponsor.\n\n## Introduction\n\nWhat sets events apart? What are the best ways to engage with events? To know what sort of events to target it is useful to look at metrics around the AAARRRP funnel (if available). If the metrics indicate a significant drop off then these are the areas you will want to focus on.\n\nWithin the AAARRRP funnel events can generally cover awareness, retention, and product. They do not and should not be used to target revenue increases. People tend to dislike being sold to at events, especially when they are not the primary decision makers.\n\nAwareness, especially for bigger companies generally comes in the form of direct marketing efforts and recruiting efforts. Note that recurring exposure increases the likelihood that people will assign more trust to a product. [[2]](https://en.wikipedia.org/wiki/Effective_frequency)  \n\nIf your objective is retention, then giving back to the community and remaining relevant will be important to you. This can be achieved through different ends:\n- contributing to open source and going to events to show off your involvement\n- building an ecosystem around your products\n- building a community around your products or becoming part of a community\n\nIf you are in the events space to obtain feedback then you will be able to obtain first hand feature requests and hear about problems. There's a human aspect when you're at events which means that you will likely hear different views (rather than just the loud people you see online).\n\n## Preparation\n\n- [ ] Decide where the created resources should live (GitHub/Google Drive/...) and ensure this is accessible to the team.\n\n## Tasks\n\n### 1. Which events should we be going to? [30 min]\n\nLooking at the segmentation analysis you completed in step 1 will give you the first hint at what type of events you should be attending.\n\nEvents are set apart by the following factors\n  - **Event Impact** - will this event influence our metrics? How many people can we send? How many people can we reach?\n  - **Attendee Potential** - what's the target audience out of the entire population of attendees?\n  - **Attendee Experience** - How experienced are the attendees?\n  - **Attendee Access** - How much access do you have to attendees?\n\nChoose a few events that you have gone to or are going to go to and check how these align with the above factors. For each event decide whether you should or shouldn't attend based on the above factors.\n\n| Factor | Event 1 | Event 2 | Event 3 | Event 4 | ... |\n|-|-|-|-|-|-|\n| Event Impact | | | | | |\n| Attendee Potential | | | | | |\n| Attendee Experience | | | | | |\n| Attendee Access | | | | | |\n| Should you attend? | | | | | | |\n\nTo help you, see below for a summary of the features of different tech events.\n\n- **Meetups**\n  - can be language/tech specific or random (e.g. HackerNews)\n  - free/cheap for attendees\n  - outside work hours\n  - organised by volunteers\n  - highly technical\n  - non-commercial\n  - attended by any sort of dev\n    - Things to look out for for inclusive meetups:\n      - pick events that do not offer the usual pizza and beer\n      - pick events that enforce a code of conduct\n      - pick events that have a diverse speaker lineup\n  - check meetup.com for inspiration on which events to attend\n  - before sponsoring a meetup, go as an attendee to check out the space\n- **Conferences**\n  - tech-focussed or ecosystem-focussed\n  - set apart by:\n    - \\# of days\n    - \\# of tracks\n    - expo floors\n    - organizers\n  - generally not free for attendees\n  - during work day or weekend\n  - often backed by a company\n  - technically diverse\n  - commercial\n  - larger\n  - attended by people with jobs\n- **Hackathons**\n  - many students\n    - check out [Major League Hacking](http://mlh.io)\n  - either company or community/volunteer organized\n  - often free to attend for attendees\n  - often during the weekend\n  - technically diverse\n  - non-commercial\n  - medium/large events\n    - in Europe student hackathons tend to be much smaller/more intimate than in the US\n- **Startup Events**\n  - Office Hours\n  - Pitch competitions\n    - companies can pitch tools\n  - fundraising\n  - expo floors\n  - free to attend for attendees\n  - during work days/weekend\n  - organized by incubators\n  - low on tech content\n  - often attached to events or accelerators\n  - attended by businesses and investors\n\n### 2. Events & your team [20 min]\nOut of the above you should have gained an idea for what type of events you should/shouldn't attend in general. In this exercise we will determine how cost and your team factor into which events you should/shouldn't attend.\n\nLet's look at the costs of attending a local 100 person conference and the cost of attending a remote conference:\n\n| | Local 100 person conference | Remote conference |\n|-|-|-|\n| Sponsorship Package | $1000 | $5000 |\n| Branding | $200 | $800 |\n| Swag | $600 | $2000 |\n| Human Hours | $1000 | $2500 |\n| Travel & Accommodation | $500 | $2000 |\n| Price per person | $28/person | $24/person |\n\nIf you are on a tight budget keep this cost difference in mind when making decisions. Note that this does not factor in the opportunity cost of you attending a conference vs doing something else useful.\n\nAside from potential resource constraints, your team will also influence which type of events you should choose. This includes the tech-specificity, locations, cultures, and languages your team covers.\n\n**Tech-specificity** means that generally your team members will have certain languages/frameworks that they are more familiar with and for which it will make more sense to attend events. Note that your team members need not be talking about your products exclusively. If they attend a Python conference and they speak about something that is not related to your company, them wearing your company swag already lets you benefit.\n\n**Location** is another obvious one. The opportunity cost of having a team member travel far for a conference is relatively high. If you have a small team you will likely want to choose mostly local events.\n\nLess obvious factors include languages and cultures. A **language** or a culture barrier can make it a lot harder for your team to be effective at events. Giving talks in English at a conference where the main language is not English will make the talk less accessible, for example.\n\nA **cultural barrier** can be as simple as not knowing how to work with the crowds while giving a talk or what swag to give out or how to interact with locals. The same jokes you make in front of a crowd in the US will not work in the UK and vice versa. Again this can make attending events less effective (even if you do research in advance).\n\nOverall, when your team members travel, they will generally be at a visitor disadvantage because they are not local. This is also referred to as backpack evangelism. If you travel around a lot you are likely not really effectively engaging with any community. It can be more beneficial to embed with local communities or with communities where you will spend significant time. Think about focus vs spread.\n\nFor this exercise, list out constraints that affect which events you can and should cover.\n\n### 3. Generalizing your event strategy [30 min]\n\nThe three main factors that determine your event strategy are event factors, people factors, and segmentation.\n\nFor the first part of this exercise:\n1. Choose 2 previous events and add 3 random other ones (e.g. Droidcon London, Pennapps, and the WaffleJS meetup in SF).\n2. Evaluate events for team factors and dev segmentation.\n3. Note what would have to change for them to become relevant.\n\nNote that event selection is a continuous process. Once you have done the above for a few events you can work out a short event selection guide. Document this guide so that current and new team can refer to it when unsure about whether or not to go to or sponsor an event.\n\nKeeping track of decisions on events (and the reasons for these decisions) can help you save time in future. If you decide against a number of events based on a missing support for that language, for example, you will have a list of opportunities in case you ever choose to do more with that language.\n\nOn top of that you should make sure to measure the quality of events you attend to be able to base future decisions on it. The quality of events can be measured quantitatively and qualitatively. Booth traffic and especially the engagement to crowd ratio and changes within that ratio for similar events will be useful as quantitative measures. Tracking for sign ups/ site visits can also give you insights. Getting the infrastructure to cross-reference event attendees with the further stages in the AAARRRP funnel can be difficult but if this is possible it can give you valuable insights (e.g. tracking changes in signups, change drivers, changes in target audience signups).\n\nNote that business cards collected / emails collected are generally vanity metrics. On top of that you should track whether the organization of the event was good, how much visibility your brand had, whether you got what you paid for in the sponsorship package etc.\n\n## Notes\n\n### A bit more about metrics\n\nThe best metrics should be valuable to the bits of the AAARRRP funnel you care about. They should be quantifiable, comparative, and divided into leading and lagging metrics. If you can manage to influence conversion rates and show your influence then you really know that your efforts are working.\n\n### Unsure what to attend?\nCheck out:\n- Eventbrite\n- Meetup.com\n- Social media\n- scrape other companies attendance off Twitter...\n\nCall For Papers (CFP) tips & tricks\n- look at [https://tinyletter.com/techspeak](https://tinyletter.com/techspeak)\n- papercall.io (standardized CFPs)\n- submit often, early, and multiple times (with different topics)\n- expect failure\n- if you go maximize exposure by also sponsoring\n\nEnsuring event success:\n- be visible\n- be proactive (set ooo emails)\n- optimize (add multiple events or organize mini events around it)\n- follow up with external people you meet\n- follow up internally by showing off event info\n\n### Diversity at events\n\nIt is _important_ that events you host, attend, sponsor, and speak at are diverse. The reasons for this span obvious moral reasons but also the fact that you do not want to be associated with events that spark outrage like [this one](https://www.nbcnews.com/tech/tech-news/flagship-tech-conference-ces-faces-backlash-all-male-keynote-speaker-n827191) or [this one](https://twitter.com/allmalepanels/status/966399599320551424).\n\nIf you notice that an event you're associated with has diversity issues you can work with the organizers to remedy the issue _if and only if this you notice early enough_. Once the line up has been announced, it is generally too late to change. Generally potential diversity-increasing speakers will not like to be asked to speak as an alibi-speaker. In this case withdrawing attendance/sponsorship or, if it's your event, canceling the event is the only right choice.\n\nA good way of ensuring you will not run into diversity issues by being associated with the wrong events is making sure that the organizing team of an event you get involved with is itself diverse. In addition you may of course ask the team about how they plan to ensure a diverse event. You will want to make sure that the organizing team advertises CFPs in diverse groups, offers mentorship, has a code of conduct etc.\n\n## Resources\n\n[1] Much of this is based on [hoopy's training](http://hoopy.io).\n\n[2] [Wikipedia on Effective Frequency](https://en.wikipedia.org/wiki/Effective_frequency)\n"
  },
  {
    "path": "Step 5: Set SMART goals/README.md",
    "content": "# Step 5: [15 min * number of initiatives] Set SMART goals 🏃‍♀️\n\n## Outcomes\n\n- Concrete goals for each initiative that will be carried forward.\n\n## Introduction\n\nA strategy is a framework for understanding what the right thing to do is and for roughly knowing how to achieve goals. In Step 1 & 2, we established the current situation and in step 3, we had a look at the company goals and set the destination for the coming months. Step 4 had us set out a strategy for events. The next step is to set specific goals which is what we will do for each initiative in this step. Let us look at SMART goals and vanity metrics before we dive in.\n\nSMART goals are a commonly used tool to plan and achieve goals [[1]](ttps://www.mindtools.com/pages/article/smart-goals.htm). SMART goals are defined to be: **S**pecific, **M**easurable, **A**chievable, **R**elevant, and **T**imely.\n\nWARNING: The caveat to setting SMART goals is being aware of vanity metrics. These can be collected but they should _not_ form the basis of your strategy. Examples of this can be measuring sign ups or measuring visitors on your website. If your team is measured on sign ups this may lead to the team accidentally focusing on activities that will make users sign up (maybe for some bonus) without noticing that they then never actually use the account. The metrics will look great but if your underlying goal is to increase usage then focusing on more long-term metrics like retention of users over time will give a more realistic impression of whether your efforts are working.\n\nSimilarly measuring teams on events attended or conference talks delivered may only yield vanity metrics and accidentally encourage the wrong things. Instead you should try to ensure you are attending the right events and that conference talks are well suited to your audiences so that engagement is high.\n\nAll the metrics mentioned above are still worth tracking (and I am sure they look wonderful on a dashboard). The thing to keep in mind is that these _vanity_ metrics should not be used to evaluate the team or your efforts. The metrics that you should be more concerned with are the ones that measure impact (not effort/achievements). Similarly, you will want to encourage quality over quantity.\n\nMeasuring the effort to impact ratio can be very useful when possible.\n\n## Preparation\n\n- [ ] Decide where the created resources should live (GitHub/Google Drive/...) and ensure this is accessible to the team.\n- [ ] Prepare a presentation of SMART goals (or print out the above section for your team).\n\n## Tasks\n\n### 1. Examine each initiative and assign SMART goals [15 min * number of initiatives]\n\nAs a team go through each initiative one by one and decide what SMART goals you intend to focus on. Ensure the document is complete. For inactive initiatives, ensure that the initiative is left in an ok-state. Ensure stakeholders are informed of the projects status.\n\n### 2. Conclusion\nThis is the last step in the in-person training. Summarize learnings and set a time to follow up on action items.\n\n## Notes\n\n- During the conclusion or after the training, collect feedback. This will help you make changes for next year. If you are willing to share this feedback, please [reach out to me](https://naomi.codes/).\n- You can choose to set SMART goals after the planning event. Thus initiative owners can think about them in more detail. You should however aim to inform the team of these goals/discuss them with the team.\n\n## Additional resources\n\n[1] [Smart Goals](https://www.mindtools.com/pages/article/smart-goals.htm)\n"
  },
  {
    "path": "Step 6: Documentation/README.md",
    "content": "# Step 6: [120 min] Documentation\n\n## Outcomes\n\n- An organized set of resources that will allow all stakeholders to understand what it is you are doing, why you are doing it, and how success will be measured.\n\n## Introduction\n\nThis is the final step which can be completed by the planning leader after the training. The completed documentation will be invaluable to keeping you goal-oriented and it will give you a baseline to compare your progress to after and during the next quarter(s).\n\nIt's incredibly important that it is completed as the documentation will serve as a clear reference point to the team and all involved stakeholders. This resource should be as accessible as possible to everyone in the organization.\n\n## Preparation\n- [ ] Decide where the instruction manuals should live (GitHub/Google Drive/...) and ensure this is accessible to the team.\n\n## Tasks\n\n### 1. Documentation [120 min]\n\nThe task is to pull all documentation created into an overall strategy document/folder. You can do this alone or as a team.\n\nIf you want to create one overall document you can find a template in [outline-template.md](outline-template.md).\n\n## Notes\n\n- As you work through all the created materials from the sessions, make sure to follow up on loose ends and assign action items. \n"
  },
  {
    "path": "Step 6: Documentation/outline-template.md",
    "content": "# Developer Relations Strategy\n\n## Who we are\n\n### Personal Intros\n_List each person's personal intro. Optionally include everyone's user manuals (- these can also live elsewhere however)._\n\n### Our place in the organization\n_Include the mindmap you created in step 1._\n\n## What we do\n\n### Mission Statement\n_Copy the mission statement into this document._\n\n### Themes for the coming year\n_Include information about your themes for the coming year. Include information about where you see yourself in the funnel._\n\n### Initiatives\n_Copy each initiative overview into this section._\n\n### Event Strategy [optional]\n_Outline which events you are attending and why. Include important decision criteria for sponsoring/attending events._\n\n### Initiative Goals\n_Copy shortened versions of the initiative overview into this section highlighting SMART goals and planned changes._\n\n### Metrics\n_Show how metrics have changed or list which metrics you will try to collect. Include the definition of vanity metrics and ensure readers are aware of them._\n\n## Conclusion\n_A short summary of what you hope to achieve in the coming year._\n\n## Appendix\n\n### Our History\n_Include the history of your company's DevRel team._\n\n### Product Analysis\n_Include segmentation exercises for your products._\n"
  }
]