Fireside with Voxgig for Professional Speakers

Joe Drumgoole

Episode:
69
Published On:
2022-10-07
Joe Drumgoole
Podcast Host
Richard Roger
Voxgig Founder
Podcast Guest
Joe Drumgoole

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 my guest is Joe Drumgoole. Joe is a senior dev rel person at MongoDB. I first came across Joe when I saw him pitch a startup at one of the very early Web Summit conferences and I thought to myself, I gotta get to know this guy. He was impressive then and he's pretty impressive now. We talk about the development of developer relations, how critical it has been to the success of MongoDB – which, by the way, is really cool these; I use it myself.

We talk about developing skill of speaking at conferences, and how it is a skill and something that you can learn. And we talk about the importance of identifying the economic reason for why someone uses your software and how important that is in developer relations. Take it away, Joe.

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 here, or follow our Twitter @voxgig. Thanks for listening. Catch you next time.

See Show Transcripts

Interview Intro

 

 

Richard Rodger:  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 my guest is Joe Drumgoole. Joe is a senior dev rel person at MongoDB. I first came across Joe when I saw him pitch a startup at one of the very early Web Summit conferences and I thought to myself, I gotta get to know this guy. He was impressive then and he's pretty impressive now. We talk about the development of developer relations, how critical it has been to the success of MongoDB – which, by the way, is really cool these; I use it myself.

 

We talk about developing skill of speaking at conferences, and how it is a skill and something that you can learn. And we talk about the importance of identifying the economic reason for why someone uses your software and how important that is in developer relations. Take it away, Joe.

 

Main Interview

Joe Drumgoole

 

Richard Rodger:  Joe, welcome to the Voxgig podcast. It is great to have you on today, on this surprisingly sunny Monday for Ireland.

 

Joe Drumgoole:  Richard, it's great to be here. Lovely to catch up again. It's been too long.

 

Richard Rodger:  Absolutely. Let's get straight into it. You work in developer relations. You look after developer advocates. Describe your average day, if you have one.

 

Joe Drumgoole:  About 8-9 hours of Zoom, Richard. I run a global team of about 23 – soon to be 24 – developer advocates and associated leaders. So, most of my day is organizing them for subsequent plans, subsequent quarters, aligning with other parts of the organization and ensuring that what we're doing is properly focused on the overall goals of a company. Now dev rel in MongoDB has a long and illustrious history; we've been always a very developer-centric company. And traditionally in the past dev rel was done organically by the rest of the organization. It's only in the last eight years or so we've had a dedicated dev rel organization.

 

So, I try and do a little bit of real work, as I call it, where you're either writing code or presenting. And I love to get on calls like this, where we can talk a little bit about MongoDB and what we do. But the life of a director at MongoDB is effectively organizing, strategizing, and making sure that we're all focused in the right direction at the right time. We've got a quite sophisticated dev rel engagement model now. We operate across a YouTube channel, a podcast; we do live streaming. We've got a brand-new dev center on MongoDB that most of the content is written by my team.

 

We engage at conferences and we support MongoDB's own in-person events. We just finished MongoDB World in New York, where my team was engaged in over 40 activities at that event. So, a lot – I spend a lot of time in Jira and in planning tools and in spreadsheets, trying to organize our time as efficiently as possible.

 

A lot of the challenge for us is to relax into the work and not get over-stressed and not get overstretched. I can show you really simply the algorithm for somebody who lasts two years in any job, and it starts with trying to work 60 hours a week. After two years of that, you're like, "I can't do this anymore." So, it's important to keep the team on a level and make sure they don't overcook themselves, trying to stretch themselves over too many activities at once.

 

Richard Rodger:  Yes, because the promotional stuff that you guys do, it's endless; you could do everything. I'm interested about the history of dev rel on MongoDB, because you guys were – were you one of the first? It's interesting that you've said it was organic and then it was only about eight years ago that it got formalized. MongoDB has to be one of the first companies that did dev rel before it was called that, right?

 

