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 am speaking to Christina Monti, and we talk about her journey from the world of finance into the world of developer relations. And in particular, we take a deep dive on the subject of empathy and how it is essential in this job. All right, let’s talk to Christina. [0:00:35]

‍

Main Interview

Christina Monti

‍

Richard Rodger:  [0:00:37] Christina, welcome, it is great to have you on the Fireside with Voxgig Podcast, talking about developer relations, and developer relations at one of the first companies that I ever integrated with, PayPal. PayPal has been around for so long, it’s hard to say developer relations is this way at PayPal. Let’s start with how it is today, and maybe we’ll talk a little about the history of how you guys got here. 

‍

I always found PayPal to be very focused on user friendliness even back in the day. Just plonk the script in and off you go. But I’m interested where you guys ended up. I know you do open source, all that sort of stuff, but what is developer relations? And you’re a developer advocate; what does to look like at PayPal today? [0:01:26] 

‍

Christina Monti:  [0:01:29] Thank you so much for having me; I appreciate this conversation. I will say that developer relations today at PayPal is going to be a lot of the – what my marketing friend would call the top of the funnel. It’s going to try to – in my mind, my value, my core value, is education. I’m trying to help educate developers into understanding the technical solutions and why they would use them. 

‍

I would love to put a callout that it could be – it was. It was as simple as copying and pasting, but let’s talk about reality. Technology has changed; the ways that we – you’re creating technical solutions have changed. And you’ve got to be in front of rather than behind. It may not be as simple as a copy paste, but it is still the most secure way to integrate. 

‍

And that’s where dev rel comes in. We’re trying to educate developers on this new way of integrating, which is the JavaScript SDK and using a back-end database to make sure that things are always secure. And it’s a lot of interacting with developers. We want to be out there with the developers, understanding the pain points, the challenges that they’re facing. We’re doing alto of meetups, a lot of conferences right now. We are doing video tutorials. 

‍

Through the research that I’ve gotten, in lots of the research that we’ve had, we’ve been able to understand the – exactly what we are all are seeing. The world is changing and how people are learning is changing. They don’t necessarily just want to see a doc. They want to also see a video, maybe a short snippet of something. They want to be able to relate to the content and be able to consume the content in their way, not necessarily in the way that we are going to dictate that they’re going to have it. [0:03:33] 

‍

Richard Rodger:  [0:03:33] I gotta – absolutely. I gotta say – I logged on to developer.paypal.com and I was just – I’d better check to see what its state is, because I’ve seen it over the years. And it’s awesome; today it’s looking really cool. And the very first thing I saw in the tabs at the top was video library. I was like, “Ah, okay.” Because so few people have that and it’s such an important way of learning. [0:03:56] 

‍

Christina Monti:   [0:03:58] It is. 

‍

Richard Rodger:  [0:03:58] Well done, wow. 

‍

Christina Monti:  [0:04:01] And more so – the video library is a great resource, but what we want to focus on is having relatable content. So, it’s not a video that’s created by a marketing team that is making it all snazzy with the screens. It is a developer who’s teaching you how to develop a PayPal solution. It’s a real person; love the man, he’s my best friend ever. But it’s authentic, and that’s the value we’re trying to provide, is authentic interactions and authentic education, so that people are relating to that information. [0:04:43] 

‍

Richard Rodger:  [0:04:44] Have you guys defined maybe a set of values that define your developer relations, that define your approach? [0:04:52] 

‍

Christina Monti:   [0:04:53] We have probably our top-down KPIs, goals, values. I’ll say, speaking for myself and the values that I bring, empathy is going to be number one. And that is more or less how I provide the feedback into the product and engineering teams, is through the empathy of developers, making sure we understand the challenges that they’re facing. And not necessarily listening to reply, just listening to understand and make a change, so that nobody else has to go through that frustration. 

‍

And so, that results in changes to the product or changes to the SDKs or even the developer experience. Making sure that we ask ourselves, if you’re doing this, does it make sense? You, not – I don’t – take the developer out of the equation; what we’re building doesn’t make sense. Would you use it if you built it, if someone built it for you? [0:05:55] 

