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. 

‍

Let me introduce you to Sid Maestre of APIMatic. We had a really question-generating interview. We talked about API governance; we talked about maybe that the three Cs of developer relations need a fourth C, which is that you have to be cross-functional. 

‍

And we go deep into the weeds on whether documentation should be generated from annotations or whether documentation should be generated from the specification. Lots of good questions from the practice of developer relations. And we're only, as a community, starting to feel our way into the answers. All right, let's talk to Sid. [0:01:00]

‍

Main Interview

Sid Maestre

‍

Richard Rodger:  [0:01:01] Sid, welcome to the Fireside with Voxgig Podcast; it is great to have you here today. And we're going to talk about APIs and SDKs and making them do what you want, building them, all that sort of stuff. But could you start by telling us who you work for, what they do, and let's talk about building APIs. [0:01:20]

‍

Sid Maestre:  [0:01:21] Sure. Thanks for having me on, Richard. My name's Sid Maestre; I'm the VP of Developer Relations at a startup called APIMatic. We've been around for quite a while, at least eight years, and we were founded out of New Zealand. And I met the co-founder many years ago. And I've been working with open API specifications and generating SDKs at my previous companies. 

‍

And I joined APIMatic about six months ago, so that I could help them raise awareness about how you could automate building some of your developer experience, specifically SDKs, a developer portal that goes along with it, that has SDK-specific documentation, runnable idiomatic code samples that I can – I can explain what we mean by idiomatic if you're not familiar with that term. 

‍

And the portal has what we call an API playground, which is an interactive API explorer. So, you can allow your developers in your community to come to your docs and drop in an API key and start making API calls directly from your documentations. Which is pretty interesting way to allow that evaluation of your APIs. Before they've ever downloaded a sample app or an SDK, they can experience and modify the payloads and see what kind of responses they get back. So, I'm really excited to talk about everything developer experience today with you, and thanks for having me. [0:03:08]

‍

Richard Rodger:  [0:03:08] Awesome, okay. So, you guys – it's an API SDK in a box. I come to you guys and you'll effectively generate all the stuff. But the first question that comes to my mind is, where does it start? I've built my startup and it's got a website and mobile app. And we're past the MVP stage and I have a couple of good devs and they've built a pretty robust system. 

‍

We've – I don't know – we've just closed our series A. We've got our 20% month on month, and now we're dealing with enterprises and they want to do integrations and we don't have an API. But we still have a system that has a huge amount of technical debt. So, is that the place? Is that the sweet spot where you guys come in? 

‍

That you help me – if I'm the CTO of a company like that, you help me go from my tech debt laden system. Build an API around it; generate SDKs for everything from iOS to Rust and have wonderful documentation. Just walk me through the process. I've got this problem. CEO says, 'I want to integrate with Salesforce and where's the API?' Where do I start? [0:04:33]

‍

Sid Maestre:  [0:04:35] We are a little bit further down the development chain. I would say our customers tend to be a little further along in the process. Because when you're series A, you're going to need to build – we don't build the API for you. I'll just – I just want to make a clarification there. The companies that come to us have an existing API. They might have some API documentation that they've handwritten perhaps. Or they might have generated it from an API specification like Swagger or Open API 3. 

‍

And the developers are showing up and they're getting this laundry list of RESTful end points that they can interact with. And they're saying, 'Okay, what else – how else can you help me? Your first couple developers that come along, they're willing to write those REST API calls from scratch. And they're willing to trawl through your documentation to understand how to authenticate and what the error responses are and how to handle them. 

‍

But as your community of developers grow and your objective is to onboard and accelerate that API integration, shorten the time it takes to integrate. And you're getting a broader pool of developers of different skillsets who learn in many different ways. You really need to think about what you're you can do in your Dx, and that's where I believe SDKs are a competitive advantage. 

‍