Joe Drumgoole:  Yes, and so the original company, when it as founded, it's all engineers. And so, the way you would engage is, you would typically rock up; get your badge, your laptop, and then you would be sent out to a conference. Almost – a very common occurrence in – when we were sub about 50 people was, you would get your gear and then you'd head out to a conference or to a meetup. And so, we would turn up on the opening of a bottle top. We were -

 

Richard Rodger:  But these – was it ordinary engineers or a specific-

 

Joe Drumgoole:  Ordinary engineers. And it became a real problem because the engineers were doing so much advocacy and so much dev rel that it was impacting their ability to just ship the product. And so, from there we moved to a field team. Now they were called pre-sales and consultants, but at least half their time they were doing dev rel.

 

So, when I joined MongoDB in 2013, I had a team of about 12 pre-sales people, because when I joined, I ran pre-sales for EMEA for the first couple of years. That team did all the things that dev rel does now. They went to meetups; they did office hours, they presented at conferences. And they did a little bit of pre-sales work at the same time.

 

So, there was a very strong impetus to be in a dev rel function but not in a dedicated dev rel function. So, we didn't have a real dev rel team in earnest till about 2014. And the change came when we brought in a new CEO, Dev Ittycheria. The reason we're a public company now is Dev and the team he brought in. And Dev and the head of sales refocused the pre-sales team on a singular goal, to help find the economic buyer and encourage him to part with his money in order to purchase MongoDB.

 

And we had a couple of things that happened all at the same time. We brought in Dev; we brought a company called WiredTiger, which transformed the storage engine inside MongoDB. The WiredTiger engineers have been working on databases since Berkeley DB. They invented Berkeley DB; then they went to Oracle to build their NoSQL-

 

Richard Rodger:  Hold on a sec. Are you saying Mongo is now the descendent of Berkeley DB?

 

Joe Drumgoole:  Yes. Pretty much, yes.

 

Richard Rodger:  Wow, I did not know that.

 

Joe Drumgoole:  Berkley DB was the very first key value store.

 

Richard Rodger:  That was the first database I ever used.

 

Joe Drumgoole:  Yes. Well, written by Keith Bostic and Michael Cahill. They then went on to join Oracle and Berkley DB became Oracle NoSQL. They then left Oracle to build WiredTiger, and WiredTiger was designed to create a storage engine for modern hardware, modern cloud hardware. So, what's the two things we know about modern cloud hardware: very large memory footprint and lots of CPUs.

 

So, they spent an enormous amount of time building a very – what they call a lock-free storage engine. WiredTiger was basically 10x the performance of MongoDB when we put it in., and so, that made a huge change for us. It also enabled us to do things like distribute transactions, because there was already a transaction engine in the WiredTiger storage engine.

 

So, huge pivot there, huge pivot with the change in the management organization. And we did it without anybody noticing; I never saw anything in the press about changing over. But the big change, they gave us a database engine that could compete with the best in the world, and a database on top of it, MongoDB. An executive team that could compete with the best in the world, and that's what set us on the path to an IPO.

 

Of course, we began to realize as we focused on finding the economic buyer that we weren't paying as much attention to the developers, and that prompted the creation of a dedicated dev rel team. And I moved into dev rel in 2014; I'm trying to think. Might have been late 2014, early 2015, I have to check my own CP. And that became the genesis of what became dedicated dev rel.

 

And so, we've had a dedicated dev rel team. It grew from a small – four or five people, up to – it's about – I'd have to go and look at the org chart – about 40 or 50 people now. And divided into three groups. The – there's a community team under a colleague of mine, Stennie Steneker, who's based in Sydney. They run our user groups, our forums, and run our Champions program There's Advocacy, which I run, which is a global team of software engineers, with a high propensity for communication. So, a lot of our job as developer advocates is explaining how you can use MongoDB most effectively.

 

One of the things that we do in MongoDB is, we've been innovating constantly for the last 10 years. Each year we release a ton more functionality. At MongoDB World, we produced serverless MongoDB, data federation, a wonderful thing called queryable encryption, where you can actually encrypt every piece of data using key stored only on the client, and query that encrypted data while it's encrypted. It's almost like-

 

Richard Rodger:  I just can't (inaudible, 00.10.30)-

 