‍

Richard Rodger:  [0:05:57] And that’s a really good point, because a lot of stuff is built that the people building it would never use it themselves, right. [0:06:03] 

‍

Christina Monti:   [0:06:04] I’ve asked that question to engineers; would you do this? And its’ so funny, because it seems like such a basic question.  But oftentimes when you ask that question, the answer’s usually no. No. Why are you building it then? What are you doing? If you’re not going to use it- [0:06:04] 

‍

Richard Rodger:  [0:06:04] It’s harder. To make something user friendly, or at least user sensible, it’s harder. It’s easier to expose the insides and go, “There you go. Work it out yourself.” Which you see in so many payment APIs. I’ve integrated with a lot of them over the years. And a lot of – I remember one in particular; it was, hash up your own signatures there. We’re not going to provide you with a utility method to do that. Go off and research cryptography yourself. [0:06:52] 

‍

Christina Monti:   [0:06:53] Wow! 

‍

Richard Rodger:  [0:06:54] Yeah, for real. But I’m interested in how developer relations is structed at PayPal these days. Is it a set of teams? Who do you report to? What’s the basic setup? [0:07:07] 

‍

Christina Monti:   [0:07:08] We started – probably we’re on three years of this journey with developer relations at PayPal. And I say this time, because we have often tried, just like every other organization, multiple times to do this effort. We are in the product organization, so we sit underneath the developer experience team in product. And we have our engineering partners that we work very closely with, that are an amazing resource that help us with building the developer experience. 

‍

And then we enable our product and engineering teams that are building the products for PayPal to have the tools necessary to do things that are dev relations specific. So, giving them access to how to be presentable at a conference or write a blog post or create a video that is going to supplement the documentation. 

‍

Making sure that we have our dev rel team somewhat included in the documentation process so that we are always having a representation of a developer at the table to ask those questions that may not be asked. Because if you’re not building with the people that you’re trying to build for, then what are you building for? [0:08:28] 

‍

Richard Rodger:   [0:08:32] And the other thing that I remember from working with PayPal a couple of years back. I was at a – it wasn’t a conference; it was one of those half-day events in San José, sponsored by you guys. Where – pretty sure the Kraken open-source framework was formally announced. 

‍

And you guys – I think somebody had managed to persuade Douglas Crockford – the writer of JavaScript, the good parts, the inventor of JSON – along to give a talk. I think I was speaking at it, and having somebody like Douglas Crockford sitting in the front row when you’re doing your – it was an okay talk that I gave, but it was pretty intimidating. But I remember there was a lot of excitement around that time, of different open-source frameworks. So, how is Kraken? Is it still going? Is there still a lot of commitment to open source at PayPal? [0:09:28] 

‍

Christina Monti:   [0:09:29] Yeah. We still have Kraken. We just released also the Juno database, somewhat earlier this year, which was another one that went wild in in the public. We are still committed to open source, and we still love our open-source community. I will say that just like other things, we have work to do, just like any other company, to make sure that experience is 100%. And I can’t ever say 100; nothing is ever 100. 99.99 if you want me to get on my up times. 

‍

We want to make sure that the experience is good. There’s a lot of investment into making sure that that is part of the developer experience, and encouraging our community to come and contribute, come and – for me, it goes back to empathy. You build something using a PayPal API or using something from your own creative mindset. 

‍

I want to showcase stuff like that. I want to showcase the developers that are out there doing things that are so innovative. I love developers because of the innovation and the creative solutions that they come up with. It’s fascinating to me. And I can see in a future state an ability to utilize the platform, PayPal’s open source, to showcase other developers’ work. [0:11:05]

‍

Richard Rodger:  [0:11:06] And is there much formal coordination between the open-source projects and the developer relations activities? Do you guys feed off each other or are they separate, and then suddenly you find out about this new database. How does it work? [0:11:22] 

‍

