Speaker 1 (00:00):
I get asked a lot. What is Devereaux developer relations, developer, advocacy, developer, evangelist. And how can I get into this space? I thought I could speak to a group of experts from the fly lists community. They can give you their opinion, their journey, their history, where they've all come from different backgrounds into this space. And it's really so interesting. There is no path that you all must take. Different path adds so much value. So whatever your history, whatever your experience you can get into the space. And I'm really excited to share their stories with you. Here is our discussion. If you have any questions, don't forget to leave a comment below and we'll definitely get back to you. Give the video a thumbs up and subscribe to help support the channel, hit the bell notification button to get notified. Each time I publish a new video or go live, what is that?

Speaker 1 (00:48):
Overall develop advocacy, all those, you know, evangelists, all those sorts of things. And people also ask me, how can they get into it? Do they have to go down a certain route? There's certain things they have to do. I will start making notes and I start, I was going to create a video on it. And I think actually a San GTAs on the call. I think she was one of the people who prompted me to actually action and do something about it. Cause I always give my answer and just kind of move on, I suppose. Well, I started really thinking about it. I thought, you know what? I don't want to answer this because it's just my perspective. And so I thought it'd be really good if I could throw some starting questions out there, we can all go through them. I suppose, you know, one by one, see, I wanted to give different different perspectives and how people can get into it because I believe a lot of people are actually already doing kind of this role in maybe a small part.

Speaker 1 (01:36):
Maybe not like in a kind of 50 50 with I say with what they're doing at the moment, but they're on social. They might be sharing some small tips. So they're kind of like dipping their toe in the water. And that's what I believe. I know some people disagree with me and that's what I'm really interested to hear. My first question was what is Debra advocacy, evangelists, maybe there's some other words, people call it as well. And so for what is that, what does it mean to you? I mean, I think it's interesting in many respects that sometimes use these words, interchangeably, evangelists advocate, develop relations. It's both good and bad. I did a talk at Debra Alcon a couple of years ago and I just began to think through it to have a framework to do with time. And so whilst not everybody does all of these things all the time and some people are quite specific in their roles. I felt that sort of developer relations is, is quite in the moment you're there. You're trying to do it for understand how people are reacting to the, the talk that you're giving or the experience that you're putting forward. And it's kind of in the moment education and community building. I think that the developer advocacy is sort of a bit more after the fact. So you've done the developer relations activity. You have engaged with your community. You have learned from them, they've given you feedback. They explain some janky edge

Speaker 2 (03:00):
With the CLI or whatever it is. They've explained something that you can really bring back. I think that advocacy is sort of to me to do with that, bringing it back to the team. So you've got developer relations. Is that, that in the moment thing, advocacy, which is, is your role as a, an advocate for your community and therefore, ideally as part of the sort of product management cycle, it's not just reporting to marketing, but one of the things we don't necessarily talk enough about in Debra is developer experience, which is before the fact. So before you go out, what are the things that you could do to make a great developer experience that attracts someone to your platform, creating great documentation, really thinking about interesting sample apps that people might want to build, making it easy to access the API, having perhaps the free a tear for any developer and developer experience.

Speaker 2 (03:56):
I think as I say, sort of trying to get everything right, really thinking about how the developer will respond and then develop a relationship. As I say, it's in the moment I've got these things that I've built, let me tell you about them. Let me show you them. And then advocacy is like, I went out, I did my job. I learned from my community and now I've really got to take this back to the team and hopefully we can then feed that back into developer experience and have a life cycle. So that was my sort of long winded. I just tried to sort of think about some of the, making them less interchangeable and thinking about what some of those different functions are. I love that I do interchange them a lot. So I'm probably the worst of that. So that was pretty nice explained a lot for me.

Speaker 2 (04:43):
So thank you. I just wanted to say that I heard something from someone else that sounded a lot with James was saying about the first part is that being a developer advocate is being the representative of the community and the company, and then being representative of the company to the community. Nice. Our job is mostly just message passing and a little bit of translation between internal talk and what external people need to hear, want to hear. So this is my favorite part. How did you we'll get into this? Like where did you, what was your background? I know you've probably all got different backgrounds, which I think is just so interesting. So this is where I hope a lot more people kind of jump in and share their story. So I'm sure you all didn't do the same. I'll shut up. Now you carry on.

