Is Developer Relations Right for You? An Honest Breakdown With Fred Harper

Speaker A: In this video interview, I got to sit down with Fred Harper, who is a fellow Canadian and a developer relations manager at TinyMCE. And I thought this was really cool because I haven't yet interviewed anyone who does developer relations. So I got to learn a lot about that. We get to hear about his journey as a developer into developer relations and see how his extroverted personality ties into that. But if you're not extroverted, that's okay too because we go back and forth and discuss really how that can shift from when you are extroverted to introverted and how that all ties into different parts of developer relationships. So I think you're really going to enjoy this one. Sit back, enjoy and learn all about developer relations from Fred. Fred, thanks for joining me. If, uh, if you don't mind, to kick things off, maybe a little bit of background for how you got started in your career and how you got to where you are now for our audience.

Speaker B: Thanks for having me, Really a pleasure. So, uh, you know, I'm whole, I've been in tech for a long time, a little more than 20 years. And I was lucky because, um, I don't know how it's working where you live. Actually you're from Canada, so it's basically the same thing, I assume. But uh, you know, the basically has to you when you're around 12 years old, 14 years old, like, what do you want to do for the rest of your life? Because you need to decide where you're going to study and what program you're going to take. And I was lucky enough that I had a computer at home, which was not the case for every families at the time. I know right now it's a little more complicated comment, but it was not in my time. Now I feel so whole saying that. But, um, I was playing games and I liked it. And in my mind I was like, yeah, I can become a software developer because I like playing games. Which one does not equate the other one. But I was lucky enough that um, I decided to study software, uh, development and I also liked it, um, so super lucky. So I started as a software developer. I've done that for about 10 years, but I talked a lot. I'm an extrovert, I'm social. Um, on my free time I started to organize meetups because I just thought it was fun to give back to the community. Because I was attending meetups, uh, I started to speak at conferences. If I want to be honest, at first it was mostly for my ego, but also because I Like to share and I like to share my expertise and help other people to understand and educate people on some topics of um, experience I have. I started to write technical blog posts and um, I realized that oh there is a job for that like developer advocate and it was not super popular at the time. It was mostly bigger company like Apple, Google, Microsoft, they had like developer advocates that we were not even called developer advocates. We're either technical um evangelist or developer evangelist which was um, the title that was used at the time. But um, I switched from software developer to developer relations. So as developer advocate about 14 years ago, uh first job was at uh Microsoft. Um they approached me, they were looking for someone who live in Canada because at the time the developer relations team were specific to different countries but uh, I was covering Canada. But we're looking for someone who speak French uh because you know I live in Quebec, I live in Montreal and people speak French French here. Not everybody is bilingual so they needed someone to be able to talk to that audience and and they were like hey we're also looking for someone who is bilingual which I was not. So I had to learn English uh during that time. But they were looking for someone who speak French first and can speak English as a second language instead of the other way around. So you don't have the accent when you go talk to uh people. So long story short I've been doing developer relation for about 14 years now uh you know at Microsoft, at DigitalOcean, npm, Fitbit, smaller uh startups and right now for about uh six months I'm at tinymce, uh leading the uh developer relations team there uh for different brands also from our parent company Taigo. But as the high seat part of my job I'm focusing on TinyMC, uh a rich text editor. So been doing that for a long time, loving it. Uh, it's a great intersection between you know um, being a software developer because I still, I'm still developer, my audience are developers but it really used my you know, social extrovert skills and the fact that I love to help people being successful. It's a great way to do that. So I've been doing that for a while. So long story about where I'm at right now.

Speaker A: I guess one of the questions I have and I find this kind of uh interesting because uh, as most of us are aware I feel like uh stereotypically people that are into development are generally uh, I don't have stats to prove it but I think they're uh more introverted versus extroverted so it's really cool to kind of uh, see that you're able to leverage that sort of extroverted side of your uh, personality. But one of the questions I had was like did you find that you had to do a hard transition into like coding less or like to be able to tap into uh, doing more of your current role or were you able to maintain that or what did that look like in terms of transitioning from maybe more hands on coding work to what you're doing?

Speaker B: Yeah. So unfortunately um, with most role and it tends to change a little bit recently but like with most developer advocate role you still code. The difference though is that usually you're not part of the product team. You're not really part of engineering meaning that you're not building a software. You code because you need to learn the product because you're the customer zero. You need to test new release, you need to learn new technologies because it's not just about your product. You need to keep up to date. Uh, you need to be credible when you go on stage and speak at conference. You need to have the knowledge to be able to write blog posts or create videos. So it's uh, why I still consider myself a developer because I still code. I just don't build product anymore. Uh, it's more about the learning, it's more about getting the knowledge that I need to be able to do my job. So this is why I always say to people, I mean like I miss coding full time. Uh, I didn't left uh the software development role to uh, developer advocate because I didn't like it. I um, loved it. I love building product. I still remember my first L world. Uh, every time I talk about it I have a goosebump. Uh and it was stupid, it was just showing LOL on the screen. But like I mean like I did that and I think, I think it's fantastic. There's some a magic part of like being a software developer. So I love it but when I put this on a scale I'm like I love doing everything else a little bit more. So that's a great mix. It's a great intersection between that's the technical role but it really goes into a lot of other things that I like to do and it's a people centric role which is a little uh, less available. When you're a software developer usually like yes, you work with a team, you're not usually alone. You may talk to customers, you may talk to other teams internally but it's not the same like, sometimes, um, when I'm at home, I'm going to have meetings like everybody else. I'm going to be alone in front of my computer. But, um, I travel, I do events, and when I do events, I talk to people. Hundreds of people, from like 8 in the morning to like 10 in the evening. And that's my day. Um, so with that said, some roles right now they're looking for kind of like hybrid between, like, hey, you're gonna do, I don't know, 20, 30, 40, maybe 50% of your time where you're gonna be part of the product team and you're gonna build the product and the other 50% you're gonna talk about what you built. Uh, I think it's a fantastic approach. Um, also think that maybe it's not good in all the cases because as right now 100% of my time is about developer relation and I feel like I don't have enough time to do everything that I would like to do. And I'm not even coding, uh, the product itself. So. Yeah, and after doing that a couple of years, I mean, if I really want to be on apps, I consider myself still technical, but I'm not as technical as I used to be when I was coding like eight hours a day, uh, to build products when I was a software developer.