Christina Monti:  [0:11:24] Luckily, there is a lot of operational processes that have already been in place. And we typically have a dv rel advocate plugged into the open-source community. And the reason, more or less, is to ensure that the experience doesn’t go south. Making sure that we have governance around the repos. In my mind, it’s very easy for something to go unmanaged, especially in a large organization where you have billions of transactions and Jira tickets and asks coming in from left, right, center. It’s very easy- [0:12:07] 

‍

Richard Rodger:  [0:12:07] And teams change and people change. [0:12:07] 

‍

Christina Monti:   [0:12:08] Things change, yeah, all the time. We do try to have someone that is public facing included in the operational process for open source, just to make sure that there is that accountability in governance that continues to be held for the repos. [0:12:27] 

‍

Richard Rodger:  [0:12:29] Another thing – we were talking a little bit before we started recording. You were talking about PayPal having more of a listening disposition now, where you set up opportunities just to listen to developers. [0:12:42] 

‍

Christina Monti:  [0:12:43] Yeah. We call them the developer listening sessions, and it’s a fun opportunity for me, because I get to have a platform for developers that can come in and provide their unwavering perspective. They don’t – you do not have to sya sorry for anything that you have as an opinion to me. And I will always allow you to complain. Actually, let’s rephrase that. 

‍

It’s voicing opportunity, that’s what we say, voicing opportunity. I provide that, because if you’re not listening to the customers, then again, what are you building for? If someone says that this doesn’t work and we go – move on, but it doesn’t work. So, we have to listen to the developers; we have to listen to those that are using our docs, our dashboards, our credentials, our – everything. We have to understand the challenges, and the only way we’re going to be able to do that is by listening. [0:13:53] 

‍

Richard Rodger:  [0:13:54] There is another challenge that PayPal has, which is, you’re not selling to developers as such. You’re selling to businesses or consumers. Developers enable things to happen, but they’re not a primary customer as such. And a lot of companies find it difficult to navigate that positioning of developers within their ecosystem. Is that recognized internally? How do you guys manage that? [0:14:24] 

‍

Christina Monti:  [0:14:25] It’s recognized by me. 

‍

Richard Rodger:  [0:14:29] And you’re advocating for developers, which is great. 

‍

Christina Monti:  [0:14:32] It’s recognized by me. It is one of the things that I will say, as a developer advocate in a company that is not developer first, it is very challenging. Because you oftentimes are saying the same things over and over again in different ways. Because you’re trying to help others understand why it matters. 

‍

And typically, I have to make it in their world. I have to tell them, “If you have a developer who takes seven days to get an integration up and running, that means that you are not going to get your TPB. You’re not going to do this.” I have to translate it to the business and what is the business impact. 

‍

There is an interesting methodology though, because there’s a lot of developers that are doing things on their own. We’re calling them the freelancers, the contract workers. They’re the ones that are working for the agencies that are getting freelance work. And when we talk about the difference between them and someone who’s a business decision maker – so take a larger corporation – the developer is not going to be the one who’s making the decision of a platform in a large corporation. 

‍

But that’s not the case for a freelancer. A freelancer’s going to advocate and talk about and say, “I want this one,” because this, that, the other. It makes more sense. It’s going to – I’m going to be done in two days versus three days.” And our offerings are competitive; they are competitive against others. That’s the way the world works. Have to be- [0:16:27] 

‍

Richard Rodger:  [0:16:27] That is such an important thing. But I guess that   non-technical aspects of businesses don’t recognize sometimes the developer enabled sale. Let’s unpack the freelancer experience for a minute, because I have been one in the past. And I’m trying to pick between PayPal and – there’s another – I forget their name now – another payment provider. S – Stripe – something or other – yeah, Stripe. Those guys. 

‍

But from my perspective as a developer – and it always come down to economics. If I have had a good experience with one or the other, I’m predisposed towards going with that one. And then if I’ve done two or three integrations, I’ve now invested intellectual effort and time into learning the API. If a client asks me, a startup client asks – or a small business asks me to integrate payments – and I know PayPal’s API; I don’t really know Stripe’s. But I’m just going to say PayPal, because I know I can get that job done super quick and I know it works and I know what to do and I know where to go for answers. I don’t have to learn stuff. 

