3526: TinyMCE and the Human Side of Developer Experience

[00:00:03] Why do some voices in the developer world instantly put people at ease while also stretching their thinking? It's a rare skill. And today's guest is one of those rare people. He can guide developers without ever sounding distant. His name's Frederick Harper. He's a Senior Developer Relations Manager at TinyMCE.

[00:00:26] And he's also someone that has spent two decades helping developers feel seen, supported and ultimately equipped for whatever the industry throws at them. And let's be honest, over the last few years there's been a lot coming their way. But I also want to find out more about Fred's origin story, his path from practitioner to advocate and how that has given him a grounded view of the pressures that developers are facing right now.

[00:00:54] And this is a road that he has traveled on before. He has lived the deadlines, the technical snags, the moments when expectations jump ahead of reality. And I think it's this practical background that sits alongside years spent representing global names for Microsoft, Mozilla, Fitbit and NPM to name but a few.

[00:01:15] But I think what makes his story even more compelling is his personal philosophy that is shaping the way he communicates, teaches and supports communities. And his interest in Buddhism also gives him a much calmer center and a deeper curiosity about people, which I'm sure is one of the many reasons why so many developers trust his voice.

[00:01:39] So today's conversation will move from the hidden complexity of rich text editing to the realities of DevRel in 2025. And yet we'll also talk about the emotional side, the emotional labor behind his community work, the awkward truth about how companies treat open source and even take a peek at personal branding in a world where every post risks blending into the same AI shape blur.

[00:02:08] And Fred's going to counter that with the kind of honesty that makes all of this work feel human. So how can a developer advocate, stay authentic, stay well, while also helping thousands of people succeed in a fast changing environment? Well, I'm not the guy to give you those answers, but Fred is. So enough from me.

[00:02:28] Before introducing today's guests, I just want to give a big thank you to my friends at Denodo, who are helping enterprises make sense of the data world. For example, are you overwhelmed by data chaos? Because between AI hype and lake house sprawl and siloed systems, it can feel impossible to keep up.

[00:02:50] But Denodo is helping you cut through that noise. They unify your data across clouds, apps and sources so you can power trustworthy AI and accelerate lake house optimization, delivering data products that scale self-service for every business unit. Now, whether you are a CIO architect or analytics leader, Denodo will help you engage faster and deliver real results.

[00:03:19] And with their partners, you can also modernize without disruption. So if you're finally ready to make sense of the data world, visit Denodo.com today. But now it's time for me to officially introduce you to today's guest. So a massive warm welcome to the show. Can you tell everyone listening a little about who you are and what you do? Yeah. So my name is Fred. I'm a senior developer relations manager at Tygo focusing on one of our brand tiny MC.

[00:03:49] You know, I've been in tech for about 20 years now, started as a software developer. But in the last 14 years, I've been a developer advocate at different companies, really helping developers being successful. Whatever does that mean for them? Well, there's so much I want to talk with you about today. And I always like digging into the backstory, the origin story of my guest. So you've spent, what, two decades helping developers succeed across companies far and wide from Microsoft, Mozilla, Fitbit, now tiny MCE.

[00:04:18] So when you look back at your journey from practitioner to advocate, are there any key moments that stand out that maybe shaped how you show up for developer communities today? There must have been a few war stories along the way too, but tell me about that journey. There's a couple of them. I would say first and foremost, I think being a developer for almost 10 years helped me being a better developer advocate because, you know, I've been a developer.

[00:04:45] I know the nice thing about being a developer, but also, you know, the things that may not be as nice when you build software, when you work with customers, when you have to use different technologies and different features. So I think that made me more credible when I talk to people, but also really understanding my audience, which are developers. But my first job as a developer advocate was at Microsoft, and I was focusing on open source, open data, and capability.

