Interview Intro

Richard Rodger: [0:00:00] Welcome to the Voxgig Podcast. We talk to people in the developer community about developer relations, public speaking and community events. For more details, visit voxgig.com/podcast. All right, let's get started.

Today I'm speaking to Colm Doyle, who is Head of Developer Relations at Intercom. Colm was previously in a similar role at Slack, so he knows his stuff. What's interesting about this conversation is his personal journey into developer relations, and in particular, developer relations leadership.

As developer relations has become a recognized function in the software business, we're starting to see the importance of the leadership role when it comes to making developer relations work. We spend a lot of time talking to guests just about developer advocacy, but in this podcast, we're focusing on the role of the leader when it comes to setting up a developer relations team, structuring that team, motivating the advocates and making it all work. So, without further ado, let's talk to Colm, who knows how to do this stuff. [0:01:13]

Main Interview

Colm Doyle

Richard Rodger: [0:01:14] Colm, welcome to the Fireside with Voxgig Podcast. Great to have you on today, talking about developer relations. [0:01:20]

Colm Doyle: [0:01:21] Thanks for having me, Richard. I'm excited to see what we talk about. [0:01:25]

Richard Rodger: [0:01:26] Awesome. Given all the wonderful stuff that's happening, with APIs being taken away and given back by companies that shall not be named, and given your experiences working for some of the larger tech companies, I thought it'd be interesting to talk about long-term care and feeding of APIs. So, companies – and we were just talking about Twitter as a good example – sometimes throw out APIs without thinking of the strategic implication.

Twitter famously let anybody build Twitter clones effectively, using their API. Subsequently thought that was a bad idea and then made it easy again and then took it away again: all sorts of carry on. If you were put in a position now with all that benefit of hindsight for a large tech company that had ChatGPT for example; that's maybe a good one. Open API has taken off, or Open AI. What do we do? What do you do to manage their API and their developer relations for the next 10 years? [0:02:37]

Colm Doyle: [0:02:39] Yeah, it's interesting. If your target market is people building for business or for profit or some kind of return, the big priority is stability. And there's the – as a dev rel person, you're going to be balancing stability with innovation, because they can sometimes be at odds with each other.

Because you can have a really strictly versioned API and then constantly be iterating and bumping your API versions. But then you're building up all this technical debt, which will eventually slow you down. Like you say, Twitter's thing at the start was, it made sense for them to let people build clients atop their API, so that they can, as you say, build Twitter comms or supplant the Twitter UI.

But at the start, Twitter didn't really have a UI; it was all through SMS. And you could argue that Twitter wouldn't be what it is today without particularly their iOS clients. But they were bottling a unique moment in time, but like you say, with the benefit of hindsight it was a terrible move. When I worked with Facebook, our APIs were pretty clear from the outset, that you weren't to use them to build a Facebook clone. Because we were really passionate about controlling that experience and not letting other people be – get between us and our users.

So, you have to advocate – because you're advocating for your developers, and that doesn't necessarily just mean, "Build this feature," or "Build that feature" or "Fix this bug." But it also means making sure that the business has some kind of strategy around their APIs. Because if you don't have – you have to have a strategy if you want to be a platform. If you just want a goofy hook for someone to do something, then you can throw up an API or two.

But a platform's not a platform without a strategy and being able to explain to developers why they should invest their time and energy in building a top-tier platform. And for companies like Slack, that was – there was momentum there, and we were getting – we were a big footprint, particularly in tech.

So, if that was your target audience, we were the elephant in the room. You couldn't not integrate with us. So, that was – the strategy was for the companies integrating into Slack was like grabbing onto the side of the rocket ship. But Slack, to be fair, had APIs from the start, and it was always a big part of the Slack narrative was- [0:05:33]

Richard Rodger: [0:05:33] Yes, exactly. [0:05:34]

