#28 DevRel, say what?!

This is very much a microcosm of odd experiences. So don't judge the rest of the US by what you see in Vegas. Ale wciąż to jest dobry miejsce do spotkań, wiesz, możesz wypełnić wszystkie niesamowite pomysły i co jest najlepsze, nigdy nie dostaniesz do top 10, niesamowitym, w tej samej nocy, więc nie martw się. Nazywam się Maciek Lelusz, to jest evoilutioncast. Dzisiaj porozmawiamy o relacjach z deweloperami, tak? Tak, to nazywa się DevRel. I tylko mały dodatek, nikt z nas nigdy nie był deweloperem, tak? Więc to jak dwa chłopaki, Nie mówię o tym w środku, ale myślę, że ty jesteś osobą open source. Ja jestem, powiedzmy, przedsiębiorcą.

I mniej więcej mamy zupełnie inny sposób do tego, ponieważ DevRel może iść w bardzo inny kierunek. I najpierw, jeśli możesz trochę opowiedzieć o tym, co to znaczy dla ciebie rozwiązanie z deweloperami. Słyszy się, wiesz, naprawdę skomplikowane od początku. Tak, myślę, że jedną rzeczą, która stała się prawdą przez wiele wieków doświadczenia w tym zakresie, jest to, że słowa są napisane i tytuły nie znaczą. Przechodzimy stworzeniem rzeczy, żeby Bring an idea to a short term and then we quickly overmarket that term or it gets overused and somebody wants to sell you DevOps. We had the same problem with digital transformation.

So ways to advocate for outside developers inside the organization. Myślę, że z mojej perspektywy DevRel, kiedy patrzę na to, i coraz bardziej czuję, że największą wyzwanią dla tych ludzi jest, po pierwsze, to, że to jest ważne, oczywiście, to, co powiedziałeś, jak się o tym adwokować, a po drugie, jak możesz używać tych narzędzi czy infrastruktury, które masz, I'm coming from the infrastructure background, so I will always look a little bit through it. So how you can use the infrastructure in the best way to achieve the targets that are not known from the very beginning. So, you know, when you start the project, you have, you know, like a kid in the room full of fog, right?

And there is a guy, I always think about DevRel, you know, there is a guy who is like, grab your hand and say like, come on in, come on this way, come on this way. Here's the first thing that you need to talk with, right? So it's like these games, right? That you have the master of the game. So it's a little bit like this. And from my perspective, that person is basically somebody who will take people on different parts of organization and guide them into one direction. First of all, by tools, and second, through the usually shitty process, right? So that's how I'm thinking about it. Yeah, that's a good way to think about it. I like the analogy of a room full of fog. I often think of as when you're starting out of a project, you're a kid in a candy store, right?

So those are the kind of watchwords or approaches I'd look out for when engaging with developer relationship folk to say, are they being honest and truthful about the advantages? Sure. Are they being honest and truthful about the disadvantages or the trade-offs? Those are the things I want to look out for. Z tego co rozumiem, z Twojej doświadczenia, możesz powiedzieć, że adwokat deweloperowy, czy DevRel powinien być seniorzem, specjalistą seniora, ponieważ jest ogromna ilość doświadczeń związanych z tą pozycją. To jest trudne to powiedzieć, że ktoś potrzebuje pewnego poziomu seniority, albo wypracować doświadczenie innego, nawet jeśli tylko ma rok lub dwa.

I don't know. It could, but it might not. It's a risky assumption, let's say. I think that when I think about DevRel, From my experience is the person who a little bit understand how the, you know, like all the, you know, machinery works inside, under the hood. But basically is the soft skill person. So it's a person who knows how to talk with the people. So the technology came as a second. So the first is like, you know, you can have good relation or bad relation, right? So we like basically looking for good DevRel relation, right? Oh yeah, I love the soft skills versus hard skills.

Jaki jest cel? Czy mógłbyś po prostu wyjaśnić to dla mnie, wiesz? Bo mówiąc, czasami ludzie zauważają, jak głupie decyzje robili, prawda? I mówiąc o tym, to jest takie... O mój Boże, co ja już zrobiłem, prawda? A druga osoba mówiła, że słyszę, że nie sądzę, że słyszę, co planujesz. Myślę, że to jest kluczowe. Musimy wrócić trochę do DevRel. Podkreślamy trochę osobę, personalność DevRel Perfect. Słyszy trochę jak Yeti, prawda? Musisz mieć technologicznego gościa, który ma wielką empatię, wie jak słuchać, jest bardzo otwarty, nie bada.

All these aspects in the end will follow to the target that just the process will be better, right? And I think that that's the important part. Yeah, the billing part is interesting. I've seen through different companies where folks with developer advocate or DevRel fall under either marketing or engineering. It all kind of depends on your company structure. When it comes to billable, I mean, marketing is not directly billable, right? In marketing, budgets are... We believe that if we spend X amount of dollars, we will see Y amount of revenue. And there's... . .

. Impetus of investing in helping customers understand how to use your product better or understand how customers are using your product to bring it back to internal engineering teams is valuable. I think it is inherently valuable. It's how much do you value it and at what phase of your company do you value it. If you're a two-person startup, you probably don't need to hire somebody in DevRel immediately, right? That's probably a too specific role, right? And when I was at smaller startups, A mnóstwo z nas w inżynierii przeprowadzali obowiązki DevRel przed tym, jak byliśmy wystarczająco użytkowni, aby uzyskać pełnią rolę.