[00:05:14] And let's just say that it was in the Microsoft era, the Balmer era, where Microsoft was not really seen as open. I would see a little bit like has the evil empire from the open source community. And that was my first job as a developer advocate. So that was not always easy to talk to that kind of audience, but that also really helps me to be more empathic with people really trying to understand that the interactions I have. People have different opinions.

[00:05:40] They have different visions than I have and really trying to understand where and where people are coming from. And the third thing I would say that really helps me to, you know, shape how I work with developers is unrelated to tech. So it's been a couple of years that I'm studying Buddhist philosophy, and it really helps me to become, hopefully, I think so, a better person. Also helped me to develop compassion.

[00:06:06] So it used to be a job to really, you know, try to help developer being successful. But now it's also it's it actually I think it was always a passion, but even more right now. I want to help developer being successful. And with that job quite often the ego kind of like grow because, you know, you become that expert, that public person. And the philosophy really helped me to kind of like lower down that ego and just understanding that like if I'm on stage, it doesn't mean that I'm better than anyone.

[00:06:35] I just have something to share with other people. So all those two getters, I think they helped me to be a better developer advocate and to better connect with my audience, better connect with developers and be part of that community. Wow, I absolutely love that. I always say at the end of every episode, technology works best when it brings people together. And there is so much and I completely love how you're mixing philosophy in there and spirituality as well.

[00:07:02] And your work does touch a part of the web that many of us take for granted and many people listening for granted. That is rich text editing. So for people outside of the tech space, how do you explain the hidden complexity behind something as simple as writing in a browser and what problems are developers still trying to solve in that space? Let's give us a little peek behind the curtain there. Yeah, so we see that every day and everywhere.

[00:07:29] Every tools we use, we need to, we create content at some point and there is that rich text editor and you know, heading has a developer adding a bold or a head to leg button. And it's quite easy. It's the easiest part, but it doesn't give you like a full flat experiment. What people want is everything else that is visible, but also maybe under the hood.

[00:07:49] People want collaboration tools, the one revision history, the one exporting features, the one, the one experience that is intuitive, that is bulletproof with a great UI. And this is where the complexity comes from, but it's not just that people now expect, you know, to have AI assistant part of the rich text editor that is fully integrated, but they also want something that will create accessible content that will also be secure.

[00:08:18] So all those things together, they start to be really complex. So I have a lot of respect for engineering team to build a solid platform with tiny MC, a solid rich text editor or with a wig that helps developer to implement them and has developer with, you know, I've been doing that for a long time. At the beginning, I wanted to build everything myself because, you know, I have the knowledge, I have the power I can do it, but I realized that business wise, it doesn't make sense.

[00:08:44] So now I can use a tool like tiny MC to offer my end users the possibility to create rich text content. And I can concentrate on everything else where I can bring value in the business as a developer. So try to build it to yourself, see how it goes. And if you need like minimal functions, maybe it makes sense for you.

[00:09:05] But I would say most of the time, if you really want to give a great experience to your users, you probably want to go with a tool that is already existing, that is already useful and have all the features that your users want at the end of the day. And developer advocacy, as I think has changed a lot over the last decade and the entire world has changed so much in the last five years alone.

[00:09:27] So what do you think companies still misunderstand about building trusted relationships with developers and how should they rethink the role of dev relationships in 2025? Do you think at even 2026, it looks seen as we're literally weeks away from that now. That's a good question. You know, developer relation has always been that, you know, weird beast that you're not sure what word to put in the org chart.

[00:09:53] And I think it's a long battle. It's not just right now. It's been a while that like I see people not really always understanding developer relation from from my point of view. What is beneficial is trying to or misunderstanding actually is trying to treat DevRel as just a sales funnel. I mean, if we do a job right, it's a positive side effect of my job. I will help to fill the top of the funnel.

[00:10:19] But if it becomes a goal, I just became another traditional marketer or another salesperson, which is not what DevRel is. People think so short term. We are working with the people. I'm building trust and building communities. I'm connecting with people. It takes time. So there's a lot of quick wins that I can do as a developer advocate. But let's think more medium to long term to have a really great impact with that type of role.