We've found a lot of companies in the fintech space because they are so focused on driving transactions, API calls, volume through their APIs. They appreciate the value add of SDKs combined with code samples that are runnable. You just copy, paste that code sample and you can start building production level code with the code samples that you're getting. And that's the sweet spot that we're finding a lot of success in. [0:06:52]

‍

Richard Rodger:  [0:06:54] Okay, I get you. So, I've built my REST API or GraphQL or something else, perhaps. Do you guys have tooling that automates the analysis of that, that then generates things for me? Or is it more of a service engagement? [0:07:12]

‍

Sid Maestre:  [0:07:13] Yeah. What we have – we're purely REST based right now. We have had some customers ask us about GraphQL, but that's a whole other animal. And so, we're focused – yeah, we're focused on delivering high quality SDKs for your developers who are using TypeScript or JavaScript; it's kind of the same thing. Java, PHP, Python, Ruby, C#, and we actually have our seventh language, Golang, which is being used by some initial customers. And I – we also are working on a swift SDK. So, we've got eight languages where we're trying to cover there. 

‍

And what will happen is, when you initially come to us with your API spec, you'll probably log in through our portal. You'll go to a dashboard and you'll create your – you'll upload your API definition, generate your portal, generate those initial SDKs and download and experience what the SDKs are like. When you go to production, we have a team that helps onboard our customers, because there's quite a lot of tooling that you can take advantage of. 

‍

We have the – we have our own APIs, so if you want to build the creation of your SDKs and updating of your developer docs through your continuous integration CICD pipeline, you can trigger through GitHub. Every time I make a change to my API spec, I now want it to go and call APIMatic's APIs and generate a new portal and generate new SDKs and publish those to the package management systems so it's immediately available for developers. So, there's a whole tooling aspect that we can help automate as well. [0:09:14]

‍

Richard Rodger:  [0:09:19] And in terms of the people that are coming to you, we both know developer relations has now become – it's a critical thing for a lot of companies that have developers interfacing with them. Have you seen things change, let's say, in the last couple of years, where what you do and the things that you help companies execute on have become essential? [0:09:48]

‍

Sid Maestre:  [0:09:50] Yeah. I think that – just on my background. So, I started out – I'm self-taught developer. A lot of folks, I think, have fallen on this path where you fall in love with technology and you start learning – back when I was doing it, it was a lot of books. And them more online resources, yeah. So, I was type – I was retyping code samples from books when I started out. And I got a good decade under my belt building ecommerce systems and content management systems, all those sort of things.

‍

And then about 12 years ago, I started running my own usergroups and meetups because I craved that connection with community, which led to a recruiter from PayPal approaching me to ask if I wanted to be a developer evangelist. And I had seen developer evangelists speak at conferences and I was so impressed by them. I thought I could never do that, I'm not that smart; I'm not that talented, is what I thought to myself. 

‍

So, when this recruiter identified me for my community work, I thought, wow, this is amazing. I'll give it a try. If it doesn't work out, I can always go back to being a full-time engineer, I thought. And 12 years later, I'm still doing it, and I feel like I'm still learning because the space continues to evolve. 

‍

When I started in 2011, it was a lot of travel, going to conferences and writing blog posts. But now it feels much more formalized as a profession; there's books that have been written. There's conferences dedicated; there's all these wonderful communities on Slack and other places where we as professionals get together. 

‍

And we share what we are – what our challenges are, what work we're doing, how we might work together. And so, there's definitely been, I feel, an evolution in the sense that we have our own community. Because when I started, you maybe had a co-worker to do developer evangelism with you, but you didn't have this robust community to get together with and learn from. [0:12:14]

‍

Richard Rodger:  [0:12:15] I want to focus on one thing you said, which I think is really important. This idea that the people you see doing conference talks are somehow bigger than you, are somehow geniuses. But I feel the best conference talks are the ones where people just tell a genuine story about actual experiences that they've had, and anybody can get up. [0:12:41].

‍