Joe Drumgoole:  -magic. Almost like magic. I read the white paper and went, "I don't understand this, but it's amazing."

 

Richard Rodger:  Let's zero in on 2014 and that transition from pre-sales to dev rel. Did it – the term developer relations, did you feel it was established? Was it an obvious move, or were you guys one of the first to do it?

 

Joe Drumgoole:  When we started with it, we called it community, and I like the claim the fame for changing the name from community to developer advocacy. We wanted to be clear that this was not just doing user groups, that we wanted to be building code and showing people how to use the platform. And the way I describe it is, instead of having developer relations and pre-sales and consulting, I often describe it now as, if you think about it as developer relations and customer relations.

 

The key difference between customer relations, which is pre-sales, customer success, consulting, support, is in customer relations, there's always a company. If there's no company, we're not interested. The pipeline, the standard marketing pipeline, only wants to have an economic buyer that's attached to a company, because only companies can afford to shell out the big bucks for massive deployments of MongoDB.

 

With developer relations, we're interested in the individual developer, regardless of his employment state or his employer. We're just as interested in Johnny Smith in his first start-up as we are in Jack Smith, working for one of the largest Fortune 500 companies in the world. Because we want to maintain the relationship with the individual in developer relations. And that means that we can continue to engage with a developer throughout his career, as long as he wants to engage with us.

 

That challenge with customer relations is, if you move companies, you fall out of the funnel. You disappear and you have to re-enter at the top in some new company. And that can take time and energy and we don't realize you're the same Richard Rodger as was in Coca-Cola, who's now in Pepsi. So, developer relations is like a mirror of customer relations, but we have a longer-term relationship. And we're absolutely keen that we help the company sell its products, but we feel we can do that by building great advocates for the technology, as opposed to driving them down a sales pipeline.

 

Richard Rodger:  So, if the company treated their developer relations as just the sales funnel, get – once the dev is signed up, then that's it – it's not going to be very effective, is it?

 

Joe Drumgoole:  No, it's not, because people join and leave at different parts of their career. People change jobs and suddenly they discover they're not using the technology anymore. Sometimes they return to it later. We have to be able to manage a multitude of different cohorts at different stages of engagement, and one of the challenging things to do with dev rel is, if you try and accommodate your more skilled, more tenured engineers, your vanity stats go through the floor. So, you're just not going to get as many reads on a more sophisticated piece of content as you will with something basic and entry level.

 

So, I like to think of our metrics as three components. Input metrics: these are the things that we do. Write a paper, go to a conference, do a podcast, create a YouTube video. Consumption metrics, they're the people: how many people watch, view, read, listen to. They're important. And then impact metrics, these are the ones we're really trying to focus on these days. What do they do next?

 

Your consumption metrics for a very sophisticated piece on CQRS and event sourcing are going to be way lower than Introduction to Node.js in MongoDB. But the people reading that more advanced content are much more likely to become strong advocates for your products. So, the impact metrics are what they do next. Do they become advocates? Do they promote the stuff? And honestly, it's frustrating when people only look at Google Analytics and go, "Well, your article only got 200 views." But which 200 people were looking at that article? That for me is what really makes a more sophisticated-

 

Richard Rodger:  How do you measure-

 

Joe Drumgoole:  -dev rel program valuable.

 

Richard Rodger:  How do you measure impact?

 

Joe Drumgoole:  So, we are starting to build a slightly different funnel to the more traditional dev rel. We want to have a very consistent set of calls to action across all of our channels, and you'll start to see this in the latter half of this year. So, we'll have a much more prescriptive list of CTAs for our dev rel advocates to use. And we'll be driving people to the same set of pages, properly tagged and referenced, so we can use that as a trigger metric for impact.

 

We might be driving you to sign up for Atlas and use a particular product. We might be driving you to sign up for University, or we might be asking you to sign up for a dot local event somewhere near you. Those CTAs are going to be driven through a set of pages we've constructed specifically. And so, we can measure the impact by saying, "If this percentage of people come to this page, then we know we've succeeded."

 