Speaker 3 (05:29):
I'm a software developer with a writing problem. I've been giving conference talks as a, not a beginner engineer necessarily, but as a mid level engineer, I didn't have the funds to be at conferences, no employer in a mid level web agency is going to send you to a conference. But if you speak at a conference, you can go attend all the other talks and learn all the things and make a lot of professional progress. I mean, I resisted dev REL for many, many years. I've only been divorced for four years now. Even though I've been on the conference circuit for 12 years. Yeah. Too much, too much

Speaker 4 (05:58):
Telling other people about the software. Now, here I am.

Speaker 5 (06:01):
I was frustrated with a lot of tooling. I was frustrated with the developer experience. And so my journey into this kind of came from a position of pain. I felt a lot of the pain that the people around me were feeling, and I wanted to do something about it and I wanted to help other people. So they didn't feel the pain that I was feeling that naturally almost led into, into an evangelism and an advocacy role because I was then helping with the tooling and other things to help reduce, not completely get rid of, but reduce the level of pain that people have when they're using various bits and pieces.

Speaker 4 (06:37):
It's funny. I feel like I also come to this role from a position of pain, but not the same kind of pain at all. My background starting like eight years before today, I guess now time flies. I was a cone of a marketer with a capital M I don't know, it just wasn't the world for me. And I kind of fell into Deborah by accident by through someone introducing me to a small startup in Montreal that was launching an API as a product company. And I barely even knew what an API was, but somehow managed to NAB that role, inundated myself in all of the things, API and devil at a really interesting time, like in 2011, 2012, and like SendGrid and Twilio and all these APIs as product companies were starting to surface and get funded. So I still feel like it's an incredible opportunity because folks are so open to connecting with each other.

Speaker 4 (07:28):
And it's still a new opportunity for a lot of people. And it's a really supportive group of folks, like just by the nature of Deborah, you want to connect with other products and teams and API is it's literally like, you know, integrations coming together and relationship building. So I just feel like my, probably getting a little off topic here, but coming into it as kind of by accident. It seems to be a similar story for a lot of folks, but I am starting to notice some folks being like, I actually want to pursue developer advocacy as like an early stage job, which is an interesting sign of maturity of this discipline. So I was a software engineer at a small startup where I was integrating in a lot of API because we were just like covering the basics of things that we needed to build out for marketing and sales and stuff like that.

Speaker 4 (08:18):
And so there was like that pain factor of like this experience of integrating the API could be better. Like the companies could have done a better job. And then at the same time I was tasked with we were wanting to open up a public API and I was tasked with like, go create dots for our API. Yeah. So that, that was like very, but I was still like seen as a software engineer. I was on the engineering team, but for three years previous to that, I had been building out a student developer community at my university, which was like in the first kind of round of hackathons being a thing. You know, now I'd say we're probably in like the second or third generation of that. There was this, like, I really like doing this thing. I really like to keep on doing it outside of the university space, but I also still really want to stay close to engineering. And so finding that kind of hybrid made a lot of sense for me. I didn't see myself as someone who really wanted to like spend the whole day focused on engineering challenges and tasks, but I didn't want to leave that at the same time,

Speaker 5 (09:28):
Such great stories as well. When you get to here, I'd love to hear some more if people want to, I think coming right out of college, what 11 years ago or so I knew that it really didn't. I was getting a degree in computer science. I knew that I didn't really want to do that. I didn't like the programming a hundred percent and I had taken a contract at Oracle and I really didn't like that. I had a previous manager call me up going, Hey, how do you like travel? Do you want to travel the world? And, and hired me into a technical marketing position, which devil as a name, I don't think really existed at that time. And that's what I was doing. And it was the same work. I was basically looking at our developer tools and in creating content about here's how you actually use them.

Speaker 5 (10:13):
And you're outside of your, just documents on like what the API is. It's like, here's how to actually do it. And I found that way more interesting because it was like, here's, you can have the empathy for the user. You can have your figure out your business processes and how they relate to as well as how do you actually use the tool effectively in a way that's not super painful for the end user. And I loved that part of it and pretty well, just kind of stayed along that in different, different careers. And only maybe four months ago, I finally got a dev REL title and job titles are quite funny. I had one of my clients say that we want you to do different stuff, but we haven't got budget for that. So we're going to put you in as a, I'm a full stack developer, but we're going to put you in a full stack developer, but you're gonna be doing deferral side and help us organize hackathons and mentoring and so on.

