Successful DevRel No Matter Your Org Chart  ## Metadata - Author: [[Dev Rel]] - Full Title: Successful DevRel No Matter Your Org Chart - Category: #articles - Document Note: --- tags: [#developer_relations, #career_growth, #open_source, #community_management, #metrics, #sales, #marketing, #developer_experience] Author: Barrett Sonntag Source: [YouTube - Developer Relations Talk](https://www.youtube.com/watch?v=Rd-_Au7igJ8) Reference: [Time Stamps and Summary] date created: 2024-11-14 --- # Title: Successful DevRel No Matter Your Org Chart ## Table of Contents: - [📝 Summary](#-summary) - [📖 Main Content](#-main-content) - [🗒️ Notes](#️-notes) - [📖 References](#-references) - [🗣️ Paraphrase](#-paraphrase) - [📰 Newsletter](#-newsletter) - [✅ Action Items](#-action-items) - [🧪 Hypotheses](#-hypotheses) - [📊 Methodology](#-methodology) - [❓ Questions](#-questions) - [🔮 Future Research](#-future-research) - [💡 Implications](#-implications) - [🧠 Learning Styles Assessment](#-learning-styles-assessment) - [📊 Accessibility Assessment](#-accessibility-assessment) - [🌍 DEIB Assessment](#-deib-assessment) - [✅ Logical Validity](#-logical-validity) - [🔍 DARVO Analysis Prompt](#-darvo-analysis-prompt) - [🔍 SEO Evaluation](#-seo-evaluation) - [🎯 Conclusion](#-conclusion) ## 📝 Summary: Barrett Sonntag's talk explores strategies for navigating the varied organizational landscapes of Developer Relations (DevRel). Success hinges on adaptability, aligning DevRel goals with overarching business objectives, and fostering impactful community engagement. The session offers a roadmap for DevRel professionals to measure their impact, work cross-functionally, and thrive amidst organizational change. ## 📖 Main Content: ### 🗒️ Notes #### [00:03](https://www.youtube.com/watch?v=Rd-_Au7igJ8&t=3) **Adapting to Organizational Structures** - DevRel functions differently across marketing, product, and open source contexts. - Misalignment with leadership's understanding of DevRel can risk its positioning as a cost center. #### [02:05](https://www.youtube.com/watch?v=Rd-_Au7igJ8&t=125) **Pragmatism and Business Acumen** - Demonstrate technical capabilities and pragmatism to establish credibility with leadership. - Avoid rigidly defining DevRel roles; flexibility in addressing organizational problems enhances trust. #### [06:01](https://www.youtube.com/watch?v=Rd-_Au7igJ8&t=361) **Enhancing Developer Experience** - Aim to reduce "time-to-hello-world" to improve onboarding. - Facilitate "time-to-delight" metrics to ensure developers derive satisfaction early in their journey. - Focus on affordable engagement strategies like hackathons or showcasing customer feedback. #### [08:01](https://www.youtube.com/watch?v=Rd-_Au7igJ8&t=481) **Managing Community and Marketing** - Define clear community metrics (e.g., user retention, time-to-first-API-call). - Guide issue discussions and backlogs in GitHub to foster productive community contributions. #### [11:48](https://www.youtube.com/watch?v=Rd-_Au7igJ8&t=708) **Aligning Marketing with Community Engagement** - Collaborate with sales to focus on customer advocacy and case studies. - Generate community-driven content to amplify user success stories. #### [13:45](https://www.youtube.com/watch?v=Rd-_Au7igJ8&t=825) **Revenue and Partnership Alignment** - Build healthy ecosystems that align customer and partner goals to ensure mutual benefits. - Avoid pitfalls of misalignment as seen in historic Facebook-Zynga conflicts. #### [17:43](https://www.youtube.com/watch?v=Rd-_Au7igJ8&t=1063) **Open Source Contributions** - Develop pipelines from open source communities for recruiting skilled developers. - Proactively maintain open-source projects with onboarding paths for contributors. #### [19:27](https://www.youtube.com/watch?v=Rd-_Au7igJ8&t=1167) **Adapting to Change** - Embrace flexibility in organizational KPIs and assess your alignment with shifting company goals. - Evaluate company maturity and developer community needs before transitioning roles. #### [22:50](https://www.youtube.com/watch?v=Rd-_Au7igJ8&t=1370) **Understanding Developer Incentives** - Clarify how developers benefit financially from your platform and resolve potential conflicts. - Identify and amplify successful customers to model effective use of your product. #### [24:37](https://www.youtube.com/watch?v=Rd-_Au7igJ8&t=1477) **Balancing Job Transitions** - Allocate time for job-seeking while remaining engaged in your current role. - Regularly reconnect with users to stay grounded and motivated. #### [28:16](https://www.youtube.com/watch?v=Rd-_Au7igJ8&t=1696) **Supporting Sales Without Losing Focus** - Use developer empathy to design assets that align technical details with sales needs. - Build reference architectures and scalable solutions for demo purposes. #### [30:20](https://www.youtube.com/watch?v=Rd-_Au7igJ8&t=1820) **Community-Centric Open Source** - Emphasize bottom-up strategies in open source contexts to support community adoption. - Adapt content to prioritize user-generated contributions and advocacy. #### [34:16](https://www.youtube.com/watch?v=Rd-_Au7igJ8&t=2056) **Product User Happiness** - Increase customer retention by focusing on user satisfaction and integrating community feedback. - Overcome attribution challenges for non-revenue APIs by linking ecosystem health with broader business goals. ### References: - [YouTube - Developer Relations Talk](https://www.youtube.com/watch?v=Rd-_Au7igJ8) - Hosted by Merlin on insights into Developer Relations. ## 🗣️ Paraphrase: 1. *Original*: "If leadership doesn’t understand what you do, they may see you as a cost center." - *Paraphrase*: Leadership misalignment can cause DevRel to be viewed as a non-essential expense. 2. *Original*: "Reorganizations happen, and your career at a company is just one chapter." - *Paraphrase*: Organizational changes are inevitable; view each role as part of your career growth. ## 📰 Newsletter: **Navigating the Many Faces of DevRel** Developer Relations thrives on adaptability and measurable success. Whether integrated with marketing, engineering, or open-source teams, DevRel professionals must align their efforts with business KPIs to showcase impact. Insights from Barrett Sonntag's session reveal practical strategies for balancing community engagement, leadership expectations, and organizational change. [Watch the full talk](https://www.youtube.com/watch?v=Rd-_Au7igJ8). ## ✅ Action Items: 1. Assess DevRel KPIs for alignment with business priorities. 2. Strengthen open-source contributor onboarding processes. 3. Develop customer success content highlighting high-quality product use. 4. Foster collaboration between DevRel, marketing, and sales teams. 5. Advocate for transparent metrics to demonstrate DevRel's tangible value. ## 🎯 Conclusion: Barrett Sonntag's insights illuminate the challenges and opportunities of Developer Relations across organizational contexts. His practical advice helps DevRel professionals navigate shifting structures, align with business goals, and maintain ethical, impactful practices. Short Summary for [Successful DevRel no matter your org chart](https://www.youtube.com/watch?v=Rd-_Au7igJ8) by [Merlin](https://merlin.foyer.work/) Strategies for Successful Developer Relations Across Different Organizational Structures and Understanding Your Value. [00:03](https://www.youtube.com/watch?v=Rd-_Au7igJ8&t=3) Success in Developer Relations requires adapting to different organizational structures. [02:05](https://www.youtube.com/watch?v=Rd-_Au7igJ8&t=125) Focus on demonstrating pragmatism and business acumen in Developer Relations. [06:01](https://www.youtube.com/watch?v=Rd-_Au7igJ8&t=361) Enhancing Dev experience impacts retention and community engagement. [08:01](https://www.youtube.com/watch?v=Rd-_Au7igJ8&t=481) Managing developer community and marketing effectively requires clear KPIs and engagement strategies. [11:48](https://www.youtube.com/watch?v=Rd-_Au7igJ8&t=708) Enhance marketing efforts by improving community engagement and sales collaboration. [13:45](https://www.youtube.com/watch?v=Rd-_Au7igJ8&t=825) DevRel success hinges on aligning partner and customer incentives for revenue growth. [17:43](https://www.youtube.com/watch?v=Rd-_Au7igJ8&t=1063) Effective management of open source funding - Document Tags: [[devrel]] - Summary: DevRel finds itself in different departments from one company to the next. In this talk from DevRelCon New York 2024, Bear breaks down what it means to be in DevRel when your team sits in marketing, product, open source, or elsewhere. Bear covers the unique goals, metrics, and challenges in each setup, along with practical advice on how to navigate each structure while staying true to your community. For DevRel pros thinking about career moves or just making sense of where they fit, this talk brings a clear look at what it takes to thrive across varied organizational setups. See the transcript and more at https://developerrelations.com - URL: https://www.youtube.com/watch?v=Rd-_Au7igJ8 so indeed I'm here to talk to you about how you can be successful everal no matter where in the organization you fall now I have 25 minutes to cover a lot of different organizational scenarios so I apologize in advance for the lack of possible Nuance in some of these uh but it's meant to be a conversation starter and to give you all a map of the ways that Deo operates in different businesses so that you can better assess how your own company might develop and if you're a job Seeker looking at places where you might want to work you can understand the kind of ways that will be measured the kind of goals that people will hold you accountable to and so on because devel is not singularly defined we we know this it's something that comes up develon over devalon and is a continuous conversation throughout the community and for most of us that's a good thing it means that you aren't put in a specific box and it means that you as a talented individual professional can flex and use and you have scope to change roles and uh do different aspects of the job in ways where you can contribute to the organization best but it can be harmful because if the people who you roll up to your your sea level your exec Suite you're bored don't quite understand what it is that you do or they have a mental model of what you're supposed to do that doesn't match what you do then you can be put in a risked position um and the funniest and uh oh part of this slide is if your boss thinks that you are lighting money on fire that's when things get really tricky is when not only are you this ill understood in this ill understood position you are also a cost center and so in times of stress particularly Financial stress on an organization that mismatch of understanding can get particularly bad and can constitute risk for you in your role so here's how you can think about ways to drisk yourself in this position um I've learned a lot along the way about what works and what doesn't as organizations change because I have been in pretty much every organization um at Pine Cone we are in marketing at slack I was in product at Twitter in sales inbd at Facebook and engineering and then at some startups that I both worked at and consulted for devl wasn't yet part of an organization because in a 15 person company you're not necessarily thinking about all that stuff yet so I have some tips about how you can think pragmatically about the value that you bring to an organization and also some ways that you can sus out whether an organization is right for you in the interview process everything I'm about to say is a variation on this theme you need to demonstrate that technically capable customer focused and above all pragmatic and we're going to talk a lot about unpacking what pragmatism means and looks like and how you balance business Acumen and pragmatism with the feeling of devil because we're all here to do right by developers we want to improve developer experience we want to serve communities that we're a part of and we want to build cool things together and sometimes that can feel at odds with business and sometimes it doesn't and so finding a way to make sure that everything sits right both with the business goals that you have because we all work for companies here and make it still feel like something that you are with your own value system excited to do every day that's that's the kicker um so top top priority is to make sure that leadership really trusts you in that business acument pragmatism so you want to avoid saying that something is not your job so for example if you're in a marketing org and you're struggling with top a funnel it's your problem even if you aren't sure about how exactly you're going to grow top of funnel and being a purist about what devell is or isn't supposed to do doesn't serve your credibility either internally or externally so before I get into this I also want to caveat that I am talking about how to navigate all this in a healthy organization if you are being asked to do something that you think is unethical like you're doing growth hacks to con your customers into giving you their credit card information earlier in the funnel or you're being asked to go on stage and tell lies or half truths about what is technically feasible or how your product works those are red flags you should get out it's not it's not a good thing but in a healthy and just evolving organization where organizations change these these rules can be can be helpful guidelines so I've just done a quick overview of the kpis that you're likely to be accountable to in different organizations the organizational risks that you are exposed to if you are not expressing pragmatism and the type of work that is likely to be seen as valuable so we'll talk about what pragmatism with soul looks like in each of these scenarios so you can think about how you're still delivering business value while also serving developers so in product and Engineering uh the work is often focused in product work and Engineering work you are contributing directly to developer experience implementation whether that's writing sdks or tooling that sits above the API layer you're writing documentation you're creating content content is a common across every place um in an organization that devel lives um and sometimes it also means you're doing support the kpis that I've found are pretty common across product and Engineering organizations are time to hello world so you want to be smoothing the onboarding for developers that they get to making their first API call faster um and I was talking to Jeremy me a bit about the idea of time to Joy or time to Delight I like that one too um so that's that's one where you'll often spend a lot of your time and retaining people through the funnel anything that you're doing on top of the API layer to make it a joyful experience is going to increase the likelihood that people stick with your product enough to get to whatever your definition of developer success is whether they've built an app that works whether it is something that is going into a Marketplace or is revenue generating the likelihood that they are going to not just try your product but go deeper and deeper in their integration is deeply affected by the kind of work that you do in product oriented de devil uh the other measure that might be important to you is NPS or csap because developers uh experience with your product also uh uh is something that you can directly impact with this Dev experience work NPS and Cat in turn really roll up to retention through the funnel if people like you it is about creating evangelists who will say yeah this is a great product to work with we like it and that can grow top of funnel but it is also about that retention piece pitfalls in the product and Engineering orgs include that you're not likely to have a ton of budget or expenditure for things like serving your developer Community with uh ad events or sending swag to people you have to be thoughtful about about you're doing all of that so ways that you can still Express this sort of product oriented pragmatism but still do the community nice gives are if you can't make an Roi equation work like you can't show that I sent somebody t-shirts and now we got 15 blog posts out of it and you're the product organization so you maybe don't care about that anyway uh you can keep your costs relatively low and then it just shows that you're still out there to try and figure out the ways that you can give your time you can give your attention to Developers and you can make that that feeling that of community uh feel good even if you're not spending a ton of cash uh a way that you can do that is by bringing your customers in to talk to your engineering team whether that's something like a spotlight on a customer uh inside the organization or having a hack day where engineers and product managers can observe people using the product that is incredibly valuable um and depending on your company's stance they might want to either expose the Engineers more to customers or they might see your role in Devil as being the buffer to protect the engineers time and focus so learn what the stance is and figure out how you can bring customers in in an authentic way the other the other thing you can do in this role too is some acting as an open source Shepherd a lot of people who are working on for example closed platforms but the sdks the sdks are open source on GitHub and there is some Community Management to do but the people working on them may never have worked on an open- source project and might not know what they need to do to manage a community on GitHub like how do you need to talk to people in issues how do you need to think about maintaining your backlog how do you involve the community and anything that you can add there is super helpful marketing a lot of us are in marketing or have transited through marketing um and this is really common especially at companies where the developer is the End customer which is not true for all of us some of us have worked at companies where there is an End customer that's not a developer but there is an API platform um or there is a an ecosystem play that is not directly about we sell to developers but when you're in a marketing organization you're going to be building content just like everywhere else there's some amount of events marketing community building and also support that is often part of your role and the kpis that are common that we see in a lot of deil orgs who are rolling up to marketing orgs are top of funnel growth uh marketing qualified leads or as mer coined the the term deil qualified leads um community contributed content uh as scaled evangelism so if you're thinking about growing your community what then are they doing to be Advocates like how many blog posts have they created how many times have they responded on G2 or anything else to to talk up your product um and also sales usage of the collateral that you have developed and I think that this is something that not enough people are measuring is not just did you publish a blog post and how many eyeballs did it get but have you created something for for customers who are a little bit further down the funnel then make a meaningful impact on on sales deals and can you track that Pitfall is in a marketing organization arguing that your Roi cannot be measured or tracked we have a lot of uh uh what's what's the word I'm looking for like bad feeling or worry about metrics in Devil and the thing is sure a lot of ways that we measure devil are proxies but that's kind of true in every organization there are very few ORS sales being maybe one of them where you have an exact through line between the thing that I did and revenue and that's okay you have to give your metric some amount of nuance you might change them quarter over quarter but to argue that oh it can't be measured at all is is a losing proposition so come to the table play ball have some measurement of what it is that you're doing and be ready to to Workshop that with people um the other thing that can be a major Pitfall is acting like you need to protect your community from your sales team and this is something that I see a lot where people are worried that oh if sales is going to take the list of people who came to my Meetup they're going to have a bad experience because they were just here to talk code with other developers and you know they're now they're going to be subject to sales Outreach if you talk to any salesperson who's worth their salt they will tell you that their job is to make customers successful with your product they're not there just purely to make money they care a lot about people's use cases about getting to know the customers deeply because that's the path to success so if you find that you don't trust your sales team look into why that is and see if you can find the ones who are well aligned to what it is that you're doing with community and who are looking to drive that customer value it's not impossible you should and you can you can find those those folks um another thing that's a pitfall is high spend on events and travel and expenditures that's when people start looking and say like hey your team spent $500,000 this quarter what's the uh what's the ROI on that and can you track it and if you're in Pitfall number one you say nope then then you're really in trouble um so how do you practice pragmatism on those business metrics while still staying connected first thing is to create a funnel that you're proud of if at any point you are worried that somebody who you've met at a Meetup is now going to get dropped into your marketing funnel or your sales funnel oh no and also if you're in marketing you have the power to change that so go through it and see if the materials that you're providing people are high quality things that you're proud to show people or that you maybe would have done one-on-one in a Meetup um and don't be afraid to to really try and inflect that that yourself another thing that can be easier for people to square is if you're not interested in building top a funnel for people who are maybe only passingly interested in your product team up with the sales team to think about expansion within accounts what can you create that is good material to help people who are already your customers who already care about your product do a really good job of Integrations with it that can feel much much better for folks who are who are struggling with the outbound feeling and um the other part is that EV as you build community there will be some expectation from your company that there is a get from the community are they producing content are they talking about your product are they um are they active online being Advocates and if you don't like nudging people to start creating that output it's helpful to clarify what it is that you expect the company to give them so that later when it comes time to say hey do you mind jumping in on this Twitter thread where someone's absolutely blasting us you won't mind because you know what you've given them in the past and you've know you know how you've helped them sales in BD there was a great talk just now by Jee from Roku that went into much more depth that I'm going to be able to do on this so I if you didn't catch it I suggest you go back and watch it because this is just very high level overview comparatively um the work when you're in deil within sales and BD which is different from sales engineering is about creating a healthy ecosystem often of Partners and creating sales collateral and Partnerships collateral like demos sometimes it's bridging product work like uh helping Partners try out new and uh and beta apis and uh it's as part and parcel of that it's a lot of supporting those Partners as they're getting started kpis that you're responsible for revenue and product adoption the whole thesis as you're creating a healthy ecosystem is that there is a broader Market that you can address or more people who will be made aware of your product and start using it because you've created that ecosystem so you'll probably be on the hook for seeing adoptions adoption numbers increase or any amount of direct Revenue with that partner um you'll also probably be judged on the number and the quality of logos as you think about who is in your partnership organization and what you're communicating with the types of Partners the size of companies that you're working with and so on pitfalls in this are any lack of alignment between customer and partner incentives and needs and I think it's it's been long enough since this that I can talk about it without every be like oh um Facebook and Zinga friends until they weren't because it looked like there was a great partnership there about getting games to more people on Facebook and then zingo was like great this is an amazing channel for us we're going to blast lots and lots of notifications to people and eventually it led to Facebook shutting down all the apis that enabled you to hear about what your friends were doing on FarmVille so when you when you get that kind of misalignment between the partner incentives and your end customer incentives that can be a pitfall luckily more and more I think people are very attuned to that and so I haven't seen that happen quite as often um but picking your partners uh based on devx quality is something that can be very tempting as a technical professional because you're like oh this partner's Tech is really good it's a delight to work with I really like it I think our customers are going to like it I want to Champion this product and if you can't layer that with any sort of pragmatism about the size of the company what you think their effect is going to be on your total market and their likelihood to succeed in the long term that's when you start to lose some of your credibility being in part of a business development org so my recommendation here is to partner with somebody on your BD team to help with prospecting and really understand the the nuances of the market that they think about when they're doing their job when they're going outbound to Partners and layer in your technical uh understanding wherever you can there are two more less common organizations that I'm going to talk about quickly which is uh reporting directly to the CTO or in the C's office and open source program offices these are things that are relatively less common but in going in and out of popularity in Devil when you go direct to the CTO usually you're at a relatively smaller company and usually is because there is some acknowledgement that you have crosscutting priorities that are going to serve multiple organizations um the work is pretty similar to what you might do both in a product org and a marketing org you're writing content you're creating improvements to Dev experience uh you might be working on things like like API governance across products you're you're almost likely to be to be doing it all pitfalls is that this is likely to be a temporary situation um as your organization grows it may become untenable for you to sit within the office of the CTO and your CTO also has a boss in the form of the board and so you need to help equip your CTO with the measures and the arguments for why sitting in that office is the right place for you um so as you're doing that it's helpful to have a clearly defined and consistent North Star but also to have kpis that touch other pillars of product marketing um sales so that it makes sense why you're sitting all the way across them because you have this this overarching scope another another less common one but I have seen Devin before is part of the open source program office and this is more common in larger organizations that have a an established open source practice where maybe they are the primary maintainers or even the creators of a large open- source project um they might even be working on multiple and the work is managing contributions uh managing funds any sort of donations that you're giving out to people who are doing the work and maintaining it and of course building a relationship with with a community OS tend to be pretty volatile because as a company sees or doesn't see business value from an open source project they are sometimes likely to get cut you might imagine there aren't that many many companies that say I'm so glad that we open source this project because the community has taken it in exactly the direction that we hoped we don't need to make any engineering investment in this anymore it's it's all going perfectly so with that one of the ways that you can show pragmatic value is making sure that this open source Community is creating a recruiting pipeline for your company you need to find talented people who are highly invested in the tech that is foundational to what you're working on or else there's no reason you would have an open source program off devoted to it um and this can look like making sure that there's a really good onboarding ramp for open source contributors small tasks that they can wrap their heads around and that that sort of give them an onboarding into the community and thinking about that that road in and keeping tabs on maintainers and building those relationships so that they don't think of you as the uh the terrifying corporate Overlord that is really directing the the project maybe not directly interests of community but but that actively works with them so that was a a very quick overview of various places that you might land in Deo and you might be thinking about all of this and say like that's great that you've got these ideas about how to express pragmatism but it's not really operationalizable for me if that's a word because I'm an I'm an I I don't have the scope of influence so what am I supposed to do when I get reared and when I'm buffeted by all this change and I would say that number one if you want to stay at the company show that you are willing to flex show that you're willing to play ball and understand the the kpis and the goals of the new organization where where you're being put and be honest with yourself if it's a change that you can't stomach and that you you really don't want to be doing the work anymore because the work is going to change know that about yourself and think about how you're going to plan for your next thing which is what we're going to get into next how do you vet the company and understand whether you're in a healthy part of the organization as a job Seeker first off start with the research that you can do without actually having to talk to anybody at the company there are some things that just basic Googling will get you about things like the company's stage understanding whether they are a tiny startup with 15 people and you're not going to be ored at all versus if they're a super mature company like you're you're trying to get into Google devl are going to be very different naturally just the number of people working on it the likelihood that you're going to get reorg the likelihood that you're going to be specialized in any particular area all of that is super informative as you're thinking about what it's likely to look like on the inside the next thing to think about is the stage that the community is in what do people in the community need right now from the company and what do you think that the company might be expecting from its Community is it evangelism is it uh being early adopters that are going to battle test the product is it uh you can you can imagine what else people might be wanting from community at that point and have a hypothesis before you even go into the the interview inter process so you can you can examine it together with your interviewers the other thing to think about is the competitive pressure that's on the company right now are they a startup in a really crowded space are they a large company that's trying to Pivot or creating a new product line all of that is going to inform how much pressure you are going to be under and if this is I I wish I had a better term for it but what people float around is like wartime CEO and peacetime CEO understanding whether you're going to be in that kind of pressu rized environment is going to be really informative for how the organization is likely to view how how much you have to show a line for example to revenue so here are some questions to ask as an interviewee that I think will get you signal about where the company stands thing number one um what is your hiring plan for devil and who's done it in the past this is a big tell to understand one are they planning on hiring one devil person and they think that this massive scope that they've defined is really one person's job and one person that can carry it do they have something hypers specific for you has anyone done this job before have they been reared what was what was their experience like and in talking to a lot of companies in a Consulting capacity there are lots of smaller startups that as they are finding their footing hire and fire devel folks because they aren't really sure what they wanted and sometimes that process can be clarifying for them and sometimes it's also a red flag for you as a Deval professional so this is a really helpful question to ask first another good question to know is just what are your kpis today and that also helps you understand how mature they are in their metrics tracking do you even know are you able to attribute through line between something that you do uh written on their blog all the way to conversion because in early stage companies sometimes they don't have that instrumented end to end and that's something that they're working on so getting context about that is super helpful the next thing that I like to ask especially if the developer is not your end customer but somebody Who You're trying to attract to an API platform is how do developers make money and uh who is successful right now and it's helpful to think about uh the alignment of incentives and how developers make money how the company makes money where there is any sort of conflict if there is any and how you can support people in using your platform to good effect for their own business the last one which isn't kind of a similar vein is what customers can you hold up who are doing a really good job using your product and what would you want to have people model this is informative because it tells you what the company thinks is really high quality use of their of their product and it's likely what you are going to be called upon to push people toward doing it's also an interesting tell if they don't know either because they don't have the customers maybe they're looking for a product Market fit right now or because they are creating a product where they want to see how people innovate on top of it that is it's not bad it's not good it's just a different state of maturity and this is a useful way of finding out where in that funnel the company is so through all of this it's just helpful to remind yourself organiz reworks are going to happen and organizations are going to change no matter what you do but also you are going to change and what you do at a company is just one step in your overall career and so as we think about pragmatism and and think about like proving your value also take a deep breath because your time at a company is one chapter in your life life it's one chapter in your career and you can expect that the organization is going to change and when there is no longer a match it's okay to walk and when it's time to find something new hopefully you've got some ideas of the questions that you can ask to find your next happy spot so thank you let's talk about all of that as if we haven't the last three days already two days all right as always that was amazing Barett thank you so much if you have questions just raise your hand and I'll run over to you all right first question so you know when you're when you're ready to move on uh like I did this when I was at Microsoft and went to twio um you know you have to kind of like start poking before like you're not fired you're not let go you're you're still employed how do you navigate that uh and like you know I have my own experiences with that but I'm really curious what your kind of advice is for everyone do you mean the part where you're living a double life like I'm employed but yeah employed but absolutely looking for a job yeah yeah yeah yeah um I would say you you have to figure out time boxing when and where you want to be in job Seeker mode and when and where you want to be doing your best by the community and it's helpful to have periodic uh uh contact with people who will re-energize you about where you are today so keep keep a hand in talk to some of your customers and be like okay yeah this helps me keep my head in the game for while I'm still here um and that can be helpful while you're while you're trying to avoid getting too obviously bought out in a in a role that's all about being super bought in um that's the best advice that I have you're good good um what if you're in a position oh that was really good by the way that was like super insightful I just have to add that but um what if you're in a position where you kind of want to work across multiple departments like if you like the marketing thing and the Awareness stuff but you also want to impact like the open source product and things like that do you have any recommendations for that or even have it it really depends on company size and um what that determines how much you have to work within an existing or structure to get the scope that you want to have um even at mediumsized companies I've seen that people can carve out scope just by doing the thing especially if it's unowned you you kind of can demonstrate like all right I've just started contributing to how we should manage open source and therefore you you own deao and then you can own di like you can say like this is now officially mine and I've seen that work at companies that were in the thousands of people um I'm trying to trying to think if I've seen that work at much larger companies um for really big ones sometimes you do have to make a a larger case for why something should move into your organization and it involves like pitching Executives on on why something should happen um but if you have the scope to just start doing just start doing all right coming around if other people have questions just give me a hand raise I'll come over to you early so I I appreciate how you kind of broke down where deell can sit in the organization and that's kind of a perennial question I think it depends is a great answer um one thing that I didn't see on the slides I'm curious your thoughts on is rolling up to the CEO does it make sense when does it make sense good idea bad idea I I kind of think of it as the same same flavor as rolling up direct to the CTO it is a moment in time almost always um but it can be very beneficial I mean I would love to see an organization where there is a se- level developer experience role I think that's more likely to happen at companies where developers are the End customer um and I think it's probably likely to happen as part of a broader scope of ownership that might include some amount of coo type work or or Revenue uh Revenue ownership um but yeah I would say that most of what I said about rolling up to the CTO stands with the CEO other questions anybody in the back here oh yeah hi bear thanks for the talk super good my question yall yall hiring sadly no not right now okay thank you yeah right oh there we go uh great talk by the way um I'm kind of curious uh you know I mean there like a lot of developer companies you know also have like Enterprise top Downs tops down approaches so kind of curious to know how do you as a deil help sales teams without considering yourself to be too much of a sales engineer I mean it's not a bad thing but I and at a startup you wear multiple hats but yeah kind of curious to know how can a Deo help a sales organization as well yeah and and particularly when you're trying to sell to the Enterprise yeah yeah in adop down motion yeah I would say the number one thing you can do is talk to people who are inside these large organizations and avoid leaning on tired cliches about like oh they're all using Java and Pearl and they don't read anything or like they don't use any sort of modern tooling because that's by and large not true they do face different uh blockers to adoption of new tools but the more that you can understand and have real empathy for for those developers and see them as threedimensional people with with careers um you can be very helpful to the sales team in terms of the the assets you create and sometimes the depth of assets um in my experience and this may not be broadly true a lot of sales engineers and demo Engineers are under a lot of pressure to produce lots and lots of volume demos that are tailored to the customer to tell a story and so something like a bigger asset that might take 6 weeks or 2 months or even a full quarter to develop um I'm thinking something like at Pine Cone we built a reference architecture that shows you um it it's built on AWS and palumi and you can spin up a bunch of related microservices that you need for data ingestion into pine cone and it's it's a beast of a service it takes like 17 minutes to spin up it it uses like real AWS services and people use it would the sales engineers have had dedicated time and overhead to create something like that maybe maybe not and so those are those are ways that you can be assistive in thinking about what do you what do you have the brain space and the time to create because you don't have to be quite as reactive to the sales process oh yeah um I love the platter personaly and uh it was great to see the uh the special case of reporting into an open source program office because that's the one that I find is often missing from any of these conversations I work for a open source blockchain foundation and so we don't have like a revenue side of things really and a profit side of things really so it's very much bottomup driven from the community so I'm really sort of serving the community ultimately we want more people using our product um but I'm just wondering if you had any more thoughts on sort of strategies around that and sort of differences in that versus the sort of more traditional top- down corporate approach of devl yeah it it really depends on what your Rel a ship is with that open source Community like you said that um in order for people to use your product they need to be familiar with the open source Tech which is different from a company that is a sponsoring a a product because it is or sponsoring a a a program because it is part of their fundamental stack but isn't actually part of their API offering and so I know that it's it's passing the buck to say it depends but it it does depend on for example whether uh getting the community to grow is about product adoption and is ultim further down the line about revenue or whether it is about your talent pool and whether it's about um stability and maturity of the technologies that your company is using but I would actually love it if you have any insights to share with this audience because I have only brushed OS I have not actually worked within one still still working great work in progress uh I think we have time for one more question if anybody's got one scanning scanning in the back okay okay I'm coming last question of De got uh thank you I really loved uh are your your it depends answer was really like understand the context understand the incentives and the alignments uh for developer relations uh you don't have to give like specifics but what is the best aligned situation that you've seen and what is the worst aligned situation that you've seen for devell loaded uh chadam house rules right like we we cut off the recording right here um that's a great question so I mean the the Facebook Zing example again is old enough that it's non-controversial by now but that was that was a pretty spectacular misalignment of goals between um the the developer program and uh Partnerships I also worked at Twitter um I I would like to think that that we did a good job at lack of um of aligning the the kinds of goals that we were trying to serve but the thing that was always tricky for us was we knew from surveys that um use of the platform and use of apps inside the platform made people more likely to stick around like stat Sig they were happier with the product they were more likely to pay more for it they were more likely to expand um but the the net additional value of one more app that they were using versus like are they happy with just a web hook um that that through line of attribution was really difficult to establish and in a company that where the where the API product is not necessarily directly Revenue generating and you don't have that attribution you you do carry a good amount of risk and so being in the product org helped defay that a little bit because there was um this sense of ecosystem health and the um the ways that it was a product addition to have Integrations and I do think that it worked well for the time that I was there and we've got some folks who are still at slack in the room so thumbs up y'all feeling good yay Kurt's feeling good amazing well let help me give bear a huge round of applause as our final keynote Deo KH [Applause], Successful DevRel No Matter Your Org Chart, Dev Rel, 01jcndcbc9qk093mkppv6vwhnw.