‍

Now my client might say to me, “But I heard Stripe is good.” But guess what? I can still turn around and go, “Do you want it in one day or do you want it in three?” A lot of people underestimate the power, the influencer power that developers have. And we can exercise it in all sorts of subtle ways. 

‍

You work with a lot of developers; you know that we can be difficult and manipulative. And if we like a particular tech, we want people to use it. It feels like it’s a little bit of a marketing secret weapon if you understand that dynamic. I notice on your personal site you had recommended a couple of books, things like the – what’s the one? Yeah. Developer Marketing Does Not Exist, particular favorite. [0:18:44] 

‍

Christina Monti:  [0:18:44] Yeah. Good book, amazing book. 

‍

Richard Rodger:  [0:18:46] A particular favorite of mine. Or there’s another one which is just Developer Relations or Ask Your Developer. It’s interesting that you picked those ones, because there’s a common theme in there, that you can’t sell to developers, but if you get them onside, then the whole process of making the sale goes a lot more smoothly. [0:19:09] 

‍

Christina Monti:  [0:19:10] It does. No, you can’t sell developers. Don’t – you can – here’s the thing. You can sell developers by giving them an easy experience, by not assuming their knowledge is 30-plus years with a computer science background. You have to be considerate of all situations in my mind, and the experience is what sells them. Not the pretty, shiny documentation, not the fun little GIF of something. It is – if it’s easy, you’ve made my job easy, and I don’t have to do 10 times more work. 

‍

One of the things is, with PayPal, the thing that I love in getting PayPal payments – our standard integration. It’s a single solution, and you get credit cards; you get Apple Pay. You get Venmo; you get any type of payment in one integration. That’s one time that I as a developer have to code. Not more than once, it’s one time. I couldn’t imagine if I got a payment process that only gave me credit cards, but then I also wanted to do PayPal, but then I also wanted to do this and then I also wanted to do that. That’s a lot of coding; I don’t know if I’d want to do that. I want to do it once. [0:20:37] 

‍

Richard Rodger:  [0:20:39] And try and explain that to a client is – good luck. And there’s another dynamic that – this again goes back to this developer perspective, which is, the clients of freelancers and the clients of small consultancies, they’re not technical. They don’t want to know. It’s like, “I integrated against version one of the API and now they’ve version two and it was a mismatch in a JSON schema and now it’s down for half a day.” 

‍

I’m sorry; if you’re explaining, you’re losing. I need to be able to rely on third-party APIs that will never screw me like that. And that’s happened to me so many times, where something suddenly changes; the website is down. But who gets the call at 4am? [0:21:23] 

‍

Christina Monti:  [0:21:23] You do. 

‍

Richard Rodger:  [0:21:25] I do. 

‍

Christina Monti:  [0:21:26] You do. 

‍

Richard Rodger:  [0:21:27] Right. Not the API vendor. And it’s my fault; doesn’t matter. As a developer, I’m always looking for signals that a company cares about developers. That’s why I called the portal, which I hadn’t looked at in a while, in the video library. I’m – “There’s a little bit of developer love happening here,” which is nice to see; it’s good to see. Took you a while, took you a while. [0:21:57] 

‍

Christina Monti:  [0:21:58] It did; it did. It took us a while. Luckily, we are getting there and we have so much more ability to improve and make lives easier. The one thing that I also wanted to call out in that relationship of a developer with their customer is, the developer needs to trust that those third-party APIs are going to give them the information that they need to be supportive of that customer. 

‍

What I mean is, I’ve seen plenty of times when a developer will use our documentation or use a documentation, and they coded it a certain way. When it gets to not working – “I did it the way they told me. Now you need to go figure it out.” No, that’s not – we should be empowering developers, like the car business. 

‍