So, it's – the trick is to keep it consistent across the whole team, so that everybody's using the same set of CTAs, driving to the same set of pages and tracking that through either tags or through – the only traffic that comes to this page could be from us, because the page isn't visible to the rest of the Internet, or at least is not linked to the rest of our website. And that will give us an impact metric.

 

Richard Rodger:  Let's return to this idea of the economic decision maker. As a developer, I've often been in the position where I'm not the guy with the checkbook, but if I say "Use x," that's what the economic decision maker is going to use. But it's interesting that you said that the new CEO changed the strategy or the way that approach was taken, So, where – explain to me how developers fit into the decision-making process. What was the change?

 

Joe Drumgoole:  There are three. MongoDB's sales process is an incredibly sophisticated model and it has continued to develop in sophistication, but at its base there are two important components to a sale: a champion and an economic buyer. The champion is going to help you to sell to the company. And the key thing between a champion and what we call a coach is a champion will push a product when you're not in the room. A coach will only support you when you're in the room. So, the challenge for a pre-sales person and for a rep is to find and identify a champion for your product. The champion will introduce you to the economic buyer.

 

In your case, we will be trying to ensure that you were a supporter of MongoDB and that you would introduce us eventually to your CEO or your CFO or your head of business. So, it's always a champion and an economic buyer. In very small companies they might be the same person, but in most companies the champion and the economic buyer are two different people.

 

We help by building generic champions from MongoDB. We don't have a champion that's specifically attached to an account and a territory. We create a huge amount of interest in MongoDB; we expect it to yield fruit further down the line. But we're not attached to a sales target. We don't have a quota in dev rel.

 

Our job is just to build an enormous number of champions: both champions who are officially MongoDB champions and anointed by our champions program, but also a huge range of people who are just more interested in MongoDB and more keen to use the product. That for me is the ultimate goal of dev rel; build these champions, hundreds of them, thousands of them over our lifetime.

 

Richard Rodger:  Okay. So, that is a key strategic imperative. Let's unwind or unpack the whole dev rel strategy and how you put it together. Let's use a thought experiment. I'm sure you're extremely happy where you are, but if you were offered millions and millions and millions of quid to work in a startup that was just beginning to set up their dev rel, literally you're dev rel person number one. And you have a budget, a sufficient budget, and the startup is doing well etc. so we don't have to worry about that side of things. How would you go about setting up the dev rel organization? There's nuts and bolts stuff, but then also, how would you set the strategy?

 

Joe Drumgoole:  You look at – first of all, you look at the geography; where are we? Are we in Silicon Valley; are we in Dublin; are we in London? And where is the largest adjacent market? That's where you want to put your dev rel people. Then you want to think, for a small team, your reach is disproportionate with online activity, so you want to get them writing content and more importantly, doing YouTube content. 50% of developers, when they want to find out about something, go to YouTube. Don't take this from me; that's a Stack Overflow stat.

 

Richard Rodger:  That's a new thing.

 

Joe Drumgoole:  It's not that new. YouTube's been around for a long time, and if you type any technology into YouTube, you're going to get a stack of videos about it. And videos are often easier to understand because you're watching, interactively being built, than reading. Now me, I like to read stuff; I would much rather read an article-

 

Richard Rodger:  Yeah, (inaudible, 00.21.21).

 

Joe Drumgoole:  -- than watch a video. But that's me because I'm old and so are you, Richard. You look young, but we know; there's been a few years, a few miles under your wheels. So, written content and YouTube, and then you want in-person engagement, and for me, you can start running your own meetups. It's a heavy lift, and I think meetups – if you want to do meetups, don't start a meetup; go to a meetup. Or attach yourself to a generic technology related to your technology.

 

We've been offering the space in MongoDB to other groups to hold meetups, and one of the people that's working with us is Conor O'Neill from Tines. But they don't call – they don't have a Tines meetup; they have a low-code meetup, and they offer access to anybody interested in low code. That makes it a more generic topic. Vendor communities have a half-life. If you start a community on MongoDB, I guarantee within two years, you'll have churned everybody in your meetup group. Because they' come to learn MongoDB, they learn MongoDB and then they leave.

 

