Interview Intro

‍

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

‍

Today I'm talking to Michiel Mulders and mostly about documentation and the management thereof, and in particular content analytics. Because if you don't know how your users are reading your documentation, you don't know what your documentation is actually achieving. Here we go. [0:00:36]

‍

Main Interview

Michiel Mulders

‍

Richard Rodger:  [0:00:37] Michiel, welcome to the Fireside with Voxgig Podcast. I'm delighted to have you on today, and I believe you're having better weather than me, but that is usually the case. I'm in Ireland, my usual rainy weather; my guests always seem to have better sunshine than me. How are you doing? [0:00:53]

‍

Michiel Mulders:  [0:00:54] I am great. There's a little bit of sunshine in Belgium at the moment, so very pleased with that. [0:00:59]

‍

Richard Rodger:  [0:01:00] Cool. I'm so glad to have you on, because you're doing DevRel Uni.com, which is awesome, a university for people to learn about developer relations. Tell me more about it. [0:01:12]

‍

Michiel Mulders:  [0:01:14] So, our goal is to sort of fill the dev rel gap in Web3 and the blockchain space. We are advocating Web2 developers to become Web3 developer relations experts. And we are hosting monthly, bi-monthly cohorts where we teach developers the skills that they need to become a dev rel. I am specifically hosting the documentation strategy workshop, but there are workshops in community building, organizing events, technical writing and even – many more workshops. 

‍

It's a free university; people can apply for it. When they get accepted, we require them to spend a couple of hours per week listening to the recordings and working on a small workshop each week. At the end they then graduate. They are a little bit more confident in becoming a dev rel, so that's our goal. [0:02:13]

‍

Richard Rodger:  [0:02:14] Wow, really cool. How long does the course last? [0:02:16]

‍

Michiel Mulders:  [0:02:17] It lasts five weeks. [0:02:18]

‍

Richard Rodger:  [0:02:19] Five weeks. 

‍

Michiel Mulders:  [0:02:19] Or five talks and five workshops. [0:02:20]

‍

Richard Rodger:  [0:02:22] It sounds a little bit like the Y Combinator model. [0:02:26]

‍

Michiel Mulders:  [0:02:27] Yes. You can compare it to an express bootcamp. It's not like the fulltime one where you spend 20 hours per week. You can do this in your evening hours after work. [0:02:39]

‍

Richard Rodger:  [0:02:40] Yeah, it's specifically designed that way. And are you running it as a business? What sort of structure- [0:02:46]

‍

Michiel Mulders:  [0:02:46] No. 

‍

Richard Rodger:  [0:02:46] -supports it? 

‍

Michiel Mulders:  [0:02:47] It's more about first of all getting people into Web3, also slightly to promote the company I'm working for, [Adera Hejgraf?] 0:02:57, because we are always looking for dev rels. And thirdly, personal branding as a documentation expert. And I really like doing this; it gives me the opportunity to speak publicly, or virtually at least, and get more confidence in that field as well. [0:03:14]

‍

Richard Rodger:  [0:03:16] Awesome. And is – so is there a limit to the cohort? Do you say it's going to be 10 people or could it be 100? [0:03:23] 

‍

Michiel Mulders:  [0:03:24] Usually, we try to keep it between 30 and 50, because we prefer the smaller size that we can do more personalized learning. Also give everyone that's applying feedback to the workshops they do. If we would run it with 100 people, we won't be able to provide quality feedback. For us, it's also a small-scale thing we do after our hours, so we don't want to take on too big of a challenge here. [0:03:53]

‍

Richard Rodger:  [0:03:53] Gotcha. So, you've pre-recorded or pre-built some content and then there's a community interaction element? [0:04:01]

‍

Michiel Mulders:  [0:04:02] It's actually all live, so we're hosting- [0:04:03]

‍

Richard Rodger:  [0:04:03] All live? Oh, right. [0:04:04]

‍

Michiel Mulders:  [0:04:04] -the talks, always live, so people can ask questions. We don't like pre-recorded sessions. [0:04:07]

‍

Richard Rodger:  [0:04:07] Wonderful, wow, that's amazing. That's a lot. That's hard work; that is hard work. [0:04:15]

‍

Michiel Mulders:  [0:04:15] It's hard. Well, when you get in the routine of doing the talk, it gets easier. [0:04:20]

‍

Richard Rodger:  [0:04:21] Yeah, this is true; this is true. I did a year of university lecturing, mobile app development, and wow. [0:04:30]