[00:10:47] One of the other things that I see that company may not do well, at least from my point of view, is really how we measure the impact. It's difficult to measure the impact of developer relation if you do it like any other business unit. We have different ways to do things. We should have different ways to measure the impact we do. And sometimes you use DevRel as just another person doing the exact same thing as someone else on the team.

[00:11:13] The developer advocate role is like 10 jobs in one. We can do a lot of things and using us as like saying like, oh, I have a developer advocate. That developer advocate can write blog posts. So basically use that person as just a technical writer. I'm not saying that in a negative way. Technical writer or super important role. But like there is so much more we can do if you already have technical writers at your company. Use the developer advocate to do public speaking, to build a community, to create code demo.

[00:11:43] Everything else the developer advocates can do to help companies being successful. So building a team, try to prioritize authenticity, empathy over the volume of tasks to do. Definitely try to think about medium to long term type of impact. Shift DevRel from the top of funnel marketing to, you know, product acceleration, product awareness, trust and community building, education and developer experience.

[00:12:08] And really think about DevRel as its own entity, not just a member that is part of marketing, not just a member that is part of product for engineering. We work with all those people, but we are not those entity. And of course, you've got an incredibly long history with open source and cloud native communities. You've probably heard many different debates on in those communities. So what does healthy participation look like today?

[00:12:36] And how can companies contribute rather than falling into that trap of treating open source as a free resource rather than a shared responsibility? Because we've seen so many big tech companies go in, use some of those resources and then lock it behind one of their new apps and then close it down from everyone else. But what are you seeing and hearing here? This is a pet peeve of mine. Like I want more companies to participate in open source because I would say, and it's a bold statement based on nothing.

[00:13:06] And just my opinion, I would say every product out there's benefit from open source in a way or another and could not exist without what is out there, what is open out there, any other software, framework or library. So it's really important to give back to the community. But there are ways to do that while still respecting the business vision. You know, your engineers use an open source software. They need to fix an issue that is problematic within their software or they need to add a new feature.

[00:13:36] Give it back to the product. Do a pull request to the open source product and give it back to the community was a full for you. It may be helpful for other people, but it's not just engineering. You can also allocate time for other people in your company. You have, as I said, technical writers. They can help fix the documentation. It is as important to have great documentation for open source project than the code itself. You have immense events manager.

[00:14:03] Help them organize meetups for those different product or help them, the open source organizer or people contributors to find great venues or get in contact with people that can help them to organize events or organize conferences. Sponsor a project with some resources.

[00:14:22] If you don't want to have your people spend time, give money to open source projects so they can continue to work on what they're working or help them in a less financial way that still will have an impact. You're a cloud company. Give them free clusters. You are offering a software. Give them free access to that software. So they're going to be able to continue to build their products. So there is many ways to do that without disrupting the day to day business and continuing to achieve your goal.

[00:14:50] But please give back to the open source community, especially if you're using open source software within your day to day as a business or even within your product. A hundred percent with you on that. And also before you came on the podcast today, I was doing a little Googling, a little research on you. And I know that you also have written a book on personal branding for developers long before it was fashionable and all the cool kids were jumping on that.

[00:15:16] So do you think visibility and communication skills matter more for technical professionals now? And assuming you do, how can developers build a presence that still feels authentic in a world dominated by a world that everyone is almost the same? Everything's generic. It's AI and vibe going. And I would argue that having a personality and standing out is more important than ever. But what do you see here? You're right. I think it was important when I wrote the book.

[00:15:44] I think it's even more important right now with AI. And it started to be also important with the rise of remote work, because right now as a practitioner, you are competing against people that are not just local, but basically everyone around the world, depending on the job, depending on the company for. For the better or worse, your resume is enough anymore. You need to show people that you're capable of doing things. You need to show people who you are. You don't need to become like an influencer.

