The value of long-term relationships with clients.

Richard talks to Joe Drumgoole of MongoDB. Technical sales. Whose job is it anyway? Among other things, Joe Drumgoole of MongoDB gives his experienced view to Richard in this podcast episode.

Technical sales. Whose job is it anyway? Among other things, Joe Drumgoole of MongoDB gives his experienced view in this podcast episode. Our discussion of sales team and DevRel team will help you as a CEO to see how different the two roles actually are, and their impacts on long term value creation for your company. In particular, the distinction between an economic buyer (organisations) and an advocate for your product (individual engineer free to move between organisations).

The idea of supporting users to see the value in your product is reinforced in this podcast from our archive. Microsoft’s Doug Thompson, towards the end of his wide ranging and interesting chat with Richard, discussing the power of letting your customers find the value of your product, and how storytelling can help sell your technology - watch out for his book….someday. You can follow Doug on Twitter to keep up to date with his writing @thedougthompson.

But for specifics on helping the customer find that value in your product, quality documentation, particularly for developers, is essential. Joe goes in to great detail about how to measure the impact and effectiveness of your product’s documentation and indeed your organisation’s content. For the complete conversation, search Fireside with Voxgig where ever you get your podcasts, or at this link. Here, we select two parts of the conversation that illustrate the points covered above.

We start with a little history lesson, but it moves rapidly to how sales and software mix in the DevRel role.

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 CV. 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.

But relationships are the key. People move. You want them to bring your product or service with them. So how do you manage that in a massive organisation? How do you measure the effectiveness of your efforts? This is where the good, managed content comes in!

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 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,

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 interesting

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.

So there you have it. Simple. Take a long term view of your sales relationships and make it easy for your customers and users to love you by supporting them with excellent documentation. Oh, and measure your work so that your organisation understands the value YOU bring to THEM. I hope his conversation has helped you to understand the level of thought, planning and work from entire teams that contribute to making the simple, well, simple.