Speaker A: Yeah, there's like an interesting set of like, things that you focus on. Right. So like as a developer, I mean, so, yes, like, as you're explaining to, to remain technical, you have to understand like the, the, the language that you're going to be building in the tech stack that you're, that you're advocating for. Um, but when you're building products and services and things like that, it's, it's not, it's not just knowing those things. It's also like, cool, we have an existing code base. How do we build and extend and go in different directions? Um, so, yeah, I could, I could imagine that if, if you are spending more time doing the other parts of, like, I have to understand the feature set coming up and the direction the product's going versus I need to spend time making the decisions about how we go in that direction. Um, sort of a different thing to try and balance. So.

Speaker B: Um, yeah, definitely, definitely. And, and, and no, sorry, yeah, you go ahead. Sorry, I was just going to say, and on top of that, um, if you want to be effective with your job, uh, it's not just about talking about my product because, you know, most developers don't like product pitches and most conferences don't want that. And most like if I came here to your podcast and I was talking just about tinymc, um for one hour like people would get bored as much as like I love the product and I think I'm not a bad speaker and I can't entertain people. I mean people are not coming here just to learn about that. It's okay to talk a little bit about it and there is some situation where it's fine to talk about my product but in most cases I talk about everything else. I talk about like the best practices with some technologies I'm going to talk, I'm even going to do like non technical uh talk or article or videos that still relate to my audience. So now I don't have just to learn about the technology we use or just a product that I home I also have to learn about a lot of other things which doesn't let leave me a lot of times for, for like you know, a lot of other things too.

Speaker A: Yeah and that's uh, so I'm curious about this. Uh, so basically your role is like involves obviously a lot of marketing. Right. But the audience that you are like targeting is an audience of people that probably don't want to be marketed directly to. Like uh, I don't know the right way to ask this question but like how do you approach balancing that where you're like I have a highly technical audience that I need to like be able to speak to without it making it, without making them feel like hey I'm selling you like on everything I'm saying and because then they're going to be detached from that.

Speaker B: And the thing you need to understand with Developer Revolution is that um, it's not as defined as like any other role. Like you know, when you're looking for a role as a software developer, uh, the technology is going to change maybe like the how you're going to do it a little bit is going to change the guideline in place or how the team is working the product you're going to work on. But at the end of the day you code, you build a product with developer relation depending on the approach of the company, depending on the goal, depending on the person doing that role that may change. From my point of view, um, I try to do product pitches as little as possible and sorry boss, as you're listening about that my approach by now I've been there for six months but uh, you know my job is to create connection with human and as you said developer uh developers we a product pitches uh, we hate being Sold. Uh, we hate like traditional marketing, we don't like that. So my goal is to help you being successful and I hope you're gonna be successful with my product. But most of the time I don't even talk about my product. Uh uh, as I said like we have like that's on the Tiny MC side. Uh uh, we have some partners so when I go to their conferences because everybody, they're using our product. Yes I talk about new features of my product because they're already users, it makes sense but, but most of the time I do not talk about my product. But I'm still Fred from tinymce which means that like I'm still promoting the company, I'm still helping you with other type of technology and sometime there's also a way to you know, talk a little bit about my stuff without being a product pitch. Like as an example, one of the last talk I did was introducing uh, developers to accessibility because most people know accessibility as like okay, I kind of know what it is but, but I don't care that much about accessibilities but you know, now there's laws and even without the laws I think it's important to care about accessibility. So it was not about TinyMC but within my 30 minute talks I took a minute and I said like by the way if you use Tiny MC or if you want to know tinymc we have that accessibility checker plugin that does amazing and it was one minute maximum and a 30 minute talks and I was like, and I even made a joke, I'm like hey, I need to do that. My boss wanted me to do that and people were laughing and it's fine and like it was not too much in your face uh, or you know one non technical talk that I've gave uh a couple of months ago was about how to create great developer documentations because sometimes depending on the company where you work, it's part of your responsibility to maintain the developer documentation. It's not part of my responsibility right now because engineering uh, own it at TinyMCE but it was part of my job at the previous company and when I gave that talk I was talking about how to build great developer documentation but which documentation I was using as an example, the one that I own, the one that I created, the one that was about my product. So you know there are ways where like you can talk about your stuff without being too much in your face. But as I said those are really specific example most of the time I'm not even gonna talk about my Product. I'm just gonna introduce myself. I may just say at the end like oh, if you're interested about rich text editor wizard Wig, if you have a user for this in your product, like come talk to me during the break. But that's it because again uh, it doesn't make sense and it's others people job to do those product pitch and to be that kind of person. But like if I really want to build a relationship with developers, if I really want to create something that is not just a short term impact, I need to be transparent, I need to be honest. I need to just be helpful and not always talking about my own stuff.