[00:16:13] You don't need to become a web celebrity, but you need to be out there. People need to know you. People need to know who you are, what you're capable of doing. And it's really about, you know, kind of like building that visibility. And it was really helpful for me. And this is why I decided to write the book. And because it helped me find better jobs easily, faster. And it's not because I'm better than my peers.

[00:16:40] It's just because I had more visibility because I was able to showcase people what I was able to do, what I done in the past. So in that case, just try to be authentic. Don't try to mimic other bloggers or live streamer. Just do what makes you happy. What you're enthusiastic about also, you know, don't force jokes if it's not in your style, but put your work out there. Even if you think that it doesn't matter. Even if you think that it's not interesting.

[00:17:08] Even if like that blog post, someone already wrote about the topic. Just do it. You're going to have your special selves, your special approach. And again, that's going to be things that you're going to be able to show people that like, hey, this is my knowledge. This is my expertise. This is my way of thinking. And that's going to be beneficial in different sphere of your professional life. And one of the other things I love about your work is you've got this reputation for making complex ideas feel more accessible.

[00:17:36] You talk in a language that everyone can understand, which is a skill on its own to be able to talk tech and be able to talk to business leaders. So I'm curious what communication habits or storytelling techniques have you found most helpful when you're teaching technical concepts to such a diverse audiences, whether it be on stage or inside an organization? Yeah, I would say it's three or four things that I keep in mind.

[00:18:03] Now it's a little more natural, but I would say I always start with the why and the what. So what is the problem that I'm trying to solve right now by telling you that? What kind of problem I'm helping you to solve? Or also, why should you listen to me? You have like a specific amount of time and during the day you have also a specific time of attention. Why should you care about what I'm talking about at a conference or the video that I just created?

[00:18:30] So always starting about like, what am I talking about and why should you care? Also, never assume the knowledge of my audience. And so when I do, I'm really clear about that example for did that demo. I assume you have some basic knowledge of react. So I won't explain everything in the code. I'm just going to focus on the feature that I want to talk to you about. Also, never, never, never.

[00:18:55] And trust me or don't trust me on that, but I never, ever lie about anything or never embellish the truth. It's super important to keep my credibility as a developer advocate. And, you know, people are intelligent. They will know if I lied about something. It doesn't mean that you have to go, you know, in the rooftop and yell about a huge bug in your software if you have some. But if you have a discussion with someone, be honest. And this is how you build trust when you create content. This is how you build trust when you create community.

[00:19:24] And I will say, lastly, I'm not here to sell anything, meaning that like that's someone else's job. Like we have salespeople that do that. I'm a developer advocate. So my job is to help you being successful. And let's be honest. Oh, like I hope you're going to be successful with my own software. But at the end of the day, again, I'm building a relationship. I'm going to be there to help you get out of issue. You help you have or help you improve what you're working on.

[00:19:53] And again, if I do my job well, a positive side effect is that you may start using your software or you may start paying us to use your software. If it makes sense for you to become a customer. And one thing I wanted to highlight is community work can sometimes feel like emotional labor and giving so much of yourself, whether it be through content or performances on stage or inside an organization in front of hundreds of people. It can be exhausting.

[00:20:22] And the old saying, you've got to put your own oxygen mask on before you help others is so important. So how do you look after your own energy while supporting literally thousands of developers? And what would you tell to younger advocates about finding that right balance, that sustainable rhythm? Because you will burn out if you're just on all the time. And what would you tell us about is that you're always on. That is so true because as the developer advocate, it feels like you're always on, but like you cannot, as I said, you cannot always be on.

[00:20:49] So there's a couple of rules that I try to keep in mind. And if I want to be honest, some of them, I learned them the hard way, but it's about doing that for a couple of years. So really be protective of your personal time. Make a separation work life balance. Turn those notifications off when you don't work. Nobody's going to die. People can wait. They can wait a couple of hours before getting your answers about something. So really be protective of your time.