Colm Doyle: [0:05:35] -it was like, without integrations, Slack was admittedly a lovely, very fully featured client, but it was WhatsApp for business essentially, if you didn't have those integrations. Because the idea was, if you spent all your time in Slack, then your information should come to you.

And the only way we were going to achieve that – because we couldn't go and build into every single service that existed. The only way to do that was to create this symbiotic relationship with developers, whereby they would give us the data to put in front of their users, and we would increase the stickiness of their service or something like that.

So, it's really about being clear that developers are as much of a persona, because businesses love to talk in personas. You have admin – so, at Intercom, where I currently work, we have a notion that there are people who administer your Intercom incidents. We have teammates who are the people answering the conversations.

There are what we call end users, who are our customers' customers. And these are all core personas, but developers are a persona there as well. They are as important to the business as the teammate or the admin or the whatever. And Slack was the same; it had admins and it had users, and developers were a core persona from the very start. [0:06:56]

Richard Rodger: [0:06:56] You could say – yeah. You could say – that's two places that you've direct experience of: Slack and Intercom. There is a strategy, there are developer personas. But there's thought gone into – we're going to have an API; we're going to have developer relations, and there is a long-term commitment to stability. [0:07:12]

Colm Doyle: [0:07:14] Yeah. I'm sure there'd be many Slack developers who would argue with that. Joking aside, a concrete example, Slack doesn't version its APIs, so there wasn't like – you can – if you build an iPhone app, Apple has really clear guidelines on how long an API version is going to exist. So, if you hook into such and such an API, your iPhone app will work happily until at least this version. Now it's slightly different because iOS is an embedded product, but you can see the same thing.

At Slack, there was constant requests for versioned APIs, because people wanted to just turn the thing on, and if they didn't want to adopt a new feature, then they didn't have to. We always wanted to do it, but the – business needs must etc. And we tried to mitigate it somewhat by avoiding breaking changes and having really long breaking change deadlines, but yes, I think we were a relatively stable API. [0:08:24]

Richard Rodger: [0:08:26] Compared to Twitter, which was one of my first experiences of integrating with APIs and using API – which in its day was a great API and it had great docs. But it always felt accidental; it didn't feel like a thought-out strategy per se. Whereas now, developer relations is an actual thing, and professionally, if we work in developer relations, we should be advocating for a strategy in our companies. [0:08:56]

Colm Doyle: [0:08:57] Yeah. The developer's perspective – it's your job to make sure that the whole roadmap, not just your API or whatever – the developer's perspective is taken into account across the whole business roadmap. How will we monetize the API is an interesting one. Because at Slack, my manager was Bear Douglas, and we would often talk about – is platform a cost center or is it a revenue center?

Because the reality is, at any business, at some point you need to be a revenue center, because otherwise you're just a hobby. So, there has to be a clear way to make money off the platform. And sometimes, that's super indirect. At Slack, we had metrics that told us if a workspace installed a certain number of apps, then it would increase the stickiness by X percent.

So, the business strategy there was, our customers will stay around if the AWS integration is really good or the (inaudible) Time: 0:10:12 integration is really good, or whatever integration is the strategy. For others, for Apple, it's, we want to take 30% of every time you sneeze. And you could argue whether 30% is a reasonable thing. Ben Thompson at Stratechery and John Gruber over at Daring Fireball, they often have fairly heated debates about the validity of Apple's 30%.

It's a business strategy. Apple's a good example of stability because you can disagree with Apple's rules, but you always know where you stand with them, and you can – the exceptions are really well known because they're so notable. A really – Apple's not perfect; they've made some really weird decisions, but everybody knows them., because they're so random.

Twitter's thing – putting aside the technical strength of their APIs – are the payloads formatted correctly? Is the OAuth easy to implement? The biggest thing when I would think about Twitter is – and it's gotten – this has only been magnified since it was acquired – Is you just can't trust anything they say. It's like the scorpion and the fox type fable. If you build on Twitter, you're going to be burned at some point was the sense. Whether that's accurate or not – but that was always my sense.