Speaker A: That's a really interesting point. Right. It's like the, I mean it's developer advocacy, developer relations. Right. Like it's about forming the relationship with development and yeah I guess thinking about as you were kind of uh, walking through that the, the idea of being able to put content together, put you know, talks together that are, that are just generally helpful. Right. Like you're trying to help the audience, um, they're going to be interested in that, they're going to want to attend that. If that's an area where they're like I need to learn about that, I want to be better at that. Then if you're able to like kind of add in something or the context happens to mention like the things that you're, that you're doing and even the fact that you know, if you're introducing yourself and you're saying I'm Fred from X then then they're able to say like it's kind of in their mind like okay, like I, I know that the company name or the area that you're in is not uh, not gone missing. Right. So it's just not in your face and kind of making people go like oh, this feels kind of slimy like right from the beginning.

Speaker B: Exactly. I don't want that because you know, for, for us to be successful as developer advocate it's a lot about who we are as a person. It's our personality, it's how people trust us and it's, it's how they relate to us. So and my job, I can have some quick win, but my job is mostly medium to long term type of impact because it's around the human. Um, as an example, um, at my first job when I was at Microsoft it was a really Microsoft centric workshop but people known about it. It was people that wanted to learn to uh. I think it was creating like Windows uh, 8 application after we launched Windows 8 and I was uh, leading a workshop and one attendee, uh, was having issue with aws. And I mean like I work at Microsoft. We had Azure and it was using aws and I was like, fine, like if I can help you, I'm going

Speaker A: to get out of here.

Speaker B: And. Yeah, exactly. And like, get out of my room. Like you're not using the right cloud service. Uh, but I was like, no, uh, I can help you. I have enough knowledge to help you with aws. And I helped that person. And that person was not, you know, super pro Microsoft because it was also, especially in the time where Microsoft was not, um, has open and has, let's say friendly for lack of other word, uh, that is that Microsoft is right now, no matter your opinion. Uh, it was during the Baltimore era and uh, you know, the guy was like, hey, you know, Fred is not a bad person and maybe Microsoft is not that bad for having someone like Fred. And a year or two after that person started to build application related to the Windows ecosystem. And maybe I'm putting myself too much credit but like it told me that it was like it was because of you, because you didn't dismiss the fact that I had issue with a competitor and you helped me being successful with that. And this is kind of like, you know, the medium to long term impact. So at that moment that person did not use Azure. But like a year or two after, I can't remember exactly, they started user technologies because they were in a place at that time where it makes sense. So you also need to keep this in mind in that role is that maybe right now I'm a tiny mc, maybe you don't need a rich text editor, but we met at a conference. Maybe your next job, maybe your next project, maybe you're going to need something like that and you're going to remember me like, hey, I met the bald guy at the conference and like he was funny and was friendly and, and, and we had a coffee together and like, oh, I'm, I'm going to try his product when it makes sense.

Speaker A: I just realized we have the, the

Speaker B: same haircut, so we have the same style. Like the beard, the hair, it's a,

Speaker A: it's the right way. So, um, yeah, I agree with that. I guess as you're talking about the medium to long term kind of approach here and, and a lot of your role has to focus on that from a, I guess like a personal, like career perspective in terms of feeling like um, I don't know the right way to ask this like in terms of feeling like reward or feeling like you're making progress in your career kind of thing. I feel like as developers it's like we're contributing features. Um, you kind of have a little bit, I don't know, maybe to me it seems like it's more tangible to be like I coded the thing, I delivered the thing, um, we tested it, it got released, customers are using it and the feedback loop feels, ah, maybe shorter term and uh, more tangible. How do you feel about that in your role if, if maybe a lot of it happens to be medium to long term in terms of that, like

Speaker B: that feedback loop you can have? Yeah, I understand where you're coming from and I kind of agree that like the feedback is clearer and faster when you're building stuff. Um, I'm still building in a way. I mean like I create a talk, I give it at the conference, I record a video, I put it on YouTube, I share stuff on social media, I write an article, put it in the blog. And um, obviously I could like keep track with the metrics and like say like, oh, I'm happy that many people rate their read my stuff or that many people watch my videos. But what really gave me that like, you know, feedback loop is when people really take the time to say like, oh Fred, that tutorial was useful. Or after a talk people like, uh, take me like I'm at conference and during the break and said like, hey, good talk, that was really amazing. Or I learned something or uh, like that was, that was insightful. And because people are really fast, especially on the Internet, to criticize things or bad things about your stuff, which is part of the job, you need to, you cannot please everyone. I learned that the hard way. Uh, but for people to take the time to say positive things, unfortunately it's not natural for most people and it seems like we go out of our way when we do that. So when people take the time to do that it means like, wow, I had an impact on people and this is how I see kind of like the value that I bring to the communities when I get that feedback. So I don't do that when for the feedback, but it's always, uh, you know, it's a little bit uh, heartwarming when people like, hey Fred, like tutorial you wrote really helped me with an issue I had with my product or it helped me learn about a new technology that, yeah, maybe not useful right now, but I may like play a little bit, uh, with it during my free time and maybe like my next project. Is going to be useful for me or not. So that kind of feedback is pretty good. Like seeing the impact that you have on people. Uh, you know, but that's the same thing as a software developer. Like when I was building software it was nice to also, yes, you build a feature. But what really amazed me is like when I was able to talk to users and they were like, hey, your product really helps me to save time. It really helps me to achieve something that I wanted to do. So it's a little bit of same uh, with developer relation from my point of view, actually.