So it's not only about selling hours of work or hours of working of the infrastructure or licenses or subscriptions, wherever. It's just another step there. So we want to create so many materials, right? And create that kind of relation with the developers who will use those platforms for them to have a better place to work. And actually use our resources better, right? And I think it's super important because you can create a marvelous product, but nobody will understand. And in the end it will not bring any value to you as a company or a customer or somebody, right? Like what is it if nobody uses it, right? Yeah, yeah. Myślę, że to jest taki sposób, w jaki potrzebujesz DevRel również.

Musisz myśleć, że nie będzie to dla Ciebie przeniesione do dolarów, ale w końcu będzie to dla Twoich kolegów i ludzi, którzy go używają. Myślę, że to jest super ważne. Problem, który mieliśmy, kiedy zaczęliśmy inwestować w DevRel, . . . . Mars Rocket, tak? Ktoś mu powiedział, hej, idź do Walmartu, wiesz, kupić coś do śniadania.

To nie jest dla tego, prawda? Bo oni nie zrozumieją, jak to użyć. Użyją to w nieprzyjemny sposób. Więc relacja deweloperów to jedna część, ale myślę, że jest też wiele relacji do infrastruktury, do, na przykład, zespołów właścicieli produktów. Więc nie tylko dla deweloperów samych, jest to bardziej relacja rozwoju biznesu. I myślę, że ciągle mówimy o DevRel, i próbowałem to podkreślić. Wszystkie umiejętności DevRel są ukryte. Ktoś w marketingu produktowym ma pewne umiejętności DevRel. Zna jak komunikować się z publicznością i musi zrozumieć produkt. .

So you're kind of overpaying and underutilizing at that point. A good customer success or a good account manager or a good DevRel folk will say, ah, you're running this kind of company. Sure, we have 80, 90% more features, but here are the 20% features that matter to you and right now and here's why. And being able to understand and kind of outbound engaging. Sometimes it's specific to clients, but other times it's let me write a blog post on how this particular feature or feature set helps this company do something else. So I think there's a lot of researching and crafting a narrative because stories are what help us understand the utility of something.

A dobry storyteller pomoże nam zdobyć prawdziwy używak. Myślę, że jest jeszcze jedna rzecz na temat storytellingu. Storytelling to jedna rzecz, a druga to rozumienie tego, co robisz. Nawet jeśli masz narzędzia i ktoś ci powiedział, że te narzędzia będą dobre dla ciebie, to musisz być osobą, która chce to usłyszeć. I myślę, że kiedy wygrasz DevRel, . . . .

Jest coś, o czym się zastanawiam cały czas w DevRel. Zawsze musisz mieć skalę lub kompleksność. Myślę, że kompleksność jest najważniejsza. Jeśli Twoje produkty są kompleksne wystarczy ktoś, kto będzie przetłumacznikiem. Od tej części do tej. Co ja widzę, my dużo pracujemy z kontainerowymi infrastrukturami, zarówno na przerwie jak i w górach. Widzimy, że ludzie zazwyczaj nie używają tych narzędzi w sposób, w jaki oni byli zaprojektowani przez kreatorów. I co ja widzę, największą wartością DevRel, tak to nazywamy, jest to miejsce.

. . Jak oni procesują świat. Słuchajcie. Są ludzie, którzy są otwarte i chcą iść z ideami kogoś, a są ludzie, którzy nienawidzą innych. Myślę, że DevRel wziął narzędzia, powiedzieli im, że to narzędzia są dla kwiatów. Nie włożcie je w twarz i spróbujcie wyczyścić swoje narzędzia. Kiedy wszystko masz jako kwiat, wszystko wygląda jak kwiat. Tak.

And again, architects are another role that every company is going to implement what they think architects should do slightly differently. Zostało się takie myśl, że jeśli masz architektów przedsiębiorstw, to powinni się zainteresować i robić design. Gdzie myślę, że DevRel naprawdę działa, to gdzie nie masz architektów przedsiębiorstw, gdzie wiele firm nie mają tej roli. Będą mieć seniora inżyniera, stafu inżyniera, który będzie prowadził projekt. I to jest ok, no, pozwólcie mi poszukać i zrozumieć, jakie są właściwe wybory. Tutaj jest to, co jest możliwe i pozwala w mojej organizacji i zrozumieć intersekt, jak mogę używać DynamoDB w sposób, w jaki moja firma jest szczęśliwa i służy mojemu użyciu.

Albo może Dynamo jest niebezpiecznym odpowiednikiem na to. Wiesz, więc myślę, że to, gdzie DevRels naprawdę brzmi, When they're bringing ideas to folks that don't have the advantage of having somebody of that deep technical expertise in their team available to help guide those decisions. Yeah, because when you have somebody who can make decisions, you don't need to do any decision, right? So it's a very safe place to be. Yeah, I get you. So if you have an architect, then you say, like, hey, architect, screw that. It's more than me, right? And when you don't have, or you have limited access, let's say, to the architect itself, .

Emergency services. Emergency services, right. Yeah, in the US we have 911. 911, right, so, but nevertheless, you know, this is like, it's very complicated IT system that I will be super afraid if there's gonna be no architect in there. I hope there is, I hope there is, I hope there are DevRel's as well, and there is architect, right, but, so we need to, you know, like, Musimy myśleć, że rolę w DevRel jest ważna, ponieważ jest to utrzymanie organicznego talentu od ludzi. Chcą budować coś, pomagasz im, ale powinien być zawsze... urządzenie powinno zawsze myśleć, czy mój biznes potrzebuje kogoś, kto będzie odpowiedzialny za urządzenie ryzyka.

I myślę, że DevRel powinien zostać tutaj, jako osoba, która powie im, że to niesamowite, że chcesz zbudować coś. Więc zbuduj tam, okej? I potrzebujesz dużo... I think that, you know, just relating from one of my own experiences, I was at a very small start-up, we were fast, nimble, we did all the things that we needed to do, we built very, you know, .