Sid Maestre:  [0:12:42] Yeah. There's a level of humility and authenticity that, if you combine that with your real-life experiences, is extremely powerful. Because people identify. When you talk about your failures and not just your successes, people connect, I feel; at least, I've connected with speakers in that way. 

‍

And it's something I definitely try to bring to the table. Maybe that's that background of being a self-taught developer, that I'm going to stay humble my entire career, because I feel like I didn't have all that formal training. But I've learned a l lot throughout the years and I try to bring those successes and failures into the conversation, to help others learn from it. [0:13:29]

‍

Richard Rodger:  [0:13:30] Yeah. I'm the same. I doubt either of us would – I'll only speak for myself, but I doubt I would pass the Google interview algorithm questions. I feel bad. [0:13:42]

‍

Sid Maestre:  [0:13:42] Yeah. I think that – studying for those interviews is a full-time job for a lot of engineers. [0:13:49]

‍

Richard Rodger:  [0:13:49] Wow. 

‍

Sid Maestre:  [0:13:50] So, hats off to them for putting in the work. [0:13:53]

‍

Richard Rodger:  [0:13:57] So, you were in eBay – or PayPal, sorry – around the time that they – there was a lot of change going on. I seem to remember they brought out a mobile API based on Node. Was that around your time or was that a little bit after you were there? [0:14:15]

‍

Sid Maestre:  [0:14:17] I-

‍

Richard Rodger:  [0:14:17] 2012-2013, sometimes around then? [0:14:20]

‍

Sid Maestre:  [0:14:21] Yeah, that was right after my time at PayPal. When I joined, I joined as a mobile developer evangelist, because mobile payments and iOS and mobile – shopping on your phone was such a new thing. And they were acquiring businesses left and right. There was one called Red Laser that was all about scanning QR codes, which was revolutionary at the time. And could you put a QR code in your shopping – in your physical shopping experience. 

‍

And they were trying to envision this world where the online and offline shopping experience, as well as all the analytics around it, were all going to be trackable and tied together. And business is going to be able to succeed and merchants were going to be able to make more sales because you were blending the digital and the physical. I'm not sure if we got there; maybe COVID pushed us into this world of having more of that. But it was a really interesting time, and lots of change when I was there. But I wasn't there for the Node part. [0:15:30]

‍

Richard Rodger:  [0:15:30] Yeah. And what interests me is, this is 10 years ago, so the APIs and the SDKs were handcrafted; there was no tooling. [0:15:40]

‍

Sid Maestre:  [0:15:43] No. And in fact, it – one of the biggest challenges that large companies face is, when they release a set of APIs or some technology, and then the technology landscape shifts, and what they've built isn't quite fit for purpose. So, instead of trying to go back and rewrite what they've already got, they go ahead and create brand-new APIs. 

‍

So, when I was at PayPal, I struggled to be an advocate for the technology, because they had some existing tech that worked really well on the desktop, but didn't have a mobile optimized interface for the web. So, if you pulled it up in your browser on your phone, you couldn't really do a checkout experience. Yet they had some new APIs that worked well with their native iOS SDK, and that's what they were pushing. But I was very much into – I don't know if you remember HTML5? [0:16:50]

‍

Richard Rodger:  [0:16:51] Yeah. 

‍

Sid Maestre:  [0:16:53] By web standards. I was very much like, 'How do we help those developers who want to build on the native web these checkout experiences. ' I think they eventually got there through the acquisition of Braintree, but that was – the real challenge was, they had a whole lot of different APIs and the feature set didn't have full coverage, so you struggled to help certain segments of developers at that time. [0:17:23]

‍

Richard Rodger:  [0:17:23] Okay, so this raises another question. And after PayPal, you worked at places like Zero, right, and- [0:17:33]

‍

Sid Maestre:  [0:17:34] Yeah. 

‍