Speaker 5 (11:01):
How's the community. But if anyone asks, you're doing coding all the time, you can call me what you want. I don't mind, but it's just kind of weird in a weird way. They obviously have some internal politics, which I do not miss everything we've talked about here. It's interesting because people have been saying, kind of push them almost into Debra for me, actually, there was a a major poll as well, which is that I didn't want to be just writing code day in, day out, re responsible for production code. More than that, I wanted to actually get a role where I had elements of, of marketing documentation of sample generation. I haven't necessarily got the same kind of pressures, different pressures, obviously, but I haven't got the same pressures that a full time developer has. And that's not a negative away from a full time developer. It was, for me, it was very much a positive of a role such as this. It was a pole than a push. If that

Speaker 6 (11:54):
Makes sense.

Speaker 4 (11:54):
One thing I'd add is like someone who gets a lot of fulfillment out of helping people. I mean, you can help people on a software engineering team, you help your teammates, you boost everyone else around you, especially if you move into leadership of a team, but it's helping on a larger scale most of the time. I mean, unless like, you know, you have a certain position within a large company, but it's helping P you know, making that experience for people and seeing them get excited about those things, because you made that experience better. I want to expand on what Taylor said and what SJ said about the relationship aspect of it, and like helping people. That was what really got me into it was I haven't had background in events, which is what led me to Hashi Corp in the first place, and then being at our conferences and at our company events and meeting people, it was definitely clear early on that that was something I wanted to get more into. And the building relationship side of it,

Speaker 6 (12:51):
My personal journey is I was a developer, a product development engineer. And then I missed being with people, hearing people and felt like the abstraction of being behind a screen made, felt less in touch with the users and that empathy, I would say to me, this is an imperfect example, but it's a difference between sociology and psychology and where in sociology, you're, you're studying groups and how groups move and groups act. And when you're working on a product, you're thinking of the larger groups, but when you are doing a more psychological practice, you're working one on one, you're hearing how the lens of the world has seen through their eyes. And it allowed me to learn more about perception of things just in general coming from that angle, rather than just thinking about how groups see things, but hearing the one-on-one store, the, the individual stories, the individual pain points and finding ways to address them eventually trickled up into helping larger groups because even though their perspectives were different fixing one thing seemed to change how the overall product felt for everyone that kind of made it feel as though hearing those education, those edge cases, hearing how to make things just a small thing really impacts someone's life.

Speaker 6 (14:17):
Right. Was one of the things that attracted me to devil. I'll just jump in. Priyanka Shama that's recently took over as general manager of the cloud native computing foundation. She in her talk yesterday just did really good job of articulating all of the different folks that all providing value in that ecosystem. So, you know, people running documentation or, or anything else, you know, very often we, we, as an industry obsess about the code, that's one of the, the things with the devil

Speaker 2 (14:52):
Hold people is that they're saying that there's more to life than code, but it was really interesting to see that organization, which has very, very much been predicated on, you know, it's like, here's, Coopernetti's, here's the surrounding software technologies. I thought it was a really nice articulation by her about all of those other roles. So maybe that's something that you could point at when people ask, how can I be involved in open source? Because clearly not everybody is going to be the prime sort of maintainer of a project. I was actually asking, what specifically is developer growth? Like, I feel like that's a term that is not as well known. Perhaps it sounds like a lot of pressure what's what's developer growth.

Speaker 4 (15:30):
People are kind of trying to figure that out. But from what I gleaned from a few companies, they're really thinking about it in terms of customers, their developers are their main focus and their customer. And so they're looking at, for like, you know, basically like you would customer success and nutrition, you're doing that for developers and so growth, same exact department, same exact setup, actually seeing it report to either sales or chief customer officers. Now,

Speaker 2 (15:58):
Does that mean deepening the relationship with already existing customers? So they move from novice to committed to evangelism.

Speaker 4 (16:05):
I think that's part of it. And it's also opening up the top of the funnel as well. Cause that makes sense. It's just, that seemed like a non answer,