‍

Michiel Mulders:  [0:04:30] It goes natural. [0:04:31]

‍

Richard Rodger:  [0:04:32] It was hard work. 

‍

Michiel Mulders:  [0:04:34] Was it? 

‍

Richard Rodger:  [0:04:35] Yeah, preparing lectures and assignments and grading, and then just giving the lectures. So, the way – the lectures that I gave were two-hour lectures with a one – with a coffee break in the middle, so it's pretty intense stuff. And I developed a huge respect for people who teach in all [inaudible, 0:04:59] because it's a hard job. 

‍

Michiel Mulders:  [0:05:02] I'm giving the same lecture over and over, so I can't call myself a real teacher, I would say. [0:05:08]

‍

Richard Rodger:  [0:05:09] But I have this experience when I do conference talks and I give the same one at a couple of different conferences. It's better; gets better when you do it more, to learn which examples resonate with the audience, that type of stuff. [0:05:26]

‍

Michiel Mulders:  [0:05:27] That's true. I've been improving my documentation workshop over and over and over with feedback from friends, with feedback from some of the participants and adding more examples, adding interactive content like Giphys. They do love Giphys that show – instead of showing a screenshot, they were like, ''But can you show us?' I can't open Google Analytics; also, it's sometimes proprietary information from my company. So, I created Giphys to solve the problem and make it more fun for them. [0:05:58]

‍

Richard Rodger:  [0:05:59] Interesting, yeah. I've been trying to – saying I should experiment with that with my own open source for years. I might finally be inspired to do it. Let's talk a little bit about your background and how you got into doing developer relations. Was it something that you always wanted to do or did you end up like a lot of people in it, by accident? [0:06:23]

‍

Michiel Mulders:  [0:06:23] By accident, yeah. So, I – my education is software engineering; also started working at a consultancy firm in Belgium. It was a blockchain consultancy firm, very early in 2017. But after that, I joined regular consulting company wand was getting bored of working in sprints and not being creative, just slamming down code. 

‍

So, I was doing the writing sites also, all along since college. This exposed me to writing technical content for websites. In the beginning, it was SitePoint, which was one of the main tech websites for tutorials. And after my second job, I got opportunity to move into developer marketing. That was the first time – it was – at the beginning, it was called developer marketing, but it became dev rel. And this exposed me to content creation, doing webinars, public speaking and also a bit of search engine optimization. I don't really like this part of it, but it was part of it. 

‍

And then finally, I discovered that it's actually called developer relations; since 2018-19, I have been doing dev rel as a fulltime employee for multiple companies now. And I really enjoy the mix I get between still having the technical skills, creating code examples, but also doing public speaking, communication, community building and a little bit of marketing. 

‍

Since a while, I'm focusing on creating technical video content, because it combines the technical aspects with being creative with your video editing, creating animations; don't overdo it though. It's a very fun skill to explore, and I feel and I also see in the industry that people tend to like video content over written content with images. When I can choose, I will always choose the video content. We're consuming more and more video, so it felt like a natural thing to learn. 

‍

So, that's my journey, how I ended up in dev rel. And seeing a lot of bad documentation projects, I started looking into it. I was first trying to optimize the technical writing, optimizing the documentation structure. And then I started heading deeper and deeper into content analytics with Google Analytics, optimizing the search and optimizing the developer experience. It became a rabbit hole. [0:09:08]

‍

Richard Rodger:  [0:09:10] We have a lot of stuff to get back to you've just mentioned, a whole bunch of things that we can talk about. So, it's great that developer relations has a name now, isn't it? Because a lot of us were doing this stuff, and it was, 'But you have a real job as well, right?' And now we can say, 'This is actually my job.' [0:09:27]

‍

Michiel Mulders:  [0:09:28] I am finally able to label myself. But explaining it to friends and family, there you get me like, 'What do you do? Say again?' And my official title now is developer advocate, because we are also more about building in public. And when I say that, they say, 'You're a lawyer? A tech lawyer?' No, no. [0:09:48]

‍

Richard Rodger:  [0:09:49] Yeah, my parents are very proud; I went into law. We – in my previous company, we ended up renting an office on top of a hill in a small town, and the – we were known locally as – because we did high-end enterprise consulting. You try to explain high -end enterprise consulting to someone who doesn't do that; is not in software, sounds kind of crazy. So, they just called us the computer people on the hill. [0:10:24]

‍

Michiel Mulders:  [0:10:25] Computer people, that's a good one, yeah. [0:10:26]

