Company alignment: do or die

Speaker 1: Thanks for the opportunity today. Very much appreciated. Yeah. Today's title is a little bit click baity, click click baity, I guess, do or die. It sounds dramatic, but I'll get into why I think it's appropriate.

Speaker 1: And I think a lot of some of well, certainly, a lot of the ideas in this presentation, I think, will dovetail nicely into Michael's previous talk. So looking forward to it. Okay. So quickly about me. I built two developer programs inside large telecoms companies, which is an interesting experience.

Speaker 1: I joined Twilio as their first hire outside The US back in 2012 and built a European business until the IPO, and most recently just put out a book on developer relations coauthored with Caroline Muko, who's been popping up throughout this conference. So Caroline's doing a good job. So let me start with a couple of quick definitions. But if you have been watching some of the earlier presentations, I think these terms are now being used quite a lot, which is really encouraging. But to help frame the discussion, we we've looked at defining two types of companies that operate a developer relations program.

Speaker 1: One is developer first, and these are companies with a primary business to develop a business model. That's you know, their reason for existing is to sell products and services to developers. And then there's developer plus companies. These are companies that are primarily having a business to business approach or a business to consumer approach, but have a developer offer as an extension to what their core business does. So I don't know.

Speaker 1: Maybe good examples here might be Santander Bank or Ford Motor Company. And, interestingly, based on the stated developer relations survey, more people in DevRel are working in developer plus companies than they are in developer first companies. Life can be sweeter working inside a developer first company as there tends to be less confusion around simple questions like, why are we serving developers. There also tends to be a clearer link between the success with developers and success for the company as a whole. But, you know, it's not all roses even in a developer first company.

Speaker 1: So, hopefully, there's something in this for everyone. So have you ever struggled to describe what you do, struggled to quantify how your works make your work makes a difference to the company, failed to secure headcount, failed to secure budget, had to cut your team, or in really serious situations, have you had to close your program completely? I know I've certainly been in that situation myself. So these are all symptoms of a lack of company alignment. And back to the the talk title, if unaddressed, these can lead to the death of your program.

Speaker 1: Now that does sound dramatic, but, you know, like I say, many of us have been in a situation where you've had resources pulled or your program has to close. In fact, sometimes a worse situation is when you have that death by a thousand cuts. So no one actually closes your program, but over time, your resources are chipped away. And one area of DevRel DevRel I think we don't talk enough about is the situation where we have to be the public face of a program, and we have to go out into our communities and represent our company, putting a brave face to things whilst we know that behind the scenes, the the program is crumbling and potentially might close down. That puts you in a really challenging professional situation where you are perhaps struggling with the the the issue of putting yourself out there in the in the community and presenting this positive image whilst you know that you're dealing with a whole bunch of confusion, misalignment, and issues back at base.

Speaker 1: If you've been in that situation, my heart goes out to you because it's not nice. So how do you achieve alignment? Like I say, some of this was actually, in Michael's some of the similar things from Michael's talk just before. But number one, as a DevRel leader, you should be thinking with identifying and educating your stakeholders. It all starts with your stakeholders.

Speaker 1: These are the people within your organization that could make or break your program. So you need them fully aligned with your strategy and supportive of your efforts. And you need to be prepared to answer the key question, why should we be investing in DevRel? Now if I went around the audience right now and asked each one of you that question, do you have an off the cuff, succinct, data driven answer? Remember, the correct answer isn't just based on your detailed knowledge of your own program, and it isn't just based on your passionate defense of how important developers are.

Speaker 1: Your answer needs to be contextualized for your company. In other words, how does your program relate to other projects that are competing for resources, budget, and attention of your senior management? You also need to be thinking about your company culture. To be successful, DevRel needs transparency. It needs a willingness to act on feedback, and it has to has to be operated within a collaborative mindset.