And you look at Ivory, the new Mastodon client from Tapbots. They've clearly been building that life raft for a while, and rightly so. I don't think anyone – everyone knew at some point that the likes of Twitter, if it can tweet bot were going to get cut off. It was a matter of when, not if. [0:11:52]

Richard Rodger: [0:11:53] Yes. The – a literal sword of Damocles was hanging over them for a long time. You felt it even as a user, not even as a developer. [0:12:01]

Colm Doyle: [0:12:02] Yeah. And it was different things; it was clear they weren't investing in third party clients as a strategy, which again, it's a valid strategy and probably should have been executed from much earlier. And I know folks who've worked at Twitter dev rel; Twitter, to the best of my knowledge has no dev rel team anymore. But that was an uphill battle, particularly for the second iteration of Twitter APIs, which was I think in 2018-2019.

That was – they were just – they weren't just building from zero trust. They were building from – they had a trust deficit, that they had to pay down. And to be fair to them, I think they were starting to pay it down until the acquisition. And then, as with everything, Twitter – once the acquisition closed, all bests were off on everything. You know what I mean? [0:12:50]

Richard Rodger: [0:12:51] Yeah. The only thing left is – it has the same name; I don't know what it is now. [0:12:55]

Colm Doyle: [0:12:56] Yeah, they don't even have the same coffee machines; they all creamed off all their coffee machines. [0:12:59]

Richard Rodger: [0:12:59] Let's talk about resourcing developer relations, because it would be interesting. You were talking a lot about Apple, and Apple has infinite effective resources. So, you would expect them to structure their developer relations and the way they interact with developers in a pretty sensible way and to resource it properly. Some people do complain about Apple, but it's still pretty good overall.

Whereas if you look at Slack, they were very successful; they were extremely well funded. But they were still ultimately a startup in a growth phase and did not have infinite resources. And you'd touched on it about being a profit center and that sort of thing. So, how do you – you lead dev rel now, so how do you manage the resourcing of developer relations? In Slack, the SDKs, the documentation, was that written part-time by line of business developers? Was there a separate team? And if that separate team existed, did it report to the CTO, to the CMO? Was it its own thing? How did Slack structure that? [0:14:15]

Colm Doyle: [0:14:16] The way Slack's team was structured, dev rel sat inside product, so we reported not directly to, but up through the line of the Chief Product Officer, which I think was the right home. It's one of those neverending questions in dev rel, along with how do you measure dev rel, is where should dev rel sit in the org chart. Most companies seem to sit in in product engineering or marketing.

I would personally only ever work for a company that either led me to report directly to the CTO or up through product or engineering; in Intercom, it sits in engineering. But back to Slack. Head of Dev Rel rolled up to Head of Product, and Bear, she had – sorry Bear, was the head of Dev Rel at Slack – she had four teams reporting to here.

There was advocacy, which was my team, and we were everything you would expect of dev rel. We were the conference circuit; we were the booths; we were YouTube. We were all the outbound marketing of the platform, when it came to the technical side of it, so code samples and all that kind of stuff. So, there was advocacy.

There was partner engineering, which was a real white glove consultancy for strategic partners. It was like, we'll help you build your integration. Didn't actually write the code, but walking version – walking, talking versions of the developer documentation. Then there was a team of technical writers; they were called the education team. And they – I used to liken them to – if our developer docs were a newspaper, they weren't the journalists, but they were the editors.

So, they would write a bunch of stuff, to be fair to them, but they would also accept contributions from anywhere in the business. My team could write a tutorial and give it off to the education team, and they would give us feedback on tone, on generally the content, all that kind of stuff.

But generally, I called them the editors, because as far as I was concerned, they were the ultimate arbiters of what went on API.slack.com. And they were really good at it, and they – Taylor, who was one of the early platform hires at Slack and led that team, he essentially created the voice and tone of API Slack documentation, which is… [0:16:46]