‍

Richard Rodger:  [0:10:27] Computer people. 

‍

Michiel Mulders:  [0:10:27] It's not a good label though. [0:10:28]

‍

Richard Rodger:  [0:10:30] But we weren't very friendly, because we wouldn't fix printers and things like that. [0:10:34]

‍

Michiel Mulders:  [0:10:36] I also shrugged this question; I never help people with PC or computer problems; printers are the worst. [0:10:45]

‍

Richard Rodger:  [0:10:46] I know; I'm – I can't – printers don't like me; I can't get on with printers. So, I would like to talk about documentation. I have to admit, I have a personal interest in this. And in fact, Sinead, my colleague, who helps organize the podcasts and a whole bunch of other stuff, is always keen for us to be doing better on our documentation, so any help or any advice you can give is greatly appreciated. 

‍

Just to set some context, I have an open-source project that I'd been working on for the last 10 years; I've a microservices framework. It has about 150 plugins, examples old and new, all sorts of stuff. I've written a book about it. But I've always struggled to generate high quality document, always. And I've been trying to do it by hand; I've tried to do it by conference talks, random conference talks – oh, that's also documentation. I'm tired of editing markdown, large markdowns. 

‍

So, before we started recording, you were talking about something called Divio. I don't know; let's do a bit of a deep dive and talk about – if I came to you and I said, 'Okay, we're going to do this professionally. I'm a startup and I've just got my series A or whatever. And I'm beyond the MVP stage and we have a complex SDK in multiple languages and an API. Our documentation was all written in two weeks in a massive hurry and we need to redo the whole thing from the beginning. What do we do? [0:12:34]

‍

Michiel Mulders:  [0:12:36] The Divio documentation system is – it's like the base layer. It's like  putting in the structure for your docs. And the system has been designed for people or for documentation or for developers to structure their content in a meaningful way that makes it easier for developers to find the information they need. And also to understand the tutorial section is learning oriented and the how-to guides are to solve problems. 

‍

So often, I see companies just using tutorials or mixing content. And when developers learn a little bit about the product and they have a specific problem, and they are looking for the solution or the specific problem. They are scanning through endless tutorials just to find the answer, and that's super frustrating, not being able or not understanding where the information is structured. 

‍

So, this is what the Divio documentation structure is trying to solve. It's like a matrix with four squares and on the top, you have the practical knowledge, and on the bottom, you have the theoretical knowledge, and on the top left, you can find tutorials. Tutorials are learning oriented; they go into the deepest details you can provide to a developer, step-by-step-guide, step-by-step information, to teach someone the basics about your product. 

‍

So, what they often say is, they give a cooking analogy and say, 'We want to teach someone to cook. They want to – they don't want to focus on the outcome but how do you cook water; how do you boil water? You don't want to create a recipe; you just want to teach them the basics. And you're hand-holding them. And on the right side, you find out how-to guides, so they're problem-oriented and they try to solve a specific problem a user has when they have learned a little bit about your product. 

‍

So, they learnt the basics and now they want to build something and they run into a problem. They don't bother or they don't care about – I need to install this package or I need to do this; I need to do this Docker set up. No. You leave out all of these details and you create a hyper specific guide, a short guide that solves their problem. And this avoids them to having to scroll through endless tutorials to find a snippet of code they need. 

‍

And when you already have these two elements in place, it makes it so much easier for developers to understand where to find the information they need. And if you combine this with good search, they can type their problem and they should find the right guide. To complete the matrix on the left bottom, you have explanations; they're theoretical knowledge and they're understanding oriented. These are often short snippets of information or blog posts. It can be different formats and FAQ is also possible. 

‍

And they often take a step back. They give you context; they give you background information, like why did they choose to implement a feature in a specific way, or why is the architecture off, for example, the React project designed in this way. So, they help you to understand the decisions and the design choices that have been made. 

‍

And then the fourth thing is the reference guide; it's again theoretical knowledge, but it's information oriented. This is for the developers that have a lot of knowledge about your product. And they want to quickly research a specific function in your SDK or API and they want to know what's the output parameter; what's the title of this parameter? How does this function work? This is the base structure that I always try to implement with clients with their own documentation to make finding the right information easy. And this is the base layer for developer experience as well. [0:16:36]

‍

Richard Rodger:  [0:16:38] Wow, okay, so you get – yeah, because I think it often all gets mixed up together, right? [0:16:44]

‍

