Me, myself, I work in marketing, so I'm going to start with this. This actually one of our booths at one of our events, what we do is we build brand. We build awareness. We stand on booth, we talk to folks coming to hear about us, learning what kind of tools they use, etc. I also give talks, I also give workshops, sit on podcasts, write blog posts, write tutorials, etc. A lot of stuff that's geared around user acquisition, user engagement, bringing feedback from the communities back to our teams, from our marketing team.
For example, there's this new technology we need to write about, there's this new way of thinking we need to adopt, or even the whole organization really. And we're also this kind of bouncing ground for ideas on the marketing team. Someone can just go and say, hey, I have this idea. Do you think this will work? And say, yes. You could do even better if you word it slightly differently, you're going to address it better, you're going to resonate with your audience better, that kind of stuff we can do because we're engineering stuff on the marketing team. So we're kind of closer together with them.
Product it's pretty obvious. So you want to make sure that what gets to the users is the best fit for the actual users. So we help with rapid ideation and getting feedback back. Whether that's kind of prototyping ourselves, whether that's going to the actual users, kind of demoing things, and getting that feedback to immediately get acted on, that kind of stuff through user research, through just kind of interviews, etc. That could be product management. Again, lots of docs, lots of content, probably going to be written. And that's kind of the most common threat here, which is like content. And by content I don't mean just written, it could be videos, it could be talks, it could be podcasts, it could be many ways of doing content.
And then we have engineering. So obviously there's going to be some development involved, there might be some development involved, like you might have an API, someone needs to maintain it, someone needs to write to run the open source GitHub community that we have, manage all the contributors, that kind of stuff, happen within engineering. There's also recruitment, so kind of, obviously you want someone to talk to the audiences at various events, et cetera, and act as this kind of liaison. And that's obviously what DevRel people sometimes do. In some cases, not too often, not too many times, but anyway, we've kind of established that DevRel is a lot of things to a lot of different companies, a lot of different people. Techniques change, approaches change, kind of tactics, strategies, they change, but the main objective is the same, we're kind of there to liaise between developer communities, we present the company to developer communities, present developer communities to the company, and yeah, we work on a very hectic schedule, no two days are the same, we need to prioritize ruthlessly, we need to deal with a bunch of stakeholders, and yeah, a bunch of that actually sounds like tech leadership, to be honest, to go back to my story originally, there are always many things, but so is engineering, and especially engineering leadership, you're working in this kind of weird schedule, people are much more important than pure tech outputs, and yeah, we're two sides of the same coin, you could say. That's the only gif I had, by the way. Anyway, let's look at examples. In this part of the talk, I'm going to just talk about a few areas where you could collaborate with DevRel, where you could get the most value out of us, and for us also, vice versa, where you could provide most value to the DevRel team. So yeah, let's get technical, because trust me, we are technical.