Speaker A: Yeah, no, thanks for answering that. I wanted to ask the question because I think that um, for, for different individuals, like everyone has different motivations for, for things that get them engaged or like really what they want to pursue. Right? So you know, some, some engineers are like, I just really like hard problems and being able to put my head down and like really focus on that. Others are like, um, you know, I talk like the perspective of impact. It's like I, I usually look at like two totally uh, different ends of a spectrum for impact where it's like you might be able to have uh, in terms of number of people, the impact is smaller. But how, how much impact for you, you have for some individuals is really, really great versus like, you know, like some of the stuff we're doing at Microsoft right now on like I work on the routing plane for Microsoft 365 that does trillions of requests per day. So the amount of impact per person maybe doesn't feel like much, but there's many, many people. So impact looks different. Um, and so because everyone has different motivations for things that get them engaged, I was, I wanted to be able to kind of, you know, hear from your perspective. Especially I feel like maybe a lot of my audience that watches this, they might not have a lot of insight into developer advocacy and developer relations. So they're like maybe for them they're like maybe that is an interesting area to get into. But I don't know if that's for me, like would I be finding that engaging or not?

Speaker B: So yeah, and I mean uh, specifically for that, uh, I'm just offering that to your audience. Like if you're thinking about maybe developer relation could be interesting for me, find me online. I offer free coffee chat, uh, basically like a 30 minute Zoom call and you can ask me any question. I don't have the only truth, but I have a lot of experience in that role. So I can tell you the good, the bad and the ugly of that. Role and see if it makes sense uh, for you as a person. So would be happy to do that and ah, but I really think that as you said like everybody has like different goal or visions or how they measure how they're successful. But I really think like if you want to be successful in that role, I think it really needs for you to come with the desire to help other people being successful. I think it's, it's the part and the second part that comes with it like oh, you hope that people are going to be successful with your product but like if you, if you switch those it makes more sense business wise but it doesn't make that much sense for the role uh, the role itself. So really like the passion of like helping other people being successful, I think it's what makes people in those role successful. No matter if you're extrovert introvert, no matter if you have a lot of experience as a developer or not.

Speaker A: That was uh, m. The follow up question I wanted to ask you. I think you kind of just touched on. But if you're um, like introverted versus extroverted, obviously you said for yourself you are extroverted. So it, it's probably helpful especially to, for. Okay, let me stop for a second. For people that aren't fully aware like in terms of being extroverted and introverted, uh, what I'm focusing on when I say those words are like if you feel like you're being drained from being around people all day and then you want to detach, uh, so you can kind of get your energy back, I would say that's more introverted and the opposite when you want to be around people because that feels, feels energizing extroverted. If that's not the official definitions, I'm sorry but that's what I mean. Um, do you find that uh, you can be successful as an introvert in, in such a role? It maybe it looks different though.

Speaker B: Yeah. Actually if you would have asked me that question, uh, right when I started my first role as a developer advocate, I would have said no because in my mind to be a developer advocate you need to be an extrovert. But in my first role at Microsoft I work half of the team were introverts and I was amazed by that because I thought I had that kind of like, and I'm not saying this in a negative way against introvert but I thought I had like that super power of being an extrovert that helps me doing that job. But as you said, the difference is that for them let's say, uh, because at the conference this is where we talk to a lot more people. So the day to day job of recording videos and stuff, it doesn't matter. But when you are with people, this is where it makes a difference. And from them it was exactly as you said. We're talking to people all day long. After uh, the conference they were going back to their hotel room and they were not talking to anybody and they were just like decompressing, relaxing and getting back their energy and going to bed. Earlier in my case I had a lot of energy after doing an event and I was going to the uh, events party, the conference party, continue to talk to people. And after the conference party I was still going to have drinks with other people after even when it was done because I, I get a lot of energy being with people. With that said though, doing that job for a long time, I'm also not, I'm also not 20 years old anymore unfortunately. Uh, I feel like right now I'm more like a uh, ambivert which would be kind of like a little bit of half and half. So uh, right now we're still gonna see me like at conference party. It's more because it's my job and I still enjoy being with people. But once in a while I'm gonna tell my team, I'm like, hey, you know what, I'm not gonna be even go to like the team diner. I'm going to go back to my hotel room, I'm going to go to bed early because I still need those time now that I didn't need before where I need to just like relax and get my energy done. With that said though, I'm still, I don't think it's half enough in my case. I call myself Ambiver now. I'm still a super extrovert and it's just less, a little less extrovert than I used to be uh, before. But it's really as you said, I think you can be successful no matter if you're extrovert. Introvert. I just think from the discussion I had that it may has you a little more if you're an introvert because the energy part of it.

Speaker A: Yeah. You'd have to find there's going to be aspects to the role where you do need to interact with people. And like is if you're acknowledging that and you know how to kind of manage your, your energy levels I guess then you can kind of work and optimize for that.