Michiel Mulders:  [0:16:44] Yeah. I often see the tutorials with the how-to guides and that's a big problem. [0:16:48]

‍

Richard Rodger:  [0:16:49] So, what we're talking about, just to recap is, you have to structure things around tutorials versus how-to guides versus explanation oriented content versus reference. [0:17:00]

‍

Michiel Mulders:  [0:17:00] Yeah. And the explanations, they don't necessarily have to live in the docs. For us at Adera, this was also a bit of a thing. We want to explain our core concepts. Do we do this in blogs? Do we do this in FAQ? Do we record some webinars or some videos that we link? So, explanations can live in multiple places. It's something that's not very specific or detailed in the Divio documentation system. It's a bit free to you to structure this information. [0:17:36]

‍

Richard Rodger:  [0:17:38] So, Divio itself is a documentation system that Django, the Python framework uses, right? [0:17:45]

‍

Michiel Mulders:  [0:17:47] Yeah. Exactly.  I think it originated from there. It originated from 2017 PyCon in Australia. [0:17:55]

‍

Richard Rodger:  [0:17:56] Okay, so presumably it runs on Django itself. How – when you set up Divio, how do you deploy it? How do you run it? [0:18:06]

‍

Michiel Mulders:  [0:18:08] It's not – it's just a philosophy. It's a philosophy that explains everything in detail. You can go to the website; it's documentation.divio.com. It's up to you to implement it, so you will create a new documentation project and implement it according to the standard. You can make some tweaks to it depending on your project and the complexity. 

‍

But it provides you with a general structure and it's also useful to have, because if you're working in a documentations team, you want everyone to know how they should structure their information. And it acts as a reference guide for other documentation people or developers to structure the information in the docs. You don't want anyone to add tutorials while it should be a how-to guide. [0:18:56]

‍

Richard Rodger:  [0:18:57] Yeah, you're right, okay. Because a lot of companies just end up saying to developers, 'You have to write a blog post. Just write a blog post.' And then- [0:19:06]

‍

Michiel Mulders:  [0:19:07] Just edit. 

‍

Richard Rodger:  [0:19:08] And you just get random stuff and you just – let's just post it up, right? There's a blog and then there's just a random stream of technical blogs that are not structured. Interesting, so you can use this structure to figure out where you have gaps, to figure out what the next pieces of work need to be. People can orient it based on what they like to write. Do you like to do learning oriented tutorials? Do you prefer to deep dive on a problem you've just solved, which is a how-to guide. Some people really love writing reference stuff and completing – dotting all the Is, crossing all the Ts. [0:19:48]

‍

Michiel Mulders:  [0:19:50] Well, I usually prefer to generate it, although I would say it's not always perfect. It really depends also on how you document the code itself. [0:19:59]

‍

Richard Rodger:  [0:20:01] Yeah, so in terms of generation of documentation, especially the reference stuff, do you have any advance on that in terms of tooling, or is it just the general principle? [0:20:13]

‍

Michiel Mulders:  [0:20:14] Yeah, just the general principle. I wouldn't suggest to you writing a reference guide manually, I would say. I would rather generate it and then tweak it. [0:20:24]

‍

Richard Rodger:  [0:20:26] Yeah, absolutely. 

‍

Michiel Mulders:  [0:20:26] If necessary, yes. 

‍

Richard Rodger:  [0:20:28] One thing that drives me crazy with system documentation is lack of search; drives me nuts. Especially when there's good solutions now like Algolia, right? [0:20:37]

‍

Michiel Mulders:  [0:20:38] Yeah. That was a nice transition to Algolia. [0:20:41]

‍

Richard Rodger:  [0:20:42] Did you like it? I like it. Do you see what I did there? [0:20:44]

‍

Michiel Mulders:  [0:20:46] I see what you did there. One of my passions is also documentation search, and it's a very specific thing. And people think, documentation search is shit. It doesn't matter; you type something in and then it returns you results. But if you combine it with Algolia, you can tweak your documentation search. The product is initially made for ecommerce websites to return the correct products and optimize their sales. 

‍

But in the end, when you're serving developers, you're also doing sales, especially if you're developer tooling. And for instance, Algolia, it gives you a couple of metrics that are very valuable for your docs team to collect and evaluate. For example, it shows you for which queries it returns no results. 

‍

And this is important, because you don't want a developer to not find any results in your docs. Sometimes the problem is that they used a different word to describe the feature. And for example then you can use Algolia to define pseudonyms, so in the future when a developer searches for this keyword, it will return the right feature and the right pages. [0:22:00]