Speaker 2 (16:12):
Some quite negative attitudes sometimes for people that are like, Oh, you, you know, I've been an engineer for 15 years and who are you to go out and, you know, educate about an API. And I think that's sort of suboptimal. I think anytime that you're gatekeeping in that way, that's, that's not really ideal, but we haven't yet found a way of articulating a career path where we are allowing those newer voices to enabling and supporting those new voices to come in as, as easily as they might. I think that's one thing I'd like to see the industry do a better job of because yeah, why not? Anyway, I think in general, I mean, certainly, you know, me as a, as a parent and stuff, I don't want to be on the road all the time. And I do think that like that REL quite often make sense for younger folks that are all in a position and perhaps even want to travel. Like I don't really want like vacation or travel my family, but I don't want to travel any more in business. It's so natural as an industry because it's been based on travel for that to be the case. And I think now that we're not traveling so much, that raises all sorts of interesting issues around that. Because if that isn't the primary thing, maybe there's a whole other set of people who could be more effective in dev roles. Cause it doesn't mean they have to be on the road all the time.

Speaker 4 (17:34):
I think we get describing that it's a feature. It's not a bug. It's a feature definition. It's every job, every devil job is what you make of it. So I'm like way out on the engineering SDK developer API experience

Speaker 3 (17:50):
And of the spectrum. But it's ill-defined so no one cares that I'm out there like that needs doing for our communities. And there's the freedom for me to do that and to make a difference in the way that ways they always have. It's not true. I don't travel at all, but you're right. I'm grumpy about it. My contract says I never have to because I'm more of a writer and I would rather support my communities in that way. And we've usable libraries for the people coming in early career. There's two sides to it. One is like, how do you do that? If you're not like I do it by building on extensive engineering experience. And I worry a little bit about how people can become very senior endeavors. Well, if we very quickly pigeon hole them into these less technical topics, and I'm sure some of the minorities have had this as well.

Speaker 3 (18:40):
I want you to be a project manager. You'd be great at that. You don't really seem like a coder, right? And by pulling people out of the kind of heavyweight job mainstream too early, I worry that they, that we have not young people, but early career people. And that can include career transition as well as straight out of college. The first time around, I worry a little bit that we are not giving them the time to build each of those skill sets where, because dev REL wasn't a thing until I'd been an engineer for 10 years and then I resisted it for 10 years. You know, that gave me a chance to build up all those things. And I was a blogger for fun and a conference speaker to fund the learning habit. But by bringing people in. So earlier we are we not giving them time to really level up, are they always going to be sort of middling some of these things? Do you not like I have other concerns about,

Speaker 5 (19:31):
At least for me so much of my experience was actually the building of demos and, and using the tools. So I built up those engineering skills alongside the rest of the skills. I also was very lucky that, I mean, because I was working at Avaya, which is what grand baby bell. I had some amazing engineers for mentors that could really help me there. So, so a lot of that for me personally, was luck. And just being in the right place at the right time, I think you could remove that luck and say, Hey, Deborah people need to do who are early stage in their career would just need to, to do engineering tasks as part of their job so that they learn the empathy for the engineers on the other side as well.

Speaker 3 (20:18):
So I, I started with community management developer, community management. When I was in my first year of college, I stepped in because I wanted to be that person who, you know, who stands among crowd and is talking about a product launch, a develop a product launch. But instead it ended up becoming the person who knows how to analyze a product who doesn't believe in assumptions anymore. Who knows how to ask questions. So I think this is thing that the speed

Speaker 6 (20:48):
Has taught me that how do you ask questions? How do you put yourself in somebody else's shoes and then analyze something and then bring in that perspective? So yes, that's something I've learned being here for the past four years, how to ask questions. So you should possibly think about being an industry analyst in your future. That is a very good set of skills to have asking the right questions. That's also a good segue into a product role to ask the right sort of empathetic questions about, you know, a product that a recording. There's so many good points. My first role out of college, I worked for Dell in computer support. Hearing people say like, my computer's not working. You have to ask, is it the monitor or the box at the bottom? It's really understand what they're talking about. And so that was one where I was forged in terms of both customer empathy and asking the right questions, because you have to hear what they're saying, but try to understand what they're seeing and what they're experiencing regardless of the language they use. And then you have to just make sure you can walk them from point a saying, this is the problem to point B saying, here's how you get to the solution. And you cannot ignore both of those. You have to understand where someone is and shit to get them to where they need to be. And I think right on a hundred percent, I agree with what was said, but