You buy a Ford. I took my Ford in to get my oil changed. That guy who did my oil change knew everything about that. I didn’t – he didn’t come to me and say, “Go back to Ford and ask them how to turn off your Check Engine light.” He didn’t do that. He knew; he’s empowered. And developers should be empowered the solutions that they’re making and not feel like you said – getting screwed, because I didn’t get the right information and that’s not what I should be doing. 

‍

Then you lose the trust. They need to trust your products; they need to trust your experience, your documentation. We need to make it easy and seamless so that they can build their business, because that’s what they’re in the business for. They’re trying to be a freelancer; they want to make it. They want to make their own business. And we should empower them to do so. [0:23:40]

‍

Richard Rodger:  [0:23:41] Yeah. It’s great to hear. I have to ask; how did you manage to develop so much empathy for – developers are so prickly. The real question is, how did you end up doing this job? Because it’s something that quite a few people aspire to, but it’s not like there’s a whole load of open positions, especially not this year. And a lot of people that I’ve spoken to, even on this podcast, ended up doing this work in all sorts of weird and wonderful ways – they had all these crazy journeys. What’s your journey, Christina? How did you end up as a developer advocate? [0:24:17] 

‍

Christina Monti:  [0:24:19] I’m a non-conventional dev advocate that has had – it’s funny. I landed in this position; it was three years ago, when my leader was like, “You do this naturally and this is what you do on a day-to-day basis. Let’s put you in that role.” Which was great. I do; I do this naturally, and I’m empathetic to anyone. And I’m empathetic to a merchant or a consumer or anyone that is trying to do something with technology that is being built for them, which is – if it doesn’t work, then again, what are you doing it for? I don’t understand. 

‍

But I started in – I’ve always been in banks; I’ve been at the biggest banks in the US. And I worked as a user acceptance tester. So, I took that time and I was doing the testing for the product that the engineering team was building for our internal employees. I did a stint at writing my test cases for a major banks payments platform and then I went over to PayPal and I haven’t left since. 

‍

Seven years later, I’ve been at or around developer experience. I took – this may call me out a little, but there was at least a year or two where I was the sole person responsible for looking at the feedback on our developer documentation. And I will tell you – you asked me the question, how did I become so empathetic. 

‍

It’s because I was forced to listen; it was because I was forced to find what the developers were saying as true. And prove what they were saying was true. If you can’t find the information to a certain API air code and you can’t figure out how to fix it, that’s our problem, not theirs. We should not be providing an API air code back from the API if we’re not going to document it – that’s crazy – hello. 

‍

So, I had to listen, and I will say that time in my life changed how I listen. I don’t listen to reply; I listen to understand and prove what developers are saying was right. That was me looking at a spreadsheet. I had a Google spreadsheet at that time and it was one line after another; every day, I’d read through the feedback. [0:26:58] 

‍

Richard Rodger:  [0:27:01] You did the time; you did the time. 

‍

Christina Monti:  [0:27:03] I did the time; I did the work. I had to listen. I still do the time; I just do the time in different ways. For example, we use Common Room. Love understanding insights as a whole. Obviously, we’re not a company that is small, so we can’t necessarily do one-off here, there, that, the other. We would never be able to get through the pile. 

‍

So, Common Room gives me that capability of what I did before, which was one line at a time in a collaborative – it gives me everything in themes and it tells me the things that are wrong generally speaking, so that I can provide that to the dev experience team, to the product and engineering teams and say, “People are having problems in this area. Let’s focus on that one and try to make that better.” [0:27:56] 

‍

Richard Rodger:  [0:27:58] There’s two follow-up questions that I have. One is, like a lot of people, it seems like you started doing developer relations before it was your job, and in a way, that’s the route in; isn’t it – just do it. [0:28:12] 

‍

Christina Monti:  [0:28:12] It is, yeah. Just do it. 

‍

Richard Rodger:  [0:28:14] Just do it. There’s nobody stopping you; you don’t need to ask permission. In whatever form – in your case, it was more on the empathetic, helping people side. For other people it might be go talk at meetups, do a bit of open source, whatever. You don’t need to wait – you don’t need to ask permission. It’s kind of a weird- [0:28:32] 

