Made by
Made by
Leslie Hawthorn
Leslie Hawthorn, Developer Relations Strategist for Red Hat, has been helping companies to understand developer communities since the early 2000s.
In this talk, recorded at DevRelCon London 2017, Leslie shares some experiences from the early years of her career in community building, and muses on the uniquely influential position of the contemporary developer relations professional.
So, good morning, everyone. It’s a great privilege to be here at DevRelCon. This is actually my first DevRelCon. I’ve never had the opportunity to attend before, and I’m deeply excited. I do a lot of conferences, as I’m sure everyone in this room does, and the energy here is palpable, which is really great, because I sometimes have conference fatigue, not today. So, I don’t know how many folks in the room have participated in the Google Summer of Code Program in one way, shape, or form. Can I see a show of hands? Okay. So about 10%. Once upon a time, I used to run that program. Following my time at Google, I spent some time in academia, working on open source outreach for students at the Open Source Lab at Oregon State University, and following on from that, I did stints doing developer relations for a couple of startups with an open source focus, and finally landing at Red Hat.
My day-to-day job there is to focus on community strategy and marrying the business of community and business so that it’s actually effective and we’re not just sort of waving our hands in the air and saying, “Metrics. We have them.” For my volunteer work, I am an advisor to Token Labs, they’re doing some really cool stuff in the IoT space, and also for Hoopy, which basically means that occasionally Matthew calls me to ask me a question, because he’s very smart, as is Christianos, they don’t really need me. It’s a great advisor gig to have. I thought a lot about this talk after Matthew and I had a conversation about what community actually means, because, as he was just saying, we’ve been in the community space for a very long time, and we’ve seen an evolution in what people mean by community. And it’s been very difficult for us, because we feel in some ways that the term has lost its meaning because it is so prevalent. And so I wanted to talk today about sort of my history in the community space, and what I think community means, and how we can more effectively define community to serve our users and to serve our employers as well.
And I decided no slides, because I really just want to tell you a story, and I sometimes think slides interfere. And I didn’t want to just put up pictures of cats, although perhaps that was not my best move, but that’s okay. Next time cats, I promise.
So, our story begins a long time ago in a universe very far away, so Silicon Valley, where I had actually grown up and naively thought that surely everyone had spent their childhood having a whole bank of computers, Apple IIes in their primary school. I was wrong, just so you know. And I had landed at Google, and I was working in their HR department, where I was a passionate advocate for open source and was running around installing Firefox on all of our HR people’s machines.
And they were very grateful, so that was quite good, which brought me to the attention of the director of the open source programs office at that time, who asked me to come on board and help him work on Summer of Code and open source outreach. So, as part of my responsibilities, I was hosting a lot of developer conferences at Google’s campus, because we had space, and Wi-Fi, and food, and other than people, that’s about all you need to have a successful event, provided everyone is ready to come together and collaborate.
And one of the very first events that I hosted was the Ubuntu Developer Summit, where apparently I met Matthew and had forgotten, because I am, in fact, getting old. So, at the Ubuntu Developer Summit, it was an amazing experience for me, because I had typically worked with open source projects where it was a room filled exclusively with maintainers, and they were talking exclusively about code and future development, and that was all very fine. But this was the first event I had attended where the event explicitly included folks who were working on the project in all aspects, so folks who were employees of Canonical, and folks who were not employees, people who were focusing on documentation, people who were focusing on user outreach, marketing, all aspects of the project.
And this was fascinating to me, because I hadn’t seen it before, and it seemed so rare in a world where almost all of my conversations were focusing purely on how was software written. You know, it was the era of the community handbook for Ubuntu, which was written by Benjamin Mako Hill. This was my first time meeting Jono Bacon, who is the community guy. And, you know, in looking around, I realised that if I wanted to describe my responsibilities on a daily basis, this concept of community manager was the best possible title, even though it was rare, because program manager effectively doesn’t mean very much.
And, obviously, that’s what I was doing. I was liaising with people to help them effectively work with Google’s open source programs office. So, I took on the moniker of community manager and started working with the other few people out there who were doing community management, because the open source world was suddenly discovering this idea that, in addition to the creation of software, we had squishy human problems, and it would be really good if someone who liked to care about squishy human problems was there to help. So, that was wonderful. And, you know, no one was really, like, understanding what a community manager did. I would effectively say that community managers at that time were product managers, but no one would have been comfortable with the name product manager, because it’s open source projects, not products.
But, you know, again, taking in user feedback, helping people collaborate with one another, helping people to set schedules and realistic goals, and effectively, you know, doing that sort of project management function with additional social interaction functions. So, fast-forward to a few years later, and we suddenly see the rise of this function called developer relations. The open source programs office at Google is actually a very passionate advocate for the creation of this role within Google, and that eventually spawned an entire department, which I am not going to talk to you about, because Odi will be on stage later, and I see no reason to steal time from the expert.
So, developer relations effectively came about, at least in my experience, because there was a realisation that there were developers who didn’t just revel in the arcane details of the software that they were creating. They really cared about teaching, and mentoring, and making people successful, and they actually at least were good at playing extroverts on TV and actually wanted to talk to people in person. This was kind of surprising, at least in the context that I came from, because suddenly there was a desire to not just send people to obscure help forums, but to actually help them in real life.
So, at around the same time as the developer evangelist, developer advocate function was growing in the industry and people were recognising the value of this position, the role of community manager was changing drastically. So, we had gone from a community manager is someone who’s doing, like, product management functions to a community manager being all things to all people. So, right now, I have dear friends, one of whom is a community manager, and her sole job is to work with social media.
I have one dear friend who is a community manager, and her responsibility is to put together a developer conference, everything from securing the venue to selling tickets. And I have one friend who is a community manager, and her sole responsibility is to set up meetups. And, according to each of these people’s employers, they are an effective community manager. So, what does that actually mean? How are you managing a community if these are your different job functions? And I would argue that we have created a space in which we have diluted the term community to the point it is meaningless.
And I think that people would actually argue that there was never any open source community, because there was no way to define the open source tribe effectively. I would suggest that that is incorrect, but that’s a subject for another talk. So, again, now we’re in the era where selling open source as a product, or at least as an on-ramp to potentially an open core business model where folks are using open source and then buying a proprietary product, has become the norm, right? And people have accepted that you can build very profitable businesses around an open source model, and I’ve also seen community being considered as solely an on-ramp for the sales process.
So, Matt Asay actually just came out with a great article in InfoWorld two days ago, talking about how the big cloud providers are really pushing their open source tools as a means to on-ramp people to their computing platforms and then, you know, ensure that they stay within that ecosystem. Which is, you know, a perfectly fine choice, but it’s definitely a far cry from my days of yore when open source was kind of come one, come all, take what you need, and go as you wish. And I also believe that considering community as merely an on-ramp to sales, it’s just highly problematic, right? One of the best tweets I’ve ever seen was from Liz Crombock, who incidentally is also active in the Ubuntu community, and it was, “Community is not an extension of the marketing department.”
And I’m not going to argue that community relations does not have a marketing function, because, of course, it does, but I think we have lost sight of the idea that in a business context cultivating community is empowering people and enabling their success. And we can’t simply focus on that as an explicit path to revenue. I’m not making any sort of suggestion that we can’t care about the corporate bottom line, that is silly. Of course, our community endeavors need to support our employers’ business functions, but if we consider community as solely a part of our sales process, we are losing out on the opportunity to cultivate a much more important and sustainable trajectory for all of technology, and for our own companies as well.
I like to think of community as more of a research and development expense, and I think of it, as developer relations professionals, it’s our research, and it’s their development. It’s an opportunity, of course, to learn from our users what they need from us, what they’re enjoying about our products, and what they need in order to be more successful. And if we are tracking solely the opportunity to generate revenue from these interactions, that’s not actually going to work, because we can’t measure when someone chooses to tell someone with purchasing authority that they really ought to buy our things three employers down the line, right? We don’t have metrics that good just yet.
So, instead of this kind of winner-take-all approach, I’m only going to focus on the people that I think are gonna cut us a paycheck at some point. I suggest that the most important thing that we can do as developer relations professionals is consider that our power is in user education and helping people to be more successful, whether or not they end up becoming part of our customer base, because they will, again, become passionate advocates for our technology. And if you make people feel good about what they’re doing with your technology, they’re going to make sure that other people know about it and are doing good things with it. So, I’m going to close with what I think is a very important call to action for all of us, and that is how many people in the room have folks who have gone to big companies, and you never talk to them again? Excellent. I see about 50% of the hands going up in the room. I have done that, where I went to a big company, and no one heard from me again.
As developer relations professionals, I think we are in a somewhat unique position, because we work at some of these larger enterprises, and even when we work at a small company, folks who work together closely often have a tendency to agree with one another and think very similarly. And this is not a criticism, it’s just a fact of human nature. And I think that one of the reasons why we are in some of the situations that we are now, where people are, for example, thinking about the implications of social media and its impact on society, is because lots of folks working together have similar ideas about the positive impact of what they’re working on, and they don’t necessarily have enough inputs from the outside to think through the problem space.
And, as developer relations professionals, we actually have the opportunity to interact with people and understand not just what they need to be more successful with our product, but also what are the implications of what we are building for each of those individuals, for the people that they love, and for our society. I cannot stress enough how important it is that our job function is to take information from the greater outside world back to our companies and to help everyone that we work with understand what the implications are of what we are building. Most of those implications, I’m very confident, will be very positive. And yet I think it is a privilege and a responsibility for all of us to ensure that we are effectively communicating what our users need, not just from a bits and features perspective, but from a creating a better world perspective. I think that that is a responsibility and a privilege, and I hope that we will all discharge it quite well. Thank you all for your time this morning. I appreciate it.