[00:21:18] I learned that you cannot please everyone as much as you want, as much as you try. Not everyone will be happy with you. Not everyone will be happy with your employer, with your product, and it's okay. So that is probably one of the most difficult thing that I had to understand. Like not everybody is going to be happy as much as I'm think I'm good at my job. That won't happen. And we also set your limits about what is possible and what you're trying to do.

[00:21:48] What are you tolerating from people? You know, what fits within if you're supporting people, what fits within your support parameters or technology, where are you going to be able to help people and places where it won't be possible for you. And you also don't have to accept toxic behavior because they're your customers or because they're your users. Because developers may be more than other people. And I say that as a developer and I'm someone where I can identify with.

[00:22:14] We are passionate people and sometimes passion translate in some, you know, hard words and a lot of feelings when we talk about technology. So really set your limit. And I would say the last thing is save your keystroke and try to scale what you're doing. So someone has you a question. If this is something that they cannot find in the docs, answer them, but update the documentation after. So next person will be able to find that information.

[00:22:44] You have a harder problem to explain that you think other people could have and that you can kind of like make the support public, write a blog article, create videos about it. So again, other people will be able to benefit from your answer. Someone has an issue that you confirm with the product has them to create their issue themselves on GitHub and be sure that that you use proper templates that get hold the information that you need to be able to better answer their questions.

[00:23:14] So it's about being efficient, being effective. And as I like to say, save your keystroke. So if there's something that you can reuse to help future people, that will probably save you some time. And again, protect yourself and your time. I love that. And one other thing I wanted to explore before I let you go today is that as problems inside every organization become more complex and indeed the expectations from their customers become more complex,

[00:23:41] I think it's never been more important to have diverse perspectives in solving those complex problems. And on the industry side, we still see uneven representation in developer relations and developer tooling teams. And that could be from a variety of backgrounds as well and inviting more people to live into the space. So how can organizations better create space for more women, more underrepresented groups in these roles?

[00:24:06] And how does that better representation shape the kind of innovation and problem solving that DevRel is well known for? It's again, more important than ever, isn't it? Yeah, I totally agree with that. And it's an important topic to me. But keep in mind, I'm a white dude, so I may be wrong with my answer. But this is like what I think we could do to improve. And again, I'm a white heterosexual man. So let's see.

[00:24:33] But I think we should start by fixing the hiring process. You know, I read some research that say that like women will apply only to a role when they feel like they have 100% of the criteria versus men's going to be about 60%. So be really clear in your job description. What is the critical need for that job? And what is the good to have? Use inclusive language like gender neutral language. I think it's a better approach. Also try to, you know, recruit differently.

[00:25:03] Like there's organization and communities out there that will focus on underrepresented group in tech. And try to standardize how you evaluate candidate, you know, for a job to limit or as much as possible interviewers bias. Never, never tolerate toxic or unwelcome behavior within your organization or tech event. No, John, it's not just a joke what you said. Like it can offend other people.

[00:25:33] You know, allow also flexibility on the job. And this is from what I read. So this one is just something that I read on the topic, but I has an example. Unpaid. It's unpaid caregiving. Whether it's children or other adult is disproportionately falls on women. So when you don't have flexibility, it doesn't give them the freedom to be able to do that. And, you know, be as an be an example as much as possible.

[00:26:03] You know, as a speaker myself, I can refuse to speak at an event where when I see the list of speaker, it's only white men like me. Like, no, try to diversify. It's possible to have amazing. And it's not that complicated. It's not complicated at all to have a diversify list of speaker at your events.

[00:26:22] Lastly, I would say provide, you know, DEI and implement some bias training or workshops because it helps employees recognize and address unconscious bias, which we all have. So having someone that can help us understand those and really trying to be more conscious about that.

[00:26:42] I think all those things together could help us to, you know, have a better hiring process and get more diversity in our teams, whether it's developer relation or engineering as all. Yeah, I completely agree. And the bias training is incredibly important. And there's another issue as well that we kind of didn't miss there. We alluded to it slightly is the bias in A.I. recruitment tools.