Speaker B: Yeah. And there's different type of role too. I mean like um, many developer advocates role will focus on all aspects of the job which include usually conferences or meetup which is the part where you talk a lot with people face to face. But depending uh, on the size of the company, sometimes the role are split uh, between different aspects of the role so someone can focus on like just creating video so they don't really go to conference and interact with other people. You're still developer advocate, it's just your focus on one part of the role because someone else on your team maybe the extrovert that really get energy going on conference will focus on conferences and you split the job like that. Uh, it's not always depending on the role. Like sometimes it's like just a conference and events once in a while, like once per quarter, something like that which is not that demanding. But sometimes it's like oh, 50, 80% of your time you're in the role. It depends on the approach, it depends on the vision of the company, vision of the person leading developer relations. So uh, don't assume that like hey, if you want to maybe move to a developer advocate role but you're like hey, hey, I'm not sure if I have the energy to do that all the time. Depending where you go, depending on like how the defined developer relation you may find a better fit for you that will not require you a lot of like hey, meeting with person and draining my energy.

Speaker A: Right, yeah, so that's a good point. So if people are you know, listening and watching if they're like hey, this seems like something interesting. I'm just not sure yet. For me, uh, it's not like ruled out completely or uh, guarantee. It's kind of like as you're looking around for different roles like these are things that you should be looking for and trying to see as advertised what the split kind of looks like in the expectations of the role.

Speaker B: Yep.

Speaker A: Awesome. That's uh. Yeah, no, that's, it's really fascinating. It's. I, I uh, haven't. I guess probably because of my own, my own role I have not done a lot of uh, conferences until a little bit more recently just because of outside of work in terms of content creation. I'm like I should, I should go check out this, this kind of stuff and I've started to interact more with uh, like folks in Devrel and it's like I, for me personally I didn't realize like just how much there is in this space. So uh, I found it kind of fascinating to learn from, from others but uh, at the same time it's like I have zero knowledge to share with other people about it if they're interested. So.

Speaker B: No, I understand, I understand.

Speaker A: What would you say like, I guess for people that are on the fence about it, what are kind of, do you have like a couple of top things in mind that um, if they're like on the fence, like hey, if, like if you like this, if you like that or if you're against these things, maybe um, that that might be something to kind of shy away from or kind of any advice in that. In that.

Speaker B: That's a good question. Um, I would say, you know, let me maybe first define what a quote unquote typical developer advocate roles mean. Because there is no real day to day and there is usually a lot of tasks and again it depends on the company. You may not do all those things. You may focus on some stuff but usually it's a fine mix between you know, you obviously things that everybody see. Like you speak at conferences, uh, or you speak at meetups. Sometimes you're just like on boot duty if you sponsor an event, uh, sometimes you just attend to network with people. Again because it's important to connect with the community. Uh, most of the time you're going to do webinars or podcasts like I do right now, uh, or live, uh, stream either at the company or external, um, you're going to record tutorial, video tutorial. Sometimes you may help other team and do more, let's say traditional marketing centric videos. But because you're like the technical expert, you can you know, help uh, other team, uh being able to do that. You're going to write blog posts that are in your own medium or externally. Uh, you're going to help, you know, promote the new feature and stuff. So you're basically, I like to call myself the friendly, approachable, technical, social face of the company. And this is basically a part of my job. And you interact with a lot of teams. Like sometimes you can have a discussion with people and you bring that people to the sales team because it makes sense. Or uh, you work with the marketing team to maybe I would say protect your developer audience or help them to like how to approach developer. Uh, you're going to be active on social media because that's the online way to connect people. You may or may not build or own a community, uh, like a slacker discord or some kind of forums where you're the one who's gonna like uh, being the social media manager or be the community manager. You may Also be responsible for support, technical support. If the company is smaller and you don't have a support team, you can own the documentation. Again, if you don't have technical writers. So there is so many things you can do. So there's different approach to uh, that role. So I would say, um, two things. Like if you like people, I think it's a gift. Like you need to like people you like. You cannot go uh, at an advance or talk with people online. And after you finish the discussion, like, oh, I mean like, let's be honest, that happens once in a while. But if it's always like that, uh, it won't work. Um, as I said before, I think you really need to uh, love helping people. Being successful, uh, creating content in a way or another. You can have preference. Like I prefer to do video content versus written content. Uh, I have to do both. But there's a preference. But in some role, maybe you focus on those. So there is some kind of like content creation that always been part in any, any role. Um, I think if you like those kind of things. If you are also uh, someone who is technical, like technical stuff because your audience is developer, as I said, you need to, need to be critical, you need credible when you talk to people. You need to learn new technologies to keep up. Not everything, but just enough. Uh, so those things are kind of the things that uh, you need to like, uh, or some of it, I mean to be able to be comfortable in that role. Would that say it's not always, uh, beautiful and rainbows and unicorns in natural. Uh, I would say my biggest issue with developer relation is one or two things. Um, one is that it can be totally different from one company to the other. Uh, because as I said before, it's not like, oh, you're a software developer, the job's going to be the same at every company. What's going to change it to technology, the product you're going to build and maybe like you know the best practices you're going to use. But at the end of the day you are creating a software with developer relation. It can mean a lot of things and sometimes it doesn't mean what I think it should mean. Sometimes it's just like, oh, actually you're looking for a technical writer, which is part of the role usually, but now it's, it's that role you're clicking for

Speaker A: or you're looking for someone portion of it. Right?

