#28 DevRel, say what?!

Tak, na całym planecie, w końcu będzie to taki rodzaj osób, zwłaszcza jak będą zaczęły tam jeździć, więc będą potrzebować internetu. I kiedy będą potrzebować internetu, będą potrzebować trochę góry lub centrum danych, prawda? No, ale już użyli Pythonu na helikopterze na Marsie czy coś takiego. Okej, Python jest już tam. Jesteśmy na Marsie. Jesteśmy na Marsie, fajnie. Mike, dzisiaj z nami jest Mike Fiedler, tak się powiem? Dobra, idealnie. Nazywasz się Kurt Gardener, ale znam Cię jako gościa, który dużo mówi i bardzo zależy od open source'a. Myślę, że open source będzie dobrym elementem.

Yes, I recall a fun story of one of our fellow AWS heroes. For those unfamiliar, the AWS Hero Program is a select group of about 250 individuals worldwide, where Amazon Web Services has recognized our contributions to the community or proficiency in certain areas. One of our AWS heroes, I think from somewhere in the Middle East, this was their first time in the United States overall, and Vegas was their first impression of the US. And a few of us US-based folk were like, this is not what the rest of the United States is like.

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?

You are just dazzled by all the different things you could pick, right? The choices are Almost infinite and it's really hard to, you know, at the outset, unless you've used a lot of the tools, unless you've tasted those candies before, to know exactly which ones will match the project that you're looking for. And every week there's a new company, there's a new product, there's a new process, so it becomes a little bit overwhelming to make the right choice and inevitably you're going to make some wrong choices. So this analogy of the fog I like is it's very hazy and then having someone to guide you I think is also a really good one. That comes although at a somewhat of an opinionated approach because everybody is going to, everyone is trying to sell you something, right?

You know, if you are a purchaser and they are a vendor, so it becomes a question of Are they being truthful about the downsides or the trade-offs of their product, right? The best developer advocates or relationships or even salespeople are the ones who will tell you, hey, this doesn't seem like a right fit for what you're trying to describe. Maybe we're not a good product for you. As opposed to maybe we'll figure out how to add a widget and make it work for you. So I think those are the best vendors, are the ones who will tell it to you straight and say, you know what, maybe you're not at the right size of a company, maybe you're not at the maturity of an engineering practice to deploy this solution.

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.

There are certain types of people who are just, you know, friendly. I don't know how to call it. You just enter the room and you just instantly like them, right? So they don't even need to communicate much. So the body language, you know, the small signals that they send through the air without even communicating verbally. And I think if you have that kind of person and then, you know, this person is willing to learn some technology, This is the way, like they say, right? This is the way, because then, and facilitation. I think the facilitation is another part. So you need to listen, really listen to somebody, not just, you know, like sitting on the meeting. Not just hearing them, right?

As opposed to, I want to run Postgres on three nodes. Why do you want to do that? Like, oh, I want a highly available Postgres cluster. Maybe you should use this solution over here instead of you trying to run three nodes. Maybe the right answer is you do want to run three nodes and you have reasons, but the initial request often should turn around with a, alright, what are you exactly trying to do? And read through those. I think it's super important that we have Wiesz, sytuacja, że jest ktoś, kto nie jest tak techniczny, tak? Więc jeśli jesteś super techniczny, to zwykle myślisz, że wiesz odpowiedzi na pytania, tak? I myślę, że kiedy jesteś osobą relacyjną, zapytasz sobie pytanie, dlaczego to robisz?

So that way they can actively search and nurture that kind of role. Most companies will look out and say, well this person, this person sounds or looks or feels like the way I want to represent our company, let's hire that person. And then continue to search for a ton of new hires that will match exactly what that person is and does, which is a dangerous spot to be in, because we're human, we're all unique. So I think it's recognizing the diversity of approaches, of opinions, of differences of who we are and how we speak about what it is we want to share with clients will help

. . . . . . . . No, oczywiście. But you don't focus on the direct jump on the income. You focus like, okay, let's make people better because this person will just make my team to understand infrastructure better, to understand needs better.

Więc jest to kwestia praktyki specjalizowanej przeciwko zrównoważonej egzekucji. I wiesz, jak się rozwija w Twojej firmie, w Twoim drużynie, Ale co mówię, jest ważne, żeby zobaczyć, że firmy inwestują w coś takiego, bo produkt jest bardziej człowiekowy. So, you know, like it's created by humans for humans and for them it's important that the people who will use it or people who will, for example, use their infrastructure products or, you know, like EKS or anything, they understand it.

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

Tak jak powiedzieliśmy wcześniej, mamy tak wiele narzędzi, tak? Tak. Więc jeśli, używamy konkretnego przykładu, jeśli używasz serwisów Amazon Web i używasz funkcji Lambda, i lubisz funkcje Lambda, to może być twoja tendencja, aby używać Lambda dla wszystkiego. Dla wszystkiego, tak. Dla wszystkiego. Maybe you get disappointed when it behaves in a way that you did not expect for your use case, where it's not intended for that use case, right? What was it? Somebody wrote an SSH reverse proxy in Lambda functions. It's like, well, yeah, you can do it, but I don't think you should, right?