So, you need a more elevated goal for your community, and we're trying to think about a community that's making people better software developers at MongoDB as opposed to a community that teaches you MongoDB. We have an excellent university program that's free for you to learn MongoDB, but to become better as a programmer, you want – we want you to look at our dev center, which has lots of more generic articles. And join our community, because it's a community that's embracing the idea of becoming a better developer. And if you do that, then you're attaching yourself to a higher goal than just getting and acquiring a single technology.

 

Fur us in MongoDB, we know MongoDB doesn't – is never used in isolation; it's used with a cloud provider. It's used with a tech stack; it's used with Confluent; it's used with Vercel and Next.js. If you aren't aware of at least, and often expert in those adjacent technologies, you don't get the credibility to talk about your own product. So, what I talk to my developer advocates about doing is become an expert in a third-party technology that's adjacent to MongoDB. By being an expert in and of that community, you earn the right to talk about your own technology. And so, content-

 

Richard Rodger:  Yeah, I think that's – it's an interesting (inaudible, 00.24.02)-

 

Joe Drumgoole:  -comparison and adjacency are the key things for an early-stage dev rel program.

 

Richard Rodger:  Yeah, I think you've just created a pattern for avoiding the dreaded pitch talk, which event organizers absolutely hate, and communities hate. It's like this person is just pitching their product. By contextualizing it in a wider problem space you're making it useful. That's a really good strategy. Can I ask you about documentation?

 

Joe Drumgoole:  Yes, you can.

 

Richard Rodger:  You can talk about the fun stuff. But what I found personally when I go to use third-party products and integrate them –I've either by told by the client or made a decision myself or whatever – the documentation really counts. And the archetype there – in the same way that you guys, MongoDB, was seen as one of the very early movers in getting dev rel up and running, Stripe is seen as the archetype of amazing documentation. But where would you place documentation in this space and how do you execute it? Because it's super hard to build good documentation.

 

Joe Drumgoole:  We have a documentation of long standing on MongoDB; they've been around as long as the engineering team's been around. And they've got a quite sophisticated content management system that they built themselves specifically for their purpose of being able to store and manage multiple versions of the same documentation. The doc site is super clean; there's very few ads on it. It's got everything you need in there.

 

The challenge is, always with large documentation sets, finding what you need or knowing what it's called. So, what we've done is started to wrap the docs in our dev center articles, which are a little bit more accessible. So, a lot of our docs, our dev center articles, are introductions to, or how to use multiple products together. And that gives you a more gentle entry, because our docs are still – although we're making a big push to put more tutorial material in there. Our docs historically have been a reference site for all the documentation on all the products.

 

Now like I said, you'll see each time you look in there – I go back to the docs, I'm going, "Hang on. There's all these tutorials now." So, we have these multilanguage taps now where, if it's an example, you'll get it in all the top four languages: Node.js, Python, Java and C#, so that you can get an example in your programming language.

 

The number-one site for developers at MongoDB is docs, so one of the things I look at when I'm looking at engagement and growth of the product is the docs site, and I have stats here. In 2017 we had five million people visit our docs site. In the year just gone by, 2021, we had 7.8 million. So – and those are all developers, because you don't go to the docs site to browse. It's too dense; you wouldn't find anything useful.

 

We get lots of people dropping into Mongodb.com because they've heard of us; they read an article or they watched a video or they saw Dev on CNBC. But the docs site is all developers, so that when I want to see what's happening in our community in the large, that's the Google Analytics tab I go to.

 

Richard Rodger:  So, the – let's just return to this idea of, you're setting up dev rel in your organization. Would you again say to that – to the leadership, "Okay, we've got to build our own documentation system?"

 

Joe Drumgoole:  No. I think the reason we did that way back in the day is because there wasn't really anything appropriate for doing this, for doing what they want to do, these multiple versions. They were all engineers as well, so they love building stuff. I would pick one of the many content management systems that are available now and just cast it into that. But I would say you need dedicated documentation writers; it's not a dev rel function per se.

 

It can be part of dev rel, but if you're writing documentation, that's what you're going to do 90% of your time. And honestly, really well written, well-constructed documentation may be the best developer sales tool ever. Because if you can find out easily how to use the product, you are going to crush it.

 