Speaker B: Is like exactly, yeah, uh, exactly, it's different. Or oh no, actually you're looking for a salesperson and you just put it uh, with all respect for salespeople or cooler title with like developer advocates. So like everybody people use this at every source possible in every ways possible. That is always, that is not always developer relations. So that's problem sometime uh, I think it's a little bit better now because when I started uh, we're not a lot of people doing that around the world because it was just big company because at uh, it's an investment uh, because you don't always get the return right away. Uh so that's one thing. The uh, inconsistency in terms of like what is exactly the role which is a, also can be a benefit. As I said before, maybe you're looking to do more specific activities uh and you don't really like to do the other and makes sense for a specific role. Um, the other thing is that um, even if it's more popular now, uh, even startups now like they're fifth or sixth or seventh hired even after like having a full fledged like engineering uh team they're looking for developer advocates. So people understand now the benefit of having developer relation. But there's still a lot of people that do not understand developer relations. So I've been at jobs where we had a discussion, we had interviews and it feels like we understood each other. But once I was in the role I was like oh no, like you did not understood or I was not able to, maybe it was my fault. I was not able to articulate probably what uh developer relations means to me. And now actually what you want me to do is traditional marketing. What you want me to do is basically being a salesperson which is fine, but it's not what I want to do. It's not my vision of developer relations. So again because it's, it's maybe not super well defined, um, I've seen many situation where like yeah there's a lot of misunderstanding. It's like how we're going to track this, how we're going to measure impact, how the role is going to be. Um, I'm lucky enough right now that where I work, uh, my manager, uh, uh, she hired me because she was like this is your thing, you know what it is. We know it's important. We used to have it, we want to have it again. Uh, but it's not my expertise so I want to hire someone who I'm going to trust that will be able to bring a proper developer relations that's going to benefit the company. So I'm lucky enough that I like right Now I'm like, yeah, I don't have that problem, uh, because, like, she's supporting me and uh, we have that understanding. Like, we have each her own or expertise and we try to bridge the gap and some stuff, but at the same time she's like, you know your shit, do it.

Speaker A: Yeah, exactly. Well, I was going to say, I think that as you were saying, the, it can be a strength and like a problem when you have so much flexibility in the role. And I think that probably just comes down to like, expectations, right? So if you have different expectations and uh, like whatever it, whatever conversation happens before the role versus when you're in it, if that's not met, then that's going to be challenging. But I, um, personally, I find like the same as an engineering manager, like, if I'm being tasked with, like, here's like the area that you're responsible for and I have a lot of trust in you. Please go forward and, and, and take care of this the way that you see best fit. Obviously, I'm there to support you. If I have that from my manager, that makes me, uh, set up for success in my role because it's like, you trust me, okay, and we have a good working relationship. If I need help from you or support, I'll come to you. Great. And I can imagine that in your situation, if you're being told like, hey, like, this is the exact box you need to fit into, you might be like, okay, like, that only works if that box is the shape and size that I need it to be. And when it's not, it's like, this really sucks because there's too much variability that they can try to, to kind of force you into. Is that fair to say?

Speaker B: Oh, no, I totally agree with absolutely everything, everything you said. And, um, the good thing is that, you know, when you're like, hey, I hire you because you have the expertise and you have the experience, and I will trust you. I don't know you yet, but like, you know, we talked a little bit. I'm like, okay, we're gonna start with like, I'm gonna trust you to do the right thing. It doesn't mean that. Also, uh, my manager has nothing to say, or you as a manager have nothing to say or me managing my people. I have nothing to say. I'm like, no, if I think you're going in the wrong direction, we're gonna have a discussion. And maybe I misunderstood something and you will explain it to me, and maybe I'm gonna change my mind, but maybe not. Also, and maybe we're going to realign. The thing is that I prefer to trust people. I don't like micromanagement, I don't like being micromanaged. But if I'm doing something you think is wrong, maybe there's a reason, uh, we're going to talk about it and maybe we're going to agree or maybe you're like hey, um, you choose your battle or we agree to disagree and we move to something else. But yet having that freedom I think is kind of important uh, to be successful. Because again, it depends. Uh, I mean right now uh, I report to like uh, global director of marketing. So my team is part of marketing but I own developer relation. Uh, but when I was icing icy role, um, sometimes my manager was a developer advocate. So in that case it's a little bit different. But when it's someone else, like some, at some point I was reporting to the CEO, at some other point I was reporting to cto. Uh, they may have opinions, they may even have experience, but most of the time they don't. Sort uh, of like, it's more like opinion. And even if I'm not owning Devil because like I'm not a manager, I'm not like in the leadership role, um, sometimes makes that relation a little more difficult but interesting. It's, it's kind of like a case by case I would say. But um, yeah, totally agree with everything you said.

Speaker A: That's no, thank you for sharing that. Um, in terms you're kind of talking through a bunch of the different sort of uh, day to day responsibilities that you might encounter. Right. And obviously as we just said that could, that could shift a lot. Um, I'm curious about uh, maybe the backwards direction. So a lot of what you were talking about was uh, taking things that are like in uh, either internal and obviously advocating for them to a developer audience. What about going the other way? So when you're talking with all of these developers and uh, you're hearing people either go this is awesome or people going this, this stuff sucks or like we're frustrated, um, what does that interaction look like back into development or back to marketing? Maybe how things are message and yeah, just curious on that.