Speaker 1: In a developer plus company, the business is likely to be measuring your success through their standard lens, and they may not appreciate the time it takes to establish a community, build trust with developers. Well, it's your job to teach them why this is different. So whilst you can be a positive influence, you really shouldn't be carrying the burden of trying to change the whole company, and that really shouldn't be on any DevRel job description. But equally, don't put your hands over your ears and pretend there isn't a problem if you've spotted one. Just consider if the cards are actually stacked against you for for long term success.

Speaker 1: Now as I said, you might be one of the lucky 32% working in a developer first company, but even there, friction is still gonna arise over perhaps interdepartmental communication or disagreements over go to market strategy, metrics, etcetera. As I say, it isn't perfect there either. So let's talk about corporate antibodies. So large organizations are complex organisms, and they come complete with self defense systems. So these defenses activate when you try something new or perish a thought, you try something innovative.

Speaker 1: Your company will have formed a mental construct around its purpose and its mission, and departments and individuals are head down working to achieve their KPIs. So when you come along with this great idea about serving developers, risk and disruption are not typically things that they're gonna rush to embrace. And it's also worth making the point that the further away a new idea is from the company core, the riskier it feels and the heavier the scrutiny will be. And and a fact of life is, unfortunately, in some companies, it pays to be risk adverse. Everyone just keeps their head down, and this is why large organizations get disrupted by start ups.

Speaker 1: They get complacent. Sometimes cultural issues surface surface themselves as like a not invented here attitude from a department or a leader that you actually need support from. Some leaders or teams position themselves as the guardian of innovation inside a company, and they will just seek to block any idea or competing initiatives that doesn't originate from them. Other times, it surfaces why the frustration of trying to serve developers within the constraints of the existing business. So even though you have those nagging concerns, you've still gone to market.

Speaker 1: You've launched the developer program. But now you're live and now you're dealing with developers, you're starting to see friction and issues appearing all over the place. Some examples might be, to access your product or your API, a developer has to sign, you know, a dense legalese terms of service contract. Or maybe, a revenue shared payment is taking ninety days before it's paid out because your company is geared to paying other large companies and not smaller start ups where cash is king, and those ninety days could be the difference between success and failure of their business. And the list goes on.

Speaker 1: It it might be something as trivial as having your social media accounts controlled by corporate marketing. So whilst that represents a really powerful channel to market for you to communicate to developers, you can't do that authentically. So to succeed, it's therefore vital to put yourself in your stakeholder's shoes. Ask yourself questions like, by supporting my program, how will it help them achieve their goals? Or what risk am I asking them to take by supporting my idea?

Speaker 1: So how can we help? Well, here's a a couple of tools that might might give you some pointers, might give you some help. Let's dive into the first one. We call this our kind of stakeholder mapper. And the idea behind this this tool is to help visualize the influence various departments have on your program.

Speaker 1: So how you use this is you you talk to your stakeholders, your different department leads inside your company, and you ask them to complete the scoring exercise. And you also do the same thing with your immediate DevRel team, assuming that you have one. So you ask each participant to score what they feel is an appropriate level of influence in the DevRel program for each department, not just score their own department, all of the departments. So what this exercise does, it gives you a visualization, and it helps you reveal misalignments. You might be able to see complete differences of opinion in terms of one department over another and the level of influence they believe they should have.

Speaker 1: It surfaces potential for conflict, but also it shows you your shows you your allies. So in this example, we've contrasted the score of the immediate DevRel team alongside the aggregate the aggregate score of the stakeholders and just kind of contrasting those two scores. But, you know, do whatever works for you. You can use this. You can adapt it.

Speaker 1: It doesn't have to follow the same format. One thing I would say is repeat this exercise every six months because things change. I'll talk a little bit about organizational disruption in a second, but one thing's for sure, if you're working in, like, inside a a company of maybe a thousand people above, you can guarantee that every six months, there's gonna be new people joining, new people leaving, restructures, reorganizations, etcetera. Okay. So the next one, which is something that that was discussed in Michael's talk, is really understanding your company's priorities.

