Made by
Made by
Director of DevRel
Pincone
DevRelCon New York 2024
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.
Bear: Indeed, I’m here to talk to you about how you can be successful in DevRel no matter where in the organisation you fall. Now I have 25 minutes to cover a lot of different organisational scenarios, so I apologise in advance for the lack of possible nuance in some of these, but it’s meant to be a conversation starter and to give you all a map of the ways that DevRel 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 you will be measured, the kind of goals that people will hold you accountable to and so on. Because DevRel is not singularly defined. We know this. It’s something that comes up. DevRelCon over DevRelCon 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 you have scope to change roles and do different aspects of the job in ways where you can contribute to the organisation best, but it can be harmful because if the people who you roll up to your C level, your exec suite, your board 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. 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 centre.
And so in times of stress, particularly financial stress on an organisation, 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 de-risk yourself in this position. I’ve learned a lot along the way about what works and what doesn’t as organisations change because I have been in pretty much every organisation at Pine Cone. We are in marketing at Slack. I was in product at Twitter in sales and BD at Facebook and engineering and then at some startups that I both worked at and consulted for. DevRel wasn’t yet part of an organisation 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 organisation and also some ways that you can suss out whether an organisation 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 you’re 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 DevRel. 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 the kicker. So top priority is to make sure that leadership really trusts you and that business acumen, 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 of 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 DevRel 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’m talking about how to navigate all of this in a healthy organisation. If you are being asked to do something that you think is unethical, like you’re doing growth hacks to 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 a good thing. But in a healthy and just evolving organisation where organisations change these rules 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 organisations. The are organisational 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 will 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, the work is often focused in product work and engineering work. You’re 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 in an organisation that DevRel lives and sometimes it also means you’re doing support.
The KPIs that I’ve found are pretty common across products and engineering organisations 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. And I was talking to Jeremy Meise a bit about the idea of time to joy or time to delight. I like that one too. So 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 DevRel.
The other measure that might be important to you is NPS or CSAT because developers experience with your product also is something that you can directly impact with this dev experience. Work NPS and CSAT 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 tonne of budget or expenditure for things like serving your developer community with at events or sending swag to people. You have to be thoughtful about how 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, 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 organisation so you maybe don’t care about that anyway, 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 feeling of community feel good even if you’re not spending a tonne of cash. 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 inside the organisation or having a hack day where engineers and product managers can observe people using the product. That is incredibly valuable. 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 DevRel as being the buffer to protect the engineer’s time and focus. So learn what the stance is and figure out how you can bring customers in an authentic way. 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.
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, 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 or there is an ecosystem play that is not directly about we sell to developers, but when you’re in a marketing organisation, 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 DevRel orgs who are rolling up to marketing orgs are top of funnel growth marketing qualified leads or as Mary T coined the term DevRel qualified leads community contributed content as scaled evangelism.
So if you’re thinking about growing your community, what then are they doing to be advocates? How many blog posts have they created? How many times have they responded on G two or anything else to talk up your product 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 customers who are a little bit further down the funnel than make a meaningful impact on sales deals? And can you track that pitfalls in a marketing organisation arguing that your ROI cannot be measured or tracked. We have a lot of, what’s the word I’m looking for, bad feeling or worry about metrics in DevRel. The thing is, sure, a lot of ways that we measure deral are proxies, but that’s kind of true in every organisation.
There are very few orgs, 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 metrics some amount of nuance. You might change them quarter over quarter, but to argue that I can’t be measured at all 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 workshop that with people. 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. They were just here to talk code with other developers and now they’re going to be subject to sales outreach.
If you talk to any sales person 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 and you can find those folks. 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 ROI on that?
And can you track it? And if you’re in pitfall number one, you say Nope, then you’re really in trouble.
So how do you practise 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, and don’t be afraid to really try and inflect that yourself. Another thing that can be easier for people to square is if you’re not interested in building top of 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 struggling with it, the outbound feeling. And the other part is that eventually 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 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 know how you’ve helped them. Sales and bd, there was a great talk just now by Gene from Roku that went into much more depth than I’m going to be able to do on this.
So if you didn’t catch it, I suggest you go back and watch it. This is just very high level overview comparatively the work when you’re in Devrel 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 helping partners try out new and beta APIs and 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 adoption numbers increase or any amount of direct revenue with that partner.
You’ll also probably be judged on the number and the quality of logos as you think about who is in your partnership organisation 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 been long enough since this that I can talk about it without everyone being like, whoa, Facebook and Zynga 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 Zinga 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 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, but picking your partners based on devex 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 longterm, 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 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 understanding wherever you can. There are two more less common organisations that I’m going to talk about quickly, which is reporting directly to the CTO or in the CTO’s office and open source programme offices. These are things that are relatively less common but going in and out of popularity in DevRel, when you go direct to the CTO, usually you’re at a relatively smaller company and usually it’s because there is some acknowledgement that you have cross-cutting priorities that are going to serve multiple organisations. The work is pretty similar to what you might do both in a product org and in a marketing org.
You’re writing content, you’re creating improvements to dev experience. You might be working on things like API governance across products. You’re almost likely to be doing it all. Pitfalls is that this is likely to be a temporary situation as your organisation 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. 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 sales so that it makes sense why you are sitting all the way across them because you have this overarching scope. Another less common one, but I have seen Deralin before as part of the open source programme office, and this is more common in larger organisations that have an established open source practise where maybe they are the primary maintainers or even the creators of a large open source project and they might even be working on multiple.
And the work is managing contributions, 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 the community. OPOs 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 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 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 programme office devoted to it. 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 sort of give them an onboarding into the community and thinking about that road in and keeping tabs on maintainers and building those relationships so that they don’t think of you as the terrifying corporate overlord that is really directing the project.
Maybe not directly interests of community, but one that actively works with them.
So that was a very quick overview of various places that you might land in DevRel and you might be thinking about all of this and say those 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 am an ic, I don’t have the scope of influence, so what am I supposed to do when I get reorged 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 KPIs and the goals of the new organisation where you’re being put and be honest with yourself if it’s a change that you can’t stomach and that 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 organisation 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’s 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 orged at all versus if they’re a super mature company like you’re trying to get into Google DevRel are going to be very different naturally just the number of people working on it, the likelihood that you’re going to get reorged, the likelihood that you’re going to be specialised 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 being early adopters that are going to battle test the product?
You can imagine what else people might be wanting from community at that point and have a hypothesis before you even go into the interview process so 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 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 pressurised environment is going to be really informative for how the organisation is likely to view how much you have to show a line, for example, to revenue.
So here’s some questions to ask as an interviewee that I think will get you signal about where the company stands. Thing number one, what is your hiring plan for DevRel and who’s done it in the past? This is a big tell to understand One, are they planning on hiring one DevRel 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 hyper-specific for you? Has anyone done this job before? Have they been reorged? What was their experience like? In talking to a lot of companies in a consulting capacity?
There are lots of smaller startups that as they’re finding their footing hire and fire DevRel 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 deferral 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 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 who is successful right now?
And it’s helpful to think about 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 is 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 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 stage 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 reorgs are going to happen and organisations 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 think about proving your value, also take a deep breath because your time at a company is one chapter in your life. It’s one chapter in your career and you can expect that the organisation 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.
MC: All right, as always, that was amazing Bear, thank you so much. Thank you. If you have questions, just raise your hand and I’ll run over to you.
All right. First question.
Audience member 1:
So when you’re ready to move on, I did this when I was at Microsoft and went to Twilio, you have to start poking before you’re not fired, you’re not let go, you’re still employed. How do you navigate that? And I have my own experiences with that, but I’m really curious what your kind advice is for everyone.
Bear: Do you mean the part where you’re living a double life like I’m employed, but
Audience member 1:
Sure, yeah, employed, but absolutely looking for a job. Yeah, yeah,
Bear: Yeah. I would say you have to figure out time boxing when and where you want to be in job seeker mode and and where you want to be doing your best by the community. And it’s helpful to have periodic contact with people who will reenergize you about where you are today. So 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. And that can be helpful while you’re trying to avoid getting too obviously bought out in a role that’s all about being super bought in. That’s the best advice that I have.
Audience member 2:
You’re good. Go ahead. What if you’re in a position? Oh, that was really good by the way. That was super insightful. I just have to add that. But what if you’re in a position where you kind of want to work across multiple departments, if you like the marketing thing and the awareness stuff, but you also want to impact the open source product and things like that. Do you have any recommendations for that or even have?
Bear: Yeah, it really depends on company size and that determines how much you have to work within in the existing org structure to get the scope that you want to have. Even medium-sized companies, I’ve seen that people can carve out scope just by doing the thing, especially if it’s unowned, you kind of can demonstrate like, alright, I’ve just started contributing to how we should manage open source and therefore you own defacto and then you can own … You can say this is now officially mine. And I’ve seen that work at companies that were in the thousands of people. I’m trying to think if I’ve seen that work at much larger companies for really big ones. Sometimes you do have to make a larger case for why something should move into your organisation and it involves pitching executives on why something should happen. But if you have the scope to just start doing, just start doing
MC: Alright, coming around. If other people have questions, just give me a hand raise. I’ll come over to you early. That’s fine.
Audience member 3:
So I appreciate how you kind of broke down where DevRel can sit in the organisation. That’s kind of a perennial question. I think it depends is a great answer. 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?
Bear: I kind of think of it as the same flavour as rolling up direct to the CTO. It is a moment in time almost always, but it can be very beneficial. I mean, I would love to see an organisation where there is a C-level developer experience role. I think that’s more likely to happen at companies where developers are the end customer 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 revenue revenue ownership. But yeah, I would say that most of what I said about rolling up to the CTO stands with the CEO.
MC: Other questions? Anybody in the back here? Oh yeah. Hi
Audience member 1:
There. Thanks for the talk. Super good. My question, y’all hiring?
Bear: Sadly? No, not right now.
Audience member 4:
Okay, thank you.
Bear: Yeah.
MC: Oh, there we go.
Audience member 5:
Great talk. By the way. I’m kind of curious. I mean a lot of developer companies also have enterprise tops down approaches. So kind of curious to know, how do you as a DevRel help sales teams without considering yourself to be too much of a sales engineer? I mean, it’s not a bad thing, but at a startup you wear multiple hats. But yeah, kind of curious to know how can a DevRel help a sales organisation as well,
Bear: And particularly when you’re trying to sell to the enterprise.
Audience member 5:
Yeah, yeah. In a tops down motion.
Bear: Yeah. I would say the number one thing you can do is talk to people who are inside these large organisations and avoid leaning on tired cliches about like, oh, they’re all using Java and Pearl and they don’t read anything or they don’t use any sort of modern tooling because that’s by and large, not true. They do face different blockers to adoption of new tools, but the more that you can understand and have real empathy for those developers and see them as three dimensional people with careers, you can be very helpful to the sales team in terms of the assets you create and sometimes the depth of assets. 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 six weeks or two months or even a full quarter to develop. I’m thinking something like at Pine Cone, we built a reference architecture that shows you it’s built on AWS and Lummi and you can spin up a bunch of related microservices that you need for data ingestion into Pine Cone and it’s a beast of a service. It takes 17 minutes to spin up. It uses 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 ways that you can be assistive in thinking about 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.
Audience member 4:
I love the platypus analogy and it was great to see the special case of reporting into an open source programme office. 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 a revenue side of things really, and a profit side of things really. So it’s very much bottom up driven from the community. So I’m really sort of serving the community. Ultimately we want more people using our product. 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 DevRel.
Bear: Yeah, it really depends on what your relationship is with that open source community. Like you said, that 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 sponsoring a product because sponsoring a programme because it is part of their fundamental stack but isn’t actually part of their API offering. And so I know that it’s passing the buck to say it depends, but it does depend on, for example, whether getting the community to grow is about product adoption and is ultimately further down the line about revenue or whether it is about your talent pool and whether it’s about 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 OSPOs. I have not actually worked within one. Still working, still working. Great
MC: Work in progress. I think we have time for one more question if anybody’s got one scanning. Scanning in the back. Okay. I’m coming. Last question of DevRelCon. Thank you.
Audience member 6:
Thank you. I really loved your, it depends, answer was really like understand the context, understand the incentives and the alignments for developer relations. You don’t have to give specifics, but what is the best aligned situation that you’ve seen and what is the worst aligned situation that you’ve seen for Devrel.
Bear: Chatham House rules? Right. We cut off the recording right here. That’s a great question. So I mean, the Facebook zing example again is old enough that it’s non-controversial by now, but that was a pretty spectacular misalignment of goals between the developer programme and partnerships. I also worked at Twitter. I would like to think that we did a good job at Slack of aligning 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 use of the platform and use of apps inside the platform made people more likely to stick around Stat sig.
They were happier with the product, they were more likely to pay more for it, they were more likely to expand, but the net additional value of one more app that they were using versus are they happy with just a web hook that through line of attribution was really difficult to establish. And in a company where the API product is not necessarily directly revenue generating and you don’t have that attribution, you do carry a good amount of risk. And so being in the product org helped defray that a little bit because there was this sense of ecosystem health and 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? Yeah. Kurt’s feeling good.
MC: Amazing. Well help me give Bear a huge round of applause as our final keynote of DevRelCon.