Richard Rodger:  [0:17:34] -and other places. These are large organizations. They have a whole bunch of disparate APIs from different eras; they've legacy APIs, APIs focused on mobile versus web versus whatever, presumably with a lot of different teams. So, you've been there in the field. How do you knock it all together? How do you keep – and from what you just said, PayPal didn't. But in an ideal world, how would you keep that all consistent and coherent? [0:18:08]

‍

Sid Maestre:  [0:18:11] I would say that consistency may not be your top priority. [0:18:19]

‍

Richard Rodger:  [0:18:19] Okay, interesting. [0:18:20]

‍

Sid Maestre:  [0:18:21] And the reason I say that is – I'll give an example. When I was at Zero their original API for their accounting software – because their cloud accounting software was written, I think, in 2009, so it was kind of RESTful. I won't go into all the details. But one thing that stood out was that they used this – there are Microsoft C# developers that built the platform. And they used this really odd Microsoft date format. And it was stored in the database in such a way that when it came back from the API, developers had to parse the date using some non-standard techniques, so it didn't fit your standard ISO date format. 

‍

But then as additional product teams built different products, like an account – a payroll product, an expense product, they would then roll out APIs, and they were doing it in a more modern way. And so, if you tried to use the same SDK to read the date from the old legacy – not legacy, but the old accounting API that was written in the past, and the new APIs, it would blow up, because it just couldn't handle both of them if you tried to do it with the same method. You had to approach those things differently. 

‍

And it was raised; why don't we fix this date format issue? And they said – we talked about it and we said, 'We've got thousands and thousands of developers and customers who rely on this API. If we were to just break it, then just for consistency's sake, that would be a terrible experience for the developers. And honestly, between investing engineering resources and fixing that one problem versus other technical challenges, they never addressed that one. 

‍

And so, we addressed it in our SDKs when we started building and automating howe built those. We put in the methods to help do that translation between that unusual date format that we had into a standard date format that could then be translated back and forth. And the developers never had to think about it because it was all handled by the client libraries. And that was how we ended up solving that problem; was not at the API level but at the SDK level. [0:20:46]

‍

Richard Rodger:  [0:20:47] The SDK level, right. So, that shows you the power of SDKs. So, you have APIs; a lot of people also have SDKs. And from a software architecture point of view, should SDKs be preferable because they can solve – they can hide technical debt like that? [0:21:06]

‍

Sid Maestre:  [0:21:08] Yeah. Ideally, we – we're – I like to think we're more enlightened in 2023 and that our engineers – we have more established standards and practices. And something that I've noticed at companies that I've been working at more recently. There's a lot more talk about API governance and styles, style guides and standards that teams like – I had a conversation with the team over at Square. 

‍

And they have a committee that gets together; I believe it's a steering committee – to talk about their API standards, across not just Square but all of them, all of the different companies that they've brought into the fold and how they want to approach in building APIs. And so, there's a lot more planning and conversation about how do we keep our APIs consistent. And API versioning is probably part of that. 

‍

What's your versioning policy; what's your deprecation policy?  And so, I think that's just a signal of the maturing of the APIs. So, you don't have to cover up that API design with SDKs. it's preferable to have some policies around how you're improving and expanding your API set, so that they are great, no matter how a developer interacts with them. [0:22:35] 

‍

Richard Rodger:  [0:22:36] Now that means we're moving to a world where best practice is – APIs are like Web RFCs, where you write the spec and the documentation first and then you have implementations, perhaps more than one, and you do your versioning. But that means, if that is the case, there's a danger of writing the documentation first and then trying to implement. 

‍

I've always found that when you start implementing things, it feeds back into the documentation and you have to change, because you couldn’t think of everything. Whenever I've tried to write documentation first, I've always had to go back and change it. So, is – do you have to set it up as a feedback loop, or are there approaches you can take to doing it documentation first then keep it safe?  Have you had experience of going documentation first? [0:23:36]

‍