Richard Rodger: [0:16:47] It's pretty good.

Colm Doyle: [0:16:48] Yeah, very well known. You can argue the pros and cons of some of the API documentation at Slack, but everyone – it's – is it the gold standard like Stripe? Maybe not, but it holds its own. [0:17:01]

Richard Rodger: [0:17:01] Yes, of course.

Colm Doyle: [0:17:02] And then the last team was the SDKs, and they were responsible for Bolts, which was our rapid development framework, and then the underlying SDKs, which were in Python, Java and JavaScript. Well, technically Typescript, but… [0:17:14]

Richard Rodger: [0:17:14] That's an interesting team, the SDK team. And a lot of people struggle with this, because that team needs to be composed of developers that can code in multiple platforms and languages. [0:17:26]

Colm Doyle: [0:17:27] Yeah. They were across three languages, but every one of them could get up on a stage, no problem. They could do the typical dev rel public facing stuff. That was – I want to say we used to talk about 70:30 or 80:20 on the SDK team. It was your 70 or 80%, your standard software engineer, but you need to not be – if we send you to a meetup, you need to not fall over yourself. [0:17:53]

Richard Rodger: [0:17:55] Okay, that's an interesting strategy. People struggle with SDK development, either just don't do it entirely, and it's like, there's the REST API or GraphQL; knock yourself out. Or they have – some of the clients are the good ones and then the others are sort of ropey. [0:18:14]

Colm Doyle: [0:18:15] Yeah. And at Intercom – Slack had a team of – the SDK team was about – I want to say six or seven people. And they just did three languages and they did them very well, our TypeScript SDK. We converted the SDK from JavaScript to TypeScript fairly early on, and our typings were excellent. And you could – we leaned into TypeScript as a language. [0:18:48]

Richard Rodger: [0:18:50] And it's perfect for exactly that use case, because you have typings. [0:18:52]

Colm Doyle: [0:18:54] Yeah, it's – I love typing in TypeScript; it's great. And it's this pretty excellent fusion of documentation and programming language, where you're using- [0:19:03]

Richard Rodger: [0:19:03] Microsoft wins again. [0:19:05]

Colm Doyle: [0:19:06] Yeah, schooling us all since the '90s. But at Intercom we – my point was that Slack had six or seven people, focusing really had on doing three languages, doing them well and not caring about the rest. Intercom are spread a bit thinner, so my strategy there is, I don't want to let down the developers who've come to rely on the SDKs, that could do with some love, frankly.

But I do – I don't want to do a disservice to them by pretending we're investing where we're not. So, what we'll probably lose there is, we've literally just finished creating an open API description of all of our end points. So, what we'll probably do some version of in the future is, auto – tiering the SDKs. And the tier ones will still be artisanal, handcrafted SDKs and the tiers twos will be, look, we've gone to the effort of running the open API generation script for you, but this is a generated SDK.

Which is not great, but it's better than nothing, and it's also better than creating a false expectation with a portion of your developer community, that you're invested in that particular element of their success. I would rather be – invest in the community success as a whole, by making that there's good documentation and there's API end points that allows them to build interesting integrations.

And then on the second tier, be like, "And if you use" – so, again at Slack, it was JavaScript, Python and Java. It was like, if you use one of these languages, we're going to go the extra mile for you, because the metrics tell us that most of the developers are here. But for the rest of you, we're not going to do that for you, but we will give you these things, which make it just that little bit easier to develop- [0:20:49]

[Crosstalk] 0:20:50

Colm Doyle: [0:20:51] Yeah. It takes the same – takes the edge off it. It's a little bit thing. And if we see the metrics change and more people go in that direction, then we'll change direction appropriately. [0:21:02]

Richard Rodger: [0:21:04] And should we be on the lookout for hand=built open-source SDKs that somebody that's really into the service has just decided, "I don't want to talk to any prologues. I'm going to build a prologue SDK." How do you interact – how does a dev rel team interact with those people if they exist? Do you try to hire them? Do you give them T-shirts? What do you do?