Speaker B: Now I'm ashamed because I forgot to talk about that part when I was talking about the day to day because for me it's a super important part. Um, you know, it's a two way street. My job is not. You know, when I started that job, the title, the popular title were Evangelists and I loved it because it was A good icebreaker. People were like, what do you do? You go to church every Sunday. And um, hopefully it was not negative, uh, seen in a negative way for religious people. Uh, for me it was just like no, like technology is kind of like a religion. You know, just talk with like a big fan of iOS, Apple, uh, and a big fan of Android, put them in the room, uh, that's gonna be like there's no way to change their mind. Like it's like even if you have like great like points and, and like research about stuff like no, this is my device, this is the best, this is my company, this is the best. So there's that kind of like religious part in technology from my point of view. So I love the title evangelist but people assume that the role was just like I evangelize what I the company to the other people and it was just a one way street. My job was just to be like, you know, a speaker for the company and just here to convert you. Right, exactly, exactly. And obviously there is a little bit of that like at the end of the day, uh, like if I do my job well I'm going to get more users. If I do my job well, I'm going to get more paid users. If I do my job well, paid users may pay more for their features but it's a positive side effect of my job. With that said though, uh, it's probably why the title changed more for developer advocates because I advocate on the name, uh, for the name of developer for developers. So yes, there's still a lot of like evangelization where when I speak out about stuff but as you said it's super important to have. It's a two way street. My job is to represent developer internally. Meaning that all the feedback I get, uh, I bring it back to the product team or to the team where it makes sense. Um, also try to, I said protect because I had bad experience in the past but like I protect the developer audience. Uh, sometimes uh, I'm lucky right now it's going super well. But at some other companies I was basically like trying to achieve something and marketing was destroying what I was trying to do with their approach or the sales team was like screwing up my stuff and I was like no, this is not how you approach developer and let me help you to do that. So there is the part where I bring the feedback internally to help us either find issues or uh, have features idea that we didn't have or sometimes just to confirm we're doing the right direction or not with the Roadmap. But there's also a part where like I'm a resource for internal teams. You know, uh, let's say I'm not a salesperson but as I said before, if I talk to someone who looks like hey, I want to pay for that feature, I'm not the best, I can have a little discussion with them but like I'm not the one who's going to be able to give them prices and bundle and have like proper discussions on my expertise. So I'm going to bring them to the sales team. But it's not just that too. I mean like I can talk to the sales team and say like hey, what are the people doing support and what are the questions that are the most popular you get? Oh, okay. Uh, it don't seems like we have content to help you. Uh, so you can have like that one link that you send them instead of having to repeat this all the time or that video that hopefully is going to minimize the number of question about that specific feature issues. So the job is really like hey, developer relation internally representing uh, external developer internally, uh, representing the company externally. So it's kind of like a mix of all those things.

Speaker A: And would you find that like in that sort of that reverse direction from outside in. I'm calling it reverse direction. That's probably not the right thing to say but they can understand. Um, when you're going from the outside in, do you find that there's more interfacing, uh, and maybe this changes from company to company, but more interfacing with like product management or like directly with the like the developer team and engineers or hybrid or like what does that kind of look like?

Speaker B: It's. I think you answered the question for me. Uh, it really depends on the company. Uh, you know right now uh, at TinyMC that's going to be a mix between I have a discussion with the PM or uh, the engineering team. If it's like if I usually go that way. Like if it's, if I think it's a bug, I just talk to the engineering team. Like hey, I think I got that bug reported. I was able to replicate it or I'm not able to replicate complicated. Can, can you look at it? If uh, it's more like about the feature idea. I'm going to talk to the pm. Um, at some companies it's possible and I have a great interaction with the developer teams or the engineering team, the product team. It uh, was not always the case. I think to be successful you need to have that relation. But also it depends on the size of the company. Uh, when I was at Microsoft, uh, and maybe that changed now because it was like 14 years ago, uh, we didn't really have access to the product team. Uh, so yes, I was listening to developers but it was really hard for me to bring the feedback to the product team. I uh, know it changed a little.

Speaker A: Makes a big difference.

Speaker B: Yeah, exactly. And at the same time, um, if I want to be honest, not all the feedback that I get from external developers make total sense or are valuable. So I'm also some kind of like the first filter around it and uh, it's impossible also to please everyone and sometime. But it's good to have that relation because also I don't always have the answer, but I need to find the answer at some point. And sometimes the answer is we know that's an issue, but we have a limited amount of people working on a product. It's not a priority for X reason or yes, that feature is really great, but it's not in the mindset about where we think the product should go. So things but like, like it won't happen. Uh, and to be able to do that you need to like have clarity about the roadmap. You need to understand what's coming up. You need to understand how your team is working internally. So um, right now I have a great relation team. Previous company was the case, other company was not the case also. So also it depends. Um, I had some companies where the product team was like, don't disrupt us with your team. Like we have a revision and we do our stuff. And I was like, fine, but like we have real users that may have issue, may have problem, we have suggestion and they may not all be good but we need to listen to them because even if we don't implement those stuff that helps us to understand what the people using your product needs or have issues or misunderstand about our product. Because you build that thing all day long, you know how it's working. A, uh, new user may use it the wrong way, but maybe that's the way that most people use it because they don't know the product like you do as someone who built it. So anyway, I'm blabbering now but uh, long answer to say like yeah, it really depends from one place to the other. But I think to be successful like for a couple of years now when I do interviews and um, I change job or unfortunately have to change job, uh, one of the things like how is my relationship, how is my relationship going to be with the product team because I think I need that relationship to be successful and I don't want to just tell people, my people like oh yeah, no, I don't talk to the engineering team. So whatever you're going to tell m.

Speaker A: Me basically going nowhere.

Speaker B: Yeah, exactly. Like, like talk to the plushies next to me. That's going to be the same thing, the same result.