‍

Richard Rodger:  [0:22:00] That's really powerful. That is really powerful. [0:22:01]

‍

Michiel Mulders:  [0:22:02] Yeah. And another thing is as well, we had a problem at Adera where if someone looked up a specific feature, it would return first the reference pages and the release notes. But they would first return the release notes and that was a big problem because only result number eight was the actual reference implementation; result nine was the feature page. So, that was a big problem. 

‍

And usually, from research, the average click positions should be maximum three. So, the click position refers to which result in the list of results the user clicks. Usually, it should be the first, the second or the third, not the eighth result. This is also something Algolia allows you to tweak. 

‍

You can define weights for certain concepts or for certain pages. So, what we did was, we ended up lowering the weight for the release notes, because only a very limited portion of people reads the release notes. And that allowed us to boost the right pages to the top and also put it in the first place when searching for this. [0:23:10]

‍

Richard Rodger:  [0:23:12] Michiel, let me ask you a question. Is this – you cover all this stuff in DevRel Uni? [0:23:17]

‍

Michiel Mulders:  [0:23:18] Yeah. All the knowledge is covered. [0:23:19]

‍

Richard Rodger:  [0:23:20] Wow, okay. Very cool, very cool. Very cool. Wow. [0:23:24]

‍

Michiel Mulders:  [0:23:25] So, yeah. It's a very fun thing, and it's like – people think documentation is just about writing content, but you can already see there is a wide range of analytics and tooling skills you need to make it really good. [0:23:39]

‍

Richard Rodger:  [0:23:39] Yeah, take it to the next level. Okay, that brings us to the next topic that we – we were talking about stuff before we went on – which is content analytics. And you just mentioned one aspect of it there which is analyzing the search activity on your site and then tuning Algolia and helping that to identify missing parts of documentation. But let's just step back a little bit and introduce the subject of content analytics and how – what you do with it. [0:24:11]

‍

Michiel Mulders:  [0:24:13] Yeah. So, in general, content analytics allows us to first of all detect problems in our docs. If there are a lot of people dropping off at certain pages. Maybe there is an unclear call to action or a link is broken. And in general, we use it to measure how many people complete our Getting Started section, how many people read certain tutorials. And it allows us to also find content gaps or just in general find problems in our documentation. [0:24:48] 

‍

Richard Rodger:  [0:24:51] So, how does it work? Is there specialist tools or what do you use? [0:24:54]

‍

Michiel Mulders:  [0:24:56] So, personally, I prefer using Google Analytics, because it's still one of the better tools. With the SiteNote, suing Google Analytics in the EU is not very legal. There are alternatives, but they do not return the same results. So, if you are analyzing the US segment of your documentation, then you're good. 

‍

One thing specifically I really like using is the user flow analysis that Google Analytics provides. You can say – we often link people to the landing page of our documentation. Google Analytics allows you to set a landing page, so obviously, we set it to the first page. And then we can analyze where people navigate on our docs. 

‍

For example, we want to know how many percent – what the percentage is of people are completing or getting started. You can see 50% dropped off after the first page, and then they went to three different pages. So, it helps us understand and optimize and do A/B testing. If we make changes, does it improve or did we make it worse? 

‍

And for example, one of the funny problems we had was, a lot of people were jumping back and forth between tutorials, and we realized that at some point, we forgot to write down one requirement, which was pretty key to complete the next step. And the next step assumed you had this requirement already done. 

‍

So, a lot of people were jumping back and forth between the two tutorials, creating the key they needed and then going back to the original page. So, that's something that you can solve or can detect using the user flow. And also, we want to understand how many people drop off and we try to improve this page to see if it improves the drop-off rate or the bounce rate. In general, it's a very neat tool to understand what your users are thinking and doing. [0:26:58]

‍

Richard Rodger:  [0:27:00] I like this philosophy, because a lot of people treat documentation as one and done. You just bash it out; get the text up there, put it live, that's it. [0:27:09] 

‍

Michiel Mulders:  [0:27:11] Yeah, but there's a whole aspect of A/B testing. We design the process with monthly meetings; we try to define 3-5 goals we want to improve or problems we detected We tried to implement the solution and measure it before we implemented it, and then measure it after a month again or after two weeks and see if it changed or not. We're not doing A/B testing where we show 50% of the users one version of the docs, and that's too much. We just implement the change and see what results it gives. [0:27:40]