Sid Maestre:  [0:23:37] Yeah. When I was at Lob, we had a really well-defined API specification. And if you want to get down to the most basic way of telling – explaining to someone what an API definition or an API specification is, it's documentation; it's just machine readable. And from that specification, you can generate the more human, readable, beautiful developer portals and things like that. 

‍

And what I think – maybe what you're talking about is how do you create that feedback loop before you start writing code or changing your code. And what we were doing at Lob was, we had a new API set we wanted to create. And we took an API specification approach first, where we designed the end points. We thought about the use cases; we developed the models. We had it all defined in the spec. 

‍

And then we stood up and mocked those end points and put it in front of a few of our customers who were asking for these end points. And they were able to provide the product managers a lot of really valuable feedback about things that they expected in the responses, or things that they expected as far as functionality through the end points. 

‍

And that helped inform and results in a much better 1.0 version of that API, because we had put it in front of real customers and gotten real feedback before writing a line of code. Is that the only or best way? It worked pretty well for us. I'd – I'm curious what other people in the industry, how they're approaching this problem, but I think it's a pretty good solution that worked well when I saw it in action. [0:25:36]

‍

Richard Rodger:  [0:25:37] There's a lot of pitfalls; there's a lot of pitfalls. I've seen things where you've architects defining APIs and then it's just farmed out to a bunch of junior devs as a task list, which usually goes horribly wrong. I had a personal experience fairly recently of defining an API through a Swagger spec and then also being involved in the implementation and then having to go back and say, 'You know what? It's wrong. Now that we're looking at it, we can see that it's wrong." But we skipped that interesting step where there's a mocking version and you get feedback. That's interesting; that's a powerful technique. 

‍

Is there a place for saying, 'We need to develop best practices around API development?' I guess this fits into a bigger philosophical question. And I do this with my junior devs is, I try to explain to them that there's deferent types of code; there's business logic code; there's throwaway scripts; there's unit test code. And then when we're building libraries and SDKs, the quality level is even higher, because these are going to be foundational elements of a system. So, you've got to be really strong in quality. 

‍

So, is – we have agile methods or whatever, even though a lot of people don't like them so much anymore. But do we as a community, as – need to start thinking about specifically the building of APIs and SDKs as a separate-named development activity that has to have its own approach?  [0:27:30]

‍

Sid Maestre:  [0:27:33] I think that we've learned a lot in the last decade and we're going to continue to learn from each other. And there isn't – I worry when we start to think that there's one way to do it. I've been talking a lot about an API specification first. We had API first and now I'm talking API spec first. 

‍

That's my preference, because I like the idea of having one document being the single source of truth. But there's another school of thought, which is, I want to have my specification generated from annotations within my code base. As my developers are writing that new API end point, they can add some little bit of description and add a little bit of annotation. And then I'm going to use a tool to generate my API specification from that. 

‍

That works pretty well if you're generating documentation, but I'm not sure; I've yet to see anybody – I haven't had first-hand experience of someone doing that and generating an API specification that is totally robust. It has all the examples; it has all the descriptions. Because those examples and descriptions are what make your documentation great and what make your SDKs really great. 

‍

And I feel like if you're generating a specification from your code, there is a trust that you have to have that your developers are going to write good descriptions, are going to remember to put in all the annotations that you need, and that the tools support all the annotations that you need to create a great spec. 

‍

We could get there, but I don't have any first-hand experience with that, so I can't tell you if that exists today or if it's something we want to build in the future. Because those are very different approaches, but they get you to the same – I hope it gets you to the same result, which is a great experience for those developers consuming those APIs, which is the – your customer in a way. And that's who we care most about, is that they easily understand and have a good experience using your APIs and technology. [0:30:03]

‍

Richard Rodger:  [0:30:08] Yeah, the annotation approach as the benefit that it's going to be – it's going to generate correct documentation by definition. But it gives me PTSD thinking about trying to parse Java doc back in the day, where it generates massive amounts of supposed documentation that is completely useless. 

