On this episode, we've got Sebastian Witalec from Weviate to chat to us about his work at the company and his role as head of DevRel. Weviate is rather popular in the AI space. It's an open source vector database that allows you to store data and vector embeddings from machine learning models. It's similar to putting information on an XY plane. Similar data points will have similar coordinates. This makes it easier to organise and use your data.
We won't get too technical in this description, but safe to say Richard ensures that all the nerdy questions are answered during the episode. So Weviate is a database; does this mean it's similar to the document stores of fifteen years ago? Well funnily enough, Sebastian's previous role to this one was DevRel at MongoDB.
A year and a half ago, he met the CEO of Weviate and had that lightbulb moment. He knew that this was a brand new way of doing data storage. So he jumped to Weviate, and sure enough, a year and a half later, vector databases are all anyone is talking about, and Sebastian gets to be at the forefront of it.
One of the most important things to Weviate, and Sebastian personally, is joy. They want to not only create with it, but for people to experience it when they use Weviate to build. They want their developers to take joy in their work and they believe that their wider community should be just as important as their customers. This is a really special perspective to have, and we're so glad Sebastian decided to join for this discussion.
Reach out to Sebastian here: https://dk.linkedin.com/in/sebawita
Check out Weviate’s services here: https://weaviate.io/
Find out more and listen to previous podcasts here: https://www.voxgig.com/podcast
Subscribe to our newsletter for weekly updates and information about upcoming meetups:
Join the Dublin DevRel Meetup group here: www.devrelmeetup.com
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.
Vector databases are the new-new database, and today I am speaking to Sebastian Witalec of Weaviate, all about how you can implement wonderful new AI algorithms like Retrieval Augmented Generation, which is also the new -new algorithm. We speak about how telling your users not to use your product is one of the best ways to build trust. We talk about the difference between developer relations metrics and developer relations signals, and of course, we talk about developer relations leadership. [0:00:52]
Main Interview
Sebastian Witalec
Richard Rodger: [0:00:54] Sebastian, welcome. Welcome to the Fireside with Voxgig Podcast, talking about developer relations. You are head of developer relations for Weaviate, a rather popular, fashionable database in the AI vector database space. So, we’re delighted- [0:01:10]
Sebastian Witalec: [0:01:10] Yes, it is.
Richard Rodge: [0:01:11] -delighted to have you here today. My first question is going to be, take us from zero to hero, about what the Weaviate database does. [0:01:20]
Sebastian Witalec: [0:01:22] Yeah, thank you. What Weaviate is – it goes almost in the name; it’s a vector database. And what’s so special about it? The idea is that many people have heard pretty much of machine learning models and machine learning in general. And there is this whole idea that there is those – there are those models that allow you to put in some data. And as a response, you get this thing which is called a vector embedding, which literally is a bunch of numbers.
Certain – very much like a picture is defined by a bunch of pixels which are numbers. In the case of vector embedding is just how AI or machine learning understands the meaning of information. And the cool thing is that if you imagine a vector embedding was just X and Y position, it’s a place in the map. And two places in the map that are close to each other are automatically similar.
And following that concept, if you have a billion objects, you could create vector embeddings for them. And then if you search for a kitten, you’ll be able to find a cat and maybe dog and maybe other pets, because they’ll be close to each other. But if you search for a car, you’re not going to be anywhere near that.
So, expanding on that, the vectors are a lot deeper; they contain a lot more information than that. We’ve created a database that – it was built from the ground up, on the idea of working with vector embeddings. Instead of – sorry, so that it allows you to query and run super-fast searches across huge volumes of data, and this is super-popular. So, this is the bread and butter, the most basic stuff. But you can do a million other things on top of it as well. [0:03:19]
Richard Rodger: [0:03:21] And just to put it in context, the usage that I would be familiar with is using for – using it in parallel with generative AI. The basic idea being that I have some knowledge base or some domain. I put my query in; it goes through Weaviate and it generates a subset of relevant information, which I then use as part of the prompt to ChatGPT or something like that, right? That seems to be one of the- [0:03:56]
Sebastian Witalec: [0:03:56] Yeah, that’s-
Richard Rodger: [0:03:56] -big use cases.
Sebastian Witalec: [0:03:57] Yeah, that’s one of the big use cases, and there’s a term even know called RAG or Retrieval Augmented Generation. And that’s really cool, because it’s a two-step thing, where on one step you have your query, that allows you to find all your relevant pieces of information first. And a second part is, I found what I was looking for. Let me put it into an LLM, or a large-language model like Chat – like GPT, and say, “Given this context, please answer this query for me.”
And this is super cool, and why this is really cool is because if you look at those models, usually, they are trained at certain time and they’re stateless. So, if you keep asking me question or providing information to that model, the model doesn’t learn from it from then on. And if you are an enterprise, you wouldn’t necessarily even want GPT to know about your internals, but what if you could use the power of GPT to answer questions based on that.
So, the power is, maybe use a vector database like Weaviate to do the pre-querying part; gather all the relevant information and then passing it on. Say, “Given this context, write me a report that I can send to my CEO as my report.” And you have this beautiful, structured content and it’s super powerful and really fast.” It’s great. [0:05:23]
Richard Rodger: [0:05:23] Awesome. We are going to talk about developer relations, but I’ve got to get my inner programming nerd on first, so I do have a couple of follow-up technical questions. How do you create the vectors in the first place? I have all this raw data; let’s – it’s the plays of William Shakespeare or something like that, right? Do I have to define a vector space or mapping in some way, or does Weaviate do that for me? [0:05:47]
Sebastian Witalec: [0:05:47] In a way – that’s the thing. We did works in tandem with those machine learning models. So, usually how your vector space is defined is based on that model, understanding of the world. If you have a model that is, let’s say, trained on medical data, any content that you send into it, it would be able to generate a vector that is based on that. If – but if you send something that is completely unrelated, what it will give you back is nonsense, because it goes, ‘”I don’t know about it.” And it’s very much – it’s – that’s the idea.
The way that you would define space using an OpenAI other model, which is a very popular one, or maybe you use the Cohere multilingual model, which is also pretty awesome, what you do is say, “I’m using this model.” And now you send let’s say 10,000 objects into Weaviate. What Weaviate will do is grab each of them, use them all to generate the vector embedding, and it stores the data with the vector together. So, you don’t even need to worry about it, that the vectors are involved; it happens behind the scenes for you. [0:06:57]
Richard Rodger: [0:06:58] That seems to be a key technical difference of vector databases with some traditional datastore. And traditional datastore, I can put anything in; I define my own little scheme and I can put anything in. But with something like Weaviate, I do have to say my data is with – is in respect of this model, and that defines- [0:07:17]
Sebastien Witalec: [0:07:17] Yeah, exactly.
Richard Rodger: [0:07:17] -the mapping for me.
Sebastian Witalec: [0:07:20] Here’s the thing. You can still use any kind of data. Weaviate is still a database that allows you to bring in any kind of information. And also, you can bring in different modalities; you can have images, audio, video. You can work with text and even all of them combined.
But you can also have an object; say, “I have a book that has a title and description and there’s also and a data burden, and all of this,” so you have all the flexibility. But the vector part of how the search is done or how that space is done is attached to the model that you say, “Cohere would be really good for my data, because it is written in German, English, French, Chinese and all the other ones. And I want a single query that any human language I put in, I want to be able to get a response across all of that content.” So, that’s the beauty of it. [0:08:12]
Richard Rodger: [0:08:14] I get the similarity search thing, were I put in kitten and it gives me back cat. What other types of queries can I do? [0:08:19]
Sebastian Witalec: [0:08:21] Yeah, it’s a good question. Similarity across text is one of the parts of it, and also being able to work across multiple languages. Because – and this is the beauty of it, with those multilingual models, that a sentence in English or German or in French, if you send it into that model, it will spit out pretty much the same vector, if it’s the same meaning. So, multilingual is one of them.
We also have something that we’re super proud of; it’s – we call it hybrid search. That allows you to combine a keyword search together with vector search. In some cases, maybe the model that you’re using is very well-trained on most of the content that you have, but maybe you want to – and this is actually something we did with our own documentation. Maybe there is some terms that are only relevant to your docs.
Obviously, the model wouldn’t know something like what’s in your text? I don’t know. I never seen it. So, for that, you may want to combine the keyword search, because the keyword would find those. But for anything else like how do I delete an object, the model would understand that and be able to find it.
We talk about – the multilingual part, you could have the keyword search, which is super powerful; RAG is one of it. And there’s also different kinds of applications that maybe you can use. You could build a chatbot where you could combine the functionality of these generative models.
Like, we mentioned ChatGPT or we have Palm 2 or there’s a bunch of other ones where you could treat the Weaviate as their long-term memory. Then suddenly, you could have a conversation and a generative response; it works like a feedback loop, where you could park – put it back in a database. And then next time somebody asks, you’d already used the previously generated response as the next response. And it evolves over time. [0:10:18]
Richard Rodger: [0:10:19] Yeah, it’s exciting stuff. Do you think this is similar to the wave of document stores that came about about 15-20 years ago? You had Mongo – and you had – you have previously worked in Mongo, so you have an interesting perspective there – Catch DB, that sort of stuff, going all the way back to the Java object databases.
And there was this huge eruption of all these different databases, all with the same basic idea that they were NoSQL. And now we’re seeing – we seem to be seeing the same sort of thing with vector databases. Is this another changeover of the eras? This is – it seems like there’s lots of vector databases now, which is good for everybody. [0:11:08]
Sebastian Witalec: [0:11:09] Yeah, absolutely. Honestly – and this is the thing. Like you mentioned just a moment ago, I worked at Mongo DB just before I joined Weaviate, and honestly, I had the best job in the world. I was the keynote producer, and it was super creative, a really fun job that I was doing, was part of the dev rel organization there.
And then what happened was that at one point, I met Bob Van Luijt, who was the CVO of Weaviate, and he explained to me the whole idea of vector embeddings, what are vector databases and everything. And I went with – in my head, I had this spark, and I said the same thing as you said. It’s like, “Wait, this is Mongo DB 15 years ago. There’s a new wave. There’s something big happening.”
And that was a year and a half ago, and a year and a half ago, almost nobody knew what vector databases were. And now everybody tries to talk about it. And there’s even some jokes like, is Peppa the Pig going to add vector databases to her website or something? Because everybody tries to do it, because people realize that this is pretty serious; this is very powerful. And it is going to change the way we do things. I don’t think it’s a replacement for the existing databases; it’s just a new kind of database. It’s a new kind of – something that- [0:12:33]
Richard Rodger: [0:12:33] It’s a new capability.
Sebastian Witalec: [0:12:34] -unlocks new potentials, yes, absolutely. [0:12:36]
Richard Rodger: [0:12:36] I – yeah, I think I might have had a tiny bit of experience with something similar pre-COVID. Because I was building at the time a search engine for technology conferences, and the search system we used was something called Vespa, which Yahoo had open-sourced. Which had some sort of machine learning/vector element to it, although I didn’t understand how to use it. [0:13:01]
Sebastian Witalec: [0:13:03] Yeah, Vespa-
Richard Rodger: [0:13:03] Is that similar or is that a pre-cursor? Where does that fit into the evolution? [0:13:10]
Sebastian Witalec: [0:13:11] I would say that Vespa probably would be one of the closer-aligned competitors that we have. They’re not exactly work in the same way, because there’s this whole distinction between dense vectors and sparse vectors. And I don’t want to get too near your – too deep into it. But what those machine learning models generate, they tend to – they’re the dense vectors. And usually you use that other model; that’s 1,500 dimensions.
Whereas sparse vectors is more like, for every keyword that you have in your context, you have a new dimension. If you have 100,000 different keywords across all of your content, then your vectors will be 100,000 deep. That’s the differentiator, so later on when you search through content, saying, “This content contains this, this and that.” But the ideas are very similar in many ways, but I’m not a Vespa expert, so I don’t want a deep tool to fashion that, because- [0:14:12]
Richard Rodger: [0:14:12] Because Weaviate is the dense vector on the side of dense vectors.
Sebastian Witalec: Yeah.
Richard Rodger: That gives me confidence.
Sebastian Witalec: It’s a smart dense vector.
Richard Rodger: Yeah. That gives me lots of stuff to Google, or perhaps ask ChatGPT later. Are you guys taking the same kind of philosophical approach to developers that people like Mongo and Catch DB did back in the day? Very friendly to developers, very open source. Is that part of the core strategy? Tell me; how do you guys see developers?
Sebastian Witalec: Here’s a fun thing. I’m going to take a tiny step back, but one of the main mantras or the keywords for us, is joy. And this is really crazy, but the way we want to build the company, we want to build a company with joy. Everything we do is related to creating joy. And even what we keep saying is, we want to create something that allows you to feel joy while you build with Weaviate.
This is one of the first things we want to do; we want people to really enjoy the whole process and everything. And then I can’t stress enough how often we say these words, and often, the arguments are won and lost in Weaviate based on joy; it’s incredible. And open source is something that does bring a lot of joy, and this is – there’s no doubt about it. And open source, the way we build the company and the product, it’s very open source.
So, we do two things. We build our product in open-source way, but also we have this series of metablocks, where we in the open say how we run maybe meetups, how we run our company remote. How do we do – deal with holidays etc. So, we build both the product and the company in the open and it’s pretty awesome.
Richard Rodger: Yeah, there’s an observation around this developer relations stuff, where some companies try to do it, but it’s not believable. And then other companies do it, but it’s very clear that they care about developers. Developers, you can see, are heart and soul for them. It’s very had to fake; isn’t it, caring about developers?
Sebastian Witalec: It is; it is hard to fake it, because it comes across really fast. The moment you have the first conflict, if you don’t care about the developers and your community, it will show. And very often, we will drop everything, if what we do causes pain or makes it difficult for people that use our product. Any discomfort or making it hard to work with, we’ll handle it.
And even right now in the last couple of weeks there was – we discovered a bug that was affecting one type of queries. And we went, “This is too important. It affects a whole number of users.” And the whole argument in the company wasn’t how many customers it affects; it was how many people in the community were affected by it. We deeply care about our customers, because they are very important, but we won’t deprioritize our community if there is something that also affects them; this is important.
Richard Rodger: And does that vision, does that leadership come right from the top, form the founders, from the CEO? Do they have that – do they have those values?
Sebastian Witalec: Yeah. This was something. When I was initially talking to Bob about joining Weaviate, I told him a few things. One of the things was, I will never lie on behalf of the company or for any – whatever reasons. So, whatever we do, it has to be in the open; it has to be honest. And it has to be for the good of the people who use the product.
And he was absolutely – and then I also told him, if I ever walk into a room and I see that Weaviate is a bad solution, I will tell customers or the community people not to use Weaviate, and I need him to be fine with it. And he was like, absolutely. And this one is very similar to what I learned at Mongo DB, where if something is not good for the customers or for the developers, it’s better to stop them from making that mistake. Because going backwards or – I invested six months. This is such a nonsense; it’s just not worth it for anybody. It’s from the top to bottom and from bottom up; it’s in all directions. We really care about that.
Richard Rodger: It’s such a powerful strategy, to tell your customer not to buy from you, to say, “We’re the wrong solution.” And it takes a lot of courage and a lot of companies are afraid to do it. I know that when I have done that, they come back maybe a year later, two years later, when it is the right time, and they’re an even better client, an even better customer. Because you showed that they were honest; they can trust you. You’re investing in trust. But it's – people have quarterly sales targets; it’s hard to be honest, right?
Sebastian Witalec: It is, but that’s why us being an operators’ company first of all, it’s – if you’re very successful at getting 1,000 customers that pay us a lot of money, but there is only 500 people in the world using Weaviate, then we also are going to fail. Because what you need is – sometimes there’s customers coming, like, “I love Weaviate, but now I need to hire somebody with the expertise, with the experience and everything.”
Where are they going to find someone? There’s nobody. Okay, we’re going to go to a competitor, which seems to have a lot of people using your tool. So, that’s super important. This is why we would never deprioritize the community, because it should be a win-win for everyone. And also, you’re part of our community; build a career around it. I will help you. I will anyone that builds a cool demo, I want to show it. We have this podcast we call Weaviate Air. We bring people over to share their hackathon projects or projects that they do, and businesses that they try to create. [0:20:36]
Richard Rodger: [0:20:37] Awesome. And the other aspect to this that I wanted to ask you about is developer relations leadership. We can all have these principles, and a lot of people who work as developer advocates have the same principles, but often find it a little bit difficult if leadership doesn’t share these values.
And it sounds – you sound to be in a very lucky situation where there’s alignment all the way from the CEO down. In your position as a developer relations leader, let’s talk about that; let’s talk about how you built your team, what your team does. You’re still in startup mode, so that’s different from the type of dev rel you used to do in Mongo, which is an established company. [0:21:20]
Sebastian Witalec: [0:21:21] Yeah, there’s so much to unpack here. Trying to do dev rel or doing dev rel at a startup is a completely different beast than working for an established company. And I could even explain; my team, it – I always say that it feels like three teams or multiple teams. I have five people in my team working with me and we’re just about to hire a sixth person, hopefully by the end of next week. But it’s such a – the big thing is variety of tasks and stuff that we do. And anyone that is in dev rel and hears that is like, “I wear 10 different hats.” That’s such a dev rel thing. [0:22:01]
Richard Rodger: [0:22:01] That’s such – it is, yes.
Sebastian Witalec: [0:22:03] It is. But the kinds of hats we wear that are so different, that I only have only one. Out of these five people, there’s only one of them actually has a title of developer advocate because we do such different stuff. For example, in my team, I have two people that deal with documentation and education; this is their sole focus. Then I have two other people that – one is a community manager; the other is a community support person. And I want to come back to the community support, because that’s a really important point. And then I also have Zen, who’s my official developer advocate.
And there is a bit of overlap, like for example JP, who does documentation and education. He’ll often do workshops; he’ll often give talks at meetups. But each of their goals – if you have the one thing that you should succeed at, is different between these three different groups. When I was at Mongo DB and I was doing – I was a keynote producer, I had one job. I didn’t have to think about juggling 27 different things. The one job I had was already extremely demanding. But in this case, we’d go, “Yeah, we have one job,” but really you have 10. [0:23:22]
Richard Rodger: [0:23:24] Who do you report to? Where does developer relations fit in the Weaviate corporate structure? [0:23:29]
Sebastian Witalec: [0:23:31] In our case, I report straight to our CEO. [0:23:33]
Richard Rodger: [0:23:35] Very good.
Sebastian Witalec: [0:23:35] Our CEO loves dev rel. This was something super important for him from day one, so I report straight to him. And we also have a very interesting model, because we are going with a flat-ish structure where we are divided into cells as opposed to departments. And a cell usually is like a living and breathing organism that does one job, except for my cell, because my team does three different things, but that’s fine. It’s dev rel, right? [0:24:03]
Richard Rodger: [0:24:03] It’s dev rel, yeah; it’s dev rel. [0:24:04]
Sebastian Witalec: [0:24:05] But that’s the story. And one of the things that I had to learn really fast – because this was my first proper leadership position, something that I had to learn really fast is, put more effort on mentoring and enablement than trying to get to perfection myself. There was so many times where I saw somebody working on something and I was like, “Yeah, we could do it this way.” And then I had to learn really fast that I can’t speed myself into five different places, and I focused on enabling people in my team.
And even at one point I said, “Listen, ask for forgiveness, not permission. I’m never going to punish you for anything that you do. If you make an honest mistake because you try different things, that’s okay.” If ever I will have a problem with anyone, if they didn’t try and if they weren’t brave enough. And that was amazing, because it went from a bit of handholding to a bit of overseeing to – people do stuff without me. Then knowing until it happened faster – it happened later.
And then – just like I earlier mentioned that there was this issue that we jumped on to help out. I was offline, and then when that came out, JP in my team, he noticed that something was happening; was communicating with our CTO, came up with a plan. And then when I woke up at 7.30 in the morning, instead of getting up and getting some breakfast, I saw the message and I started responding. And it was so great, because he just thought about it, right? [0:25:39]
Richard Rodger: [0:25:41] Yeah. That’s an important leadership skill, which is to let people make their own mistakes and learn. The person who’s made a mistake is more valuable because they’ve learned something. You should never fire somebody because they make a mistake. The person with lots of mistakes is the person who’s got the most skill.
The – it’s really inspiring, the way that you put things together in Weaviate, and especially the structure that’s being created. But one of the challenges that you always have in developer relations is this cross-functional thing, where you have to integrate what you’re doing with the rest of the organization, align with marketing, find out what core engineering is doing. Is that part of your job? How do you manage that side of things? [0:26:33]
Sebastian Witalec: [0:26:36] Dev rel is that unit – and I’m preaching to the choir. I was literally – we are in the middle of everything- [0:26:43]
Richard Rodger: [0:26:43] But it’s really hard.
Sebastian Witalec: [0:26:43] -almost as it’s happening. It’s super hard. It’s had and it’s super simple at the same time. It all goes down to communication and truly caring. And you have to have one thing; you have to understand who you are working for. And in my case, you go, ‘You work for Bob. He’s your boss.” I was, “No.” I work for the community. I work for the developers that use our tool. I am their first advocate.
The way I see it is, yes, I want to – sometimes tiny bit bridge towards and say, “We have this and this.” Get them excited. But in reality, I was like, “What can I do to make it successful with it.” But for me, the success is communication and collaboration. I maintain a close relationship with people across different teams, so be it the head of marketing or head of the growth team. Or I work very closely with our designer. I work closely with our HR. I work closely with our engineering.
And – but the thing is, what I don’t necessarily want to do is, I never want to be the bottleneck. I have this thing where I always say, “I want to create everything in such a way.” So that if one day I get hit by a car – and I know this is very dark, but if one day I get hit by a car, I want people to go, “Sir, we like Sebastian, but we continue on.” And that’s super important to me.
To the point for example, how – let’s say how we do releases, it’s very interesting. Because as part of the release, we take care of writing the release blog posts, and we take care of updating our documentation with the release parts and everything. And the way we do it is, when we defined – for weeks, there’s a release – we have one in one week, but at least four- [0:28:31]
Richard Rodger: [0:28:31] Goodbye.
Sebastian Witalec: [0:28:31] Four to – yeah. 4-6 weeks before, what we do is, we connect up with either the CTO or one of the heads within the engineering team, and we say, “What goes into the release in four weeks, or 4-6 weeks from now. These are the features. Great. Next step, who are the engineering experts.”
So, what happens, for each of those announcements, we have a dedicated tech expert that either works on it or defined it in some way. And then on our side, we attach a dedicated developer, a dev rel person. And there’s multiple things that happen. A) you build good relationship with all those engineers, but also, we are the ones that learn everything that comes up. With every release, we end up having this great view. And then at the end of the day, we remove the headaches from engineers. Because let’s face it, most engineers are really great at writing code – not so great at writing text.
And we do that, and this is one example, where we go from the knowledge transfer. As a side effect, we also test the tools, and we find so many bugs; we find so many issues. And a bug also is a Dx. Dx could also be a bug, where you’re just like, “This is too hard to use. Why is this?”
And it’s that communication, but what’s important for me is that I can help and establish this communication, the system. But then I make sure that there’s one or two people within the team that can handle it. So, let’s say, if I want to take time off, I don’t worry that everything will fall apart, and it’s great. [0:30:12]
Richard Rodger: [0:30:14] And it’s harder than it sounds to make yourselves unnecessary as a leader. It’s quite a trick; it’s quite a trick to be able to do it. Sebastian- [0:30:24]
Sebastian Witalec: [0:30:24] You know what’s the hard part? Because I’m talking about getting hit by a car. But it also makes – I make myself very replaceable to some extent. So technically, anyone, if you feel unsafe about your job, that is a terrible thing to do. But my philosophy is, if one day there is a different thing that I want to do, there’s not going to be anything blocking me from moving to the next stage.
And honestly, I have this mission that everyone I work with, I want them to be two – if they work with me for two years, I want them to be two or 20 years better than they were before we started working together. I want to help people build their careers. And if one day there’s a different opportunity, a different crazy thing I could do, nothing blocks me. [0:31:12]
Richard Rodger: [0:31:14] Said like a true dev rel; trust me. You like to do all the crazy stuff. Sebastian, you maybe had a suspicion this was coming; I have the terrible question – metrics. How do you guys measure what you do? Any insights? Any better ways to measure, show value to the organization? Because we always suffer; we always suffer with this question. [0:31:37]
Sebastian Witalec: [0:31:42] We went as a team – there was five of us – we went to – there was also a few people on the dev growth team – to DevRelCon in London just a few weeks ago. And I’m not kidding; three-quarters of the talks were talking about metrics, because it’s like, what the hell are you doing?
First of all, I look at things as metrics and signals, and here’s a distinction. If you look at GitHub stars, for some people that’s a metric; to me that’s a signal. Because the GitHub star indicates that something is happening, something is popular, but there could be very different reasons why there’s – one repo has more GitHub stars than the others. It doesn’t necessarily always reflect exactly the success of the efforts that you’re making.
Having said that, it is still a signal, because if you’re doing really poorly, you’re not going to have – you’re not going to go over 100 etc. But metrics wise, it’s about – and this is something we are right now establishing. We – like working with Common Room, like establishing that, and we are looking at different kind of metrics depending on the functions that we have. Like I mentioned, we have the documentation and learning.
In this case, we are looking at number of views, how much time people spend at different places, how many people for example will go from this place to, let’s say, our cloud services etc. Make those different steps, for example when it comes to customer community support. And I want to come back to that one point later, but with the community support, we’re looking at what is the average time to the first response and to the resolution.
And it’s all about, first of all – and we’re still at the stage where we’re establishing what’s the ground levels that we can then try to improve on. And then with the developer advocacy, it’s like if you’re writing blog posts, again, how much views, how many we get, but also how many reactions we get out of it. We allow people to write comments underneath our blog posts, but also if the growth team or marketing team is sharing, it’s – there’s a new blog post. How much – many reactions do we get? How many follow-ups and how much does it get responded to?
And then likewise we go to events, what happened around the event. If we went to this event and then suddenly there is a spike coming from Germany, that shows that something happened. And you probably know it with metrics in dev rel. There’s no exact science; a lot of it is reading between the lines. But being able to show that there was some impact here or here, it’s important.
And one – the last example one I use is, we’re running weekly online workshops. And it started as a small idea – who is going to come to that. And then the first ones, we had 10 people – nice. We – within six weeks we had 40 people signing up to it. And then the cool thing is that now we – because we captured the email addresses from people that joined those workshops, this becomes a dev rel qualified lead to some extent.
And where it’s important is that I would like to come back to it six months from now and say, “Of all the people that became customers, how many of them went through that dev rel workshops flow?” Because then we could show, statistically people that go to our workshops are more likely not just to sign up but stay with us, versus those that don’t go. Maybe they figure it out themselves or maybe they had some struggles and dropped off. A big part of it is setting up, making assumptions and then trying to prove it later. I hope that answers- [0:35:32]
Richard Rodger: [0:35:33] Yeah. I really like this distinction between metrics and signal, because signal contains the implicit message that you shouldn’t use them as targets. This is the problem we have with a lot of metrics, is they get turned into targets, which is unhealthy. Whereas – and there was a recent – on the Community Pulse Podcast, there was a recent discussion around somebody – somebody was asked to – you need to get X many views on your blog post.
And the dev rel said, “Why don’t I just write listicles.” Which is useless, doesn’t impress developers at all. If you use this idea of signals, you can still use the number, but you take the danger out of it, that senior management might start using it as a target or some sort of performance measurement. [0:36:32]
Sebastian Witalec: [0:36:33] Yeah, absolutely. Because my issue with those signals is – and sorry to interrupt – my issue with those signals is that sometimes if you get a bad actor, you could gamify it. Let’s say- [0:36:46]
Richard Rodger: [0:36:46] Totally.
Sebastian Witalec: [0:36:48] You put a target, like “Sebastian, we need to get 100,000 views on blog posts every month.” I’ll just throw a ton of money at ads, and they’re not going to be ads that will go to even people within our space, just somewhere I know people will be very clickbait-y and everything. And people will come. The conversion rate will be 0.000, but I will hit my target.
I’ll never do that, because I’m an honest fool, but many people would, and I want to avoid that. I don’t want to give people targets or – that are nonsense, that they can gamify. But at the same time, if they’re signals, and if I observe them from the side without trying to necessarily always optimize for them, it can give you a very nice image.
Target-targets are different. If you have like, “I have a target of this number of qualified leads, and dev rel qualified leads, where people went through the journey, connected with us. And we inspired them to maybe build the demo that one day they come around. That’s a real target because that requires proper effort. I can’t fake it; I can’t hack it. If there’s a way to hack, the way suddenly you get a million customers, my God, you could be a millionaire in a day, right? [0:38:07]
Richard Rodger: [0:38:07] We’ll just ask ChatGPT. I’m sure they must be – they must know the answer. One signal that I like – I’d be interested in your opinion on this one – is – and you’ve mentioned communities – is around communities. A signal that I like to see is returning members. So, even if the total audience is maybe low or small, if a significant portion of that audience is returning members, for me that’s a signal that you’re building a healthy community. [0:38:38]
Sebastian Witalec: [0:38:40] That’s where I would argue that that’s not a signal; that’s actually – that is not a signal to me. One example, I would say, signal versus target, is – if you have a Slack – our Slack, we have – recently, we just had our 4,000th member joining our Slack. And the number of people in Slack, that’s a signal to me, because it’s easy to attract people to this kind of joining.
But the true metric here is how many of them are active. How many people we have monthly engaged, monthly unique users or community members. And for me, that’s the real target. Because if we build a vibrant and nice community and you have 400 out of this 4,000 continuously being busy and contributing, that’s great. You may have 400 million and only 20 people are busy – well, you’re failing. But the signal looks nice, but it’s nonsense. [0:39:41]
Richard Rodger: [0:39:43] That’s a really important distinction. It’s quite subtle; that’s clever, that’s very clever. I have one last question; I have one last question. [0:39:50]
Sebastian Witalec: [0:39:50] Go for it.
Richard Rodger: [0:39:51] How did you end up in developer relations? It’s a strange – it’s such a strange job. How do people end up doing this job? [0:39:58]
Sebastian Witalec: [0:40:01] It was the biggest coincidence ever, I will have to say. The story goes – I worked at this – I worked at Experient. It was the first real job I had after I graduated from university, and I was in professional services; I was a consultant. And then one time, there was this guy Trevor, that I used to work with. He was also a consultant and he calls me, and he’s like, “Sebastian. I found the best job for you.” And I was like, “What is it?”
And then he told me the story how he was interviewing for a job at this company called Telerik, and they were – they needed somebody that would go around, talk to people, present and do demos, do coding and everything. And he said, “That’s not the job for me, but I know just the guy.” It was the weirdest thing.
And then I met Dimo, who was running the long – or the UK part of Telerik. And he described the weirdest, most exciting job I could imagine at that time. And after half an hour, I was like, “Wait, so are you going to pay me to talk?” He’s like, “Yeah. You can go around and talk to people. I’ll pay you.” I was like, “Yeah, I’m sold. Let’s do it.” And later we had a proper interview, but it was – for me, it was a massive coincidence. I – until then, I’d never been to a sales conference or a meetup or – I gave presentations, but I never did that. But I got really lucky, I have to say. And then luckily for me- [0:41:42]
Richard Rodger: [0:41:42] Good friend, that guy. Good friend.
Sebastian Witalec: [0:41:43] Yeah, exactly. And luckily for me, I turned out to be good at it. [0:41:46]
Richard Rodger: [0:41:48] Wow. That’s a happy, inspiring story to end with. Sebastian- [0:41:52]
Sebastian Witalec: [0:41:52] I know.
Richard Rodger: [0:41:53]] -thank you so much. Thank you so much. [0:41:54]
Sebastian Witalec: [0:41:55] Honestly, if you want advice on how to get into dev rel, get a friend called Trevor. [0:41:59]
Richard Rodger: [0:42:00] Good friends, and they should be called Trevor. Awesome, the secrets are all here, folks. Sebastian, thank you so much. [0:42:07]
Sebastian Witalec: [0:42:07] I know.
Richard Rodger: [0:42:08] Thank you so much. Bye-bye. [0:42:09]
Sebastian Witalec: [0:42:10] Thanks for having me. It’s been a pleasure. [0:42:11]
Endnote
Richard Rodger: [0:42:12] 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. [00.42.41]