Colm Doyle: The Java – the JavaScript – sorry, not the JavaScript. The Java SDK was – there was an engineer in Tokyo. Japan anyway; I'm pretty sure Kaz is in Tokyo. Anyway, there was an engineer called Kaz who, when he didn't work for Slack, he built a Java SDK. And he was really good at it, so one day we just hired him.

And it was after we had hired him that in some meeting, we were like, "Why isn't the Java SDK now a Slack official SDK, given that we hired the guy who created it?" And everyone was like, "That's a good point." And we moved it into the repo and we transferred over the issues, and now it's considered a first-class API. You can't do that for everyone. You want to reward people who are making contributions like that.

Slack had a Ruby SDK that was maintained by the community, not by us. And the way we "rewarded" the developers of, say, the Ruby SDK, was twofold. One, we were a bit more candid with them about our roadmap. We tried to give them somewhat advance notice of what we were building and what direction we were going, so that they could decide themselves how they wanted that to influence the SDK's roadmap.

The other way is, sometimes – I can't remember, to be honest, if we did this with the Ruby SDK, but we definitely did it; it was almost monetarily. We would say, "Look, thanks, here's $10,000 or $20,000 or $5,000" or whatever. One thing SDK maintainers – it is important to share your community some love, but an SDK maintainer can't take Slack socks to the grocery store.

So, if they want swag, you give it to them, but by and large, if they're doing you a service and you want to demonstrate value, you don't do that with little tchotchkes that you'd get at a conference booth. There's also the whole environmental impact of swag; at Slack, we were trying to limit the amount of swag we created, because who needs another tote bag or pen or whatever. [0:23:47]

Richard Rodger: [0:23:48] T-shirts. T-shirts are fun. [0:23:50]

Colm Doyle: [0:23:50] Yeah, we had a – there's – we had a rule at dev rel at Slack pre-COVID that was – it just didn't become as relevant after COVID. Was that we wouldn't produce swag – the team – the swag that our team produced, we would only produce swag that we thought had some kind of useful life. A pen wouldn't, but we had no problem creating physical books which would talk about the APIs.

Now we didn't print the developer documentation, but we printed tutorials and we printed – they were more pros guides. Because we thought, that has a useful life beyond it. We kept doing stickers, because stickers are relatively low impact, and we kept doing socks, because they were our thing. But we got rid of fidget spinners with the Slack logos on them and all the pens and tote bags and all this kind of stuff. [0:24:39]

Richard Rodger: [0:24:43] Let's continue the theme around leadership in dev rel. In some of the work that I do, I tend to have to integrate with a lot of third-party APIs. In one recent project, we had 15 integrations. And the difference in developer experience between the top tier and the bottom tier is incredible in terms of pain. But the interesting thing is, some of the bottom tier companies, literally their entire business rested on an SDK integration. Because they were doing specific things, let's say around specific user flows.

So, here's a scenario for you. One of those companies gets new leadership and figures out, we can move the needle up quite a bit if we upgrade our developer relations to be as good as Stripe without even having a developer relations team. And you're hired, let's say, to set it up and run it, with appropriate resources. What do you do What does day one look like? What does – what happens after 30 days and 90 days? What's the – how do you go from zero to Stripe, let's say, over the course of a year? No pressure. [0:26:12]

Colm Doyle: [0:26:13] No pressure. Stripe is interesting because it's a developer-first product. It's funny, because they have a dedicated developer relations team and they're incredibly talented individuals. But in a way, the whole company is the developer relations team, because if you think of what I said earlier about the business having personas and developers being a persona, you don't have to have that fight at Stripe. You know what I mean? [0:26:47]

Richard Rodger: [0:26:48] Yeah.

Colm Doyle: [0:26:49] So, if you're hired into a company where it's – first of all, you figure this out before day one; you figure this out when you're talking to the company about a role, is figure out if it's just a whim someone has taken that having a developer relations team is a good thing, or if they actually understand in their bones what they're getting into. [0:27:06]