‍

And I've definitely integrated with online services and SaaS vendors that have quite clearly done that and then dumped up the documentation site based on annotations, which is not – and usually it's not very useful. And doesn't that go back to the Donald Knuth literate programming idea? Was it him? This idea that you – programming is – should be like a written essay and then the code is the annotation to the text. [0:31:04]

‍

Sid Maestre:  [0:31:10] I'm not familiar with that, but I definitely have heard about the concept; clean code is self-documenting. And so, you're naming your methods; you're naming your parameters, things that are understandable and intuitive to the developers that come along after you and read your code. And that's maybe what you're touching on. [0:31:33]

‍

Sid Maestre:  [0:31:34] Yeah. The other thing that – I genuinely don't know which approach is more fundamentally sound. Be interesting to see how that one plays out. The other thing that I've always found useful, especially with the SDKs, and which I feel is an essential part of the documentation for using an API, is open-source SDKs. Because I can't tell you the number of times that I've been trying to use a system and trying to integrate with it. And just being able to read the source code of the SDK has helped me use the SDK. So, I don't know where you- [0:32:19]

‍

Sid Maestre:  [0:32:19] 100%. 

‍

Richard Rodger:  [0:32:20] I don't know how you feel about that side of things, because some people don't open-source their SDKs, which is – makes life very difficult. [0:32:26]

‍

Sid Maestre:  [0:32:27] Yeah. I think that sometimes the debate about open-sourcing an SDK comes from a place of a business concern, that there's something – some competitive advantage they're giving away by open sourcing, or they're giving away their secret sauce. And to me, I don't think that is a very strong argument. It could be maybe made, but I don't think it's a very strong argument. And you lose the huge benefit of community and transparency and trust that you can gain by open sourcing SDKs and other projects as a company. 

‍

I know that when I was at Zero, we generated a lot of our SDKs. And developers would show up who were much more skilled and knowledgeable about the language that we were generating in, let's say, for example, PHP. I know enough to be dangerous and I could get the SDK out the door using the templates I had available for generating them. 

‍

But there were things that were missing, methods that would be really helpful. And the developers couldn't make a pull request against the library because it was generated. And what they would do is, they would file an issue. Maybe they would even do a small PR to demonstrate what the change was they would want. 

‍

And then we could take that feedback and we could go and modify our templates sand change things internally to our tooling system, to implement that additional change, to make it more idiomatic, which is a way of saying, 'We're following the customs of that developer community and we're writing code that is familiar to them so it's easier for them to use.' 

‍

And so, that's one of the real advantages, is that the community can help you make those SDKs better and more useful for their implementations and how they're trying to utilize it. It's tough to have a team of developers who are knowledgeable in six or seven languages and have them on staff full time; it's a challenge, I think. [0:34:48]

‍

Richard Rodger:  [0:34:48] That's a big one; I've really seen that with a lot of people that we talk to. That is a huge challenge, because most companies have a focus on a particular platform. [0:34:59] 

‍

Sid Maestre:  [0:35:00] Yeah. And I don't want to make that the big – make a big pitch for APIMatic, but I think that that's one of the advantages of exploring. If you're building SDKs and you're debating about should we build these in house or should we go with a service or a company that builds them? When you go to a company that all they do is – night and day, is think about SDKs in multiple languages, and they have dedicated teams to build those. 

‍

Then that takes that responsibility and minimizes that risk of having to have that team in place. And when someone leaves the team, they leave all the – they take all the knowledge with them. And so, that's definitely one of the things that I would say is something to consider when you start building an SDK program or you're looking to revamp yours. [0:35:54]

‍

Richard Rodger:  [0:35:56] This is where the idiomatic stuff comes in that you mentioned start. [0:35:59]

‍