[00:27:08] There's almost a black box A.I. that sits in the corner that nobody really knows how it comes to the conclusion or what was programmed into it. But I think there's an article I read recently. It was showing a huge bias against women, for example. So those A.I. recruitment tools, they need to be looked at as well, don't they? Oh, yeah, I agree. I can't agree more. Well, thank you so much for talking with me today. We covered a lot in 25 minutes.

[00:27:33] So for anyone listening wants to dig a little bit deeper, join your community, get some speaking time with you. Where can they find you? Where would you like everyone to go? I'm a social person in person, but also online. So, you know, I'm on Twitter X. You can find me, Hef Harper, also Frederick Harper on LinkedIn. Feel free to hand me again. I like to connect with people. If you work in tech, connect with me on LinkedIn. Obviously, there is on the TinyMC side.

[00:28:02] You can go on tiny.cloud. That's our website. Join Tiny on Twitter or X and TinyMC on LinkedIn. Also in 2026, keep an eye on our blog because I'm planning to build a TinyMC developer community, which we don't have right now. We have people using, we have a lot of people using our product, but we don't have a place where people can be part of our community. So part of my job at TinyMC, I'm building a community that will be open in 2026. So keep an eye on that.

[00:28:32] That's going to be like where the cool kids going to be. That's going to be a place to be if you want to connect with me and connect with my team. Oh, you've left us with a big teaser there. Sounds like we need to get you back on in 2026 when everything's up and running and help spread the word there. And do you have any events before the end of the year or any speaking gigs or are you finished now? No, I'm not finished. You know, it's developer relation world. So I'm actually in two days. I'm going to Australia.

[00:29:00] I'm going to speak at Moodle Moot Australia. So one of conference two days there. And also while I'm in Australia, outside of like meeting koalas and like kangaroos, I'm also speaking at an Umbraco meetup. So those are the two last gig for the year. December is going to it's slowing down for events and conferences and meetup, which is good because, you know, 2026 is coming. There is still a lot of things on my plate to build for next year. But those are my last two events for the year so far.

[00:29:30] Awesome. Well, anybody that heard that, I hope they check you out while you're on the road. And if not this year, maybe next year. And I love so much about your story and how you've helped thousands of developers succeed by bridging the gap between cutting edge technologies and developer communities. As I said earlier in our conversation, a big skill. But you do that with not only a big heart, but also a philosophical mind as well. So kudos to you. Thanks for joining me today. I appreciate that. And really, thanks for having me. That was a real pleasure. Sure.

[00:30:00] So what stayed with you during that conversation? I found myself thinking about how Fred balances the demands of community work with a personal philosophy that keeps him grounded. And he brings a mix of patience, honesty, curiosity and real world experience that reminds us why thoughtful communication matters more than ever in tech.

[00:30:22] And his reflections on DevRel and open source participation and the emotional weight of being available to so many people, I think offers a fresh perspective that leaders and practitioners alike can learn from. And also refreshing to hear how he's framing visibility for developers without drifting into the dreaded influencer playbook. And his ideas to me feel rooted in care for the craft rather than the race for attention.

[00:30:52] He said multiple times, this isn't about me. I'm not bigger than anybody else. I'm not better than anybody else. And I think that instinct shows up in his plans for the tiny MCE community in 2026, which sounds like, again, they're giving developers a place to learn and experiment and share without judgment. But as always, I want to hear from you. How are you navigating visibility, community expectations or the shift in developer experiences as AI reshapes that work?

[00:31:21] And what resonated with you in Fred's approach? And where do you see things differently? Whatever it is, let me know your thoughts. TechTalksNetwork.com. And you can also get me on LinkedIn, Instagram, just at Neil C. Hughes. But that is it for today. Time for me to kick back and relax for a while before joining you again tomorrow morning. Speak with you now. Bye for now.