Colm Doyle: [0:27:08] Let's take that as a given, that somebody has a company and they get it. They're a former founder and they see the competitive advantage of doing this right. [0:27:18]

Richard Rodger: [0:27:19] Yeah. Honestly, the first thing to do is find your developer community, assuming it exists. If it doesn't exist, then it's a slightly different strategy, but if you're assuming there's an existing developer community there. And go figure out what the company's doing wrong, and don't necessarily listen to your PMs or your EMs or whatever. Sorry, product managers and engineering managers. Go listen to developers, because your developers know all the weird nooks and crannies, and they know – don't call it API method; call it this way instead.

And figure out – there's a bunch of undocumented hacks and stuff. Docs are always the place everyone should start. They're – there's a lot of different learning styles you want to accommodate. When I say docs, I include YouTube and code samples. But if you don't get that right, you're building on a shaky foundation from the start. So, it's critically assessing what enablement materials you have out there for developers, be they YouTube; be they code samples; be they reference documentation. And just making sure that's bullet proof.

Stripe's developer relations experience – there's a spectrum of how good they are at everything. It's generally assumed that the Stripe docs are the gold standard for developer documentation. That's – I don't think I've ever met anyone who's a dev rel professional who would disagree with that statement. They might argue whether they're first or second place, but they're definitely on the podium, for want of a better phrase.

But then you look at – Twilio have the best demo; the Twilio five-minute demo is famous. It's this thing where – it was funny. I was chatting with someone who used to work at Twilio recently. And I told them that the first time I saw the Twilio demo was in 2012. And I still remember the room I was in; I still remember what the event was. I remember every moment of that because it was such an incredible demo.

And the basic gist of it is, they have the phone number of some percentage of people in the room, so live onstage, they send everyone in the room a text message. And then they call a handful of them. And it's absolutely incredible, because the whole room lights up. So, they have the demo thing and they're doing the value prop thing. So- [0:29:54]

Richard Rodger: [0:29:55] That's the wow moment.

Colm Doyle: Yeah, they get to the wow moment really quickly. And I struggle with every platform that I work on to be, what is my Twilio five-minute demo. And slowly and surely over the course of my career, in the 10 years since I saw that demo, I've decided that I'll never match it. It was like lightning in a bottle and you just can't recreate it, so I just try and get as close as I can to it.

But what the Twilio demo is great at versus raw documentation is, like you say, it gets people to the wow moment. I'm told, having never worked at Stripe, that the Collison brothers had a rule that there had to be code on the home page. You had to – and you had to be able to run an API call pretty quickly. It was a thing famously where they had – they always had Corel commands. You could copy paste on the home page. I don't know if it's still true, but that was- [0:30:50]

Richard Rodger: [0:30:49] Yes. Send me the code.

Colm Doyle: [0:30:52] It was true in the early days. At Facebook, one of the dev rel leaders, a guy called James Pearse, he measured conference presentations in times to fixed-width font. So, it was, how far are you into the presentation before you're showing me code samples? [0:31:07]

Richard Rodger: [0:31:08] That's so true.

Colm Doyle: [0:31:10] Because that's-

Richard Rodger: [0:31:10] It's – absolutely, right? [0:31:11]

Colm Doyle: [0:31:11] But what the code sample things des is, it makes it real. It makes it – it sells the value prop of developers. It's a call to action for developers; it's – because if they're looking at the docs, they have to decide, why should I do this? What can I do with this API? I always loved – I used to be an iOS developer and I always loved developing on iOS, because it was so viscerally real.

It was like the software's on my phone right now, and it provides value instantly, and you have to figure out how to do that with your platform. And candidly, it's a struggle at a company where developers aren't your target audience. At Slack, a lot of people who built on our APIs were developers, because by and large, if your company uses Slack, the first team to adopt it were your technical- [0:32:03]