Sid Maestre:  [0:36:00] Yeah, exactly. And in fact, we just recently did several releases where we updated our code samples because we didn't think they were idiomatic enough. We didn't think – they were done several years ago, and as the community standards evolve over time, then keeping those code samples in line with the expectation so the developer community is something we took a look a. And said, 'Hey, we need to update how our code samples are coming out so they're even more idiomatic.' So, that was something we did at APIMatic recently. [0:36:39]

‍

Richard Rodger:  [0:36:41] Okay. Let us wrap up with one final question. You've been doing this stuff for a long time, back when it was called developer evangelism. And how it's developer advocacy and developer relations. And how have you – and a lot of what you've done has been in a leadership capacity. 

‍

What are your thoughts on how developer relations should be run? And by that, I mean, where does it fit into the organization? Are you looking for specific sorts of people? People are now going into it specifically as a career as opposed to having been a developer for 10 years and then randomly ending up being an advocate. If you're now setting up a developer relations activity in a company as a leader, what approach do you take? I'm opening the question, but- [0:37:44]

‍

Sid Maestre:  [0:37:44] That is a huge – that's a big question. And I could – I can go in lots of directions. So, I 'll just touch on a few things. Definitely, understanding the goals and the objectives of the leadership at the company that you're working at. Because dev rel is – it can get a little bit off in the weeds or off chasing things that are not – are good; they're good for the community, good for the developers. But at the end of the day, you're working for a company, for an organization that has goals, and so, making sure the work you're doing is supporting those goals, that's number one. 

‍

Number two, recognizing that dev rel is a very cross-functional role, and so, when you join an organization or you're in an existing one, building those relationships with the sales team, the support team, the engineering, the marketing. Because the social media team – these are folks that are all contributing to that developer experience that you care so deeply about. And so, having relationships where you have some influence but you're also gathering information from them about what's are – what's on the roadmap, what is our priority, what problems are developers are facing. 

‍

You can hear those from different channels within the company, and then that can help inform the work that you want to focus on as a dev rel team, because you're closely in touch. The worst thing can happen is when you end up in silos and the dev rel team is off planning events and running around doing things. But they're talking to developers but they can't get any of the feedback from the community back to the engineering or the product teams. 

‍

When I was at Zero, we would have weekly meetings with the platform team to share what we were hearing. And we would often have to bring up the same issue multiple times over several months until it finally got on the roadmap. But we understood that they played; they had a huge roadmap that we were trying to execute on. But we didn't get discouraged and it waws a very positive relationship that we could continue to feed them and what we were hearing. 

‍

Where dev rel sits, if it's under marketing, if it's under engineering, you're going to get different perspectives on what dev rel means. And maybe one of the bigger hurdles is helping educate people what good developer advocacy or developer relations is all about and trying to help them see the value of investing in your developer community. [0:40:53]

‍

Richard Rodger:  [0:40:54] This cross-functional thing is pretty important, and that has come up a few times with other people. So, maybe the three Cs of developer relations: code, community and content, needs another Cs. Maybe it should be four Cs, cross-functional. [0:41:06]

‍

Sid Maestre:  [0:41:08] Cross-functional. I like that. I might steal that. [0:41:10]

‍

Richard Rodger:  [0:41:12] Steal, absolute – although it's code, community and cross-functional, needs a bit more – needs a little bit of work. If you come up with a word, let me know. Sid, this has been really interesting. Thanks for going to so deep on these questions. I feel in a way that you've opened up more questions. I have more questions than answers coming out of this discussion, but that's a good thing. [0:41:36]

‍

Sid Mestre:  [0:41:38] I hope so. 

‍

Richard Rodger:  [0:41:38] A good thing. Lots to think about. Thank you so much. [0:41:41]

‍

Sid Maestre:  [0:41:43] Thank you, Richard. Have a great day. [0:41:44]

‍

Richard Rodger:  [0:41:45] You too. Awesome. 

‍

Endnote

‍

Richard Rodger:  [0:41:47] 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:42:14] 

‍