And you'll tell other people; you'll rewrite the docs in your own words because it's been easy to understand. So, yeah, great documentation is the absolute underpinning of any developer product. And I'm glad to say I think we have amazing documentation; the docs team at MongoDB does an incredible job.

 

Richard Rodger:  Let's wrap it up by returning to the fun stuff. The world is returning to normal after COVID etc. I'm sure you've started traveling and talking again – perhaps not. But what are your top tips for the traveling conference speaker?

 

Joe Drumgoole:  Getting good at talking at conferences is not something that's learned overnight, and so, there's no substitute for doing it. People say to me, "How did you get to be good at doing public speaking?" And I'm like, "I did it for ten years." And I don't think you have to do it for ten years, but you have to do a lot of it at the start. And sucking up the bad experiences with the good.

 

I'll tell you; my first public speaking experience was the most horrific event I've ever had in my life. Because I was so dumb, I didn't even realize that there could be such a thing as speakers' anxiety. And I walked down onto the stage in York University in 1987 and absolutely lost it. They had to go and get water for me; I couldn't speak. And then I barreled through the whole 20-minute presentation in about four minutes. So, it was a disaster. And you have to have them.

 

Richard Rodger:  That's epic.

 

Joe Drumgoole:  Yeah, you have to have those to – and get over them to get through it, because there is no more thing horrific than going up and speaking in public for the first time. So, what I say is, don't do what I did and submit a paper to a conference and rock up. Get used to doing it in your own office. Get used to doing it in small groups of people you trust and who love you and you love them, and work out from there.

 

And you build up slowly. The first time I did a big auditorium – you're going to feel nervous. I still feel nervous going out on stage, but now I recognize that it's part of the adrenalin that you need to do public speaking well. And don't forget; a little bit of entertainment goes a long way to making a great public talk. So, don't just be the guy who dumps facts. Bring some personality to it; bring some of your own insight. Bring some of your own personal experience. Tell a little story about yourself.

 

You’ve got to make the audience feel comfortable. The audience will be exactly as comfortable as you are on stage, so if you're not comfortable on stage, they're not going to be comfortable. And the other thing is, smile. The number of people who go onstage and they're just so stressed. It's amazing; if you can relax into it, the audience will give you back all this energy. But I don't want to sugarcoat it; it takes lots of time and effort.

 

That  mythical – I'm not sure you have to do 10,000 hours of public speaking, but I think 1,000 wouldn't be far off to really get good at it. So, don't be overwhelmed and don't get disheartened if you're not great the first tew times you do it. It takes time and energy to really get good at public speaking.

 

Richard Rodger:  Yeah, I think you're right; you just have to do it. I learned at meetups, which is a super safe step; you can make tons of mistakes.

 

Joe Drumgoole:  Yeah, meetup is very forgiving. I would recommend anybody who wants to get – dip their toe into public speaking. Find a local meetup; the audiences are so engaging and so helpful and everybody's so forgiving. You can cock up as many times as you want there and nobody will say a thing to you. It's -- mastering public speaking is one of those great skills that will pay off in spades throughout the rest of your life. And like anything in life, the time to master it is sooner the better; start now. Because the more you go on, the harder it is to overcome your own fears and your own anxieties. It's not for everybody.

 

Richard Rodger:  (Inaudible, 00.23.44) No, but it's – I think it's easier now because audiences are so – everybody appreciates actual speakers.

 

Joe Drumgoole:  There's more opportunity to talk in front of small audiences. Meetup changed the game there in terms of giving you a small audience to talk in front of.

 

Richard Rodger:  That is super-encouraging, Joe, thank you very much. And also, a whole bunch of – I'm going to have to process them – a whole bunch of insights about dev rel. I have copious notes, which I'm going to check again. There's no substitute for doing and learning, and thank you so much. This has been absolutely fabulous. Thank you.

 

Joe Drumgoole:  Lovely to talk again, Richard. We must catch up in person soon.

 

Richard Rodger:  Absolutely. Take care. Bye-bye.

 

Joe Drumgoole:  Bye.

 

Endnote

 

Richard Rodger:  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.