Richard Rodger: [0:32:03] Your devs, yeah.

Colm Doyle: [0:32:05] But at Intercom, the people building the integrations, they're not teammates; they're not the people who are on the front line of the support experience. They're not – not always. There could be – it's – there's exceptions to every rule. But by and large, they're not going to be the ones who directly benefit from their work, so you have to be a bit clearer with them. [0:32:27]

Richard Rodger: [0:32:28] More of a challenge, because there's more- [0:32:29]

Colm Doyle: [0:32:29] 100% more of a challenge, but- [0:32:30]

Richard Rodger: [0:32:31] But you're lost, right?

Colm Doyle: [0:32:32] Yeah, you have to be clear with them about the value they're delivering, because it's so indirect. Whereas, like I said, Slack or for say, Apple or Stripe or the AWS team, they can feel it. In AWS, AWS Amplify, which is a framework for helping you rapidly build applications, it's – it makes the person who's writing, whose fingers are on the keyboard, it makes their life easier. And you have to- [0:33:00]

Richard Rodger: [0:33:01] For a while.

Colm Doyle: [0:33:02] For a while, yeah. But you have to make that. If you're in a company where developers aren't your target – sorry, if you're working in dev rel, developers are always going to be your target audience, but they're not the business's target audience. It's a bit more of a journey, and you have to sell the value prop a bit more. [0:33:19]

Richard Rodger: [0:33:21] And your Intercom situation is probably more normal. It's probably – probably the majority of dev rel happens in this type of context, where there are more players. [0:33:30]

Colm Doyle: [0:33:32] Yeah, I look really jealously at people who are – they're dev rel for dev tools companies. [0:33:40]

Richard Rodger: [0:33:41] Get it right.

Colm Doyle: I think so. I wouldn't be as insulting as to say it's dev rel on easy mode, but it's like you yourself are the customer, so you- [0:33:51]

Richard Rodger: [0:33:51] Exactly.

Colm Doyle: -[0:33:51] entirely understand the product a bit better, so you're able to sell it better for your – to your peers. It's – so, it's a bit more of a challenge to be at an Intercom or a HubSpot or a Salesforce or whatever. [0:34:06]

Richard Rodger: [0:34:07] Just getting back to our original dev rel refactoring, would you replicate the mini-org structure that you had in Slack, with the docs team and the SDK team and the advocacy team? Was that a good structure? Did it work? [0:34:23]

Colm Doyle: [0:34:25] I think so; I think for the size. The overall dev rel org at Slack was about 30-ish people; all the teams were six or seven-ish people. I think it worked. The closer you can embed into the people who are building the first-run experience for your developers, the better. So, we owned the SDKs; therefore, we could iterate much faster on them. We weren't beholden to another team's roadmap. Similarly at Intercom, I'm the head of dev rel, but I'm also a senior engineering manager, and my team own the developer experience at Intercom. So… [0:35:08]

Richard Rodger: [0:35:09] Yeah, so there's (inaudible, 0:35:09)-

Colm Doyle: [0:35:10] Yeah. I am both the advocate and the person I'm trying to convince, and I just have to wear two hats all the time. Which – I don't always win in arguments with myself, but I think it works. The SDKs are an enablement material in themselves, because they make it easier.

At Slack, we pretty aggressively cared about – and we had metrics to back it up, that if we didn't – if you tried to build an app and you didn't successfully get someone else to start using it within – I want to say it was 21 days – then you would abandon it. You wouldn't bother using it. You would just give up on it and it was a hobby project you never worked on.

So, we were – we tried to pull every lever we could to make your app successful in the first couple of weeks. Now that didn't mean you had 10,000 users in the first three weeks, but you at least had your peers on the team using it and starting to get value out of it, because then you would continue to invest in it. So, having the SDKs and the docs and the partner engineering work and the advocacy under one house meant we had more levers to pull. And we were the masters of our own destiny a bit more. So, I think I did that. You can't underestimate the value of a really good technical writer. [0:36:30]