‍

Richard Rodger:  [0:27:41] And where did you learn this practice of content analytics? Is it something that you guys came up with naturally yourselves? Did you learn it somewhere else? [0:27:48] 

‍

Michiel Mulders:  [0:27:49] It happened by chance, I think. I was just exploring Google Analytics and see what I could do with the data it gave me for our docs website. And I stumbled across the user flow analysis. And you can even – the fun thing is, you can segment users; you can segment the new users and existing users or all the users. So, it's also very interesting to see what new users are doing and how it differs from existing users. [0:28:18]

‍

Richard Rodger:  [0:28:20] Apart from DevRel Uni, where you cover this material I'm sure, have you done nay conference talks on this? Because this is super interesting. [0:28:27] 

‍

Michiel Mulders:  [0:28:27] Not yet. 

‍

Richard Rodger:  [0:28:28] You probably should. 

‍

Michiel Mulders:  [0:28:29] I'm in the process of applying to multiple conferences to discuss some of the things from the DevRel Uni. [0:28:36] 

‍

Richard Rodger:  [0:28:37] Okay, so if anyone's running a conference and you're listening to this, [inaudible, 0:28:37] sends you a proposal on content analytics, I want to see it. From my experience, talking to lots of people in the developer relations space and just generally in the software industry over the last 20 years, content is such a poor stepchild. And almost universally, my experience of companies that have done it – and my wife was a technical writer in SAP in a previous life, so I've insights into how they did their stuff. 

‍

And the idea of content analytics is not something that I've ever heard executed to the extent that you are doing it. Do you think it's starting to become more widespread? Do you think people are starting to realize that they have to do it? Or is it still something that most people are hardly even aware of, like me? [0:29:38] 

‍

Michiel Mulders:  [0:29:39] I think a lot of teams know they could or should do it, but the problem often is, docs teams are under immense pressure, I would say, often. They're very understaffed, in many companies at least, maybe not the bigger enterprise companies. And they have a lot of work already. But keeping in sync with the product team, the engineering team, sometimes even syncing with marketing, creating new tutorials. 

‍

So, I do understand that they sometimes do not have the time to look into the analytics. I'm also a bit promoting for – or rooting for documentation people that are free, skilled and these kind of analysis thing. They're focused on the structure, the analytics, the documentation search, and they don't have to care about all the other things like creating content. They just focus on optimizing the overall developer experience of your docs. And if you have someone – if you're a Stripe or another company, you definitely have the budget, I assume, to hire someone that specifically does this work. And it will pay the benefits. [0:30:49]

‍

Richard Rodger:  [0:30:50] It does sound like there's a lot of overlap with the traditional social marketing activity, that type of stuff. [0:30:59] 

‍

Michiel Mulders:  [0:30:59] Yeah. It's the mindset of regular marketing content analytics applied to documentation. In the end, it's a pivot as well. [0:31:07]

‍

Richard Rodger:  [0:31:08] It's not rocket science, but I –

‍

Michiel Mulders:  [0:31:10] No. 

‍

Richard Rodger:  [0:31:10] -very few people do it. 

‍

Michiel Mulders:  [0:31:13] True. 

‍

Richard Rodger:  [0:31:15] Okay, I think that is – that wraps us up. Michiel, thank you so much. Super. [0:31:24] 

‍

Michiel Mulders:  [0:31:26] Thank you. 

‍

Richard Rodger:  [0:31:27] Super interesting stuff. And – because I do this a lot and talk to a lot of people, I think I know everything, but no. That's – I always like having new guests; you always learn something new. I can tell you right now, this idea of content analytics is something that I'm going to start thinking about how we can use ourselves. Thank you so much. And please do a conference talk- [0:31:51]

‍

Michiel Mulders:  [0:31:51] It's a pleasure. 

‍

Richard Rodger:  [0:31:51] -dev rel on it. This needs – people need to know about this, especially the practice of it, and even things like Algolia, wow. Of course, you can tweak it; you just have to go for it; actually do it. [0:32:05] 

‍

Michiel Mulders:  [0:32:04] Spend time on it. 

‍

Richard Rodger:  [0:32:08] Thank you so much, thank you so much. 

‍

Michiel Mulders:  [0:32:10] Thank you. It was a pleasure. 

‍

Richard Rodger:  [0:32:12] Awesome. Bye-bye. 

‍

Michiel Mulders:  [0:32:14] Bye-bye. 

‍

Endnote

‍

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

‍