Rebooting a community

Andy Piper: Okay, so let's start off with a tweet because I work at Twitter. People love prologues at the moment, if you will. This is going to be the Rogue one of the Star Wars saga and how I got hold of the Space Station plans and the Twitter API. If you've no idea what I'm talking about, I'm so sorry. There is another Souls reference as well as my T-shirt in the rest of the talk, so apologies in advance. So a little under three years ago, I've been doing Dev Ralph with a couple of different companies before that, but I received an email from Twitter that said, Hey, we're hiring. We are building a team in London. So I ended up on a call with the chap who was hiring.

I was sitting in a hotel somewhere in South London on a Skype call late at night with this guy in San Francisco.

And I said to Jeff, because I've been a user of Twitter myself since 2007, I'm sure many of you have been on the platform for a long time. And I was aware of what had happened with Twitter's developer platform, which was some changes to the API that weren't very popular with developers. So I said to Jeff, yeah, I'm not really sure about this because Twitter hates developers. I'm going to go right out there and say it because you're trying to hire me. And he said, well, that's not true, and we're hiring you and other people like you because we want to resolve this and move forward from here. And I love the platform. So starting point for this whole talk is really, look, that was then some choices were made in the company.

I wasn't there at the time. And my role in the last few years and my team's role in the last few years has been to, as Matthew said, and my talk title says essentially to reboot and move forward and figure out how to reset and move on. So we're going to start halfway through the saga because all the best sagas start that way. And the stuff that came before is kind of in the past.

So there's a few aspects to what we've done in the past few years, and one of them was to try to find something new for developers to latch onto with Twitter and what we had as our offerings. So when I first arrived in March, 2014, we were doing a few things. We were very focused on embedding Twitter and websites. We're also trialling some stuff which was called Custom cards, which enabled people to build more interactive experiences or different content experiences inside the Twitter platform.

That was a beta, that was enclosed beta. And ultimately the company chose not to pursue it. It was difficult to maintain. But in the autumn of 2014, we released something called Fabric, which is a brand new mobile platform. Now, the interesting thing about Fabric is twofold, actually. First of all, fabric enabled mobile developers to embed Twitter content in their apps.

And that was actually the first time in eight years of Twitter having an API that Twitter owned and provided the SDK and libraries for the platform on those mobile platforms, specifically iOS and Android. Because up until that point it had just literally been an API with a bunch of rest and JSO documentation on a website.

And other people have been able to go and build experiences on top of that. And sometimes that was problematic because they didn't necessarily understand those interfaces or those interfaces would change and be brittle and people would have to try and keep up with them. Whereas by providing our own libraries, we were able to tell developers that this is a safe way of integrating with us. The other aspect about Fabric is that it was not just about Twitter and it still is not. It's a bunch of other things as well.

It's crash reporting, it's be to distribution and other things. So regardless of whether you wanted to use Twitter's APIs, there was something in the Twitter platform potentially for you. Now at this point, I need to open this because I'm going to lose my place.

So the next thing we did as part of that launch was to launch a conference series. So we started an annual developer conference called Flight, which was kind of a big glitzy event in San Francisco where the company's based. But the challenge with those kind of events, and I dunno how many of your companies have a developer conference, very big conference during the year, and I was talking to Ian from SAP during the break and he mentioned they've kind of taken their event on the road. And that was one of the important things because you can hold an event, you can invite the press, you can get a bit of media on the day, but the actual chances of that reaching developers and people who are using the tools day to day are relatively small because you really only got the attention of those people who are in the conference venue on the day after that, you need to do a bunch more marketing and a bunch more of a push.

So the thing with Flight and the follow on event, which was called Flock, where we took the event on the road quite literally, they drove a bus around the US with a bunch of my colleagues on it for three months. I think one of my colleagues literally didn't see his own home for three or four months that year.

The opportunity there was to go and meet developers face to face. And this is a key part of the story, which I'll come back to a little bit later on.

It's really important to continue that drumbeat of information and that drumbeat of what's going on, otherwise people are not going to hear things. One of the interesting things I discovered with Fabric locally here in London was when I first started at Twitter, one of my friends, Paul Johnston, some of you will know, kind of tweeted at me because it is Twitter, why wouldn't you? And introduced me to somebody who was doing something interesting as he told me with the platform. So I went and had coffee with her I, and she was building an app called Twiz, which again, some of you may have heard of, it's a restaurant recommendation app. And I said to her at the time, what's your biggest challenge with working with Twitter?

And she said, well, look, I've got to get all the data, but then you impose all these rules on us like how we present those tweets in our app. So with Fabric, they were able to pick that up and actually have ready-made tweets ready to go. And that was a much faster way for them to operate, build something new, try and do something different, try and do something to engage developer communities, some of whom were brand new developer communities, in this case, the mobile developer community that Twitter had never sought to go and engage with and give people something different and new to get interested in rather than revisit the same old discussions that have been had with the developer community.

