Made by
Made by
The time has come, Anil Dash proposes, in this DevRelCon London 2017 talk, for dev rel experts to come together and make their value known. In this session, he talks through 10 community-sourced principles that his team at Fog Creek have termed the ‘Dev Rel Bill of Rights’, which are designed to make sure dev rel experts are supported effectively and have what they need to get all important buy-in.
We’re gonna time travel way back to the turn of the century and it sounds like a long time ago, right? It’s seventeen years. I did the math in my head. And back at the turn of the century I was a coder. That was what I did. I programmed for a living, and it was a dream and it had finally come true and I was very excited about it, and I was at an organisation that did not really care much about coders. They, sort of, said, “Here. Here’s your little cubicle and we found this old Dell lying around and you can use that and let us know when the coding is done.”
And then I think that was actually a pretty common experience back then. Even at the height of what was then the dot-com bubble, coders were not…programmers in general were not actually a discipline that was as respected as you might imagine given how much money was, sort of, sloshing around the different industries. And I stumbled across a blog. I was a blogger and so the community of people that were blogging at the time was very small, and I stumbled across a blog from a guy that had started a company called Fog Creek Software. That was Joel Spolsky’s blog, “Joel on Software”. How many of you have ever read a “Joel on Software” post? I should hope so, right, I think that’s pretty good. He should start blogging again.
And I just was struck because there was this person talking about the concerns that I had in the world as a coder and it felt like, “Wow, somebody noticed what I am and what I do and thought it mattered.” And then of course I watched what Joel and his co-founder, Michael, and their incredible teams have done over the years and they’ve built Stack Overflow which is just an incredible job. I was sort of outlining earlier, I was sort of like, “Wow, you know, I’m on the board of Stack Overflow,” and it’s like I didn’t know some of this stuff.
So that’s good. There’s this whole practice built around it and they built Trello. They built all these things. And that was remarkable and I think that’s what most people know Joel for and that whole team for having done those days. But what stood out to me as somebody who was writing code every day, not very well, I was never a great coder to my chagrin, was that Joel also created a test, and this was…it really started as a blog post but it later became, sort of, a whole framework for how he built several of his companies.
And it was this idea that there was a set of practices by which you could define whether an organisation cared about its programmers, cared about them having the resources they need, cared about them having the infrastructure they needed to be successful. And it was simple things like do you have a monitor that’s big enough for you to have your app and your window up…your editor window next to each other?
And there was more complicated things like at the time did you use version control? Now, granted back then version control was like SVN so it was a much more painful experience than it is these days. But even that was better than the every once in a while I zip files up and email them to myself which was the state-of-the-art of a lot of organisations.
And so by creating this list, that he called the Joel test, of things that would indicate an organisation cared about whether programmers could succeed within their walls, he made a standard, and it was something that organisations started to share with each others, coders started to share with each other and had a real transformative effect. Almost too successful because now coders are probably the most privileged workers in the history of the world so, I mean, we could dial it down a little bit.
No need to have quite as many free massages and snacks all the time, but, like, there was a, sort of, a balance there where they went from under-respected to very, very, very respected in a short period of time and in no small part because there was a clear declaration of a standard to which all the people in that community should be served.
And that was striking to me because actually, as Matthew mentioned, I joined a company that was making blogging tools back then and my title over the course of a couple of years shifted but eventually became Chief Evangelist or VP of Evangelism. And I picked that title because I had created a developer network and was in charge of developer relations at a time when that was, sort of, being fairly lost in the woods. You could not fill, even in San Francisco where I was at the time, a room this big with people that had that as their primary responsibility.
And I looked back at companies that had done it…as I mentioned, Apple was one of the, sort of, pioneers, and at that time Guy Kawasaki was the only person I had known who’d had the title of evangelist on his business cards, and of course his track record had just been there at the time when Apple went from industry darling to, “Are they going to survive?” And so it seemed to me like evangelist was not at all the title that was necessarily effective at growing the business but that it was that it sounded pretty cool, and so I took it.
And for me it was because the work was important. It was interesting. I had, and this is gonna date me. I started…When I started being a professional coder, I had coded pretty much my whole life, but when I started doing it for a living, I used to get MSDN, the Microsoft Developer Network, delivered as a print newspaper to my office every two weeks occasionally accompanied by floppy disks, later upgraded to CD-ROMs. I’m that old. And it was still insightful, and so I thought, “Wow, developer networks can really make a big difference. I’m gonna create one of those.”
And that work grew eventually to working with my peers in other companies at Google, which was not nearly as big back then, and other companies like that to create what we were trying to hope for would be a shared API, a shared standard between all the tools that we were building. We succeeded in creating a very complex, elaborate, inscrutable XML API right at the moment as REST APIs took over. That succeeded as well as you might imagine, but one of the useful things that did come out of that process was I found a community.
I found a community of peers, and it was, you know, five, ten of us that could fit around a table. I mean we could all have dinner together, but I found people that cared about building relationships with developers. And it seemed like there was this common thread where we understood, even though we couldn’t quite articulate it, that creating this community was really, really meaningful and really resonant and would have significance because we were affecting the developers that were shaping so much of what happened around us.
And interestingly, the company I was at, at the time was very design-driven, very forward-thinking about these kinds of practices that I think today are very standard and I saw our design team and the people in that community hashing out like, what are we gonna it, user experience or user interface, or interaction design, or information architecture?
And these titles were actually very fuzzy, very ill-defined at the time. But they spent a few years and people wrote a lot of blog posts and made a lot of diagrams. They’re good at diagrams. They’re designers. And they put it all together and they, sort of, said, “You’re in this bucket and we’re in this bucket and this is how the workflow goes between what we do. And we start to define who it is that does each step of the process.”
And the interesting thing that came out of that that I noticed was all of a sudden, we had VPs of design. We had venture capitalists talking about we’re gonna fund a design-based firm, or design-based fund, sorry, to have a design first practice for some of these companies and these startups that we’re going to invest in.
And they started to really take design seriously because designers took it seriously. They, sort of, demanded, “This is how we organise ourselves, and how we see our practice evolving, and how we make the business case and the argument for what we do.” And at the time, of course with our community, we had all these wild different titles. Some of us were doing evangelism, some were doing dev rel, some of us called ourselves developer advocates, but I knew that would settle out very quickly.
There was no way that we could get past 2005 or so without sorting out these titles and all coming to a conclusion that there was one name that would describe the practice, and we arrived at it this morning when Aaron revealed to us that we are all applied epistemologists. But the interesting thing to me was I loved doing the work. I mean, after a while I got tired of quite so many airline miles, but other than that I loved the work. I loved meeting people. I loved talking about the code. I loved learning about how people would use the technology and they could invent new applications for the platforms we’d created. It felt like a revelation. Like, you showing to me what my work means, is some of the joy of dev rel and I wanted to move forward with it.
And after a few years of thinking about that…and even at that organisation where I had been very senior, I was the first employee hired after the founders. I had a lot of access and a lot of, you know, influence on product road map and things like that. The only way for me to move forward, even with a dev rel title that was pretty much as senior as it could get, was to move out.
There was no future for me even having as much power and control and influence as I could within that organisation, and with a product that was successful, with a platform that was interesting, there was no future for me in dev rel except to look elsewhere to marketing, to sales, to product, to engineering, to the things that I was interested in that weren’t what had made me motivated in the first place.
Let’s fast forward a decade or two, about 15 years, from when the story starts to much to closer today, about a year ago. I ended up getting asked to become CEO of Fog Creek Software. Joel and Michael, the founders, had had a lot of success with Stack Overflow and Trello and each had gone to go and run those companies, and they said, “You know, we still have this company that’s making interesting things and, you know, we think you could be a steward for what it is.”
Which to me felt a bit like when Rob Halford left Judas Priest and the guy who was in the cover band got…the singer got to actually be in the real band, yeah, and then he got pulled on stage, I was like, “Wow, like, this is pretty exciting. Also, I’m not qualified for this but I’ll try it. Don’t get mad if I screw it up.” And, you know, in those interceding years I thought I had sort of learned, you know, how the world works. I had gotten the skills to get to be in a seat like CEO and to have that sort of title, but in particular I was struck by what the team had created, you know, at Fog Creek.
Before I joined, I mean, this work was, sort of, done but for telling the story where they had built these incredible platforms like Glitch. How many of you know about Glitch or have seen it and checked it out? That’s awesome. That makes me excited. They made manuscript which is like Jira but it doesn’t make you wanna cry. And that’s the tag line. We’re gonna put that on the website. And I…Gareth’s here, I could actually ask you to do that but, whatever.
And it was such a compelling legacy, but I was curious about was gonna come next, and in particular, I looked at Glitch and I just thought, “This is something remarkable.” It’s just…it brought to me the fun of the early web when you could just, sort of, view source on like a GeoCities page and hack it together and make something cool and feel like, “I made something and I can show it to someone,” and this is what I loved about the web.
This was what the promise of being a developer was about to me, and especially because as you, sort of, get further down the road on being a developer and moving into these other roles in an organisation, a lot of times, the only time you can code is, like, late at night after all your actual work is done. And I always felt like by the time my son was in bed and I’d, you know, done the dishes or whatever else, I had enough time to set up a dev environment and then I had to go to bed before I could actually code the thing that I had in my head. And to, sort of, restore some of that ability to create was really powerful.
And so I saw what the team had made and I said, “I’m in. I wanna join this company. I wanna work in this project,” and I think the expected thing we were going to do with a tool like Glitch where people are coding together and you’re, sort of, running the apps was as you would make something like a new version of Heroku, right? You would do a hosting service and you would, sort of, host people’s apps and hope that that was how you built a business. And I think that was the easy path and the expected path and not at all what we’ve done. Maybe it would be easier than what we’re doing.
And I thought about what the right thing is to do which is we’ve got this tool that’s special and it’s a place that people feel like they can collaborate together and create together. And the right thing to do was to go back to this unsolved problem which was that, I think all of us know really deeply, developers shape culture, right? I mean, you can phrase this as software saving the world. There’s a million different ways to say this, but what we look at that’s incontrovertibly true is that choices we make in software really matter.
When we see developers…something as straightforward as we used to think about how to represent somebody’s gender in an app, and that used to be, you know, a radio button with two choices of male and female and say, “You know what? There’s such a wide world that we can make this an open ended TextField and just accommodate everyone instead of being convenient to our own preferences or our laziness as developers, and simply indicate to somebody that they belong in this app, in this community as much as we do.”
And those little choices we made in our software were, sort of, revealing our values. And when we realised everything, like, every pixel on the screen, every dropdown choice in a menu reflects culture, then the role that we have as people that care about relating to developers and supporting them becomes even more important. The stakes are suddenly much, much higher. And then I thought, “Well, if we’ve got the chance where we’re building tools that people happen to like, then serving that need is the most important mission we can have,” and especially because this is happening in every organisation.
I mean, so much of the conversation focuses on public-facing APIs and, you know, the sort of very visible startups that have a lot of resources to invest into dev rel, but, you know, every organisation has some surface area they’re exposing through technology, whether that’s an internal API or a B2B interface or something that is for developers out in the world, this is, sort of, how they’re saying this is the way to interact with our organisation, with our institution.
And so this becomes a very, very pervasive need. And I realised if we’re gonna do justice to that, it would make sense to go back to first principles which is, how do you raise the bar and raise the standard for a community when their work has not been sufficiently respected? Because interestingly to me, when I spent that time in San Francisco in the startup the world, and it wasn’t the scene for me but I got to meet a lot of people and see a lot of interesting things happen.
And I, you know, I saw when GitHub was a weekend project from two guys that were in the community and I said, “That looks interesting.” And I saw, you know, the very first version of the Stripe home page and there was a curl command on the home page and I thought, “That’s new. That’s different.” And seeing the first version Twilio and then saying, “Why isn’t this harder because isn’t this supposed to be a lot harder? This is really easy.”
And, you know, each of those was a blip. It didn’t register to me at the time this is a milestone in this greater practice of what we’re doing, but over time, as we started to understand, “Oh, it’s great. These are ways to do documentation. These are ways to do examples,” what we didn’t have was a way to make each of these organisations and institutions care deeply about the practice of dev rel. But what if we could set a standard in the ways that designers had done for their practice, in the ways that I had seen Joel do for developers themselves that we could set a standard for what dev rel was?
And, you know, my trepidation about this was it felt a little presumptuous for one, me to be the one to write it and two, to call the Bill of Rights. But I’m an American and the Brits here will know we’re, sort of, insufferable. And I decided, you know, there isn’t going to be a right person, a qualified person. There isn’t gonna be a perfect person. There’s just gonna be whoever shows up because that’s how community works. That’s how dev rel works. And so we would put out something imperfect and imprecise as a starting point to hopefully galvanise the conversation.
And there’s actually, if you look on our Twitter account, our Facebook account, you’ll be able to see, you know, where we’ve linked to this Bill of Rights, but I wanna run through just a couple of the points real quickly. I don’t know, I not going to recite the thing at length but I think some of the points are less obvious or were harder learned lessons that took a lot of time for me to get why they mattered and took me going on this path to leaving the discipline and coming back before I understood their importance.
So the first point was a clear set of business goals. And, you know, this sounds obvious, but so much of the time dev rel is this opportunistic hire that an organisation makes is like, “We’re supposed to have dev rel now. Let’s go get one.” And they leave goals under-defined, and what happens in that the people in the position cannot win. There’s no way to say, “Well, I achieved what you asked me to achieve,” because there hasn’t been that clarity of goals.
And so this is such a straightforward, simple request to make, and, you know, this was one of the first things I thought of because I thought if I can give you a tool where you can say, “Well, this one company that’s been around for 17 years wrote this list and can we just check this first thing of the list?” radically increases the chances that the work you do will be something that persists in time and the position you have will be one that grows in time.
The second was a well-defined place in the organisation. How many of you your job is dev rel, dev evangelism, dev advocacy? All right, almost everybody. How many of you report into an engineering or product team? About a third, maybe. How many into marketing? Yeah, what are some other teams that you connect into?
Male: Sales.
Anil: Sales, right? How many into sales? Just a few. How many of you none of those? Yeah. How many of you don’t know? You don’t have to put your hand up. And, you know, that was me for a long time. I was like this…you know that thing they do in org charts with you, “Well, you have dotted line into this person.” I had all dotted lines. There were no solid lines, which is, sort of, the way of saying that you’re a hot potato.
Nobody wants to, sort of, be responsible for you, but especially nobody wants to carry your budget, right? You’re cost and nobody is like, “I would like to volunteer for the cost of this person or team whose goals are ill-defined.” Right? There’s no way to win there. And so to demand, “I want to know who my boss is and who I report to,” is not an unreasonable request. And to say that their budget is accountable to us for these items is not an unreasonable request. So let’s set the bar at least that high, although that’s not very high.
A structured way to impact product and platform. This was, sort of, very carefully chosen wording here, and this was that sometimes you will be part of a product team. Sometimes you’ll be part of a platform team. But whether you are or not, when you go out to an event, when you talk to somebody on a forum, on Stack Overflow, out in the community, on social media, and they say, “We need your platform to do x, y, and z,” and you believe them because you’ve heard that a hundred more times before, for you to be able to take back that to the product team and have them hear you and acknowledge you, and maybe they’ll close your Jira ticket, but they had to have seen you and said to you, “We’re not doing that right now,” have a process that matters, that matters. It’s the basic level of respect for this role.
And so often we’re trying to, sort of, beg, borrow, and steal, we’re using soft power, right? “Well I hope if I just have enough meetings, and I wear them down, and they hear me complain about the fact that our API is broken in this place they’ll finally fix it.” They will not. That’s the answer. They won’t. It’s not because they’re bad people. Maybe they are, but mostly they’re not. It’s not because they have bad intent. It’s because the process hasn’t been defined and when it’s undefined you cannot win, right?
And I look again at the analogue of a marketing team, a sales team, right? How did they interface with product? And then, you know, we don’t all have to emulate sales in every way, but if you think about salespeople eventually they bang that drum loud enough, they get the feature they want or something that scratches that itch that appeases their demand there. And we should be able to expect at least that same level of accommodation.
This is my mastery of word wrap. The open lines to communication to marketing I think is so key. There’s something interesting about the fact that many, many times dev rel does either report our dotted-line report into marketing. Most often what we find is that’s where you have to budget from. And yet, if you say, “Well, we wanna know what your schedule is or the stories you’re about to tell. What are the narratives we’re doing? How do we make sure that dev rel is incorporated in the centre of what you’re doing as opposed to at the very end let’s sprinkle some dev rel on it?” which tends to happen.
This is about planting that flag as well. And, in talking to a lot of you, one of the things I, sort of, want to reflect back is nobody thinks this is working great. I don’t mean that in a negative way, but nobody thinks, “You know, marketing really is totally in sync with me, and they ask us first and they build dev rel in the centre of their message.” Not one organisation…I hope there’s exceptions here, like I hope I’m wrong, but for the most part almost no organisation that I’ve talked to has the dev rel team said, “We are top of mind when marketing is making decisions about audiences they wanna communicate with or about who they treat as authoritative in crafting their messages.” This will change. This can change, but today that’s where we’re at.
And this one’s near and dear to my heart. The right tools designed for the job. I’m struck by having, sort of, done my time in marketing and sales and these other teams. If you look at sales and the level of detail and measurement and metrics of what people do on those teams, you can tell when somebody takes a coffee break on a sales team by looking at the spreadsheets, and the outputs, and the reports from Salesforce or whatever they’re using, right?
And the marketing team has, like, you know, HubSpot and they know how many e-commerce abandons happen in the cart. Like, they’ve got this, like, down to the hundredth of a decimal point detail over what they’re doing, and then you look at dev rel practice, and we’re just guessing, just throwing darts at the wall, right? Just, sort of, saying, you know, “How many people tried our API today?”, “Some,” right? “How many of them succeeded?” “A bunch.”
And that’s a hard way to work, and this is where honestly I have the most self-criticism. This is where we’re our own worst enemies about giving every other department ammunition to say, “Theirs is the budget to cut. Dev rel is the one that should be cut.” And why? What have they shown? Where’s their numbers? Right? Is it up into the right? Is it flat? And you say, “There’s no numbers at all.” It’s like, “We’ll that’s a tough argument to make.”
And, you know, the interesting thing is, marketing teams that are good, they can show the number going down and it’s not headed the right way and they’re like, “Well, let me tell you why. Let me tell you a good story about it.” And they’ll still make the case for why…you know, I always joke, sort of, like, marketing is like policing is in the US, if crime is going up, you need more police, but if crime is going down you need more police. And marketing, sort of, works the same way. And I don’t want us to be, you know, always saying dev rel just has to get more and more money, but I think there’s a way to say, “Let’s defend getting resources based on metrics and measurement.”
And then a couple of things which, actually we’ve had a great conversation about today that I’m gonna go through quickly. One is explicit ethical and social guidelines, just setting the rules, putting them in writing, the same reason we have a code of conduct in our communities and in our code. It’s such a powerful tool to be able to do the right thing. I’ve been really inspired and heartened by seeing how many of you have given voice to this and articulated this today and in your work by making sure that’s on the list.
Similarly, support for building inclusive communities. This is money, right? This is resources. This is flying to the people that you wanna reach, flying to people that you need to reach to your events, being able to invest and actually doing outreach as opposed to, “We held an event and they didn’t show up and why didn’t they?”
This stuff I think a lot of you have become, you know, as all of us have much more fluent in the past several years on what’s needed to do this, but being able to say, “This is part of the work. Without this you cannot succeed at doing the work or the work will be compromised,” is something that I think we’ve, as a community, gotten a lot better at and we can support each other in, sort of, fighting for.
This is the one that I get the most positive feedback on but it’s all in DMs. Nobody wants to say it publicly, distinction from sales engineering. Sales engineering is a noble profession, an important and valuable one. It is different to dev rel. It’s different. It’s different. Now, maybe you work closely with them. Maybe you have some fluidity in smaller teams where people switch back and forth between those roles, but being clear about what those boundaries are, and especially because compensation is different.
There are people that like to do sales engineering because they like to be compensated like a sales team is. Sometimes it’s a whole different structure. Being able to set those boundaries is critical to succeeding. If you don’t define this, the sales team will treat you as de facto sales engineering. Why? Because they can. Because they have metrics and they actually have a budget. And so this is one of the things where it’s just is about getting it in writing, making it clear, setting expectations, and being able to move forward.
Resources for your professional development, right? What we do so much of the time in dev rel is help others develop their professional skills which is great, but events like this, which is a rare and special treat, are where we get better at the practice of what we do. There aren’t too many of them. It’s not like we could go to one every week, and so being able to ask for time, resource, and that commitment to be able to do so is really valuable. The good news is all of you are on the right side of this because you’re here. What we have to think about is our peers who tried to make the case for being at events like this one and couldn’t make it.
And then finally and most importantly is this connection to a community of peers. This is this idea that there’s something special about being in a room with other people who understand what we do. Most of the time dev rel is a very solitary role in an organisation. It’s a very small team, maybe it’s one person. Almost none of the other people in the organisation understand what it is that you do, and that’s especially acute because to want to do this role you’re probably a people person. You’re somebody that’s social. You like to talk to people. That’s why you do the job.
And so if you think of a community of people who are very social, like communicating with each other, and work in organisations where they almost certainly will not have someone to talk to about what they do, what’s the likely outcome of that scenario? The only way it doesn’t end in a lot of unhappiness and a lot of frustration, is if we’re all connected to one another. That’s why these are vitally important events for us to be like this in real space, in virtual space all the time. And most importantly because I think about that challenge I had of moving forward where I thought the only way in the past that I could have a future in dev rel was to leave it, and it was frustrating. It was frankly depressing.
I just couldn’t believe that something that was this rewarding and satisfying had it’s only path forward to leave the practice and hope that somebody else would pick up the ball, and also that it couldn’t be that the only other option was, well I could stay at dev rel but at the expense of the ambitions of my career or curtailing what my potential would be within the organisation.
And what I realised is that there’s a potential to take some of these principles that have come from all of us together coming with the ideas that formed this Bill of Rights. And possibly, if we all push forward with them together we would be able to elevate the practice, get the rest of our organisations, the rest of our industry to see this as a professional and serious trade, that there’s a chance then there’s a future for all of us to stay in this practice together and have no limits to what we achieve. Thank you.