Speaker 1 (22:11):
I think in our industry, the fun part is we're all always new. I stole this from Soran. She gave a talk recently at some online conference. And like I was doing something new, like get her actions like a week ago or two weeks ago, I was a newbie for that. I knew what CEI was, but I hadn't done have actions, you know, didn't have to configure it. And all the rest I was doing that on a live stream and made lots of mistakes and it was as a farm, but we will figure it out together. Cause I mean, working in the end, but I think we're all always newbie and that's, that's why we love what we do and industry industry's always changing, even if he knew and their JavaScript a few years ago, it's going to change now. Right. And it's gonna change again in a year. There's more, more features all the time. And that's just in any language is part of the fun.

Speaker 6 (22:50):
It's interesting because I think Wesley touched on this before about having to have empathy, but ask the right questions. And I think it's also a matter of being able to act as a translator. And we touched on this before, you're translating both ways. You're translating from the company to the community and you're translating from the users and the community back to the company. You know, my background is more in marketing with the technical background as well, but more marketing. And so, you know, coming from that angle, being able to try and understand users, understand who your customer is, what their pains are. I think people in this role understand customers better than anybody else. And it's the lifeblood of any company to have that information, to understand there's the perception of, Hey, we bought this great widget everyone's to love it.

Speaker 1 (23:46):
And then the, you know, the devil folks go out and they say, yeah, this didn't go over as well. And here's what everybody really wants. And here's what we really need to do. And it's bridging that gap between the perception and the reality and really translating what the actual needs are into workable

Speaker 7 (24:03):
That people not only will want, but actually me

Speaker 1 (24:07):
A real life example of that as well, which is quite expensive, not for me, but for the company, what's a typical day for you. I don't know if people want to say something or we just move on to the next one because I think every day is different. Right. But I'll let you jump in and maybe say that on the video. It's not me saying that. Let me take us. Yeah. Lots of meetings, lots of white boarding,

Speaker 7 (24:29):
Waking up to new builds from the community is something I'm really grateful for. And then people are tagging me that, Hey, thank you so much for helping us or teaching us this particular framework. And you're building this today. So they are suddenly extroverts and they don't mind sharing what they're building with a whole community of thousands of people. So this is something that I'm truly grateful for.

Speaker 1 (24:51):
That actually ties me into a question I haven't got on my list. So I'm kind of deviating slightly, but it's, it's quite important question to me personally. So I get some people messaging me saying, I looks like I show a bit of favoritism to certain people and maybe I do. And I want to kind of reply why, but I don't know if that's a good thing, but I do because I know they help other people. So it allows me to scale more. So for example, there's a lady in Nigeria who, whenever she messaged me, I always reply back because I know she's helping a group of teenager, girls in Nigeria get into opensource and I can see their commits and their pull requests coming in. I love that. So I'm very responsive to say her for, to take it as an example, then to someone else who's always like, help me, help me.

Speaker 1 (25:33):
I help me. I need help. I need this, I need this. It's just like, just do a Google. It's the first answer that comes up at the beginning. I probably give them the, I see James cringing. I don't know if I'm doing this really, really bad. You're all going to hate me now. But like I do reply to them. But then after a while, I just think just you never help anybody else. You don't just, I've answered that question for you. Someone else just asked it in this school. Why can't you reply with how you solved it? And I know appreciate that might not always be there, but you can notice these things after a few months off who tries to help and who doesn't, you know, JFK is a true thing. I mean, someone asked the other day, they were like, what was the advice you would give to someone in order that they would be about programmer and mine was don't use Google. Of course you should be taking advantage of the assets that we have. You know, like the idea that you would never look at, we live in a sort of, there was a lot of really good information out there and, and we should sort of take advantage of those information assets. Although obviously it's nice to ask people questions as well. But no, no. I mean, that's a very reasonable, I mean, what am I, I'm going to hate you Eddie, because you just said you're like trying to help somebody building out the Nigerian ecosystem

Speaker 2 (26:44):
And working with teenage girls in, in, in Nigeria. You know, if you know me, if it's all, that's the kind of thing that I'm going to do. So no, I think you're in good shape. Okay. Thanks. If it nervous to say that I'm not still processing

Speaker 4 (26:58):
The advice that I would share with anyone entering my role or any community management role in general, it's also a comment on our last conversation of not being able to answer everyone, not being able to help everyone, just not being able to do all the things is that take into consideration that community management always has a certain aspect of emotional labor. And I do feel like invested in that way in my role. And with that being said, like, I need to protect my peace and know that I can't help everyone. And sometimes it is okay to answer, like you were saying, Eddie, like just Google it. That's totally okay. Obviously in a kinder way than that, but you can't help everyone. And sometimes if you can just maximize your role by helping others help themselves, that's fine too.

