Playing DevRel's Advocate  🔗 **Source:** [Playing DevRel's Advocate](https://share.snipd.com/episode/98608f7d-d766-4d4d-90ba-166811f856d3) ## Highlights - **DevRel Sees Problems First** - DevRel often spots problems early because the team lives in the community and sees product or marketing issues before others. - That early-visibility creates a tension: speaking up risks being labeled a blocker, which makes teams mute concerns until it's too late. Transcript: Jason Hand In DevRel, we're often the first to see a problem coming. Marketing language that's going to frustrate developers, a product change the community is going to push back hard on. We see it coming because we're living in that community every day. But the second you raise a concern, you risk becoming the person who's always pumping the brakes. And when that happens, people stop listening. So we end up softening it, hedging, or not saying anything at all. And the things we're worried about, they happen anyway. So how do we get better at this? How do we bring concerns to stakeholders in a way that actually lands without losing credibility, without coming across as obstructionist, and without abandoning the community We're trying to protect and advocate for? ([Time 0:00:00](https://share.snipd.com/snip/f2aef534-f8c1-4fc5-b47e-0efe70e8f716)) - **Frame Feedback Around Stakeholder Incentives** - Influence by understanding stakeholders' incentives and motivations before presenting community concerns. - Melissa recommends empathy and curiosity to reframe feedback from the stakeholders' point of view so it resonates. Transcript: Melissa Appel Yeah, I think that the idea of influencing others is something that most people struggle with. So as we're talking about, you know, how do we bring the feedback and insights from our users back to the company? How do we make sure that we're taking into account what the company needs as we're talking to our users, right? We're thinking about two different groups of people who have very different incentives and motivations. And understanding the incentives and motivations of other people is, I think, the key to influence. So we all think, you know, why aren't people seeing it the way I see it? It's like, well, they're different people. They have different experiences and different contexts and different incentives. ([Time 0:02:44](https://share.snipd.com/snip/1a49d612-788b-4d41-93e5-edd47a756657)) - **State Community Backing Explicitly** - Make clear your perspective represents the community, not just your personal opinion. - Jonan warns to explicitly state feedback is gathered from peers so stakeholders don't dismiss it as "just one developer's" view. Transcript: Jonan Scheffler Yeah, they don't believe me, man. Nobody listens to me. Like they don't listen because I'm just one guy, right? I'm just this developer. I'm not like a developer who's spoken to 10,000 developers a year for 20 years. I'm just a developer, right? So when you meet someone in your company, I think it's important to demonstrate your perspective from the perspective of those around you. You were entrusted and expected to speak on behalf of your peers and represent their opinions. And it's easy for us to accidentally represent them as our own. And whether that's ego or pride or what, I don't know. But humans do it, and I do it. And then we kind of stand staunchly on those opinions because we know we're right. It is my opinion. But it's an opinion I borrowed from the community, and I need to express that very clearly, that it's not the opinion of just one guy. It's the opinion mostly of way smarter people who talk to me in hallways. My job is stand around really smart people and be curious. And I love my job. And I listen to them and I try and communicate their needs to my company. But I really have to try to make sure that they hear it is coming from the community and not me. And I don't have great solutions for doing that yet. At this point in my career, I feel like I should have figured that out. ([Time 0:06:22](https://share.snipd.com/snip/c9c4494e-2094-4018-88ed-82c5384bfd20)) - **Phrase Feedback To Reduce Ego** - Phrase feedback to reduce ego and increase credibility by saying "Here's what worked for me" or "I found" instead of "I think." - Multiple hosts note wording differences change perception and build expertise without sounding obstructionist. Transcript: Jason Hand 100% agree with Melissa there. And I've got something, you know, several projects I hear. I feel like here recently where I've had to kind of check myself. I don't know, maybe I'm having a bad day or something in my initial notes and thoughts of what I wanted to say. I've wanted to tone it back of, no, we're not going to do that. You know, like I'm trying to be very opinionated and leader like, but I'm finding that it actually is more effective to say something, which is still very true, but to say something more To the effect of here's what's worked in the past. You know, like I have actually been around the block on this and like, I can tell you what's worked, you know, and I'm not here to just like rain on your parade and say your ideas are bad. I'm just telling you what's worked for me, you know, and that's where I'm coming from. And so anyway, that I just want to drop that in there with with agreement on what Melissa had said. Melissa Appel It's a little bit of your mileage may vary kind of thing, right? Where if you say, hey, this has worked for me, it might not work exactly here, but I feel like it's worth a try because I've seen it work in the past. And that's kind of a way to establish expertise without expressing kind of ego. ([Time 0:08:53](https://share.snipd.com/snip/b0046596-90bf-486e-8791-fcf41b98a467)) - **Use Soft Data And Team Alignment** - Bring data — even soft or anecdotal data — and align your DevRel team to a single narrative before presenting. - Jonan describes tallying hallway conversations and having teammates back the data to strengthen the case. Transcript: Jonan Scheffler I was going to say, bring data if you can. It was really helpful to us as a team. Sometimes this is fuzzier data maybe than some people are comfortable with, but we would sit down and talk about what we had heard in the hallway and what we thought about the thing and Why we thought the thing. And I had this conversation with this person and we would kind of tally it up and be like, well, you know, we spoke to a bunch of developers and probably four or five of them prefer the Phoenix Framework to this other thing. And so maybe we should give the talk about that instead of this other thing. And this is kind of soft data, but every little bit helps. And especially having your peers on the team, hopefully you've got a good team of people who are around to support you so that they're able to push that data with you because you really Have to have a common narrative. ([Time 0:10:24](https://share.snipd.com/snip/be28617c-5192-4222-a7c3-a8231758dcbe)) - **Match Evidence To Decision Maker** - Tailor the evidence format to how decision-makers think: some want numbers, others want quotes or feelings. - Melissa points out knowing each person's decision style dictates whether you present metrics or user stories. Transcript: Melissa Appel Would say on the data piece, I totally agree with coming with data, but you also have to think about how your audience makes decisions. So depending on the person, they might want numbers, they might want quotes, they might want something else because different people, again, have different ways of influencing them, Different ways of making decisions. So some people are like, just give me the numbers. I don't care about what people are saying. What are the numbers? ([Time 0:11:30](https://share.snipd.com/snip/f79a7558-c58b-4fb3-89c8-6333e3c8c870)) - **Raise Concerns As Open Questions** - Present concerns as questions to surface if others share them rather than as definitive threats. - Wesley suggests asking, "Does anyone else share this concern?" to raise awareness without forcing action. Transcript: Wesley Faulkner Much a know your audience. Well, and I think that's one of the interesting things too. I had a coach a couple of years ago at this point who I was running into this issue often internally and we talked through it a lot. And he finally came back and said, okay, are you presenting it in a, this thing is going to happen and so I'm concerned about it and we need to fix it. Or are you presenting it in a, here's the broader concern that I have. Does anyone else share this concern? If no, cool, we can move on. But now I've highlighted the potential concern and made other people at least somewhat aware of it and that there's a possibility or a pattern that is forming and something that could Happen as a result. But learning how to phrase that, I think, is incredibly important. And to your point, Melissa, how do you phrase it to different people? How do you phrase it with the data that you're bringing along with it? Joden, you made a comment about anecdotes and that's still data. And that's one of my favorite phrases for years has been anecdotal data is still data. ([Time 0:12:07](https://share.snipd.com/snip/c836c1ac-35fa-4c02-b7e5-cca35f355f59)) - **Reddit Example That Soured Leaders** - Jonan shared an enterprise Reddit example where a single ill-judged post created years-long backlash. - He used that case to force leadership to see the gravitas of misaligned channel engagement before they experimented publicly. Transcript: Jonan Scheffler Was going to say, it reminds me of talking about Reddit with people at large corporations. When I worked in enterprises, they tend to treat Reddit as another advertising channel. They're like, well, we just pay for the Facebook ad. We'll pay for the Reddit ad. But instead of paying for them, why don't you just post, you know, on your name, just advertise for us with your, and there's, there's actually a subreddit. I think it was about Woody Harrelson or someone else who went on there and just shilled one time. And 15 years later, they still have a dedicated subreddit to hating that person for doing that thing. It's so unwelcome in that community. And so part of what you're trying to communicate is how to engage and where. But in this case, I remember distinctly that I just wasn't stating it strongly enough. They really didn't understand until I showed them examples of companies and people burning alive on the internet for their actions. Like, look at how dangerous this is. This is not a thing we can play with. Well, let's just try it. It's a new channel. We'll just experiment. I was like, you get one experiment, you get one try, just do it right. So I think expressing the graveness of the concern is sometimes also important, but I think we're discussing a lot about how to soften our approach to communication. ([Time 0:13:42](https://share.snipd.com/snip/454ac389-0e4f-4307-8a87-f9d117b22eee)) - **Structure Shows You Represent The Business Too** - Structuring trade-off conversations shows you care about business goals as well as community needs. - Jonan explains pro/con lists and prioritization reveal opportunities and align recommendations with company objectives. Transcript: Jonan Scheffler Absolutely agree with you. And I think actually putting the structure down also gives you an opportunity. And I'm not saying you gerrymander this situation, but you will naturally show your, hopefully your dedication to your employer's goals as well in that process. As you prioritize things into pro and con lists, you will say, okay, well, this represents a potential growth opportunity. We could get 10,000 users at this conference if we do it right. But these other conferences are dedicated at home, and these people have supported us for years, and we've always sponsored them. It's overlapping, right? You have these choices to make. You can, in conversation, do your best to represent your ideas authentically. And my genuine hope is that you understand that companies need money to pay you so that you can serve the users. This is a thing I explain to people all the time. I absolutely know that the checks need to come in. I don't care. You guys handle the checks. I will handle the people. I would like to talk to the humans, right? But in order to be able to keep helping the humans and fight for the users, then we have to get the checks. And understanding the balance of those business needs has historically been a topic of much contention in DevRel. And I have always landed on the sides of the users because, frankly, I'm not a particular fan of money in general. But I think that in your conversation, it's really important to be a little more nuanced than that, if you can. ([Time 0:17:09](https://share.snipd.com/snip/1b726bd0-3c8e-403e-81f9-d2f4043fae35)) - **Say No With Alternatives And Experiments** - When delivering hard news, suggest alternatives, lower-risk experiments, or success criteria. - Melissa advises saying no tactfully by proposing other approaches or pilot metrics and asking to revert if the trial fails. Transcript: Melissa Appel Yeah, I think there's two pieces to this. There's how do you deliver difficult news? And there's how do you say no to something? And they're definitely related, right? You know, delivering difficult news is like, you know, nobody wants to hear that their baby is ugly. So, you know, you don't want to say like, oh, people hate this. You want to say, well, they agree on what it's trying to accomplish, but maybe there's some ways we can improve it to make it more usable, Right? Like it's, again, with the phrasing to say that. Sometimes you just need to say like, we cannot in any terms roll out this thing. It is not going to fly. It's going to damage our reputation, whatever it is, right? This is just not happening. And in my book, actually, we have a whole like section devoted on how to say no. Um, and there are some kind of ideas for how you say no, like suggesting an alternative, right? Well, instead of doing it this way, could we do it this way instead? And that would alleviate these risks. Um, or, you know, uh, bring on some subject matter expert, like bringing quotes or something, right? That you've talked to people about this and they're like, I would hate you for that if you did that, right? So, you know, thinking about how you can make it not about you and your opinion, but make it about like, hey, well, why don't we try this other thing first? Or maybe there's a lower risk experiment that we can do. And if it doesn't work out, then we'll change directions, right? To say some alternative, like I hear you, we can try something, but we shouldn't go all out because of these risks. So there are different ways to kind of say no or not now, but later, or to kind of experiment with things and say, well, you know, we'll try it your way. Here's the success criteria. If it doesn't work, can we try it my way? ([Time 0:19:02](https://share.snipd.com/snip/3ffac653-8ab1-4dbc-bec5-a7ed734e534e)) - **Report Problems With Facts And Solutions** - Be objective and bring solutions when reporting incidents: present facts, what you did, and remediation steps. - Jonan likens this to a post-incident report that leaders prefer over opinionated warnings. Transcript: Jonan Scheffler I, again, I agree with you on all points, brilliant. But the part about opinion especially struck me in that I think developers, I mean, we kind of pride ourselves on having strong opinions, loosely held, right? It's the thing. You have very strong opinions until you change them because someone else gives you a better strong opinion. And I wonder if other parts of the organization, because of the nature of the other parts of the organization, would be a little bit more focused on removing their personal opinion from The conversation and trying to be objective than developers are. I think that developers maybe develop their strong opinions over years and they hold those ideas and the strength of their opinions because it kind of gives them the technical authority That makes their careers. And in some parts of a company, expressing your opinion loudly and proudly can be a severe career disadvantage. And so I wonder like maybe if we just are less practiced about it. I wanted to say also on the topic of just delivering bad news that most of the time in my case, it's been like post-incident. Something happened. Something happened. We had a situation at an event. Some employee got up in a good, this thing happened. And bringing all of that entirely without opinion is the way to go in my perspective. You are the security guard reporting wrote on the instant that happened, like you're reading a technical document and you report all the facts and then try to share in the decision-making With the leadership about the outcomes that are necessary to address that. And when you do that, you also bring to them the things that you have already done to address that. As a leader, I much prefer people who come to me with problems and solutions than those who come to me with just problems. So try to bring the solution to the challenges that you've encountered, how we can do better in the future, what you've learned from the lesson when you come and have those kinds of stories. ([Time 0:20:58](https://share.snipd.com/snip/0f771bd5-6675-400e-8725-0236cb4616b2))