As opposed to I'm going to use the same service for everything. Because while you will probably get very good at a given service, you will be leaving opportunities and optimizations on the floor that could end up costing you millions of dollars or millions in time I I think it's extremely hard. Because, you know, like you said, the toolset, it's

Outranges, so like there's so many tools on the market and to understand you know like the best pick right for this use case because everybody comes with different use case so I want to build application for wherever right and there is billions of ideas and then you need to find out the use case for that so from one side it's enterprise architect or architect position but from second side it's a position of the person who ask why what so so it's it's It's like questioning everything. Questioning everything, but in a very polite way, let's say. Well, you bring up enterprise architecture, right? And this is, I guess, a practice that is not entirely massively popular today, depending on the size of your company.

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

I'm a Polish, so my limited language skills is there, so thank you very much, Mike, but really I meant everybody, yeah, thank you. Absolutnie, nie ma problemu. Ale ta procedura jest absolutnie prawa, prawda? Nie wszystkie firmy mają specjalistów na to, jak budować dom. Bardzo często mamy ludzi, którzy wiedzą, jak wyciągać łokcie, prawda? Więc jeśli dajesz im jedną łokcie i parę brzegów, zdają sobie coś. Tak, tak, tak, tak, tak, tak, tak, tak.

Zniszczyliśmy trochę zaufania. To nie jest najgorsze, ale to oznacza, że po takim wyjściu będziemy patrzeć na to z bardziej krytycznym ojcem, żeby zobaczyć, co nie robiliśmy, dlaczego to zbudowaliśmy w ten sposób, czy powinniśmy wytworzyć w przyszłości lepsze decyzje. Or did we cut corners and just not put stability into the house we built because we were being cheap? And if that's the case, then it's like, well, then what did you think was going to happen, right? You build cheaply, it will fall apart eventually. It's just a matter of time. Więc, być w stanie zrozumieć ryzyko wraz z wynikiem i to, co to Ci kosztuje, to inna umiejętność. I nie każda drużyna inżynierii ma taką umiejętność.

Myślę, że w niektórych częściach zgodzę się z Tobą, ale w niektórych częściach absolutnie nie. Zacznę od drugiej części, bo to mi się podoba. Dlaczego? You know, when you're building some construction, right? And the construction, like you said, the collateral damage or the risk is huge, right? When the construction is collapsing, people are dead, right? With IT systems, we used to think like this, but we should change our mind because there are so many systems, IT systems that are responsible for life of people, not maybe directly, but indirectly. For example, I know we have 112 number, right, in Europe, so you're typing in and you call the guys from, I don't know, hospital.

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.

Kreatywność może iść do głowy. Daję Ci przykład. One of my favorite example, big e-commerce, European market. The guys had this kind of rule that the six months people can work on some side projects. Like one day in the week they can work on some side projects. It was amazing, right? So this was like exactly nurturing the creativity. Wiesz, ci ludzie pracują, pracują. Niektórzy deweloperzy, wiesz, pracują, pracują, pracują. I nagle wiesz, że jest konferencja, każdą pół roku, żeby zaprezentować rezultaty, rezultaty różnych osób, co oni robili w swoich wolnych czasach. I ci ludzie zaprezentują, wiesz... To było zajmowanie się wielkimi danymi, albo coś takiego. Więc oni robili coś zupełnie innego, coś w ramach networkingu, wiesz, i zaczęli zaprezentować, ludzie przyjeżdżają.

. . . . Once I wrap my head around that the thing that customers are coming to this company for is reliability, I got on board. I was like, oh, I want reliability from this kind of organization as well. Maybe we shouldn't have every latest and greatest framework and technology. Maybe it should bake a little bit for this enterprise.

It all comes down to which organization, But there's also obviously a risk to not adopting new technology because then you get stuck in the mud of maintenance forever. And then you won't be able to move forward when the competition has already outpaced you. So I think investing in that notion of an internal facing, like in your example with the hackathon, investing in internal developer relations when you're at a certain scale is also very useful because one quick conversation with those folks would have maybe headed them in the right direction I powiedzieć, że zamiast napisania VLAN-u, dlaczego nie wykorzystujesz VLAN-u i robisz to, co chcesz zrobić na zależności od tego?

I think it's super hard, just a side note. So it's super hard for many of our customers when we talk with them today to understand what is really important for them. So for example, we built huge farms of Tanzu, hybrid clouds, different approach to the architecture. But the first conversation that we have usually is like, what your business is doing? What's important for you? What do you want to arrive in? Sześć, sześć, sześć, sześć rozmowań, w których mówimy, że produkujemy brzuchy, że chcemy sprzedawać brzuchy tak szybko jak to możliwe. Ja mówię, tak, tak, tak, tak, tak, tak, tak, tak, tak, tak, tak, tak, tak, tak, tak, tak, tak, tak, tak, tak, tak, tak, tak, tak, tak, tak, tak, tak, tak, tak, tak, tak, tak, tak, tak, tak, tak, tak, tak, tak, tak, tak, tak, tak, tak, tak, tak, tak, tak, tak, tak, tak, tak, tak, tak, tak, tak, tak, tak, tak, tak, tak, tak, tak, tak, tak, tak, tak, tak, tak, tak, tak, tak, tak, tak, tak, tak, tak, tak, tak, tak, tak.