# Get executive buy-in or else {% embed url="" %} Video {% endembed %} ## Summary: * **Three types of executives** * They get it. * Middle ground. * No clue. * **Implement Strategy** * Program your initiatives * Creating measurements * Communication * The key is that you need to understand your value to the executive team. * Then you need to use that to measure against their priorities. * **Defining executive buy-in** * Looks different for a lot of places. * For the purpose of this talk, executive buy-in is an executive that understands your goals at a high level and advocates for you. * Not only defends you but advocates for you and says yes I understand what this person is doing, here’s the value they bring in, and I am behind it 100%. * **Questions to ask executives** * Overall value. * Success Factors * Teamwork * Communication ## Scribbles: ### Three types of executives * **They get it.** * They’re on your page. * They have a clear plan, there’s no question on budget or initiatives. * They’re all in. * **Middle ground.** * Understand developer relations. * They think it’s a cool thing, I’ve heard it and they’re “bought-in” and I do quotes and we’ll talk about that in a minute. * **No clue.** * They’re not quite sure what they need * “Dev rel” and they’re like “Yeah I don’t know. I don’t need to talk about that”. ### They get it. * How do you maintain buy-in and make sure there is no single point of failure? * Because yes they bought in but it doesn’t mean they’re always going to be bought in. * How can you maintain it? * Communication * Internal evangelism * Create a Roadbook for your future advocates so they know when they come in. * What does it mean to be an onboarding developer advocate at your specific company? ### No Clue * Ultimately you’re going to be fighting an uphill battle, and if your executive doesn’t have that buy-in, there’s not a lot of point for anything else. -- look for another job. \~ Speaker’s opinion. ### Middle Ground * Where a lot of developer relations departments and teams are right now. * The executive is there, they’ve heard of it. * How do we measure and execute? Not sure, kind of in-between space. * Ask more questions. * Make a clear path to align company values with yours. * Discussing what success factors look like for that department. * Communication, Teamwork, and ultimately, some strategy questions. ### Questions to ask executives #### Overall value. * “Why do you think developer relations are important? * What value do you think it brings? * What are you looking to get out of dev rel?” * If the answer’s “I don’t know”. --- maybe it’s time for another job search. * If you have that question and they say they saw another company doing it and that’s the only reason they have, that’s a warning sign. #### Success Factors * What does a successful dev rel person or team look like? * “How are you measuring success?” * And not just in developer relations but in the whole company. * How are they measuring success for Engineering? For Marketing? For Sales? * What does success look like to the board? #### Teamwork * How is that divided amongst the whole company? * What does Marketing do, what do Sales do, what does BizDev, do you even have a BizDev? * Do you have a Customer Success team? * Do you have an Education team? * Changes in scale from companies from 0 to 50, 50 onwards and that could look different at one 50 person company to another, or even 1,000 person company. * How is the goal distributed? * And are stakeholders goals being represented around the team? * What goals are associated with them? * Are those goals then represented in your team? * How are they being found? \ **Communication** * How do you currently communicate? * Are there newsletters that go internally? Externally? Is it all in a forum? * You can see how they communicate within departments and how you can communicate as a developer relations department. * How is communication handled between other departments? ### Defining executive buy-in * Looks different for a lot of places. * For the purpose of this talk, executive buy-in is an executive that understands your goals at a high level and advocates for you. * Not only defends you but advocates for you and says yes I understand what this person is doing, here’s the value they bring in, and I am behind it 100%.
### How do you get executive buy-in? * It is a tough place where people say “I believe in developer relations but I’m not quite sure how to measure and execute it”. * You might be going back and forth but you have a path and it may not always be clear. * Digging in and going back to those questions you have to ask the executive team. * Help start lining up your strategy and your goals. ### Implement Strategy * **Program your initiatives** * Setting up programs for what you’re working on. * **Creating measurements** * What is it that you are measuring? * You need to set that measurement up. And with that reporting ideally. And then * **Communication** ### Program your initiatives * Segmenting your developer relations teams or your developer relations initiatives into programs is really beneficial. * It May look like an ambassador program or a hackathon program, * Different types of events. * Education initiative. * Segment into programs and then you can have clear outcomes. ### Creating measurements * **Developer Engagements** * How many people were in your audience? * I’m giving a talk here so I can report back that x many people showed up and heard me speak. * Example - Goal as a company and we want to be in this forum, and we want to measure how many users are on there, and how many active users are there. ### Communication. * **Communicate internally.** * Because then nobody in your company knows what you did. * They think you’re doing work. * But you have to communicate that. And that may look different in a lot of different places. * **Letting the company know what you’re working on is really key.** * Important because they may not know and maybe they missed the email because we get a lot of them. * That’s really big and it won’t take much of your time. * **Doing an internal wiki to showcase your work.** * Have a homepage page that shows what we’re up to, here’s what we’re working on, and come talk to us about it. * **Sitting in on other department meetings.** * Coming into your partner department and going and asking what they’re up to. * Learning about what they are working on once a month or whatever that cadence looks like is really important. * **Doing event recap internally and externally.** * Do a quick recap on why you thought it was important for the developer community. * **Team meetings** * Having an open invitation for any department to come to join your teams.