 Hello, everybody. Thank you for coming to my talk today. My name is Barton George. I'm going to be talking to you about the Seven Principles for Developer Engagement. So let me get started here. All right. As I said, I'm going to be talking to you about the Seven Guiding Principles for Developer Engagement, but you're also getting four bonus tips. This is going to tell you how to actually get started. So as I said, I'm Barton George from Dell Technologies. Let me just give you a quick run-through of what I'm going to be talking about today. First half is some background. So why does this matter? Why should you put together an engagement strategy? Then what do you need to do about it? And that's, of course, where we get into the guiding principles and the tips. And then just as background before I get started, what the presentation is based on is learnings that I've gathered over the last year with regards to reading about developer programs as well as research I've been doing to put together Dell's Developer Strategy and Developer Program. I also love Venn diagrams, as you can see to the right, and I'll be taking you through that a little bit later. And then the other part is actually I've been doing open source and community work and Linux for about the last 15 years. And as you can see here by this laptop down here, this is actually something that I started as a project. It was an incubation project. And it's due to the power of the community, the developer community, that we were actually able to take it from a Skunkworks project to a product and then to an entire product line. So I'll be referring to that as I go through, because a lot of the learnings that I have came from there. So first of all, Stephen O'Grady of Red Monk, who coincidentally had been the one who thought of the idea of putting Linux on a laptop, wrote a book in 2013 and it was called The New Kingmakers, basically a wake-up call saying, if you're not focused on developers, you're in big trouble. Here's the quote here talking about how the businesses that will survive over the next decade will be those that understand and appreciate the importance of developers. And it's vital for companies to have strategies for engaging. So here's some help in putting together that engagement strategy. But first, let me just give you a quick walkthrough of how developers came to power. So in 2013, which is when Stephen's book is, what led up to it was open source, public cloud and REST APIs. All things that the developers picked themselves and started working on outside of regular IT. And what they actually did was by using the cloud and open source, they were able to circumvent operations. And this actually led to greater innovation and productivity, which was recognized from the business. And then they started getting more and more influence because the business would look to them in that they were delivering greater productivity. And what started this shadow IT then became sanctioned. And this actually was then what served as the foundation for modern IT. So 2013 is when Stephen's book ended and things have only accelerated since then. So developers influence has continued to climb. And if we look in 2013, some of the technologies that have led to this accelerated influence are cloud-native technology and developers, containers, DevOps, Kubernetes, infrastructures, code, all of these, well, many of these were around in 2013, but they really came to the fore over the last, say, five years. And this has helped the application developers and then operations, which also helps application developers in that operations goal is to support developers and their productivity. And then here's just some numbers about the impact that developers have made. The top part here is from a study that McKinsey did where they found out that developers in the top quartile actually delivered to their company 60% higher shareholder returns and four to five times faster revenue growth. And then as far as influence goes, this is a great stat. This is from a survey that Nutanix put together, but this is sort of the power of the torpedo from developers and saying 35% of opportunities are lost as the direct result of a developer influence. So there's someone that you definitely want to make sure that they at least know who you are and that they don't keep you from the short list. So with that, let's jump into the seven guiding principles. So here's how I've organized them. You've got the two intersecting circle, the enterprise and the community, the developer community. And then I've broken these into outbound, inbound, and internal. So outbound is what your company should keep in mind when looking out towards the developer community and interacting. Inbound is what you need to do for them when they are looking to access information and offers that you have. And then internal, of course, is within your own company and what you need to do to really foster an understanding and support of developers. So the first one to start with the outbound is participation. And as I say here, developer engagement is not a spectator support, a spectator support. And I think one thing that you hear a lot is that code talks and that's extremely important for the community and that is indeed true, but that's not the only thing. You can contribute through docs, through promotion of projects, the events and participate in the conversation and then social media as well. And questions are as good as answers because when you're going to be starting out in this area, you're really not going to have a lot of the answers, but what you want to be doing is asking, seeking out folks what matters to them and learning from them. And then the other thing is if you take give back, and this was something that was important to projects, but Nick, which is if you take open source and benefit from it, you should donate back to the community. And so what we did is when the drivers were written for Linux, we had the device driver manufacturers then push those drivers up to the mainline Linux kernel so that everyone could take advantage. Then the next one is the tone that you want and the approach you want to take, which is transparency and authenticity. Authenticity, Trump's budget in this case and transparency builds trust. And obviously with all customer types, you want to be transparent and authentic, but with developers, you go one step further. And when you're engaging, it's about open dialogue and plain speak. You don't want to be talking about reliable available scalable or any types of superlatives. And then you don't want to over promise or take on too much. So as long as you as long as you bound things and are open with the with the community saying, hey, we're only doing X right now, and then we hope to expand, that's fine. What you don't want to do is then make promises that you can't back up. Agile communications versus the big reveal, this maps with the one below it, which is you start communicating early, add details as you go. And as opposed to keeping everything quiet and then getting up on stage and saying, ta-da, we've got this great new product, which works in some cases, but is not as effective here. And that's actually something we used with Sputnik is we launched it on my blog when it was just a project and we said, hey, we've got this idea for a potential Linux laptop for developers. What would you like to see? What would you like in a laptop that would be best for you? And so we brought people into the actual product development process. So now if we look into the inbound, so when developers are looking to engage with you and material, you don't want to have gated material. So short-term gain really pales in comparison to the long-term trust that you need to be building. So what you want to do is you want to provide unfettered access to the code early on and then they also expect self-service material, some of the types that I've listed here. And then once again, getting back to Sputnik when we launched as a project, we put out a really rough ISO. So we had all these caveats saying, please, we'd love you to use this, but know that the touchpad doesn't entirely work. Brightness is having some issues, but we are working on these. We will keep you informed and let you know when as things get fixed. So they were happy. They would prefer to have gotten a bumpy ISO ahead of time rather than waiting till things were perfect. So being able to be part of the process. And then inclusion, that's what I'm talking about here. And this is what we use for Sputnik when I said we solicited input from developers and we had a list of things that people wanted and then they could vote up or vote down. And by including people in the process, it does three things. It helps to build trust with the community. It also drives awareness for your project or product. And it ends up giving you a better product because customer input is always a good thing. And you can actually use this not just for products, but for input to drive projects and strategy. And then when you're getting into the game, so if you're new to the developer engagement space, you want to do a lot of listening. And as I said before, listening, asking questions, and people will respect you for that. And then just making the point that all companies, and I know particularly for Dell as well, is that you're always soliciting customer input to better understand your products or what customers want. The difference here is you're not bringing in a customer council or bringing people in under NDA. You're doing this out in the open on social media, as we did here with this IdeaStorm, where people could comment and as I said, they interacted and could vote things up or down. And then if you look within the enterprise, and this is things that you would look to do after you had made some progress on the first two buckets, is coordinating within your company. So the sum is greater than the whole parts and misaligned parts will damage your engine. So what I'm referring to here is if you start digging around, you will find that there are efforts that you didn't know existed, whether that's open source contribution or developer type projects that are going on that would be great to share. And what you really want to be doing is you want to get these people aligned and aware of each other. Doesn't mean that they have to in the beginning fit into some grand strategy, but you don't want to be contradicting each other. And then like coins between the pillows in your couch, once you start looking for items like this, you'll be surprised at how much you actually have in the way of projects and things going on. Understanding, this would be what you wanted to focus on when you're looking to move beyond the Enlightened. So beyond those folks who already understand it, if you wanted to spread throughout the organization, you need to start educating. And it doesn't have to be in great detail, but you want to be able to provide an introductory overview to the world of developers, talk about open source, talk about their norms, how do they expect things, which are different than our traditional customers. And then most important is why should I care? So folks have a ton to do, right? Maybe they've got 10 items they're juggling and they can only do eight, and then you want to add an 11th, and it just falls to the bottom unless you can explain to people why it is important to them and the overall company. And then last in this area is incorporation. And this is the type of incorporation I'm talking about within the processes of your company. So in your product development process, you need to have a line item there for a developer. So they are officially there, not just something that if you remember, you include them. And then as I have here, you want to put it into various different areas, marketing, sales material, et cetera. You want to integrate it into all of that, but you're not going to go whole hog right off the bat. You're going to try some proof of concepts in a couple of areas, work out the kinks before going bigger. So now getting started, telling you all that, obviously building developer trust is easy, and now that you have the seven principles, away you go. And if you want to go faster, you just throw money at it and you see the slope goes way up and you get things done. No, just kidding. It takes time. Even these great seven principles won't accelerate things to the extent that I was showing you. And throwing money at it, as I said, it's not going to work. So you need to keep at it. You need to be steady and you need to build trust. So those were the seven principles. Now let me talk about the four tips to get your program off the ground. This is to get it bootstrapped. And so the first thing is to build a team. And what you want to do is you want to assemble a coalition of the passionate. And just like technologies that you'll find throughout your organization, you'll find that there are people there who really are excited about developers and do have some deep knowledge. And you want to get those people together. So the folks on the right here, myself included, were the team that started off Sputnik. And so none of us worked full-time on this. Jared with the beer there, he actually worked in the server side that said nothing to do with his job, but he was excited and he helped out. And so you're not going to get a ton of headcount right off the bat. Maybe you do, but I know at Dell and a lot of large companies, they're not going to give you 10 people if you say I want 10 people to kick off a project. So what you need to do is show value with this guerrilla team, show the need for more people, then you hire and then you go again and again. And that's how you slowly put together a team. And then what do you need to put out? So as you're thinking about what you're going to show the community to start getting input on, you're going to go through and take an inventory of what you have. And when I say inventory, this isn't exhaustive. This is going in and finding some highlights quickly and then looking to turn those into things that you can put out. One thing to keep in mind is you always want to prioritize things that you can execute. So if you have something, and I mean execute, execute now. So rather than waiting for this perfect project in six months, you take the one that's not as great, but it's available right now. And then as I mentioned, you're going to want to set up pilots in certain areas. You're going to want to deliver MVPs and proceed iteratively, get that feedback, figure out what's going on, and then tweak accordingly. And then when setting the direction and focus, as we talked about before, you do want to get input from the community. And then for all the reasons I talked about, it gives you awareness. It gives you a better product. They feel involved. And then the other thing is you want to stay analysis light on this. So this MVA is something from Jeffrey Hammond at Forester, minimum viable analysis. So you want to be going, once again, quick, you're going to be working agile fashion. You want to be learning from experience and with a minimal amount of analysis. And then metrics. This developer programs are notoriously bad for being able to tie back to units or to dollars. So one thing you may want to try is engagement and measuring that. So how many page views do you have? How many comments are left? How many people link to your blog or to your developer portal? And then as you go, you can refine your metrics as you figure out what's important to you and what's important to the business. So in summary, basically you have your seven guiding principles. Outbound is participation and when you do that, you want to be transparent and authentic. Internally, when developers come to get things from you, you want it to be accessible and you want to include them in the product development phase and strategy. And then internally, which is the last bucket that you focus on, you coordinate the efforts that you do have, you start to build up understanding within the company, as I said, to get it beyond the enlightened. And then you want to officially incorporate it into processes. And then with regards to getting started, the team, start with passionate volunteers, offerings, start with what's available and work with MVPs, the direction you listen and you want to stay analysis light. And then metrics, you want to check engagement and refinement. And here we even get you a fifth bonus one, which is when you're building up your developer program, there's going to become a point. In the beginning, it's going to be a hub and spoke where all the questions are going to be coming to you. And it's just going back between you and the group. What you want to do is you want to get to a network area where they're talking to each other and not just talking to you. And then if you go even further, you start building an ecosystem with this network effect. And so the people aren't just working with you and the initial group, they're taking your products or your offerings, building on them and then creating, as I said, this greater ecosystem. So in summary, remember, start small, start now, and keep at it. Thanks for attending. And now let's take a look at some questions through Slack. Alrighty. Thank you.