Another part of resetting and another part of operating the team that we've had over the last three years was to build and provide some new tools. And I'm sure many of you will have had some of these yourselves. You've kind of got the kind of core things that you expect as a developer from a platform, the developer website, some way of talking to the company in our case through forums and through Twitter documentation and those kinds of things. So when I arrived in 2014, we had a Drupal based site which focused very heavily on embedding tweets and websites because that was something that we could control quite easily. I dunno if any of you have ever used, and I'm not bashing Drupal for the sake of bashing Drupal, but I dunno if any of you have ever used Drupal as a forum type environment. Yeah, one or two hands in the audience.

It's really not built for that. It's a CMS and it's really, really not nice to use as a modern kind of forum software.

So this is what the forums looked like back in 2014 when I joined. Now there were a couple of issues with this. First of all, these things were spammed all the time. So myself and one of my colleagues in Japan every morning would spend probably half an hour just going and deleting a bunch of spammy things about witch doctors and weird stuff because there was no inbuilt way of stopping that. Now secondly, we had a bunch of categories on here, rest APIs, authentication, things that made sense, but we also had a category called feedback. Now, now feedback's lovely, everybody loves to hear some feedback, but unfortunately feedback had become, by this time kind of place for people to just come and rant about Twitter in general.

I don't like the new Twitter layout, Twitter layouts. I want the old layout back, give me the new layout's.

Awful. Give me, and I won't even tell you the kind of stuff we got when we changed stars to hearts. It was the end of the world. So look, it had become problematic. The people who had been there before hadn't paid so much attention to the forums. And for me, forums is where I live half the time. I'm an open source person. I've done a lot of work in different communities over time, and the forums are where people are talking about your products and giving you a lot of useful feedback, technical feedback if you can manage those conversations because unfortunately they do need management.

We need to keep things on topic. We need to keep people paying attention to the purpose. So we took all of the content from our original Drupal instance and we worked with the folks at Discourse who now host our developer forums for us.

They migrated that content over Before we relaunched this, we also did some thinking about what those categories were. We did some thinking about how to keep the discussions on topic. We put in place a code of conduct or some guidelines about how to behave, how we expect people to engage with us. Don't just start flaming each other or shouting abuse at us as some people obviously want to do sometimes because sometimes they get frustrated if things don't work the way you want them to and you are not prepared to put in a bit of extra work, you're going to get angry. I know that I had that same feeling myself sometimes with products.

We also scrubbed, I'm sorry to say, but for good reason, we scrubbed all of the inappropriate language and content from the old forums before we relaunched that content in the new forums.

And the reason for that is because if you come into these environments, as I'm sure many of you're aware and see that kind of language or behaviour, then it's something you may feel is something you can emulate and you can copy and that we just decided was not appropriate. It was not helping anyone. And it's also off-putting to newcomers who have a simple question to come and see these people ranting about a topic. This course is great. It's got some really great, if you're not familiar with it, it's built by the same folks that built Stack Overflow. It's got some great moderation tools. It's one click to flag or delete spammers or mark things as off topic.

It's been very, very good and helpful for us. Now, we've already spoken about some other things today, such as the perennial battle with allowing slack through a corporate firewall that's entertaining.

There were already IRC channels for Twitter, API entirely owned by people that had all left the company as channel ops. And literally it's taken me until this year to actually get control of one of those channels. But the fact of the matter, we don't have the resources to spend all of our time in IRC or Slack or those other places. Unfortunately, as a team, we just don't have the capacity. So we monitor those. But the thing that we monitor most carefully, funnily enough, is Twitter.

And Twitter builds quite a cool thing called TweetDeck in our office in London. And TweetDeck lets me have a load of columns that have advanced searches where I can look for references to the Twitter API, things being broken, things being annoyed and upset, and we can respond to people. So simply by engaging our own product and using that more effectively, we found that really useful. By the way, getting rid of the native apps was a bad idea. The tweet deck. Yeah, I'll pass that along. Thank you. Good feedback.

Which means no one can just use the forum. Yeah, just come and rant about it on the forums. It's great. Don't worry. Anybody use Reddit for developer support in the room at all? Just curious. A couple of people. Yeah, our Twitter is fun.

I do pop in there at least once a week. It's usually people trying to figure out how to spam us or break things for fun. But stack overflow obviously, as many people have already mentioned, is also a core thing to monitor in terms of engaging with the community. Better samples was the other thing. So we started a samples gallery on GitHub, so again, we could provide code that showed good ways of using the API. Now, Twitter's been around 10 years and people assume it's a huge company. It's not huge. There's quite a lot of us, but from the developer relations perspective, we're a relatively small team and therefore how we actually manage to scale this effort out is really important.

So when I joined, the team was primarily North America based. There were two of us, three of us in London, and we were hiring for Asia and for South America.