Speaker 2 (27:51):
Okay. I'm going to ask you these questions coming up. Any tips, any recommendations you give to people who want to get into Debra?

Speaker 4 (27:57):
I see start poking around in an opensource project sign. I get a project, you know, ask questions and find a discord channel or Slack, you know, get to know the people who are the main contributors to the team. And that's often the way you'll become really well known or even potentially get a job offer in the future too, or find other work for me. I think it's about exactly this finding ways to practice those skills and kind of decide if you want to move over, like what I'm interviewing. It's very common to command engineering and that's fine, but if you've never written a blog post and never spoken at a user group and never made an opensource contribution, like maybe you need to go and try some of those things before you commit to doing dev REL full time. And it'll tell you if you want to be doing that as well as telling me if you want to be doing that, right.

Speaker 2 (28:46):
Writing is just so important. If you can communicate, it's just such an amazing way of scaling knowledge like writing. So write about your craft and write about your learning journey. I mean, I think in terms of this question about, you know, do you need to be like the fully fledged incredible sort of engineer that has all of these skills actually. And I see this, a lot of people say, well, would this be an interesting blog post or I'm sure this is a really simple thing. Those are always the best things. Those are always like any time you're asking yourself the question, write it. So I think that writing is a brilliant pathway to comms and technical communications and potentially an advocacy role. If I'm having to ask the question, I guarantee you, a lot of other people also want that answered. And then to Eddie's point when someone Googles it they'll find your blog posts and then we'll all be able to move forward. So yeah, no. Right, right, right. I that's just absolutely

Speaker 6 (29:42):
Critical. I've just, I've taken that point forward that as we said earlier about committing to, to open source, going out and getting involved with things, those are all very important. But for me, I think developers do that or most of them do that anyway for me, is most important is communicating is getting into that habit of talking to people. It's very easy to be able to sit down, to write code on your own, schedule your own habits, to understand what you and your team do. But communicating, I think is one of the key skills that, that really leads you away from that very highly technical role into something else. And that communication might be standing up in front of people. It might be talking, might be writing blog posts, be doing other things. But that communication is what gives you the visibility of, of what the pain points are, how you can help externally or internally to your company. So for me, I think communication is the thing that people really need to focus on. If they're looking at death row, because if you do that well, then you're going to do well in Deborah.

Speaker 7 (30:39):
One advice that I can give. And that's something that I followed is try explaining any technology that you love to people from different backgrounds, from children to old people. And then just see if you're able to do it. I mean, it will not happen in one day, right? You have to keep on practicing because at the end of the day, it's developer relations and relationship requires connection. So it's so much important for you to be the person who's connecting with their audience. So

Speaker 6 (31:07):
Yes, I would say the other thing that you should get comfortable with is making mistakes in public. I think that is you have to be able to be vulnerable and not be held back with doing something wrong in front of a lot of people. I think that keeps you out of spaces and it keeps you from doing things that will help you grow. And your mistakes are also not just valuable to yourself in terms of growth, but to other people that they can see that you also are struggling with some of the same things and that you are learning things. And you could be that person that may get more arrows and stings and bad comments, but you help people feel less alone by letting yourself be vulnerable. In that way, I feel like lessons learned and postmortems are some of the most interesting things to watch and read out there.

Speaker 6 (32:00):
How'd you keep a work life balance so you don't burn out. Is it? I get asked this a lot. I think from my perspective, this is something that I've seen from a lot of dev REL people that it does worry me, especially as, I mean, it's not as bad. It's different now because we're not traveling, but the travel was really crushing people. And also I think that one of the things that never all people can be prone to is burnout because the sort of the there okay. Honors and so on can be a little, they're not perhaps as clear as for some other people in the company, you know, you're doing incredible, like glue work you're doing, you're bringing people together, you're doing all this great stuff. And then someone might be like, well, yeah, but you don't always feel in control of things. So the organization might, Oh,