Speaker 1: So to successfully line up your stakeholders, it's vital to be able to connect the dots between your program and the things that are important to the company. Now this, as I said, might be straightforward if you work in a developer plus company as your program is likely the key driver of adoption of your company's product and therefore directly helps drive revenue. Pretty simple. However, the value of serving developers might not be so obvious if you work in an organization like Santander or Ford that I used as an example earlier. So how do you fully so do you fully understand your company strategy and priorities?

Speaker 1: Have you kind of done a similar exercise? Have you connected the dots between your day to day work and the things that, your executive team care about? So when you're setting your department and personal goals, make sure they line up. As I mentioned, one of the programs I developed was for a telco called o two in The UK. And when I first launched my first program, o two Litmus, I actually had to sell that concept in around the theme of how Litmus would actually benefit our early adopter customers to drive higher levels of engagement, higher levels of retention, and increase smartphones smartphone sales and revenue from apps.

Speaker 1: You'll probably notice I haven't mentioned developers once in that sentence. The way I got traction was describing the developer program in the terms and the metrics that that the actual company cared about. So despite me understanding that the key constituent here was developers, that wasn't actually the way that this this proposition was sold in. Because, you know, the reality was the management team were a million miles away from seeing the developer as a customer. So it's all about framing your work in the terms the company will understand and value.

Speaker 1: And, again, the answer to a key question is why invest? You you have to have that answer to that very simple but very challenging question in your back pocket at any time. So this model can be helpful to help you articulate the answer to why a dollar spent on your program is better than a dollar spent somewhere else in the company. Now, naturally, most programs tend to gravitate to the top right hand box. You know, these are the very external developer centric reasons that you typically run a developer program.

Speaker 1: However, there's many other ways that your program might bring value to the company, and it's important you explore all of these and and and have them as part of your pre prepared answer. So along the top line, you've got value creation. Excuse me. So, for example, if you're an API business, if you have invested in APIs, you might have a direct internal benefit of increasing your speed to market for new products, you know, using eating your own dog food, so to speak. Don't forget also on the bottom line, as well as value creation, you've got cost reduction benefits as well.

Speaker 1: So for example, simplified service access and service reuse will save you development time and money of bringing new products and services to market. And, of course, by offering a frictionless self-service experience, you'll lower your cost of acquisition for new customers, and you'll also lower your support costs. Okay. But the classic question, who cares? You might be thinking, okay.

Speaker 1: This is all great, but I really don't really care about corporate politics and all that BS. I just wanna focus on delivering the best possible developer experience. And and that's a valid answer. Right? But I would say if you are either a DevRel leader or you aspire to be a DevRel leader, focusing on that stuff isn't enough.

Speaker 1: So make no mistake. This is all about leadership. So your job as a as a DevRel leader is to build the support and provide the air cover for your program and your team. Every company has intense competition for resources, and the job security, the people placing the bets rests on them getting that right. And and here, it's no difference between a developer first company or a developer plus company.

Speaker 1: Everyone is accountable for their performance. Just remember, inside a developer plus company, the priorities and competing projects will be much more diverse and mostly unrelated to serving developers, which means more of your time being spent on stakeholder education. And I think I heard a talk earlier today saying that for the first two years of their program, 75% of their time was spent internal, trying to evangelize and spread the message about why this stuff was important. So just quickly to recap, number one, understand your company goals and your strategies, connect your work to a company priority, map your stakeholders and understand their motivations, be clear on the answer to why invest, understand your company culture, and ask that tough question, is it conducive to DevRel's success, and then repeat. Because as we said, change is constant.

Speaker 1: Sometimes a DevRel champion builds enough momentum internally to launch a program, but then loses support twelve or twenty four months into the effort. So in summary, don't operate in a bubble. And if anyone is interested in the book, just a quick promo code there. If you go to that Bitly link, dev rel 20, and use code dev rel, that'll get you 20% off the book. Thank you very much.