‍

Christina Monti:  [0:28:32] It is. 

‍

Richard Rodger:  [0:28:33] -activity that way, isn’t it? 

‍

Christina Monti:  [0:28:34] Yeah. 

‍

Richard Rodger:  [0:28:35] The other one is, you mentioned Common Room, but do you think that finally, developer relations is beginning to get some proper tooling? Do you use other things inside PayPal? Do you have other recommendations for tools that have worked really well for the developer relations teams and activities? [0:28:57] 

‍

Christina Monti:  [0:28:58] There’s a lot of different things that I will say yes, absolutely. We have now a champions group where we are actively recruiting for champions to go out there and do things on behalf, whether it’s promoting your own experience and whatnot. It’s the people that are absolutely killing it when it comes to our developer experience and they’re very close to our products. 

‍

There is tools that will now help you to manage that process, whereas before, you probably had to have an Excel. You would have to go look at their profiles; you’d have to go see what they’re posting and doing all the things. Now there’s a tool. I think that there’s a lot of new tools for dev rel to be successful. 

‍

What I will still say is that these tools that are out there still need an advocate, a group of people dev rel to tie that back to the value. What is the value of this? How are we going to continue to create value? I personally – you asked my opinion; this is not the opinion of PayPal. The value for me is, if someone’s excited and happy about the experience, that doesn’t bring dollar; it’s not tied back to- [0:30:24] 

‍

Richard Rodger:  [0:30:24] Indirectly, it will. 

‍

Christina Monti:  [0:30:26] Indirectly, yes, but it’s not – it’s indirectly, but not respected as it is directly. It’s like, I’m glad they’re happy, but did they give me money? Yeah. But that’s just me. I understand the value long-term. I understand that developers rely on their community first and not your product that you’re building for them. 

‍

If they have a developer in their network that has created or used a platform and said, “This was an amazing experience. You should try it,” they’re going to try it. They’re not going to use your docs; they’re going to say – they’re community first. So, I understand the value. I think that they’re – the tools, while they’re built, you can automate a lot of it. But you still have to get the dev rel advocates, the dev rel team, to tie it back to value. [0:31:20] 

‍

Richard Rodger:  [0:31:23] Yeah. And ultimately, you can’t tool your way to a healthy community. That’s – it’s literally boots on the ground. You’ve got to run the meetups and do the events and support the people who are active members. Christina, this has been really cool, really wonderful. Thank you so much for coming on. And I’m really heartened to see an established company that’s gone through so many different phases of developer interaction embracing an empathetic approach to developer relations. It’s pretty inspiring – onward and upward, for sure. [0:32:06] 

‍

Christina Monti:  [0:32:06] Absolutely. That’s all we can go from here, is up. That’s all we done. And I’m going to continue to advocate for empathy and the developers as long as I can, anywhere I can. Even if I wasn’t at PayPal, I would still advocate for them, just because I understand how difficult it is to be a developer and the cognitive overload of the brain. It’s a lot. If I, someone who has never done a technical solution, can be that person for the developers, absolutely will, absolutely will. [0:32:39] 

‍

Richard Rodger:  [0:32:40] It’s great to know that people like you exist, I have to say. I’ve been coding for a long time and it’s not the norm, unfortunately, but things can change; they can change. [0:32:50] 

‍

Christina Monti:  [0:32:50] Make it, we’re going to make it. That’s what the podcast is for, right? [0:32:53] 

‍

Richard Rodger:  [0:32:53] Exactly. 

‍

Christina Monti:  [0:32:54] Make it the norm. 

‍

Richard Rodger:  [0:32:55] We’re going to make it happen. All right, Christina, thank you so much. Take care; take care. [0:32:58] 

‍

Christina Monti:  [0:32:59] Absolutely, thank you. 

‍

Richard Rodger:  [0:32:59] Wonderful. Bye-bye. 

‍

Endnote

‍

Richard Rodger:  [0:33:02] 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.33.30]

‍