Speaker A: No, that's uh, thank you. I think that's super helpful because uh, I'm thinking through uh, like in my software development experience I've not, not uh, worked with uh, Devrel, like at a, at a company like you know, with my team or anything like that. But I'm. Some of the things you're describing, I'm thinking about product managers I've worked with that do an excellent job of like some of those interactions where they're fielding, you know, customer requests. It's not their full time thing but if they're at um, if they're working with salespeople, they're working, going uh, to conferences, they're doing some of that, getting information directly. Um, and I feel like some of the things you're talking about where it's like yeah, maybe not all the feedback is like we're going to go action that or maybe it doesn't make sense for the product. But you're describing a lot of things that when I work with product managers that facilitate some of that um, I, that's not for me because I would be like overwhelmed by that or like trying to tell people like yeah, we're not going to go build that. But, but I also feel for you at the same time like it's ah, yeah, it's a really. That's got to be kind of challenging

Speaker B: to have to go both ways because the thing though is not always negative. Uh, you know like last uh, conference I was um, we had a booth and most, a lot of people were using our product and people just came to the booth to say like amazing, love it, magical. And I was like yeah, you know what? Great feedback. And that just remembered me that I didn't bring that feedback to the product team for that conference. But like it's also part of my job not just to bring the negative but also like hey you know what? Because you like most of engineers do not interact with users most of the time, it's great to have like the feedback not just like understanding like oh bravo, like like your product bring more revenues, fine. But like is people loving them or they just use it because they don't have the Choice and it was imposed. No. So also the positive feedback is something that if I want to be honest, I'm not good at uh, bringing back to the product team because I'm just like thank you and I move to the next step. But like it's, I think it's part of the job to also bring that positive feedback.

Speaker A: Yeah, absolutely. Like I uh, think probably many developers would say like knowing that what they're building not only obviously helps a business make more money, but people are like hell yeah, this is great. Um, I think that goes a long way. Fred, with a few minutes left, uh, do you want to share any specifics around like what you're currently doing and how people can reach out and find you and like all of that kind of stuff. I'll get links and stuff from you after and I'll put them in the description and all that. But yeah, kind of share where you're at and how people can find you.

Speaker B: Yeah. So um, I'm a developer uh relations manager at Ah TinyMC right now which is a rich text editor. You may or may not have used it. We're there for the last. We exist since like 20 years now uh, if I'm not wrong. Uh, so it's basically a WYSIWYG and a couple of line of JavaScript. You had this, your application and you have like a full fledged text editor. So if you're building anything that your users need to create some rich text content, uh, think about us, uh, let me know if uh you have a good or a bad experience. As I said before, if you listen to all the show it's part of the job uh to get both. Uh, you can find me uh, on LinkedIn, uh, Friedrich Harper or just look for Harper. Uh, maybe it's going to be easier uh, it's not my face though. It's like a drawing icon on my face where I use everywhere. So it's it harder but easier also to find me. Uh, I'm also on Twitter F. Harper. I'm on Blue Sky. Not super active there but uh, I'm still there. Uh, and um, yeah also even LinkedIn, uh, I know some people do not accept everyone but like if you work in tech, um, if you're a developer, work in tech, you just want to have more, one more connection. As I said I'm really social. Uh, I'm going to accept you and I'm going to be really happy to have a connection with you, uh, connecting with you on LinkedIn or on Twitter. And um, as I said before Also I offer free coffee chat. Uh, basically as I said, it's a 30 minute Zoom meeting. We can talk about tech, you can talk about developer relation, we can talk about tiny mc, we can talk about meditation, coffee, uh, cats, whatever uh, you want. It's, it's.

Speaker A: I see cat in the back.

Speaker B: There is. Yeah, yeah, there's a, uh, like I have two cats. One of the uh, cats quote, uh, unquote work with me. Uh, actually he's a bad employee. Sleep all the time. All the time. And I have a lazy. Lazy. Yeah, he is lazy. I have a cat painting behind me. Uh, I love cat. Maybe a little bit too much. But uh, those coffee chat are not like just business related actually. It's like if you just want to know one more person in the business, uh, it's nice because it's, it's a tech is big, but it's small at the same time. And what I always tell people, it's often all about the network. It's about who you know, who do you like, who knows you. So uh, just connecting with people, I think it's, it's really interesting and I always love to do that. With that said though, so I travel quite a lot for that job. So I do a lot of conferences at Meetup a little bit around the world. So uh, two things. If you see me in your city, even if you don't go to the events where I'm gonna go, just being me, I, uh, may not have the time, but sometime I'm gonna be, if I have the time, I'm gonna be born and happy to go have a couple coffee with you. Um, and if you organize conference and meet up, think about this guy. Um, I have some speaking experience that I can bring to the table and uh, always looking for uh, places to uh, share my passion about technology, uh, and help your audience, uh, with whatever makes sense for you.

Speaker A: Awesome, thank you so much. And honestly I learned an awful lot here because like I said in our conversation, it's like I'm aware of the role, uh, I know very little about it. And uh, you know, I think that's helpful for me especially if, if uh, I'm talking with people and it's, it's one more thing that I can kind of put in front of them to say, hey, maybe this is a direction that like you could be interested in. So uh, Fred, thanks again so much. And like I said, I'll follow up with you after and stuff to get links and uh, we'll figure all that out.

Speaker B: So, yeah, thanks. For having me. It was a pleas.