Richard Rodger: [0:36:31] I would not; I would indeed not.

Colm Doyle: [0:36:33] We have a literal poet on our technical writing team in Slack. She was – she moonlighted. She moonlighted as a dev rel person; her real calling was being a poet. So, you have your – a good technical writer should always be one of your first hires, definitely in your first three. [0:36:53]

Richard Rodger: [0:36:54] Most undervalued role. [0:36:55]

Colm Doyle: [0:36:56] Yeah, but the thing about a technical writer is, like I said, at Slack, we treated them like editors. They wrote – don't get me wrong – they wrote tons of docs from nothing. But the real value was using them as a force multiplier for other teams. Because they had – folks who really deeply understood good information architecture, which is important and often overlooked. Because if you – you can have – you can write incredible docs, but if nobody can find them or they're not structured in the right way it doesn't matter.

Stripe does this really well; Twilio does this really well. Zendesk, one of our competitors, does this really well as well. They – when you land on the page, there's a really clear guide to get you to the information you need. Too many people just say, "Well, we put search on the docs," or "Google will do that for us." And they- [0:37:46]

Richard Rodger: [0:37:47] Yeah, that doesn't [0:37:47]

Colm Doyle: [0:37:48] They abdicate that responsibility, and it's just not as good as doing it yourself. At Slack, the team, the docs team thought a lot about, what was the user journey through our documentation. [0:37:57]

Richard Rodger: [0:37:59] Because these days, you're up against ChatGPT and things like that, literally. [0:38:02]

Colm Doyle: [0:38:03] Yeah. We're going to get it incredibly wrong. The next interesting thing in dev rel is, how are we going to optimize our developer experience for a world where people are using ChatGPT or GitHub Copilot. I wouldn't say I sit awake at night, but I do – whenever a Copilot fires in my browser, I'm always like, "Is there a way I could be writing my code samples so that GitHub Copilot gets this right more of the time, more often than not."

And I don't even know; I haven't had the bandwidth to look at how possible it is. But it is a thing. Intercom recently launched a bunch of ChatGPT style features into the product. And I look at that and I'm like, "How can we make this easier for developers to leverage?" [0:38:55]

Richard Rodger: [0:38:56] You need to be talking to your ML teams, because goals- [0:38:59]

Colm Doyle: [0:38:59] Don't worry. I – my ML teams hate me. But it's the thing of, how can we use AI to improve the developer experience? GitHub are doing fantastic work here with the Copilot stuff and just in general. I have a reasonably cordial relationship with the GitHub dev rel team.

And they have this perfect mix of both being a developer-first company, but also, their – everyone who's a customer of GitHub is a developer. But only some of them are using GitHub's APIs, but it means that the whole company is talking about how to make life easier for developers. It's Copilot features; it's about making pull requests better; it's about all these different kind of things. They have an exciting challenge, which is interesting. [0:39:51]

Richard Rodger: [0:39:52] Colm, we need to wrap up. This has been – it's been really fabulous and interesting, particularly the leadership stuff. Go easy with the ML; don't invent SkyNet at Intercom. Try not to do that. [0:40:05.7]

Colm Doyle: [0:40:06] No. I won't try that. [0:40:07]

Richard Rodger: [0:40:10] It's – there's definitely new stuff coming in dev rel around all that, which is going to be super interesting to watch. Thank you so much. It's been fabulous. [0:40:17]

Colm Doyle: [0:40:18] No. Thank you for having me. [0:40:19]

Endnote

Richard Rodger: [0:40:20] You can find the transcript of this podcast and any links mentioned on our podcast page at Voxgig.com/podcast. Subscribe for weekly editions, where we talk to the people who make the developer community work. For even more, read our newsletter. You can subscribe at Voxgig.com/newsletter, or follow our Twitter @voxgig. Thanks for listening. Catch you next time. [0:40:47]

‍