Speaker 2 (32:40):
We've done this successful 20 city Paul. So now we're gonna make it a 47 city tour. And you're like, but I didn't really sign up for that. And I do think that there are a lot of the, the point I'd like to make, unfortunately, because of the Rona, it's not as an easier one is that no is your best friend. Like your company is not your best friend. Your employer is not your best friend. Your best friend is your best friend. And know the word. No, it's actually, I call it, do that thing. And that's really scary, really hard. But if you don't do that, if you don't ever say, no, you can't look after yourself and you can't look after your teams. You can't look after your family in an ideal world. It would be like it was maybe two years ago where it was so hot that I wish he said there are other jobs out there. So say no all the time. Unfortunately it's not quite easy at the moment, but I still think that no, a well-placed no is, is a very important aspect of, of self care.

Speaker 4 (33:38):
One thing years ago on one of the teams I was on, we had a Slack community and like, it was very easy, but the user ask a question late at night and you want to answer them. So like having very clear boundaries of like, when are times you answer and when times you don't, and sometimes that means you're going to have to tell a community member or user, like, you know, either tell them or they see somehow you're not going to get back to them right away. Like having those clear boundaries with them, it's, it's painful to do because, you know, you feel like you're disappointing this person, but like having those really oppressive. And maybe that means you also don't have a in real time chat too. Like that's, that's part of that. And then the second part of that is like, some of my burnout has not actually come from travel has not come from overworking.

Speaker 4 (34:31):
It's come from not having clear goals and metrics. And just having that like two way street with management and, you know, misalignments of values to just like what even was dug well and stuff like that, that is where some of my, most of my burnout has come from, not from, because I was traveling too much, which I always like I can monitor. And like, not because I was overworking myself. And it was a struggle because at first I was like, and it struggled to really do even was burnout because I was like, I'm not overworking. That's what gives you burnout. But it's it's so it's, it often comes from so many other things too,

Speaker 2 (35:14):
Work life balance that it's an average and not a constant. And like I used to be really down on myself when I was like, you know, I'm just going to skip working out today because I just don't have it in me. And just realizing that it was okay to shift some things do more work, do less leisure at different points. As long as I looked at the average and the overall, that was something that helped me

Speaker 5 (35:38):
In my terms of my own self regulation of just giving myself permission to not do some of the self care stuff and to do some of the self care stuff at points and times where I know it add more stress in my life or just to make sure that, you know, I can take care of work and feel good there, then move on and then focus on myself, focus on my home life. And like the center may shift and move. Occasionally. I can't make them all constant, but just working about the average, I don't travel as much as a lot of people on here, but the problem for me is the world never sleeps. And I feel very hard on myself because you see Slack most as you come in, you see post on forums, you see all these things and you know, this is a community that you are supporting, you know, when you're emotionally invested in it.

Speaker 5 (36:26):
But it's very hard sometimes to say no to James's point and being able to say, actually, no, this is my time. You know, this isn't the time I might work Australia times occasionally when I want to, but this is my time now I'm saying no, I think the hardest thing is the fact that the world never sleeps. And you've got to say no, in order to, to, to manage that. Yeah. I found it very useful to just lean into the fact that my schedule can be as flexible as I need it to be. And so that might mean that I work six to nine in the morning and then four to nine in the evening. Right. And I, and I have the day free and I can go do whatever I want during normal working hours. I'm still getting my job done. And nobody really cares. We're not,

Speaker 3 (37:15):
I definitely have the workaholic tendencies. I've only been badly burned out by yeah. Lack of control. Take away autonomy. I can't live. I've been freelance. So I've run my own business for a bunch of years. As I went from junior developer that no one really wanted to help to well known author didn't make any money in the process, but that's fine. And because I've worked for myself now, I kind of have boundaries around. This is just a job. There's probably another one where that came from at the same thing where the world never sleeps. My team never sleeps with globally distributed, but I have two phones. There's no work stuff on my phone. This one stays here or comes with me and I'm going to events or something. This one stays here and I don't come back to my desk. It's a challenge if I'm hacking on opensource, but I also do laptops. So, you know, I can do it. And I don't have a problem with setting a Slack reminder for Monday morning. And I think you have to be really upfront about that. If I'm constantly sweeping in, I'm stopping the people from other time zones fighting, growing their own skills and having their own agency to deal with things as they come up. So it's important that I should step away and have a lot of autonomy at work right now. And that's helped a lot.

Speaker 5 (38:18):
Your main thing, Eddie is, is thank you very much for this interesting sessions. I think it went really well. I appreciate it. Thank you for being the host this week and thank you to everyone. It was awesome. I know we could have chatted for another hour as well with all the great tips and suggestions from this awesome community. So thank you all.