It is also important to note that I've mentioned the time before episode four, there were people, excellent people at Twitter doing developer relations prior to my arrival as well. So it's important to draw a line between decisions that were made in the company and the people that were doing the work to put all the documentation out there. In fact, when I was editing my notes for this over the last couple of days, Evan oes started doing its contextual thing and saying, are you talking about Taylor Single Terry who now runs developer relations at Slack? I'm like, yes, I was because he was awesome and he was at Twitter.

As we grew as a team, we chose to take the Google route in that we had developer advocates. So the people like myself that hand wave in front of audiences, spend time in forums, build sample code, and also partner engineers because we have a series of organisations who we have tighter integrations with who need a high level of commercial support.

That has enabled us to give a lot more focus to our efforts as well. We were able to build out those functions around the world in different ways. Another way that we used to scale was to after the first year of having these new forums, we were able to actually delegate and nominate some of the more engaged community members to be community moderators with us. And that gave them some opportunity to get a little bit more trust with us. We trusted them and to help us out a bit more.

And the final part of all of this is relatively new, which is that about a month ago we announced Twitter developer communities. If you're familiar with the Google developer groups, this is a somewhat similar programme. But the idea here is we have individuals in different countries, many of which we don't actually have physical presence, especially in terms of developer relations, including Kenya, Italy, et cetera, where they are now running their own developer meetup groups.

And in the course of just a few months before we formally announced this and just afterwards, we're up to over 4,000 members of those meetup groups that have probably a quarterly meetup. So that's been a very, very useful way for us to scale out our efforts.

Again, it's important. This is a quote from Biz Stone, one of the co-founders of Twitter from a product chat very recently, just last week. It is important to manage those communities or help them to grow in ways that are beneficial to both them and to you. It's important to maintain contact and give them information and help 'em understand where things are going. The biggest problem and biggest challenge that I have had in the last few years has been this one because we're all familiar with this. If we lose our trust in someone or something, you're going to think twice before giving it back to them.

My approach with working with developers in all of my jobs, especially specifically in my current one, is just to be as honest as possible and open as possible with them. And unfortunately, no matter how hard we work on a one-to-one basis, there are going to be some people that are going to have a feeling that there is nothing there for them. We can't help them. They're not interested in working with us. So how have I gone about rebuilding this? Have we gone about rebuilding this? We've travelled as all of us do developer relations. That's what we do.

We get on aeroplanes and hand wave in front of audiences, but have one-to-one honest conversations with people in public.

Strive to be humble, strive to be honest, say sorry, when we screw things up or when people feel aggrieved, empathise. It's all the words we're going to hear throughout today I'm sure, because we're all in this together and we're all in the same industry. My old friend Matt Webb, Jen Mon, formerly of Bergen and other amazing things said to me, I had a chat with him shortly after I started at Twitter, and he said, all of your emails to developers relating to platform notices should always start with the words. Thank you for building on our platform. Because you need to show that gratitude to developers. You don't just want to go and say your application has been suspended because you should say thank you for spending time and investing your time and effort on the platform. And I think that was excellent advice.

Consistency is really important in messaging and approach. And anybody here familiar with the word patience, kind of a big deal in our industry. But despite all of that, and again, apologies for those of you who haven't obsessively been watching the Rogue One trailers on repeat for the last three months, I'm looking forward to my midnight showing next week. In spite of all of that, there's a good chance that we are never going to win some people over. So success factors, don't ask me about measurement because I'll just jump on you. For me, there have been some key successes. There are people that I know and have known whose products I have used in the Twitter developer community who really hated on the company when I joined three years ago, and now they're friends of mine and they have a better understanding of where we're going as a platform and they're allies.

And for me, those two or three individuals, specific key individuals, becoming friends and trusting me and trusting us has been a key change.

And that for me is an important success metric. I've already shown you the scale of participation in our developer communities is just getting off the ground. But for me, from nothing when I started in terms of having those meetup groups out there, that's huge. And having an engaged set of people in our forums is huge. And I'm not going to throw up all of these statistics about number of instals of fabric and so on, because those are somewhat misleading in some ways because they're not always going to be talking about Twitter, the platform. They're going to be talking about mobile tools. But regardless, we've got millions of instals of those SDKs, which shows that people are interested in what we have to offer.

So just to finish off for me, the role of a developer advocate.

And for me, the characteristics of being a developer advocate are these in winning back communities. Be passionate, be patient. I've lost count of the number of times my colleagues. Tell me how patient I am, particularly in forums and be yourself. Be authentic, as Jess was saying first thing this morning. So I say the end, but of course this is not the end because all of you in the room, I'm still learning, we're still learning, we are tuning, we are discovering, we're thinking of new ways to do things. We're finding new medium in which to engage developers, and we're always looking to improve. So this is not the end.

I haven't spent three years at Twitter and said, right, that's it. Community rebooted, we're done. Now that's nonsense. This needs to continue and all of our jobs need to continue in order to keep up that momentum. So thank you all very much for listening. I hope that's been useful. Introduction to what we've been doing.