devrelshow episode 49 - Niall Deehan from Camunda

devrelshow episode 49 - Niall Deehan from Camunda ![rw-book-cover](https://img.youtube.com/vi/PzHm7Q1X9as/maxresdefault.jpg) 🔗 **Source:** [devrelshow episode 49 - Niall Deehan from Camunda](https://www.youtube.com/watch?v=PzHm7Q1X9as) > [!note]+ Document Notes > tags: [developer-relations, devrel-evolution, technical-credibility, career-sustainability, marketing-vs-product] > author: [MISSING] > source: YouTube > reference: [https://www.youtube.com/watch?v=PzHm7Q1X9as] > date created: {{date:YYYY-MM-DD}} {{time:HH:mm}} > > # 🏷️ Title: devrelshow episode 49 - Niall Deehan from Camunda >  ## 🧭 Table of Contents - [📝 Summary](#-summary) - [📖 Main Content](#-main-content) - [🗒️ Notes](#️-notes) - [📚 References](#-references) - [🗣️ Paraphrase](#️-paraphrase) - [📰 Newsletter](#-newsletter) - [✅ Action Items](#-action-items) - [🧪 Hypotheses](#-hypotheses) - [📊 Methodology](#-methodology) - [❓ Questions](#-questions) - [🔮 Future Research](#-future-research) - [💡 Implications](#-implications) - [🧠 Learning Styles Assessment](#-learning-styles-assessment) - [📊 Accessibility Assessment](#-accessibility-assessment) - [🌍 DEIB Assessment](#-deib-assessment) - [✅ Logical Validity](#-logical-validity) - [🛡️ DARVO Analysis](#-darvo-analysis) - [🎯 Conclusion](#-conclusion) ## 📝 Summary - **What happened**: DevRel Show episode featuring Niall Deehan from Camunda discussing the evolution of developer relations over 11+ years. - **Why it matters**: Reveals fundamental tensions in DevRel between authentic developer-to-developer communication and marketing-driven outcomes. - **Key stakeholders**: DevRel professionals, marketing teams, product teams, engineering leadership, developers as end users. - **Risks and tradeoffs**: Moving DevRel to marketing departments risks compromising authenticity; staying in product may limit resources and reach. - **Bottom line**: DevRel sustainability requires genuine product enthusiasm, technical credibility, and organizational alignment with honest developer communication. ## 📖 Main Content The conversation explores how developer relations has evolved from its origins as authentic peer-to-peer technical communication to a more marketing-oriented discipline. Both speakers represent the "old guard" of DevRel—technical practitioners who fell into advocacy roles organically rather than pursuing DevRel as a primary career path. ### Core Evolution of DevRel Originally, DevRel emerged from a simple need: companies wanted technical representation at developer events that could bypass traditional marketing constraints. Early DevRel professionals were developers who could speak honestly about their products' strengths and limitations to peer audiences. This model worked because: - **Product ownership**: DevRel reported to product teams, not marketing - **Technical authenticity**: Practitioners were active developers - **Honest communication**: No requirement to tie activities to immediate revenue - **Peer credibility**: Speaking developer-to-developer, not company-to-customer ### Current Challenges Both speakers express concern about modern DevRel's drift toward traditional marketing: 1. **Organizational placement**: Moving DevRel to marketing departments creates pressure for measurable financial outcomes 2. **Career DevRel professionals**: People who specialize in DevRel skills but lack deep technical domain expertise 3. **Title proliferation**: Role ambiguity through confusing job titles and scope creep 4. **Authenticity erosion**: Pressure to present products in "best light" rather than honest assessment ### Technical Credibility Debate The discussion addresses whether DevRel professionals can maintain credibility while switching between different technical domains (frontend to databases, for example). Fred argues that learning new technologies is manageable for experienced practitioners, while Niall emphasizes the importance of genuine domain expertise and product enthusiasm. ## 🗒️ Notes #### ⏱️ [00:00:00](https://www.youtube.com/watch?v=PzHm7Q1X9as?t=0) Opening and introductions - Fred introduces episode 49, approaching milestone episode 50 - Two-year guest waitlist demonstrates healthy DevRel community interest - Weather affects mood and energy levels for content creation #### ⏱️ [00:04:12](https://www.youtube.com/watch?v=PzHm7Q1X9as?t=252) Niall's background and philosophy - 11 years at Camunda, 8 years in DevRel specifically - Started as software developer, transitioned to advocacy naturally - "Practically perfect in every way" - positive mindset approach - Originally DevRel meant honest developer-to-developer communication #### ⏱️ [00:08:45](https://www.youtube.com/watch?v=PzHm7Q1X9as?t=525) DevRel evolution concerns - Original model: developers sent by product teams to speak honestly to peers - Modern reality: marketing-driven roles with revenue attribution requirements - Avoids saying "DevRel" to other developers due to negative associations - Common reaction: "Oh, so you're marketing basically" #### ⏱️ [00:15:30](https://www.youtube.com/watch?v=PzHm7Q1X9as?t=930) Organizational department impacts - Product vs marketing placement significantly affects role perception and execution - Product placement: focus on user feedback and honest technical communication - Marketing placement: pressure for growth metrics and promotional messaging - Fred's experience maintaining boundaries within marketing organizations #### ⏱️ [00:22:18](https://www.youtube.com/watch?v=PzHm7Q1X9as?t=1338) Job titles and credibility - Niall dislikes his "Process Alchemist and Technical Evangelist" title - Title was imposed, not chosen, creating explanation burden - Industry shift from "evangelist" to "advocate" due to religious connotations - Title consistency matters for career progression and role clarity #### ⏱️ [00:28:42](https://www.youtube.com/watch?v=PzHm7Q1X9as?t=1722) Career sustainability discussion - Question: Is DevRel a sustainable career path? - Challenge: Maintaining technical credibility across different domains - Niall would likely move to similar technology company rather than different DevRel role - Fred: 15 years moving between different technical domains successfully #### ⏱️ [00:35:15](https://www.youtube.com/watch?v=PzHm7Q1X9as?t=2115) Technical expertise requirements - Debate: Should DevRel require deep technical expertise vs communication skills? - Ideal candidate: domain knowledge + communication abilities - Reality: Often choosing between technical depth and advocacy skills - Learning technology is easier than developing communication/relationship skills #### ⏱️ [00:42:30](https://www.youtube.com/watch?v=PzHm7Q1X9as?t=2550) Product enthusiasm necessity - Impossible to succeed in DevRel without genuine product excitement - Developers have strong "bullshit detectors" for inauthentic advocacy - Fred turned down lucrative offer due to lack of product enthusiasm - Caring about product impact more important than just technical competency ## 📚 References - [DevRel Show](https://www.youtube.com/c/DevRelShow) - Fred's ongoing interview series - [Camunda](https://camunda.com/) - Niall's employer, workflow automation platform - [TinyMCE](https://www.tiny.cloud/) - Fred's employer, rich text editor platform ## 🗣️ Paraphrase This DevRel Show episode captures a candid conversation about how developer relations has evolved over the past decade. Fred and Niall, both veterans with 11+ years in the field, discuss their concerns about DevRel's shift from authentic peer-to-peer technical communication toward marketing-driven activities. The core tension revolves around organizational placement and role expectations. When DevRel teams report to product organizations, they can focus on honest feedback loops and genuine technical discussions. When moved to marketing departments, they face pressure to demonstrate immediate financial impact and present products in the most favorable light possible. Both speakers emphasize that successful DevRel requires genuine enthusiasm for the product being advocated. They argue that developers can quickly detect inauthentic promotion, making it nearly impossible to succeed without believing in what you're representing. This creates interesting challenges for "career DevRel" professionals who might excel at advocacy skills but lack deep technical domain expertise. ## 📰 Newsletter **DevRel Evolution: The Authenticity Challenge** This week's DevRel Show featured a fascinating discussion between two industry veterans about how our field has evolved—and where it might be losing its way. Niall Deehan from Camunda and host Fred shared concerns about DevRel's drift from genuine developer-to-developer communication toward traditional marketing approaches. Key takeaway: The most successful DevRel professionals maintain genuine product enthusiasm and resist pressure to compromise on honest technical communication, regardless of which department they report to. If you're in DevRel, consider how organizational placement affects your ability to serve developers authentically. Worth watching for anyone navigating the balance between business objectives and developer trust. The discussion of career sustainability and technical credibility across domains offers valuable insights for planning your DevRel journey. ## ✅ Action Items #### DevRel - **Organizational placement audit**: Map how department placement affects DevRel authenticity and developer trust across portfolio companies - **Career pathway documentation**: Create guidelines for maintaining technical credibility when transitioning between domains - **Authenticity metrics**: Develop frameworks for measuring genuine developer engagement vs vanity metrics - **Cross-department relationships**: Build processes for DevRel success regardless of organizational placement #### Community - **Veteran practitioner interviews**: Capture institutional knowledge from early DevRel practitioners before it's lost - **Role definition standardization**: Work toward clearer industry understanding of DevRel responsibilities and scope - **Authenticity best practices**: Document successful approaches for maintaining developer trust in marketing-oriented organizations #### WordPress - **DevRel placement strategy**: Evaluate optimal organizational structure for WordPress.org developer relations activities - **Community feedback loops**: Strengthen mechanisms for honest technical feedback from developer community to product teams - **Contributor authenticity**: Ensure contributor relations maintain peer-to-peer rather than company-to-developer dynamics ## 🧪 Hypotheses - **Organizational placement hypothesis**: DevRel professionals in product organizations maintain higher developer trust and authenticity than those in marketing departments - **Domain expertise hypothesis**: Technical domain knowledge is more important for DevRel credibility than general advocacy skills - **Enthusiasm requirement hypothesis**: Genuine product enthusiasm is necessary (not just helpful) for DevRel success - **Career sustainability hypothesis**: Long-term DevRel careers require either deep specialization in one domain or exceptional ability to build authentic expertise quickly - **Developer perception hypothesis**: Developer audiences increasingly associate "DevRel" with marketing rather than authentic peer communication ### 📊 Methodology - **Longitudinal study**: Track DevRel professional career paths and perceived credibility across organizational moves - **Developer surveys**: Measure trust levels toward DevRel professionals in different organizational contexts - **Content analysis**: Compare messaging authenticity between product-led and marketing-led DevRel teams - **Outcome correlation**: Analyze relationship between DevRel placement and long-term developer engagement metrics ### ❓ Questions - How can DevRel professionals maintain technical credibility while transitioning between domains? - What organizational structures best support authentic developer advocacy? - Is the "career DevRel" path sustainable without continuous technical practice? - How do we measure authentic developer engagement vs performative metrics? - What role should revenue attribution play in DevRel evaluation? ### 🔮 Future Research - Industry-wide survey on DevRel organizational placement trends and outcomes - Longitudinal study of developer trust metrics across different advocacy approaches - Analysis of successful domain-switching DevRel professionals' strategies - Correlation study between product enthusiasm and advocacy effectiveness ### 💡 Implications - **Practice**: DevRel hiring should prioritize product enthusiasm and domain expertise over generic advocacy skills - **Policy**: Companies should carefully consider organizational placement effects on DevRel authenticity - **Education**: DevRel training programs need stronger emphasis on technical depth and honest communication - **Funding**: Investment in DevRel should account for long-term relationship building rather than short-term attribution ### 🧠 Learning Styles Assessment Reading level estimate: 12th grade (Flesch-Kincaid) #### 👀 Visual learners - **Present**: Conversational video format with speaker identification - **Improve**: Organizational charts showing DevRel placement options, career path diagrams, timeline graphics of DevRel evolution #### 🔊 Aural learners - **Present**: Full audio discussion with natural conversation flow - **Improve**: Chapter markers for key topics, audio summary highlights #### 🗣️ Verbal learners - **Present**: Clear definitions of DevRel terminology, analogies to traditional roles - **Improve**: Glossary of terms, comparison tables between old vs new DevRel approaches #### 🧩 Kinesthetic learners - **Present**: Real-world career examples and decision points - **Improve**: Interactive decision trees for organizational placement, hands-on assessment tools #### 🧠 Logical learners - **Present**: Cause-and-effect relationships between organizational placement and outcomes - **Improve**: Framework diagrams, decision matrices for role evaluation #### 🧑‍🤝‍🧑 Social learners - **Present**: Peer-to-peer conversation format between industry veterans - **Improve**: Discussion prompts for DevRel community groups, collaborative reflection exercises #### 🧘‍♀️ Solitary learners - **Present**: Individual reflection points about career decisions and authenticity - **Improve**: Self-assessment worksheets, personal mission statement templates #### 🌿 Naturalistic learners - **Present**: Organic evolution of the DevRel field over time - **Improve**: Ecosystem thinking about DevRel's place in broader tech industry evolution ### 📊 Accessibility Assessment #### Screen reader semantics - **Present**: Video title and description provide context - **Improve**: Full transcript with speaker identification, timestamp navigation, chapter headings #### Keyboard navigation - **Present**: Standard YouTube player controls - **Improve**: Custom transcript navigation, keyboard shortcuts for topic jumping #### Contrast and readability - **Present**: Standard video player interface - **Improve**: High contrast transcript option, customizable text sizing #### Text resizing and reflow - **Present**: Responsive YouTube interface - **Improve**: Dedicated transcript page with responsive design #### Media and captions - **Present**: Auto-generated captions available - **Improve**: Professional captions with speaker identification, downloadable transcript #### Forms and interactions - **Present**: Basic video controls - **Improve**: Enhanced navigation with topic bookmarks, note-taking interface ### 🌍 DEIB Assessment #### Cultural breadth - **Present**: Perspectives from Canadian and German-based practitioners - **Improve**: Include voices from underrepresented regions in DevRel, discuss cultural differences in developer communication #### Inclusive language - **Present**: Generally professional and accessible terminology - **Improve**: Define industry jargon more consistently, avoid assumptions about career privilege #### Neurodiversity support - **Present**: Conversational format may be engaging for some learners - **Improve**: Structured topic headers, consistent pacing, summary sections #### Representation - **Present**: Two male perspectives from established companies - **Improve**: Include diverse voices across gender, company size, career stages, technical backgrounds #### Psychological safety - **Present**: Honest discussion of career challenges and industry criticism - **Improve**: Content warnings for career anxiety topics, resources for support ### ✅ Logical Validity #### Strong reasoning - **Experience-based arguments**: Both speakers draw from 11+ years of direct industry experience, providing credible firsthand perspectives - **Causal relationships**: Clear connections drawn between organizational placement and role authenticity outcomes - **Pattern recognition**: Identification of industry evolution trends supported by specific examples #### Fallacies - **Anecdotal evidence**: Over-reliance on personal experience without broader industry data to support claims about DevRel evolution - **Survivorship bias**: Perspectives from successful long-term practitioners may not represent challenges faced by newer or struggling professionals - **False dichotomy**: Presentation of product vs marketing placement as binary choice ignoring hybrid organizational models #### Tone of voice - **Conversational and authentic**: Natural discussion style maintains credibility while remaining accessible to various experience levels ### 🛡️ DARVO Analysis No DARVO patterns detected. The conversation involves honest professional reflection and industry criticism without defensive tactics or victim/offender dynamics. ## 🎯 Conclusion This conversation reveals fundamental tensions in modern developer relations between authentic peer communication and marketing-driven outcomes. The speakers' concerns about DevRel's evolution toward traditional marketing highlight the importance of organizational structure and genuine product enthusiasm in maintaining developer trust. **Practical next steps**: DevRel professionals should evaluate their organizational placement's impact on authenticity, prioritize genuine product enthusiasm in role selection, and maintain technical credibility through continued learning and honest communication practices. The industry would benefit from clearer role definitions and better frameworks for measuring authentic developer engagement beyond traditional marketing metrics. ## 🔄 Refactor Appendix — devrelshow episode 49 - Niall Deehan from Camunda ### 📚 Literature Atoms #### Organizational placement fundamentally shapes DevRel authenticity and effectiveness > [!quote] > "When you put into uh that that department identically into a marketing department for example and again I can only speak to my experience you then need to re-evaluate what you are bringing to that department because now you are being paid by the budget associated with promoting the company positively to the people who will pay for it" **Context & use**: - Core tension between product-led vs marketing-led DevRel around 15:30 - Explains why departmental reporting structure affects role execution and developer trust - Critical for understanding modern DevRel organizational challenges **Tags**: #xref #devrel-structure **Highlight**: [view highlight](https://www.youtube.com/watch?v=PzHm7Q1X9as?t=930) #### Product enthusiasm is necessary, not optional, for DevRel success > [!quote] > "I think it's incredibly hard to do the job if you don't at least care or not necessarily care, but let's say have a good understanding of um why the product is something people should be excited about in some way" **Context & use**: - Around 42:30, discussing requirements for sustainable DevRel careers - Distinguishes between technical competency and genuine product belief - Addresses why "career DevRel" professionals struggle without domain passion **Tags**: #xref #devrel-authenticity **Highlight**: [view highlight](https://www.youtube.com/watch?v=PzHm7Q1X9as?t=2550) #### Early DevRel model prioritized peer communication over marketing outcomes > [!quote] > "The early uh sort of devril folks if you were a developer a software developer and you could talk and explain the technical aspects of what you were building really well you ended up sort of being the first cohorts into what became Devril" **Context & use**: - Around 8:45, explaining historical origins of developer relations - Contrasts authentic peer-to-peer model with modern marketing-driven approaches - Provides foundation for understanding current industry tensions **Tags**: #xref #devrel-history **Highlight**: [view highlight](https://www.youtube.com/watch?v=PzHm7Q1X9as?t=525) ### 🧠 Permanent Candidates #### Authentic developer advocacy requires genuine product enthusiasm over generic skills **Claim**: Successful developer relations depends more on authentic belief in the product's value than on general advocacy or marketing capabilities. **Evidence pointer**: [[#Product enthusiasm is necessary not optional for DevRel success]] **Scope & conditions**: - Holds when: Target audience consists of experienced developers with strong "BS detection" - Breaks when: Audience is less technically sophisticated or when short-term metrics matter more than trust **Links**: - [[Developer trust metrics]] — because evidence-for measuring authenticity - [[Career sustainability frameworks]] — because applies-in long-term professional planning - [[Marketing vs product alignment]] — because contrasts on departmental priorities ### ✏️ Fleeting Queue - [F1] Research industry data on DevRel organizational placement trends — validate anecdotal observations - [F2] Investigate frameworks for measuring authentic developer engagement vs vanity metrics ### → Things 3 - [ ] Survey DevRel community on organizational placement experiences and outcomes #things - [ ] Document organizational structure options for authentic developer advocacy #things --- ## Full Transcript [00:00] Heat. Heat. [00:31] Hello, hello, beautiful people. Welcome [00:33] to another episode of I was going to [00:36] talk about another show, but the terra [00:37] show with Fred with Fred. I was going to [00:39] say welcome to another episode of [00:41] Backstage with Fred, which is a show I [00:43] do I do at Tiny MC when I'm on the road. [00:46] Uh yeah, no, it's a Dro show. It's the [00:49] It's the right one. So, uh really happy [00:51] to be here. always excited uh to do the [00:53] Dell show. It's uh one of may my baby [00:56] and actually episode 49 if I'm not wrong [00:59] today which mean that like the next one [01:01] is going to be episode 50 which is some [01:04] kind of like milestone. I mean like you [01:06] know half uh so it's going that [01:08] direction. I'm nowhere near uh to stop [01:12] that show. I mean, I will continue to do [01:15] that as long as I have guests because as [01:17] I always say, that show obviously [01:19] there's my name and kind of like my face [01:21] on it because that's kind of my show, [01:23] but like you could remove me from that [01:25] show. It's all about the guests. They're [01:27] the one making the show. So, as long I [01:28] have as I have guests, I don't know how [01:30] I like I'm not able to speak in English, [01:32] but as long as I have guests on my show, [01:35] that show will continue. And let me tell [01:37] you, my friend, so far so good. I think [01:39] I have guests. Uh, and I'm not even [01:41] lying here for the next two years uh, in [01:43] the wait list. So, it's a good problem [01:45] to have. It It's really sad though for [01:47] uh, people that wants to join the show [01:48] because I'm like, "Yeah, can you wait [01:50] like about two years before coming on [01:52] the show?" And hopefully he's still [01:54] going to do that job while uh, that's [01:56] going to be your turn. But anyway, I'm [01:58] blabbering now again. Maybe I don't [02:00] know, maybe I'm just happy like it's [02:01] finally summer in Canada. We really had [02:03] bad weather until recently. Uh yesterday [02:06] we started to have like summer weather [02:08] and whether you like it or not weather [02:10] affect your mood. Uh and now my mood is [02:13] just more I don't know peppy. I don't [02:14] know it's summer time. Anyway, super [02:17] happy to be here. I have an amazing [02:18] guest today. Nile. How is live? [02:22] >> Practically perfect in every way. And uh [02:24] you can't tell me any different. [02:27] I I I feel that if it if you don't wake [02:29] up in the morning believing that then it [02:31] can only go, you know, can only get [02:32] worse because my day can definitely get [02:35] worse from there. But it's still pretty [02:36] good by that stage if you're already [02:38] starting at quite a high point. So [02:39] that's my usual rule of thumb. [02:41] >> I like I like that. I like that. Uh and [02:44] and you tell me if I'm wrong because I'm [02:46] really bad with, you know, with names. [02:47] Like I don't think we like we never met [02:50] in person, but we're connected on [02:51] LinkedIn for since since probably [02:53] forever. Uh, so it's basically the first [02:55] time we're interacting together. And [02:57] >> you know what I do with my guests is [02:59] that's usually to join 15 minutes before [03:01] the show. So I can just give them like a [03:03] little bit like, hey, let me tell you [03:05] what I sent you by email, but like just [03:06] to be sure you remember like how the [03:08] show's going to go. Uh, no real prep, [03:10] but just like, hey, this is how we're [03:11] going to do. First part it's discussion, [03:13] second part is the demo and and just [03:15] testing like everything is working well. [03:17] And uh so I basically quote unquote know [03:20] you for like 10 minutes and I just love [03:24] the energy. I just love the energy and [03:26] like just based on your answer the [03:28] positive uh approach that you've done [03:31] because uh you know I I don't want to go [03:34] into into religion or philosophy be like [03:35] I'm Buddhist. Uh I follow the Tibetan [03:37] Buddhist philosophy uh which is uh you [03:40] know like basically the premise is like [03:42] life is suffering which seems super [03:44] negative when you think about it but [03:46] that's a little bit true which doesn't [03:47] mean that like I'm someone negative or [03:48] someone that seeing like life is [ __ ] I [03:50] just know that like there's always [03:52] something happening but as you said if [03:54] you have a positive attitude yeah things [03:57] can go down but like if you start on a [03:58] high note and you try to keep positive [04:01] uh I think it's great. So I just wanted [04:04] to, you know, highlight the fact that I [04:06] just love that approach. Uh it's so much [04:10] more fun too. It's it's like it hyped [04:12] the vibe too when the other person are [04:14] positive instead of like when if I ask [04:16] you like how are you? How is life? [04:18] You're like yeah it's not going well. [04:20] It's rainy outside. We don't know about [04:22] our job is going to be secure and [04:24] whatever. [04:26] >> Yeah. And and don't forget as well, not [04:28] only am I practically perfect in every [04:30] way, it's also 6 PM my time. So, I've [04:32] been doing pretty well all day. So, this [04:34] is not only a starting point, this is [04:37] where I'm essentially like grounding my [04:39] day to. No, I had a very lovely day [04:41] today. And uh yeah, I um I I fully [04:44] expect this to be a wonderful hour of of [04:46] of your time, of course, and anyone [04:48] watching, but uh because we got a really [04:50] fun stuff that I really want to talk to [04:51] you about because I think um one of the [04:54] things that I was quite looking forward [04:56] to you about is Devrell stuff in [04:58] general. This is the Devrell show after [04:59] all and because [05:02] um I am in a really small team of myself [05:05] and a few other folk, but no one else [05:07] would consider themselves like in [05:09] Devril, right? So, I have a bunch of of [05:12] interesting discussions, I think, lined [05:14] up for you about just the concept of how [05:17] you feel about Devril in general. We've [05:19] both been in the industry for the same [05:21] kind of amount of time, maybe you're a [05:22] little longer than me. Um, and then we [05:24] can maybe start talking about sort of a [05:27] uh how the dynamic has shifted over the [05:28] last little while because I'm interested [05:29] in your opinion as well of course about [05:31] uh if [05:32] >> love it [05:33] >> we all live in the bubbles of Devra in [05:35] some cases and you wonder like is this [05:37] how the whole industry is or is it just [05:38] what's going on in like the the [05:41] connections that I have. So I'm quite [05:43] looking forward to chatting about that. [05:44] >> I really love that. Great ideas. I love [05:47] when the guests come and like hey this [05:49] is what I want to talk about. Uh but [05:51] like before we even jump into that uh [05:53] two questions for you. One what what are [05:55] you drinking or and the second thing the [05:58] second question is like who are you? [05:59] Like tell like people that do not know [06:01] you like who are you? [06:02] >> I like how you prioritize those [06:04] questions and you were right to [06:05] prioritize what I'm drinking first when [06:07] I'm I live in Berlin and I am drinking [06:10] an IPA uh from Burllo which is a [06:13] relatively nice local brewery. Um not a [06:16] small brewery but a local brewery. I [06:18] wouldn't say it's the best craft beer in [06:19] Berlin, but it's um the one I have and [06:22] it's quite nice. I'd suggest if you like [06:23] the kind of beer, you should uh give it [06:25] a try. And who I am, which is again less [06:28] relevant uh but still important. Who's [06:30] who's drinking the beer is the question [06:31] people are going to ask. So I'm Nile. So [06:33] I um work as uh I work for Commund doing [06:37] developer advocate stuff. I've I've been [06:39] doing it for a long time. I've been with [06:41] Commund for for the last 11 years or so [06:45] doing various things and I think just [06:48] like most folks tend to fell into Devril [06:51] kind of not by looking at the the what [06:56] people do but doing it and then being [06:58] told that's what it is that's what [06:59] you've been doing and uh that happened [07:02] quite a while ago. So I've been doing [07:03] deval stuff for about eight years maybe [07:06] and before that I was a software [07:08] developer and uh then like I think like [07:13] the early this is this is my perception [07:17] like the early uh sort of devril folks [07:21] if you were a developer a software [07:23] developer and [07:26] you could talk and explain the technical [07:29] aspects of what you were building really [07:31] well you ended up sort of being the [07:34] first cohorts into what became Devril, [07:36] right? So that in that in that universe, [07:39] Devril was trying to solve for a [07:41] relatively small problem which was we [07:43] want our product team to be properly [07:46] represented outside of the company uh in [07:48] a way in which we can kind of skip [07:50] around other departments. Now how do we [07:52] do that? We send a developer who likes [07:55] talking to a conference or something or [07:57] to a meetup group or they talk to their [08:00] peers [08:01] and free of like the trappings of um [08:05] talking points and uh pre-approved [08:08] slides, right? You show code and you can [08:10] have really honest conversations. And [08:12] honestly, I was really drawn to Devril [08:15] easily for that. loved talking honestly [08:19] to developers um who uh use the uh who [08:23] use the software we were building and uh [08:26] having a lot of honesty around that. It [08:28] was a fantastic time. One of the things [08:30] that kind of like disillusions me to [08:34] Devril these days is that that's a [08:36] really rare one, right? I'm not sure [08:39] that really exists so much anymore. a [08:41] developer who actually is sent by owned [08:44] by the product team who is sent to speak [08:47] honestly about the software to not to [08:51] users, clients, potential customers, but [08:54] other developers, their peers. And I [08:57] think that's a big movement that Devrell [09:00] has had in the last 10 years that has [09:03] really um made me feel like while I've [09:06] stayed in this one lane, this whole big [09:10] thing has happened in the meantime that [09:12] has just reshaped it to the point where [09:15] if someone like asks me, oh, what do you [09:18] do? I avoid saying Deborah. I will I [09:21] will cry [09:23] depends on their the context. Who are [09:25] they? If they're a software developer [09:27] who I'm interested in having a [09:28] discussion about the nitty-gritty of [09:31] software saying I'm I'm Devril I have [09:34] found recently and when I say recently I [09:36] mean the last maybe four years so it's a [09:39] while right I have found the reaction is [09:41] oh so you're you're marketing basically [09:45] >> yeah yeah [09:45] >> and so what kind of impression Fred do [09:47] you have out of interest uh around that [09:50] same idea what what do you think first [09:53] of all about the growth cycle I talked [09:55] that resonate with you at all? [09:57] >> I have so many things to say about [09:59] everything you said. Um, wow. I don't [10:02] know where to start. So uh the first [10:03] thing I've seen that change a little bit [10:06] also in the role where like like [10:07] initially there was like hey you know [10:09] with all respect for for traditional [10:11] marketing that was not the way to [10:13] approach uh you know developer with all [10:15] respect from the sales team like [10:18] developers are allergic to sales uh and [10:20] we were like hey we need like developers [10:22] to talk to developers but as you said [10:25] also remove from the like I don't know [10:28] let's call them shackles of like the [10:30] company or or like you know hey you need [10:32] do it that way and you need to sell it [10:34] with those words and you need to use [10:36] those terms so like it's going to make [10:38] sense for the business and it was like [10:40] no let's just be honest. So uh sorry for [10:43] the word but like since I do that job my [10:45] my moto was always uh no [ __ ] Uh [10:48] first because like I'm not that kind of [10:50] person. Secondly because I don't think I [10:52] can be successful in my role if I'm [10:54] trying to line or or talk about things [10:56] that do not make sense for developer do [10:58] not resonate with them. Uh I think it [11:00] was a lot more exactly what you said at [11:02] first. I think it depends on the company [11:04] and or the people doing the job. So it [11:06] changed obviously like as a general rule [11:09] like as you said like I I feel the role [11:11] change a little bit and again it can be [11:12] so different from one company to the [11:14] other. Um I think it's the first time [11:17] I'm going to say that this but I think [11:18] I'm really proud of like me keeping my [11:22] ground on that like no this is how I see [11:24] the role. This is how I think the role [11:26] is effective. this is how I think it can [11:28] benefits the company if I do it in my [11:31] own terms with my own vision of dev [11:33] which is exactly what you talked about [11:34] we we started with that where was like [11:36] developer talking to developers I'm not [11:39] part of engineerings or or most of the [11:41] jobs I had I was not part of product uh [11:44] but because I always came with the [11:46] approach of like no I'm not I'm not [11:49] going to lie I'm not going to I'm not [11:50] going to be a salesperson if I do my job [11:52] well like hopefully maybe developers [11:54] will use our product or they become [11:55] users they become paid users or [11:57] customers, but like that my goal is to [11:59] help developer being successful. And uh [12:02] again, hopefully, don't get me wrong, I [12:03] like to have a paycheck, so hopefully [12:04] they're going to be successful with my [12:06] product. But if my product is not right [12:07] for them, uh it's fine. If another [12:09] product is also good to a competitor, [12:11] I'm not going to lie about that. I may [12:13] not go on the rooftop and say like, [12:15] "Hey, use that other product." Like [12:17] they're better with that specific [12:18] functionality. But if we have a [12:20] discussion with someone, like I'm going [12:21] to be really honest about it. [12:23] >> Yeah. I'll tell you why. That's um [12:25] that's something that really uh concerns [12:27] me. So here's the thing about uh Deell [12:30] is not part of um product right um and [12:34] I've experienced this where the Devril [12:36] department shifts around and the shift [12:38] from product to marketing um made very [12:41] little difference I think on the [12:44] dayto-day of the people uh working right [12:47] um but it had a profound impact on the [12:51] perceived value of uh of of the team [12:55] because when you're in product right uh [12:59] the goal is uh um very much well depends [13:04] company like company again I can only [13:05] speak my own experience which is which [13:06] is what I will do the goal tends to be [13:09] you are in a department a very technical [13:11] department with a lot of technical [13:13] people who are both interested in the [13:15] feedback from the developers which is [13:17] the ideal scenario a devro person should [13:19] of course be a voice of uh of the end [13:22] user the the developer user inside the [13:25] the product the product and also So be [13:27] able to get that information that the [13:29] devs are trying to say, hey, this is the [13:31] way we see our the the stuff we're [13:33] writing being used in a in the here's [13:35] the best way to do it and go and like [13:38] make sure that folks understand that [13:39] because it's not always very obvious for [13:41] whatever reason, right? So this made it [13:43] a really really nice two-way street, [13:45] okay? Because you really do end up with [13:48] this embedding and everyone kind of [13:49] works quite well with that. A key thing [13:51] that's not there is any um illusion to a [13:57] um uh a dissemination of marketing [14:00] talking points or more importantly a [14:03] requirement to link the work you do to [14:06] specific financial outcome uh which I [14:09] think is no matter where you put devil [14:11] is impossible. So when you put into uh [14:14] that that department identically into a [14:17] marketing department for example and [14:19] again I can only speak to my experience [14:21] >> you then need to re-evaluate what you [14:25] are bringing to that department because [14:27] now you are being paid by the budget [14:30] associated with promoting the company [14:33] positively to the people who will pay [14:35] for it because as lovely as marketing is [14:38] they have no interest in telling someone [14:42] who has no money how great the product [14:44] is. Yeah. Because they are, you know, [14:47] what value does that have? [14:49] >> Um, and when I say what value, what [14:51] immediate value does that have? [14:53] >> There's no sort of long train on that. [14:55] So then you find the activities you do, [14:58] the things you're judged on end up being [15:01] quite uh tainted by this creeping uh [15:06] pattern of judgment based on um growth [15:12] and projections that the marketing [15:14] department also believe in. So which [15:18] makes everything you do less sincere. [15:22] And so um I've never loved the idea I've [15:25] actually well not never loved disliked [15:27] intensely the idea of having to have [15:31] what should be a completely productled [15:35] role put into a position where you need [15:39] to have this terrible idea of standing [15:42] in front of some a developer who uses [15:45] the product and or who doesn't and tell [15:48] them things that you know maybe are [15:51] showing the product in the light but not [15:52] the most honest light because you know [15:54] that you probably it's better to show it [15:56] to them in in the best light because [15:59] that way they'll join the community or [16:00] do something that's measurable right so [16:03] that's how I felt I think most of well [16:06] that's how I perceive devro as a [16:10] concept has gone which is why I don't [16:12] tend to tell people that I'm associated [16:15] with devrell because they make a link [16:17] these days and again I'd love to hear [16:19] your feedback on this yeah [16:20] >> these days from that person does devril, [16:23] that person does marketing, marketing [16:25] are liars, that person's a liar. [16:28] It's always a little more nuanced than [16:29] that, but that I tend to get. [16:32] >> Yeah. No, I mean I I agree with most of [16:36] what you said with uh a caveat uh in the [16:40] sense that like it is like that in [16:42] general. Uh and this is also uh why I [16:46] lost some jobs because you know I was [16:48] part of a marketing and we had [16:50] interviews and you know you have [16:51] interviews it's like I don't know if [16:53] you're lucky it's just three or four [16:54] interviews so you talk to maybe three or [16:56] four people for let's say four hours so [16:58] like you don't know each other but I'm [17:00] still really always transparent about [17:01] like this is my vision of devil this is [17:03] how I usually wants or should be [17:05] measured uh and I I don't want to be [17:08] tied to amount of money uh those are my [17:10] reasons this is my approach it may be [17:12] totally different from what your team [17:14] does, but you need to live with it. And [17:15] if you don't, I'm not a right fit for [17:17] you. And please, when I say that, I'm [17:20] really privileged. I've been doing that [17:21] for a long time. Uh right now, maybe [17:24] life is different like with with [17:26] everything that is happening. But like [17:27] it was a little bit and I'm not saying [17:29] that like I'm so good. It's just because [17:30] I've been doing that for a long time. I [17:31] have a great network. Uh work at at [17:33] great places that give me legitimacy [17:36] even if if it means nothing in the end, [17:38] but like it was easier for me to get a [17:40] job. I was able to filter jobs and be [17:42] like, "No, this this is not a good fit [17:44] for me." But some places, even if they [17:46] were like, "Yes, okay, sounds good to [17:48] me." They were still expecting me to be [17:50] more like traditional marketing or more [17:52] like a salesperson or more like another [17:53] role or have a different approach after [17:55] like a couple of months or a year. They [17:56] were like, "Oh, yeah, Fred Fred is not [17:58] changing his mind. Uh, okay, bye. Like, [18:01] we we don't need you. We need someone [18:02] else." uh it's also why I lost some jobs [18:05] or I moved in like from other jobs uh [18:07] once in a while because I was like no [18:09] this is not my vision but al so been [18:11] lucky that I joined team that like [18:14] because I rarely was like my perfect [18:16] place as you said would be like it in [18:18] product or engineering uh because of the [18:21] nature of the role and there is a little [18:23] less uh you know expectation from you to [18:27] align with the goal of like marketing [18:29] teams or other teams that may not align [18:30] with de uh But also usually they don't [18:34] have budget. So uh when you're in [18:35] marketing at least there is the [18:36] opportunity to have budget to do some [18:38] stuff. But I've been lucky that like [18:40] most of the jobs I had uh like where I [18:42] am right now uh marketing is doing an [18:45] amazing job is doing an amazing [18:46] marketing job but they also really [18:49] understand my manager um she just left. [18:52] So we'll see with the next one but my [18:53] manager she was really like hey where [18:55] are you for reasons? I know there's a [18:57] different way for you to do things. I [18:58] know there's different reasons and I was [19:00] really clear about like yeah I'm not a [19:02] salesperson. I'm also not a marketing [19:04] person. I'm part of marketing. Uh but [19:06] also I'm gonna have a different [19:07] approach. So you know the first talk I [19:09] did uh when I joined the company I [19:10] didn't use the template slides. I didn't [19:12] use the marketing slides that were [19:13] created. Some people were not super [19:15] happy with that but my boss was like no [19:16] there's a reason and I explained them [19:18] why I do it that way. And people got in [19:21] and now I mean like marketing is [19:23] updating your website. They're like hey [19:25] Fred like what do you think about that [19:26] doesn't resonate with developer? and and [19:28] I can go to the team and say like no you [19:30] know what that line is [ __ ] I mean [19:32] like like it may sounds right in your [19:34] head a developer will look at it and it [19:35] will say like no it's marketing [ __ ] [19:38] so we changed and we updated so long [19:41] answer to say uh I agree with exactly [19:43] what you said but it will depends on the [19:46] in my experience again I'm just talking [19:47] about my own experience in my experience [19:49] it depends on the team and the people [19:50] that are on the team and I've not always [19:53] been lucky but I would say most of the [19:54] time where I am right now so far so good [19:57] uh people understand that like have a [19:59] different approach. you also understand [20:00] that like from my point of view [20:02] developer relation is uh you can have [20:04] short wins uh in terms of like you know [20:07] you just talk about stuff and like hey [20:09] that happens I'm still always like I [20:11] don't do product pitches most of the [20:13] time I talk about other stuff that [20:14] excite developers and but I'm still Fred [20:17] from Tiny MC so maybe they're going to [20:18] be like oh what the hell is Tiny MC and [20:20] maybe they're going to be in a website [20:21] maybe they're going to be curious maybe [20:22] try it maybe they're going to become [20:24] users and or customers but it's also a [20:26] medium to long-term type of job because [20:29] my primary role is to build relationship [20:31] with developers. And maybe you don't [20:34] need my product right now, but maybe [20:35] your next job or your next project. [20:37] Maybe you're going to remember me that [20:39] didn't try to sell you anything that was [20:41] really honest with you that uh you know [20:43] didn't try to like complete goals that [20:46] don't make sense with my job. So anyway, [20:48] I'm talking after that. uh just saying [20:50] that like yeah I've been lucky that uh [20:53] in some jobs I was even if I was still [20:55] part of marketing um I was still able to [20:58] basically do what I think my role should [21:01] be and not be tied to metrics that will [21:05] let's be honest poison my approach or my [21:07] relationship with developers and to be [21:10] successful no matter the department you [21:12] are uh and after that I'm going to read [21:14] a question unless you have something you [21:15] want to add right away about what I' [21:16] I've done what I've said but um Um you [21:20] know also to to be successful and even [21:21] if you're not part of product or [21:23] marketing you need a really strong [21:24] relationship with those teams uh because [21:27] you know the product I need to [21:28] understand where we're going like what's [21:30] the road map uh I need to be able to the [21:32] engineering team and product to bring [21:34] them the feedback from the developers [21:35] when I talk to our users or people that [21:37] try our product because as you said it's [21:39] a two-way street for me was always a [21:40] two-way street. Uh, it's also why and I [21:43] want to talk a little bit about your [21:44] title at some point because first I like [21:46] the first part and the second. No, did [21:48] you say please don't? [21:49] >> I hate my title. I think it was given to [21:51] me as a joke uh to uh so I I actually [21:55] rarely I I left it out of my intro kind [21:57] of on purpose and I had this a funny [22:01] enough I had a an I'd give a talk with a [22:04] colleague of mine like on Tuesday at a [22:07] guest lecture and I I asked him hey [22:09] listen during the intros I'm not going [22:10] to say my job title is that okay and I [22:12] don't want you to do it either and he [22:14] said no problem and then the the the [22:16] professor came up and then immediately [22:18] introduced us by our titles and then [22:20] question me about it. But no, I think it [22:22] was uh yeah, I think it was meant to um [22:25] humiliate me. And uh [22:27] >> okay. [22:28] >> Well, [22:29] >> I like it. I like it. If I want to be [22:31] honest, [22:32] >> it's quite meaningless. And of all the [22:34] things I don't like about being [22:36] associated with sort of the the what is [22:39] like the the newest version of Devril, I [22:42] feel an obscure job title with with no [22:46] understanding of what this might be is [22:48] one of those things that like I want [22:50] people to know what I do and my job [22:52] title doesn't do that at all. [22:54] >> Yeah. Yeah. Okay. I get it. I was just [22:56] excited about like the the alchemist [22:58] part of it and also the the technical [23:00] evangelist because like u you know I've [23:03] been doing that rail for uh now maybe 15 [23:06] years and when when I started the title [23:08] we were all evangelists like it was [23:10] either technical evangelist developer [23:11] evangelist and at some and I loved it uh [23:14] because [23:15] first nobody known what I was doing so [23:17] it was a good icebreaker and they were [23:19] like are you going to church or be [23:20] something and I was like yeah that was a [23:21] good icebreaker but the the the oil [23:23] industry slowly switched to developer [23:26] advocates because they felt like, yeah, [23:28] we we we're not just evangelizing stuff. [23:30] We're like, it's a two-way street as you [23:32] said and also because some people were [23:33] offended probably because of like the [23:37] religious connotation of like [23:38] evangelism, but like I always like that [23:40] title. So, okay, we won't talk more [23:42] about it. Uh [23:43] >> I do like developer advocate was [23:46] something that is two words. It's got [23:47] developer in it. People can kind of [23:49] guess. He's pretty good. process [23:51] alchemist and technical evangelist is an [23:54] insane thing to call yourself and uh I [23:58] understand that and uh unfortunately I [24:00] need to explain to other people that I [24:03] didn't choose it for myself uh which is [24:05] something people think and I just need [24:06] to get out there. [24:07] >> I thought it was I thought it was the [24:09] case because I'm like there is no in my [24:11] mind I was like there's no way that HR [24:13] was like so uh we going to hire uh what [24:16] do we need to help the business being [24:18] successful? Oh yeah, process alchemist. [24:20] I'm like, "No, I don't think ASR is [24:21] going to do that." So, I was like, "Yo, [24:23] Nile, choose a title." But like, now I [24:24] know. Sorry. I was like, I was just [24:26] like, "I need to talk about this because [24:28] it was excited." And N was like, "Nope, [24:30] please shut up." [24:32] >> But, uh, okay, let's move to another [24:34] topic. Uh, with that said, last thing [24:35] about title, uh, [24:37] >> I think no matter your title, it's [24:38] probably unusful for like I don't care [24:40] about titles at all. I know there's a [24:42] lot of people that care about them, but [24:44] uh you know like like my job right now [24:47] um I lead a team so they gave me like [24:49] senior developer relations manager. Uh [24:52] if I want to be honest, if I look at the [24:54] other people on the chart and it's not [24:55] because oh I'm so better or not better [24:57] but uh like like compared to other [25:00] people that does about the same job as [25:01] me at a company where I am it should be [25:04] director of developer relation. Do I [25:06] care? Not at all. Some people care [25:08] though. Uh so I think it's also why it's [25:10] a little bit important because the day [25:12] you want to find a new jobs uh people [25:14] will like if if it doesn't work where I [25:16] am right now and I want to find a new [25:17] job like they won't think about me as [25:19] like a director they won't think they [25:21] will think about me as a manager. Even [25:22] if my day-to-day role is like a mix of [25:24] IC stuff mix of management but also the [25:27] big picture thinking about their role. [25:29] Anyway, let's jump to uh oh yeah [25:31] actually last thing before I move to the [25:33] question. Daniel uh Andress was like I [25:35] feel like all titles are made up these [25:36] days. uh which is true and this is also [25:38] one thing that annoy me a little bit [25:41] with developer relation uh not the fact [25:44] that that there's different titles but [25:46] like developer advocate title can mean [25:49] something totally different from one [25:50] company to the other [25:51] >> meaningless these days it's it's [25:53] hilarious how meaningless it is it's the [25:54] only reason I had to get rid of that [25:56] thing developer advocate no longer [25:58] represented what I did because it was [26:00] such a broad and misunderstood title [26:02] that um better to have complete [26:05] ambiguity than people making assumptions [26:08] about what I can or what I am or am [26:10] capable of. And so that if I had to [26:12] choose, I'd probably keep my title over [26:14] going back just based on the power of [26:17] ambiguity can at least give you that at [26:19] least people have to ask. Um so that's [26:22] something but I totally agree with [26:23] Danielle there. [26:24] >> Yeah. And uh I I just forgot one [26:26] question. You wanted to have my my my [26:28] opinion or or vibe or experience about [26:30] it. Uh so far uh I didn't see people [26:34] reacting negatively when I say I'm a [26:37] developer advocate. Uh the thing that [26:39] changed over the years is that people [26:41] now have an idea what I do where in the [26:43] past I was like okay let me let me [26:44] explain you uh what I'm doing because [26:46] you know when I started it was mostly [26:48] big companies like only people who had [26:50] like technical evangelist was like [26:51] Microsoft, Apple, Google. My first job [26:53] was at Microsoft. Uh and after that, [26:55] like a couple of years after, like a [26:57] startup that had like 15 people, not [26:59] even like a full-fledged engineering [27:01] team to build the product that they [27:02] wanted. They were like, "Hey, now our [27:03] product is mature enough. We want [27:05] someone to talk about it and and and I [27:07] don't know, own the docs and do videos [27:08] and stuff like that." And we're hiring [27:10] developer advocates. So now more people [27:11] know about it. Uh with that said though, [27:14] obviously like some people may see a [27:15] negative connotation about it. Uh the [27:18] the things that I've always done in my [27:20] life is that like I always feel like I [27:22] looks like nothing compared to other [27:23] people. I'm always like my black t-shirt [27:26] and my beard and I look like a hobo. But [27:28] like once once I start to do my [ __ ] [27:30] people are like oh yeah I think this guy [27:31] know a little bit what he's doing and [27:33] the title like is less important more [27:35] than like oh I like your approach. I'm [27:37] like oh you're not trying to sell me [27:38] this. I'm like no it doesn't make sense [27:39] for you. I'm like oh what do you think [27:41] about that competitor? They're doing an [27:42] amazing job. Like if you need them to do [27:44] this this this go with them. If you need [27:46] something else, oh, go with else. And uh [27:48] this is my approach. So anyway, uh talk [27:51] way too much, but that's also why I'm [27:53] being paid. Uh so there's a question [27:55] from uh Neil Lee. Um I'm sorry. I'm just [27:59] going to say uh there's a question from [28:00] someone. [28:01] >> Nan. Yeah. [28:03] >> Oh, you're so much better. I don't know [28:04] how like I struggle with names so much. [28:06] It's why [28:06] >> it's a classic German name that I'm I'm [28:08] aware of. Yeah. [28:09] >> Okay. [28:10] >> Nulman. Yeah. It's [28:12] >> wonderful. Thank you. And I Sorry. I [28:14] apologize. I should stop trying to say [28:16] the name of people. Uh because most of [28:18] the time I I screw them up and I hate [28:20] that. [28:20] >> Mine is hard, but it's only four letters [28:22] or five letters. I think I can never [28:24] even remember myself. I think it's more [28:25] than three anyway, but I have misspelled [28:27] my name multiple times. Um [28:29] >> so yeah, do you think Davel, uh sorry, [28:32] >> go ahead. [28:33] >> Yeah, I was just going to read that [28:34] question. So do you think Davel is a [28:36] sustainable career? How can someone go [28:38] from being a front-end developer [28:39] advocate to advocating for vector [28:42] database without losing technical [28:43] credibility? That's uh good question. [28:46] Big question too I think. So uh do you [28:48] want to go uh first to your guest? [28:51] >> Well the first thing I would say to that [28:52] is uh well from my perspective um if I [28:56] were to leave my current job I would not [28:58] become a developer advocate. Um I am [29:01] primarily interested in the fundamentals [29:04] of workflow automation and automation in [29:06] general of stuff. that's kind of what I [29:08] really care about and I get the most joy [29:11] in general out of like building stuff [29:13] that that that that can utilize that [29:15] technology. So if it if um if I were to [29:20] do this this this job, it would probably [29:22] likely be I would move away from Devril [29:26] to another company that does a similar [29:28] type of thing. Uh rather than move into [29:31] a company that does Devril that I could [29:33] do exactly what I do but for a different [29:35] technology. Um that's partly due to the [29:37] fact that my career was I was interested [29:41] in this software first and then Devril [29:44] kind of found me rather than move [29:46] around. Right? So therefore I've never [29:49] uh needed to I've never applied for a uh [29:52] a Devril position rather in internally [29:55] in my company. I was given that role [29:57] because we were a very small company [29:58] when I started and I was there when we [30:01] sort of we didn't even know what devell [30:02] was uh when we started and then we got a [30:04] a manager that was able to actually put [30:06] manners on things and kind of had done [30:08] deval and stuff like that. So that was [30:10] that was a hope that was that was a nice [30:11] uh transformation. But the um the the [30:15] point is that for this question I would [30:17] say that it's really hard to keep [30:19] credibility. uh if your job is to speak [30:23] to a technical audience about a very [30:25] technical subject and you've come into a [30:28] role without that technical knowledge [30:30] for example I think it's really really [30:32] hard to sustain that because um I think [30:36] it's if you can it's easier to stay [30:39] within your technical expertise and move [30:42] within the Devril community in that [30:44] maybe if you wanted to do Devril [30:46] primarily but I think that actually sort [30:51] dedic it sort of showcases a an issue [30:53] with Devril in general where you can end [30:57] up with career Devril folks who end up [31:00] being very good at Devril, right? But [31:03] they're they could then end up in the [31:05] wrong technology [31:06] >> that that they they they don't fully get [31:10] don't really like they get hired first. [31:11] They have a great track record for [31:13] example of doing de stuff. they get [31:15] hired into a a technology that they just [31:18] never really click with. And if you [31:20] can't understand or speak honestly about [31:23] the technology that you're supposed to [31:24] advocate for, it's not like marketing [31:26] where you're kind of supposed to just [31:28] learn to lie. [31:29] >> You need you need to talk to people on a [31:31] fundamental level about how this works [31:33] and and be able to give honest reaction. [31:36] And that's why I always I I think so I [31:39] often think about what how difficult it [31:41] would be to do my job if the stuff I did [31:43] wasn't good and wasn't um and in the [31:46] past there's been there's been like a [31:48] few releases where the software was not [31:49] in great shape where it was way harder [31:52] to do your job. [31:53] >> But you know I still like the overall [31:55] technology. I knew the potential. So you [31:57] got to speak honestly about that. [31:59] >> Yeah. Um yeah, and that again is much [32:02] easier if the department is not in [32:04] marketing where you're being told here's [32:06] how you're supposed to speak about the [32:07] software. Doesn't matter that I can't do [32:09] that yet or that it does it very badly, [32:11] but this is we're talking about the [32:12] future and I think um that can be a [32:15] trapping as well. But yeah, that's my [32:16] opinion on that's a very long answer to [32:18] the question. [32:19] >> No, that's good. That's good. Um I'm [32:20] going to share my opinion too because um [32:22] there's things are a little bit [32:24] different from from what you answered. [32:26] Um [32:28] just to add on the last thing you said [32:30] you know like like again I from my point [32:32] of view again it's it's not like black [32:34] or white in terms of like oh marketing [32:35] is just like like they ask you to do [32:38] that or not like as an example when I [32:40] joined Tiny MC they were like hey when [32:41] we talk about Tiny MC we use the term [32:44] rich text editor because this is how it [32:46] is defined in the industry uh this is [32:48] like I don't know there's also SEO [32:50] implications stuff like that and I was [32:51] like fine. So I'm like, okay, it's this [32:53] my first job in in that specific area of [32:56] expertise. So I'm like, I'm going to do [32:58] that. And after my first event talking [33:00] to developers, it was like no developers [33:02] know what is a rich text editor. Like [33:04] everybody's like, so what is this [33:06] exactly? And at some point I was like, [33:07] oh, wait a minute. Uh, it's a wiz. And [33:09] everybody's like, oh, okay, I know what [33:11] it is. And now I can have a discussion [33:13] with someone that already have like the [33:14] the the light bulb flash over their [33:16] head. I'm like, so I came back after the [33:18] first event. I'm like, hey, you know [33:19] what? uh continue to use rich text [33:21] editor wherever it makes sense because [33:22] we have like different target audiences [33:25] mind their developer doesn't make sense [33:27] and people are like oh that's different [33:29] from what we're used to I'm like doesn't [33:31] matter what I'm telling you is that rich [33:32] text developer rich text editor they do [33:34] not know what that is when I say wiz [33:36] awake they're like they understand so I [33:38] changed my language and people are like [33:39] okay awesome it makes sense for you so [33:41] again it depends on the team of the [33:42] people so I just want to be sure there's [33:44] no nuance there and also uh if there's [33:46] my marketing uh colleagues watching like [33:49] I want you understand that. I understand [33:50] there's difference and I I think we're [33:52] doing a great job. Again, I'm not being [33:54] a soccer. [33:55] >> I'm speaking very frivolously about [33:57] marketing as a concept, not individuals [33:59] or any specific team [34:00] >> and I understand too. I understand where [34:02] it's coming from. Uh if I want to be [34:04] honest, uh and I'm usually always honest [34:07] and for the better or worse in my life. [34:09] Uh I'm always honest and I had really [34:12] bad experience with marketing. I also [34:13] had a really terrible experience with [34:15] the sales team who were basically [34:16] screwing me over because they were doing [34:18] things that doesn't make sense for my [34:19] audience. And I'm also happy where I am [34:21] right now when I when we have a booth at [34:23] events and I'm always with a [34:25] salesperson. Why? Because I'm not going [34:28] to be the one who's going to sell to [34:29] developer but as a business we still [34:31] want to sell to developer but they're [34:32] doing an amazing team and I love their [34:34] approach. They will never force someone [34:35] to say like hey they're on commission so [34:37] like obviously they need to do more [34:39] sales. want to have a proper salary, but [34:41] like I really love the sales team. We [34:42] have a tiny MC where they're like, [34:44] "Okay, doesn't make sense for you." [34:46] Fine, keep us in mind. Maybe in the [34:48] future we're going to have a [34:48] functionality that makes sense for you. [34:50] Maybe in the future you're going to have [34:51] a use case, but they're not pressuring [34:52] people, which was not an experience I [34:54] had with most people. So, there's also, [34:56] it always depend on the people. It [34:57] depends on the leadership team because [34:59] they're basically the one who set the [35:00] tone. To go back to your question, uh [35:03] 520, this is what I'm going to call you. [35:05] Uh do you think the is a sustainable [35:07] career? Uh I would say yes from my point [35:09] of view. This one is a really personal [35:11] question. I don't think there is a right [35:12] answer. Uh in my case it is my career [35:15] for the last 15 years. So I started also [35:16] as a software developer. I was coding [35:18] full-time talking to customers doing [35:21] architecture but mainly coding. Uh I [35:23] loved it. I miss coding full-time but [35:26] also like when I put this on a scale [35:28] between like devil job and like develop [35:31] like like software engineers. the real [35:32] job is a little bit higher for me [35:34] because I'm also a big social extrovert [35:36] that love to help people being [35:38] successful that love to be with people [35:39] that love to talk to people that love to [35:41] talk also way too much. So like for me [35:44] it's it's good and this is what I'm [35:46] doing for the last couple of years. Uh [35:47] what you said though Nile it's true uh [35:50] it's harder to move from one technology [35:52] or one focus of technical area. Uh I've [35:54] been doing that for the last 15 years [35:57] mainly every jobs I was my product was [36:00] totally different. So you know like the [36:02] the last job I was in cloud native. This [36:04] one is like rich text editor which is [36:05] mostly JavaScript, react, angular focus. [36:08] Uh the one before when I was at Fitbit [36:10] uh that was like you know smart watches [36:12] and and you know targeted to health. Uh [36:14] for me I liked it because that's a great [36:16] challenge. Uh I never and maybe maybe it [36:21] happened but like I've never perceived [36:23] people that say like hey you're not uh [36:25] you're not credible because you're [36:26] switching uh like like different [36:29] technology or focus of technology or [36:30] type of product. Actually usually it's [36:33] more positive. I'm like oh [ __ ] you're [36:34] about to do that. With that said though, [36:37] I want to like I still consider myself [36:39] technical, but if I want like I don't [36:41] know why I always say if I want to be [36:42] honest because I'm always honest and I [36:44] feel like when I say if I want to be [36:45] honest, it means that I was not on us [36:47] before, but that's just an expression. [36:48] Anyway, uh I'm not as technical as I [36:51] used to. I'm still a developer. I can [36:53] still code. I still understand code. I [36:55] think I still have the credibility when [36:56] I go on stage. And if it's not the case, [36:57] please people on my room, let me know. [37:00] If you watch my video, you're like, [37:01] "That is [ __ ] Let me know. I want [37:02] to know." But I'm not as technical as I [37:04] was before. Why? because it's been 15 [37:06] years that I didn't put something [37:07] serious in production. Uh it's been 15 [37:10] years that like I didn't work full-time [37:11] in a product. And there's things that [37:13] you can learn when you're all day long [37:16] it's about building software versus I [37:19] learn technologies because I need to [37:20] know about it because I need to create a [37:22] tutorial because I need to record a [37:23] video because I need to give a talk at a [37:25] conference. So I still consider myself [37:27] technical. So far nobody told me I'm not [37:29] credible but maybe they just don't want [37:30] to say it to my face. Uh but again I'm [37:34] not as technical that I was when I was [37:37] like 10 years full-time software [37:38] developer. I'm still technical. I still [37:41] developer still call myself developer [37:42] but again the reality is that I'm not [37:44] building software in production for the [37:46] last couple of years. So yeah uh going [37:49] to your second kind of like followup [37:51] question which I also liked. Uh also uh [37:54] shouldn't Dell come from deep technical [37:56] expertise? If that's the expectation, [37:58] why not hire engineers or solution [38:00] engineers with do knowledge instead of [38:02] generalist devril professionals? Uh [38:05] please go ahead and if you have I'm [38:07] pretty sure you have something to say [38:08] about this. Um, I think it's hard to [38:11] argue that [38:14] if you were to just like it was Dev was [38:16] built from scratch from somewhere along [38:18] not too long ago really and that was [38:21] from the people with domain experience [38:23] that also had the ability to properly [38:27] communicate that. I think those two [38:29] factors should be true of most Devrell [38:31] folks, right? You should have the domain [38:32] experience and the ability to properly [38:36] um explain or um he even yeah advocate [38:43] for the thing you're talking about if [38:44] it's a fair thing to say. Um therefore I [38:47] think in most cases folks would if they [38:50] had a choice uh say we're looking for [38:53] Devril and I think this is I think I saw [38:55] this I see this around a lot. There's a [38:57] lot of roles out there that are Devril [39:00] skill set. Let's say they would have [39:02] called Devril maybe five or six years [39:04] ago that are not called Devril anymore [39:06] because they are let's say those domain [39:09] knowledge roles are the primary concern [39:12] like we need somebody maybe a consultant [39:14] I don't know I'm not sure what kind of [39:15] role like a solution arctic somebody who [39:17] understands the stuff really really well [39:18] and can explain it really well right but [39:21] they don't necessarily call that devril [39:23] for whatever reason [39:24] >> and maybe it's because it's not in [39:25] marketing so I would say to my my my [39:28] answer to that question would be [39:30] something Like yes, best case scenario, [39:33] you find someone with domain knowledge [39:36] who's able to either learn to or already [39:39] able to express that domain knowledge in [39:42] a way that is captivating and makes [39:44] sense and makes people engaged. I think [39:46] that's fair enough. Um I don't think [39:49] people always have that option. Uh I [39:51] think is the other uh the other part of [39:52] that. Um and I think that's maybe what [39:56] happens. And also and again this is from [39:59] my experience sometimes maybe this has [40:01] doesn't happen anymore but folks would [40:04] be put into devril from other [40:06] departments they would just be like sort [40:08] of plucked and like um we need somebody [40:10] to do some stuff so you're devro now. [40:12] >> Yeah. You did a lunch and learn one so [40:14] now you're dev. [40:15] >> Exactly. Yeah. And that could that could [40:18] be have been somebody with no domain [40:20] experience but a very good present [40:21] presentation style for example. And uh [40:24] so there's there's loads of ways in [40:26] which someone falls into this career. [40:28] And I think if you were to write down [40:30] what exactly are we trying to achieve, [40:32] you would say let's get a professional [40:34] with domain knowledge who can explain it [40:36] correctly and hire them or find that [40:38] person in the organization and convince [40:40] them to uh to do that role. Um I think [40:43] the alternative is just the next best [40:45] thing. I think it's if you can't do the [40:47] first one, but I could be wrong. [40:49] >> No, I mean uh I agree with everything we [40:51] you said. I'm still going to have [40:53] comments because, you know, it's it's [40:54] like I just have to it's physically [40:57] impossible for me to not say something [40:58] about stuff uh that I have opinions on. [41:01] Uh which is basically everything. But [41:03] which doesn't mean that I have the only [41:04] truth though. I always say that it [41:05] doesn't mean I have the truth. Um, I [41:07] agree like when when I hire developer [41:09] advocates on my team, the perfect [41:11] candidate is going to be someone who who [41:13] who has the skills of developer [41:15] advocates and have the dominant [41:16] expertise because you right away bring [41:19] the the the the what developer advocates [41:23] going to do the skills that like many [41:25] engineers don't have because there is a [41:26] lot of engineers that have like [41:28] tremendous expertise and they're really [41:30] like they know their [ __ ] like from in [41:32] and out but they're not able to [41:34] communicate probably to external people [41:36] uh they don't want to be on a stage, [41:38] they don't want to record videos, they [41:39] don't want to write an article, they [41:40] don't want to do those things because [41:41] for them it's boring and or they're [41:43] afraid of it and or they're just let's [41:44] be honest not good at it. Uh so trying [41:47] to find as you said trying to find like [41:48] the perfect fit where like hey you have [41:50] that experience or expertise or you're [41:52] able to do the de job plus you have the [41:54] domain expertise best candidate [41:57] >> most of the time it's not the case from [41:59] my point of view I I think I wrote an [42:01] article many years about that but like [42:02] from my point of view what every other [42:04] jobs consider as as soft skills you know [42:07] being able to communicate being able to [42:10] you know write stuff being able to to [42:12] connect and and with people uh those [42:14] things that are always great like Yeah, [42:16] I want an engineer, a software developer [42:18] that can build code, but I also want [42:19] that software developer like like to be [42:21] able to work with their colleagues and [42:23] communicate with them and help them [42:24] being successful. Usually, it seems that [42:26] like the soft skills or many other jobs [42:28] is like it's a bonus to have that. From [42:30] my point of view, developer relation, [42:32] it's the hard skills you need to have [42:34] that like it's the most important [42:36] because from my point of view and maybe [42:38] I'm going to sound pretentious here, the [42:39] easiest part of the job is to learn the [42:41] technology. Uh because it's also Yeah. [42:44] Yeah. from my point of view is that uh [42:46] because um you know uh anyway as a [42:49] software developer you cannot just say [42:51] like okay I learned things at school [42:53] then I'm done no if you've been in the [42:55] industry for a long time you always have [42:56] to learn so it it should be a little bit [42:59] part of like who you are as a [43:01] professional always trying to learn new [43:03] stuff always having to learn [43:05] >> uh some technology may not be like you [43:07] may start to learn them like oh I'm [43:09] bored of [ __ ] with that [43:10] >> I actually do agree with you on the [43:11] learning part it's actually not it's [43:13] actually because I learning is is not um [43:15] as relevant as caring, right? Because in [43:18] developer advocacy is a little unlike [43:20] being a developer on a product because a [43:22] developer on a product, you can probably [43:24] do a pretty good job and not [43:25] fundamentally care how it's used at the [43:27] end of the day, right? I don't think [43:28] that's that's such a hard thing to [43:29] imagine. You get a ticket, you uh [43:31] basically need to um build a solution [43:34] for that ticket. And in a lot of cases, [43:37] especially in larger companies, you [43:39] don't even have a concept of how that [43:40] fits into the whole product itself, [43:42] right? So as a developer, I think you [43:43] can learn the stuff on a technical level [43:45] and uh not care about the product [43:47] whatsoever or fully understand it. [43:49] >> Now Devil is different. I think it's [43:52] incredibly hard to do the job if you [43:54] don't at least care [43:57] >> or not necessarily care, but let's say [43:58] have a [44:01] a good understanding of um why the [44:04] product is something people should be [44:07] excited about in some way. I uh not that [44:09] it's impossible, but it would be much [44:11] harder. So I think [44:12] >> I would say it's impossible or or you [44:15] like I would go to like you were for the [44:18] lack of better word with my English, I [44:19] would say extreme with a lot of like [44:20] things you said and for once I was like [44:22] this one should be extreme like in my [44:24] from my point of view like it's it's [44:26] like don't get me wrong, you probably [44:28] can fake it for a couple of months at [44:30] some point you're not going to be [44:31] successful. Uh I'm not saying like you [44:34] need to be a workaholic. I'm not saying [44:35] that like you need to dream about your [44:37] product when you go to bed. No, no. I [44:39] like my product. It's nice. It's a nice [44:41] product, but it's also a job. Let's be [44:43] honest. But I need to be excited about [44:45] it. I need to understand the values [44:47] because if not, you are jumping in the [44:50] bullshitting part of like what you [44:51] should not do. And developers, [44:54] engineers, they're really they have like [44:56] [ __ ] detector. This is why like and [44:59] and I'm saying that with all respect for [45:01] traditional marketing ourselves, but [45:02] this is why most developer [45:04] allergic to uh you know traditional [45:06] marketing and or uh you know even new [45:09] ways of doing marketing or like the [45:11] sales team because they had bad [45:12] experience with people that wanted to [45:15] reach their goal no matter what it takes [45:17] no matter what they were saying which is [45:18] not true for most team it's not true for [45:20] my team if you're listening and you know [45:22] it's right and you know that I believe [45:23] that but uh I mean like this is the [45:26] experience they have with most people so [45:28] de I think the big difference is like [45:30] that we should not have to do that as we [45:34] discussed since the beginning. We should [45:35] not have to [ __ ] We shouldn't like [45:36] and to be able to do that, you need to [45:38] be excited. You need to believe it. Like [45:40] I had when I was looking for uh a job [45:43] last time, there's a company, amazing [45:44] company, amazing people. They reach out [45:46] to me and I'm like, "Hey, Fred, uh want [45:48] to hire you." The offer would like like [45:50] the the salary, everything was amazing. [45:51] I was being able to build my devil team. [45:54] I was not excited at all by the product. [45:57] It's a great product. It solve issues [46:00] that is good for people from my point of [46:02] view. I was not saying it's a bad [46:04] product. I was just like there's no way [46:06] for me to be excited about that. So I'm [46:08] not going to be able to do my job well [46:10] and I I didn't take I I did not even [46:13] enter the process to like take the job [46:15] because I was like no it doesn't make [46:17] sense for me. Again I'm also coming from [46:18] a really really privileged place where I [46:20] was able to do that and not just take [46:22] the first job that I have but uh from my [46:25] point of view like every job is a job [46:28] like like like I'm I'm not a workaholic. [46:30] I do I work because I need a salary. Uh [46:33] at the end of the day, this is the only [46:34] reason I would probably still do some of [46:36] the stuff that I do as devil on my free [46:39] time if I was full of money just because [46:41] I was doing that before it was a job [46:43] when I was a software developer. This is [46:44] how I started. I was speaking in events. [46:46] I was writing blog posts. I was writing [46:48] meetups just because I love to do that. [46:49] And at some point someone was like, [46:51] "Hey, we can pay you to do that." I'm [46:52] like, "Okay, sounds like a good deal." [46:54] Uh so I would still probably do those [46:55] things, but at the end of the day, it's [46:56] a job. uh but I think that like [47:00] specifically for developer relations [47:01] because we are with the people we talk [47:04] to the people to developers you like you [47:07] cannot fake that enthusias enthusiasm [47:10] about the product you cannot fake that [47:12] yeah like you really believe that it's [47:14] like solving issues [47:15] >> it's just that it's harder your job is [47:17] so much harder if you have to do all of [47:19] that understand the product [47:21] >> talk about the product and pretend to [47:23] like the product I don't know how anyone [47:24] could do that sounds like a lot of [47:26] that's a that's a workload code. Um, and [47:29] I think um, it's not I I don't I can't [47:31] imagine someone being able to accomplish [47:33] that in a way that is effective. Um, I [47:36] think there you can watch someone stand [47:38] on stage and go through the motions for [47:40] sure. They can technically do their job, [47:42] but not in an effective way. It's so [47:45] hard to do that. Um, I guess it depends [47:47] as well where your what your devril role [47:50] is because a lot of them don't [47:51] necessarily require you to actually be [47:53] in front of anybody. It's probably a lot [47:54] easier to lie and text. I'm not sure. Or [47:56] to or to fame enthusiasm. Just ask um uh [48:01] ask uh JBT or something too. Can you [48:04] make me sound enthusiastic about this [48:06] product? And then see what happens. [48:08] >> Yeah. It doesn't work when you're in [48:10] front of people, especially with my [48:11] face. My face cannot lie. So there's [48:14] like like I like it's impossible. So [48:16] yeah, you know, I understand. And just [48:17] to clarify and after that, we're going [48:19] to move to the Nemo part. We've been [48:21] talking forever and as much as I enjoyed [48:22] that uh like I don't think people will [48:25] still watch us after 3 hours of talking [48:28] which I'm pretty sure we could do. We're [48:29] in a good in a good uh direction that [48:32] yeah also you know about the about the [48:35] new learning stuff I say that's the [48:38] >> easiest part maybe the word is like the [48:40] simpler part more than easier because it [48:43] still take time it's still [48:45] >> the role of dev to learn the everyone [48:47] who joins a technical role needs to [48:49] learn the thing therefore it has the [48:52] most um the easiest path to follow [48:55] because almost every dev developer [48:59] let's say a technical um marketing [49:02] person, let's say a pre-sales person, [49:04] stuff, stuff like that. They've all done [49:05] that. So that's the easy part. I think [49:06] you can definitely learn the technical [49:08] aspects especially if you have a [49:09] technical background. [49:10] >> Yeah. And and and you know and for me it [49:12] plays in my favor. Like the last job I [49:14] had I was in a startup uh I was it was [49:16] in a cloud native uh space. So you know [49:18] a lot of Kubernetes stuff and I did it [49:21] just a little bit when I was a digital [49:22] ocean but nowhere near to be like I'm an [49:25] expert and like and it was a little bit [49:26] newer at the time. Uh so when I started [49:29] I was really honest with people. I'm [49:30] like hey um it's not the first time I [49:33] play with Kubernetes but let's call it [49:34] the first time and I was like I'm not an [49:36] expert yet but like I'm learning which [49:38] is what everybody who is starting to use [49:40] Kubernetes now is doing so we're going [49:42] to be in the same journey. So it kind of [49:44] like played in my favor. It took me way [49:46] longer than any other technology to call [49:48] myself at least greatly knowledgeable [49:51] about community not even an expert. It [49:52] took me like couple months a year uh [49:54] before my my my like co-founders at the [49:57] startup who were really expert were like [49:58] okay Fred you start to know your [ __ ] uh [50:01] but like it took me a lot of time but [50:03] during that time I also went to the same [50:05] journey and like people were starting to [50:06] use that technology and gave me other [50:09] positive aspect to be able to do my job [50:11] and and again I'm also always honest I [50:13] didn't go on the stage and like hey so [50:15] I've been doing Kubernetes for 10 years [50:17] no like I just started now uh so if I [50:19] say something stupid let me know and and [50:21] people laugh and we go [50:22] like and and it's just working. So [50:24] anyway, uh I'm liberating now. Uh great [50:26] great questions. I appreciate that. Um [50:30] >> yeah, thanks for uh thanks for thanks [50:32] for discussing this uh controversial [50:34] topic. Uh yeah, the last thing I'm going [50:36] to say about that and I know it's been [50:37] 10 times that I say that. Um I know that [50:39] like uh sorry, in the past um I don't [50:42] know if it's true anymore. I think I [50:44] think the the industry kind of like get [50:45] back to it, but like at some point if [50:47] you wanted to be a developer advocate, [50:49] you needed to be a developer first and [50:51] engineer first. Like there was no way [50:52] for you to move to that role without it. [50:54] You need because this is the the the [50:56] beginning of developer relation. It was [50:58] like developers, engineers that were [50:59] like, "Hey, you know, I can talk to [51:01] people and they were doing it." And at [51:03] some point we started to see a role [51:05] where like some people had no experience [51:06] as software developer and they were like [51:08] hired because they know how to [51:10] communicate and [51:12] like feel free people to disagree with [51:14] me or or not. I I think we have the same [51:16] opinion here, but um I don't think it [51:18] end up with like really great developer [51:21] people, developer advocate people [51:23] because uh and I say that with all of [51:26] developers are really judgy. Uh so, you [51:29] know, I can always being bra even if [51:30] it's just 15 even if it's 15 years ago [51:33] now, I can still say like, hey, I've [51:34] been a full-time software developer and [51:36] engineer for 10 years. I know how it is [51:38] to work with customer. I know how what [51:40] it is to put things in production. I may [51:42] not know how it is to build with AI [51:43] right now and have that pressure, but [51:45] like I know a lot of like or I know it a [51:46] little bit because I do it, but like not [51:48] in in like in the terms like being a [51:49] full-time software developer and uh like [51:52] I get that credibility because I've I've [51:54] been through the nice thing of being a [51:55] software developer, but also the shitty [51:57] things of it. When once once you don't [51:59] have it, uh I think it's a little bit [52:00] harder. But again, as you said, it [52:02] depends on the role. There are roles [52:03] that are a little less technical, still [52:04] call themselves developer advocates [52:06] because they talk to developers. I'm [52:08] still maybe a little like I still have [52:09] the old tinking that's like I prefer to [52:12] have someone that have a little bit of [52:13] experience software development [52:14] experience uh because they're going to [52:16] talk to developers. But anyway, [52:18] >> I would uh completely agree with that. [52:20] Um I I don't know how someone could do [52:22] the job and not be able to have at least [52:25] been a developer or be in the process of [52:28] becoming a software developer. Either I [52:29] think works. If the dev roll department [52:31] is embedded with the product team, I [52:32] think you have a chance of of of joining [52:36] as a non-developer and then growing into [52:38] the role because you're actively there [52:40] and learning what developers are going [52:42] through. But if you don't do either of [52:43] those things, I don't I think you just [52:45] call yourself something else. You're not [52:47] what that is. You're um which is fine. [52:49] Just that's yeah, just to be something [52:51] else so we should know. Yeah, [52:53] >> I agree with that. [52:54] >> Yeah. Who wants to watch me do a [52:56] 20-minute demo in seven minutes? You can [52:59] do it as long as you want. Uh so yeah, [53:01] it's uh uh God, I have a I know it was [53:04] around Kimunda. Uh so you know what? I'm [53:07] a really bad host. I'm just going to let [53:08] you introduce your company and and the [53:11] demo are going to do and uh the screen [53:14] is yours. [53:15] >> Yeah, sure. Thanks so much. I'll be [53:16] relatively quick. The thing I want to [53:18] show is just kind of a fun thing that I [53:19] built a little while ago that showcases [53:22] what command So command is a an [53:24] orchestration um software where you [53:27] basically design um uh what the state [53:31] shows right which is what the state [53:33] progression looks like and then you uh [53:36] that gets executed in a um a visual [53:38] medium. Uh it's really fun to build. Um [53:41] the fundamentals of it are that it's [53:43] designed in order to be a centralized [53:45] point in a distributed um system and uh [53:48] the idea is that command sits on a layer [53:51] uh which then orchestrates all the [53:53] systems externally. So nothing is [53:54] actually added to command layer. It is [53:57] purely this the owner of state and the [53:59] owner of state progression. That's the [54:00] short part of that. And um this is a [54:03] model I built because it's it's the new [54:05] thing we're doing is that we are as part [54:08] of a process. In the past processes were [54:11] almost always predictable, repeatable, [54:13] and deterministic. And um because of AI, [54:17] uh that's all ruined because now things [54:19] are supposed to be dynamic. Things are [54:21] supposed to be a lot less rigid. Um but [54:25] we can still build that really easily. [54:27] So actually what you're seeing here is a [54:29] process with two agents that are [54:32] specifically in charge of not really [54:35] executing any of the tasks but simply [54:37] choosing what should be executed. And [54:40] there's some really really great side [54:42] effects of that architecture. And I I'll [54:45] showcase that with this little um front [54:47] end that I have. This is like a local [54:48] thing that I'm running. The actual [54:51] commund instance is running in the [54:52] cloud. So just as a FYI, I'll talk a bit [54:55] more about that later on. And this is an [54:57] insurance claim process. We built this [54:59] really um not too long ago and I really [55:01] like the way it it works and the [55:03] technology it implements. So I want to [55:05] talk through what makes it unique as I [55:06] build it and why I quite like building [55:08] it. Um so my name as we all know is this [55:13] um and I would like some uh work injury [55:16] insurance. By far the biggest problem [55:19] for the company we were working for was [55:21] this type of insurance because I've had [55:23] my bike stolen multiple times and uh the [55:26] insurance policy is they give you money [55:27] and you're quiet, right? That's how it [55:29] works. Work injury insurance or like I [55:31] think it's called workers comp in the in [55:33] North America is where I'm not sure what [55:35] the French is. Fred, maybe you can tell [55:37] me if there's a French equivalent of [55:38] workers comp. [55:40] Uh [55:40] >> actually, I do not know. [55:42] >> That's okay. What's the word? [55:48] >> So, the idea is, of course, that I'm [55:50] hurt, I can't work, and the insurance [55:52] companies to pay me until I get better. [55:54] Okay. So, I'm going to submit this. Um, [55:58] the process then is going to kick off. [56:01] And it's got a few different agents. And [56:02] the first agent is the is relatively [56:04] standard. It's doing what you expect [56:06] agents to do. Now what we're looking at [56:08] is as things light up the agent is [56:12] deciding what to execute. So you can see [56:14] that it's already executed this task to [56:17] get procedures and requirements. It's [56:20] also executed the task to get my data, [56:22] my customer data. It's queried that and [56:24] it's got my insurance policy. Now these [56:26] are already things that basically any AI [56:29] agent can do. The next thing it's done [56:31] is actually much harder and that is that [56:34] it's um funny enough sent me an email. [56:37] Saying an email isn't hard, but waiting [56:39] for a reply is really hard. So, if I [56:41] take a look at um let's say I know um [56:46] trying to find my yes, there it is. It [56:48] did actually send me an email. It's [56:49] good. So, the email looks like this. And [56:51] it said, "Dear Nile Dehan, that's my [56:53] name. You've submitted a thing. Uh we [56:55] need to assess it. I need some stuff [56:57] from you. Uh can you let me know?" So, [57:00] luckily I'm the kind of person who has a [57:02] load of test data available. So, so a [57:05] bunch of PDFs of my ID, details of my [57:08] injury are all there. It's all very good [57:11] and all [57:14] all in the docs. Okay. Now, not only is [57:19] at this point the business logic is that [57:22] it's waiting for an email to come in, [57:24] which I hope it does, it's also waiting [57:27] in case no response happens. And how it [57:29] does that is by utilizing um a [57:32] subprocess. So this agent has triggered [57:37] a deterministic flow that at the moment [57:41] has sent an email and then began [57:42] waiting. This is where the engine's in [57:44] charge of because all the am did was [57:46] actually select the task to execute and [57:49] then what the engine does is actually [57:50] perform those tasks. The first three [57:53] were tasks that simply queried external [57:55] services. But this one's way more [57:57] complicated. This one actually does a [57:58] bunch of stuff. And in particular, this [58:00] one here waits for an email to be sent. [58:02] Now, this thing here pulls the inbox [58:05] every like 30 seconds or something. So, [58:06] it'll be a little while before it [58:08] actually finds the email. But in the [58:10] meantime, I'm going to go back up here [58:12] and I'm just going to take a look at [58:13] what other stuff it can do. So, this is [58:15] running on that subprocess. [58:17] And the agent itself is only in charge [58:20] of stuff in this scope because the [58:22] process is quite large. And so certain [58:25] agents have their tasks and their [58:26] abilities and it's totally visualized of [58:28] what actually gets executed. But also it [58:31] has humans involved. [58:34] So we have here two different um people. [58:37] >> One that gets the final report and one [58:40] that gets like if they can't figure [58:43] something out for some reason gets [58:44] classifications. Now this thing is [58:46] already finished. So what I expect I [58:48] hope is I get a final report and then [58:51] I'll be able to see the data that I [58:54] submitted combined with the information [58:56] it's got already in a predefined report [58:59] that that this particular person needs. [59:02] That's why it's taking a little long to [59:03] trigger that task because the the LLM [59:06] itself is generating that data. And now [59:08] we see it's triggered this user task. So [59:11] now a user is involved. So they can then [59:13] take a look at what the agent has said [59:16] to us. And this is all the fun stuff. So [59:20] we have our uh report generated on this [59:23] day. No, it's about right. And uh yeah, [59:26] information about me, including my [59:28] definitely real phone number and [59:30] apparently I live in Maple Grove now. [59:33] >> Yeah, I was going to say at least it's [59:34] not your real address. [59:35] >> Yeah, I hope not. I I think it's got the [59:37] city and the country wrong. So that's a [59:39] good start. Um, and then other bits and [59:41] pieces about the insurance policy that [59:42] it knows about and all sort of fun [59:44] stuff. And then it goes down and here [59:46] are all the checks it needs to make that [59:48] it knows it needs to make. And then it's [59:50] able to say, "Okay, that's good. I'm [59:51] going to approve that. That's great." [59:53] Now, um, I can also not approve it. The [59:57] thing about that makes this unique is [60:00] kind of not that interesting right now. [60:02] The only thing I showed you that's [60:03] relatively unique is the idea here of [60:05] being able to call a subprocess with the [60:07] context of an agent. That's kind of [60:09] unique. That's kind of fun. Uh, but this [60:11] next agent is doing stuff that I really [60:13] enjoyed building because this was a real [60:15] problem they had to solve. This agent [60:17] here, um, again, unlike most other [60:19] insurance types, this is a very [60:21] longunning agent. It runs for about [60:23] three years, well, maximum three years [60:26] until the policy runs out. And you would [60:30] first think, well, that's too long for [60:31] an agent that would bankrupt you. But [60:33] the fact is that most of the time, the [60:35] agent is actually not doing much [60:37] waiting. And I'll explain what I mean by [60:39] that. First of all, it's asked me for [60:40] some information. So, let's head back to [60:42] my lovely email address. And let's see. [60:44] Yes, I've got Oh, it's way more formal [60:47] now. I'm no longer Nile. Dear Mr. Dean, [60:50] so this agent is far more formal. [60:53] Definitely wants to approach me in a [60:54] more direct way. [60:55] >> You You look like you're legit uh you [60:58] have legit claims. So, now we're going [60:59] to be polite with you. [61:00] >> Exactly. Right. Yeah. This person looked [61:02] at me and thought, "No, I'm not sure [61:03] about this guy. Let's like make sure he [61:04] gets through the uh the the process [61:06] first and then we'll call him by Mr. DM. [61:09] So, it's asked me for how I'm getting on [61:11] this sort of stuff. Now, this is [61:12] important because the course of the Now, [61:16] what I'll do is I'll quickly reply and [61:18] luckily [61:20] um I happen to keep a uh uh at all times [61:26] um free text of exactly how I'm getting [61:28] on at any time. Just happen to keep [61:30] that. So, my typical day is blah blah [61:32] blah. there. I've put kind of all the [61:34] stuff they're asking for which they've [61:36] detailed very nicely. I have just dumped [61:38] into a big paragraph and I'm sending [61:40] that. Okay. [61:42] >> So, we don't find that unusual. This is [61:44] a normal thing to happen because of [61:46] course this is what the the the client [61:48] told us that that the user mainly their [61:51] their main job this is this person up [61:53] here. Their main job is to to find out [61:57] how the patient is doing or how the the [61:59] the client is doing right now as a [62:02] baseline to determine how they get [62:04] better. And that means that they need to [62:06] try and get this big block of text thing [62:08] into a more usable format to be able to [62:10] have a a consequential [62:14] um action for the next response. And we [62:17] can see that if we take a look at this [62:18] thing here, it should trigger, I hope, [62:20] but it's an LLM, so we don't really [62:21] know. Yeah. So, this has come back [62:24] And it can ask for clarification maybe. [62:26] Okay, it is going to show the report. [62:28] And we can see that it turned that text [62:30] into something more usable, right? It's [62:33] got it's parsed it together. This is not [62:35] unusual. This is just a good thing an [62:36] LLM does. And some positive and [62:40] negatives. Great stuff. And I'm going to [62:42] say that's great. And now we're going to [62:44] do something [62:46] that most LLMs will have an incredibly [62:48] hard time doing. Um, let's [62:53] uh wait for 3 months and ask him again. [62:58] Okay, [63:00] so I've just told it how long to wait. [63:02] That could be any amount of time [63:03] depending on the case. It could be okay, [63:06] let's see in a week after their hospital [63:07] visit. But the thing we were told here [63:09] that the LLM needs to dynamically wait [63:12] for an amount of time. And the way we do [63:14] that is we use a BPN construction here [63:17] that allows it to put in a wait time and [63:20] then the agent so the engine then waits [63:24] for that amount of time. So right now we [63:26] are waiting for three months. Okay. [63:30] And um that's pretty good. That means [63:32] that in 3 months the agent will wake up. [63:35] It will then communicate to the client [63:38] and say hey last time you said this and [63:41] that. how are you feeling now? And then [63:43] be able to report back on the progress [63:46] of that person. It's pretty good, right? [63:49] But [63:49] >> so we're gonna you're gonna come back on [63:51] the show in three months and we're going [63:53] to see if [63:55] >> Well, don't worry. Nile is not [63:56] trustworthy. So, we don't need to go [63:57] back in three months because in this [63:59] case, Nile um is going to do something [64:02] that's going to trigger this second [64:03] thing here. Because one of the [64:05] requirements we had, which I find really [64:07] interesting, is while the agent is [64:09] waiting to get back to someone, there is [64:11] another department in this company, the [64:14] fraud squad, and [64:17] >> they are checking up on folks. And as I [64:20] said, Nile is not trustworthy. So, uh, [64:24] we have a specific claim ID, which is [64:26] here, which is a which is a unique [64:29] identifier. And what I'm going to do is [64:31] I'm going to say he wasn't giving a [64:33] guest lecture. Nile was seen [64:37] on Fred's [64:40] Devil show. [64:45] Okay, this is not good for Nile. This [64:47] shows that Nile is actually up and [64:48] about. So I'm going to send this message [64:51] and you can imagine like I'm sending [64:53] this from my local system. So you can [64:55] imagine that the fraud squad have their [64:57] own system completely. [64:58] >> And this is just a button they click on [65:00] their system to say give the LLM [65:03] additional context, [65:05] >> right? You just send it as long as you [65:06] have the application ID so you can find [65:09] the right waiting instance. And what [65:11] happens is that wakes the agent up and [65:14] then the agent is like, "Oh, uh, I've [65:17] woken up from my slumber and I've got [65:19] some new context to deal with." So then [65:21] the agent needs to say, "Okay, what I do [65:22] with that context?" And, um, they [65:25] already because it's woken up now, it's [65:27] given the the the the what's happened so [65:30] far. So, it already knows it's ask Nile [65:32] about stuff. And let's see if I get the [65:33] Mr. Dehan response this time around or [65:36] if I get my all three of my names which [65:39] is how angry people usually refer to but [65:42] no this is dear Mr. I hope this finds [65:44] you well. Blah blah blah. Hey, uh, [65:47] recently appeared on Fred's devil show [65:48] before scheduling quarterly. I got some [65:50] clarification. Oh, no. The nature of my [65:53] appearance. Okay, but don't worry. [65:56] That was just my twin brother. [66:01] He's like me but smaller. [66:06] Okay. Anyway, so then we can continue [66:08] the fun. So that agent then goes ahead [66:10] and tries to solve that problem. The [66:12] nice thing is that what we have here is [66:15] a lot of agent technology solving a [66:18] relatively hard problem that first of [66:21] all it it involves humans in a way that [66:23] makes their job much easier which is [66:24] really really good. But secondly it's [66:26] it's totally visual and auditable. This [66:29] is something that needs to be auditable [66:31] and you can see exactly what runs. We [66:33] have control of the state. you have all [66:34] the variables and makes it very very [66:36] easy to implement AI in places where [66:38] they're very very heavily regulated and [66:40] um [66:41] >> yeah the fact that you put humans in the [66:43] loop too which is something that is [66:45] missing in many system that should [66:46] probably be there especially in [66:47] something as regulated as that uh yeah [66:51] >> yeah absolutely in fact in this first [66:53] section here one thing you'll notice is [66:55] the agent actually can't complete it [66:57] unless it talks to a user and a user [67:00] decides to reject or continue so they [67:02] the agent has actually no decision [67:05] making on whether someone should be [67:07] accepted or not. The agent actually [67:09] needs a human to do that. [67:11] >> Love that. [67:13] >> Yeah. And I think uh yeah, that's not [67:14] bad. I did my I think I I managed to uh [67:18] to complete that in in the in the a [67:20] loted time there, Fred. So [67:21] >> Oh, you had a as as I said, you had as [67:23] little as much time as you wanted. Uh I [67:26] know we went over the usual like one [67:28] hour that a book in people's calendar [67:29] and I don't want to take too much of [67:31] like your evening time but do you have [67:33] time just for one last comment that may [67:35] uh a user had that may require us to [67:38] comments on it. Do you have still a [67:40] couple minutes? Okay, let's do that. Uh [67:42] Daniel uh you also had great input. Uh [67:45] Daniel said uh every company on boards [67:47] new folks and teaches uh their product [67:49] but a general job those teams are so [67:52] lean they don't have the time to teach [67:54] you those skills. So [67:56] >> that's the thing. Yeah. In teams that [67:59] I've been on, we've been definitely the [68:02] the in in like the most functioning [68:04] deval teams that I've been part of. Um [68:07] they this they are very good at that. [68:09] They have the people and able to bring [68:11] people along best they can. Right. But [68:14] this comment is absolutely right and it [68:17] also showcases [68:20] a big risk that Devril has in uh a [68:24] marketing department in particular in my [68:25] opinion which is the value of the team [68:28] as it is for doing things like this like [68:31] helping on board new members of the team [68:33] is never considered when for instance [68:36] cost cutting needs to be taken into [68:37] account that's when they'd look at [68:39] Devril and think well why is it so big [68:41] it's because everyone is doing a lot of [68:43] different stuff here. There isn't there [68:46] aren't individual roles here that are [68:49] that are that are cut out. Even a a [68:52] goodsized Devril team will have people [68:55] that are utilizing loads of different [68:57] aspects of what they're good at. And I [68:59] in an ideal scenario that involves [69:02] enabling other members of your team [69:04] because as Danielle quite rightly says, [69:06] you don't usually have a lot of support [69:08] from other parts of the department. If [69:10] you're in the marketing department, that [69:12] usually means you don't have access to a [69:13] lot of technical people to help you [69:15] understand the product and you rely then [69:16] on the Devril um department to like help [69:19] enable that and that can work. That can [69:21] be really really good. Um but I think [69:24] that what ends up happening is people [69:26] underestimate the um value of um uh [69:31] those bigger Devril teams because they [69:33] don't fully see the definitely in [69:35] marketing departments. I think if you go [69:37] into product again, you have that [69:38] feedback loop thing that I can I've seen [69:41] technical managers value heavily. So you [69:44] have that additional thing, but that [69:46] doesn't exist in the marketing [69:47] department. You're not talking to the [69:48] devs every day, right? You're not giving [69:50] that feedback. You're giving the [69:51] feedback to marketing and they're like, [69:53] "Well, we can get that feedback [69:54] ourselves. Maybe some other way if we [69:55] get rid of Devril." So yeah, I think [69:57] this is a great um comment and a really [69:59] really good um uh um uh assessment. [70:03] >> Yeah. Yeah. No, no, I agree with that [70:05] too. Uh the last thing I would add is [70:07] that from my point of view, the the the [70:10] little time I had people that could help [70:12] me ramp up to the product and or the [70:15] company and or uh technology. The [70:18] company is good because like you know I [70:20] want people to tell me what's the good [70:21] how things work uh what's the processes [70:23] the red tape and those kind of things [70:25] that helps me to get started faster. [70:27] usually for the product or the [70:29] technology. Uh I like to not having help [70:32] and it's not because I'm so good. Uh [70:34] it's just because I want to be like any [70:36] new users. So what I usually do is like [70:38] how like any new users I'm going to use [70:40] the docs and I'm going to use the [70:42] tutorials out there. I'm going to use [70:43] the video out there. So I can know from [70:46] like the first two three weeks maybe [70:48] like hey what I think is missing. If I [70:50] have suggestions about the docs as a new [70:52] user, I can go to the joy or the pain of [70:55] new users and uh if I want to get it [70:58] takes me more time to like you know get [71:00] into it versus like oh uh like someone [71:03] else another devil on the team who knows [71:05] the technology real well or someone an [71:07] engineer is going to spend a couple of [71:08] hours with me to teach me to show me how [71:10] it's working to help me. Uh obviously if [71:12] I get stuck for for an amount of time I [71:14] just ask help. I'm not stupid either. Uh [71:17] I know I look like but I'm not. uh but [71:19] at the end of the day uh by by being [71:21] that kind of like you know uh I I I [71:23] believe that Devril should be customer [71:25] zero like there's a new release we [71:26] should be the first one to try it test [71:28] it to learn about it to know about it uh [71:30] because we need to usually create [71:31] content about it but also like you know [71:32] we talk to people but by doing that in a [71:35] new job it really gave me the lay of the [71:37] land about like what is missing for like [71:39] like a user experience a developer [71:41] experience when to join the company so [71:42] again it takes me more time to go to [71:44] that direction but I like to do that [71:46] >> which not everybody who hire me likes [71:48] need to do that. But that's my process [71:50] that uh after many years I helped me [71:53] really be successful in what I do. But [71:55] um yep, on that note, I think it brings [71:59] us to uh the end of the show. So uh any [72:01] last word, last sentence, something uh [72:04] intelligent or not to say [72:06] >> I can go with not intelligent. That's my [72:08] default. And thanks thanks a million [72:10] actually. No, there was a great [72:11] discussion. I thoroughly enjoyed it. Um [72:13] it was nice to get your perspective on [72:15] topics that um yeah that I I think about [72:18] a lot but I'm always interested in [72:21] bouncing these off folks because yeah [72:23] it's uh it's it's lonely where I am in [72:25] terms of the Devril stuff. I don't have [72:27] a lot of Devrell folk around me. So um [72:29] it's good to uh to get the opportunity [72:31] to bounce those off. So thanks for uh [72:33] for taking on these discussions. They [72:34] are really good. [72:35] >> My pleasure. Thanks to you for being on [72:37] the show. I know uh you're part of like [72:39] the the couple quote unquote first [72:41] people that reach out or I reach out to [72:43] you to be a guest and it took forever [72:45] and everything was delayed and like it [72:47] was complicated. Finally, we're about to [72:48] go online. I think you're one of the [72:50] last person now that the other people [72:52] are aware that like it may takes time [72:53] and like I'm not doing that every other [72:55] weeks now and I'm not scheduling also a [72:57] year in advance which is is what I was [72:59] doing when I was not traveling because [73:01] like it's fine like there's very little [73:02] thing that's going to disrupt that. Now [73:04] it's not a reality. So anyway, thanks [73:05] again for being on the show. It was a [73:07] real pleasure. Uh true uh to have you on [73:10] the show. It's also great u that we have [73:12] uh you know it's great that we have some [73:14] like common opinion but also like when [73:16] we like there's some disagreement but [73:18] we're like fine with it because that's [73:20] life. We don't have to agree about [73:21] everything and that makes a better show [73:22] when like the answer is not always like [73:24] hey I agree with everything you say. Uh [73:26] so thanks for doing that. I really [73:27] appreciate that uh when it's done in a [73:29] respectful way and was done. So uh [73:32] thanks to everybody thanks to everybody [73:34] who join us live. Uh thanks to everybody [73:36] who joined. Uh I was going to watch the [73:38] I don't know how to talk anymore. Uh how [73:40] did people who will watch the recording? [73:43] Thanks to you and uh I should probably [73:46] write those things down because every [73:47] end of the show I do not know when is my [73:50] next episode. It used to be every two [73:51] weeks and now the next one's going to be [73:53] in one, two, oh actually in two weeks. [73:57] Uh so yeah, my next show is going to be [73:59] in two weeks. Uh I have another amazing [74:01] guest. I'm going to announce that uh [74:02] probably beginning of next week. uh you [74:05] should join us. It's going to be [74:06] amazing. And on that note, I wish you a [74:08] great evening, morning, afternoon, night [74:12] if you're watching us at night. And see [74:14] you in two weeks for the next episode. [74:16] Bye everyone. [74:17] >> Cheerio. Bye.  ## 📺 Video ![](https://www.youtube.com/watch?v=PzHm7Q1X9as) ## Highlights - When you put into uh that that department identically into a marketing department for example and again I can only speak to my experience you then need to re-evaluate what you are bringing to that department because now you are being paid by the budget associated with promoting the company positively to the people who will pay for it - Note: 📚 Organizational placement fundamentally shapes DevRel authenticity and effectiveness · - Core tension between product-led vs marketing-led DevRel around 15:30 - Explains why departmental reporting structure affects role execution and developer trust - Critical for understanding modern DevRel organizational challenges · #atom/literature/h1 - I think it's incredibly hard to do the job if you don't at least care or not necessarily care, but let's say have a good understanding of um why the product is something people should be excited about in some way - Note: 📚 Product enthusiasm is necessary, not optional, for DevRel success · - Around 42:30, discussing requirements for sustainable DevRel careers - Distinguishes between technical competency and genuine product belief - Addresses why "career DevRel" professionals struggle without domain passion · #atom/literature/h2 - The early uh sort of devril folks if you were a developer a software developer and you could talk and explain the technical aspects of what you were building really well you ended up sort of being the first cohorts into what became Devril - Note: 📚 Early DevRel model prioritized peer communication over marketing outcomes · - Around 8:45, explaining historical origins of developer relations - Contrasts authentic peer-to-peer model with modern marketing-driven approaches - Provides foundation for understanding current industry tensions · #atom/literature/h3 - Authentic developer advocacy requires genuine product enthusiasm over generic skills - Note: Holds when: Target audience consists of experienced developers with strong "BS detection · - [[Developer trust metrics]] — because evidence-for measuring authenticity · #atom/zettel/z1 - Research industry data on DevRel organizational placement trends — validate anecdotal observations - Note: ✏️ Fleeting capture #atom/fleeting/f1 - Investigate frameworks for measuring authentic developer engagement vs vanity metrics - Note: ✏️ Fleeting capture #atom/fleeting/f2 --- # 📝 Full Notes (Deep-Read Analysis) # 🏷️ Title: devrelshow episode 49 - Niall Deehan from Camunda ## 🧭 Table of Contents - [📝 Summary](#-summary) - [📖 Main Content](#-main-content) - [🗒️ Notes](#️-notes) - [📚 References](#-references) - [🗣️ Paraphrase](#️-paraphrase) - [📰 Newsletter](#-newsletter) - [✅ Action Items](#-action-items) - [🧪 Hypotheses](#-hypotheses) - [📊 Methodology](#-methodology) - [❓ Questions](#-questions) - [🔮 Future Research](#-future-research) - [💡 Implications](#-implications) - [🧠 Learning Styles Assessment](#-learning-styles-assessment) - [📊 Accessibility Assessment](#-accessibility-assessment) - [🌍 DEIB Assessment](#-deib-assessment) - [✅ Logical Validity](#-logical-validity) - [🛡️ DARVO Analysis](#-darvo-analysis) - [🎯 Conclusion](#-conclusion) ## 📝 Summary - **What happened**: DevRel Show episode featuring Niall Deehan from Camunda discussing the evolution of developer relations over 11+ years. - **Why it matters**: Reveals fundamental tensions in DevRel between authentic developer-to-developer communication and marketing-driven outcomes. - **Key stakeholders**: DevRel professionals, marketing teams, product teams, engineering leadership, developers as end users. - **Risks and tradeoffs**: Moving DevRel to marketing departments risks compromising authenticity; staying in product may limit resources and reach. - **Bottom line**: DevRel sustainability requires genuine product enthusiasm, technical credibility, and organizational alignment with honest developer communication. ## 📖 Main Content The conversation explores how developer relations has evolved from its origins as authentic peer-to-peer technical communication to a more marketing-oriented discipline. Both speakers represent the "old guard" of DevRel—technical practitioners who fell into advocacy roles organically rather than pursuing DevRel as a primary career path. ### Core Evolution of DevRel Originally, DevRel emerged from a simple need: companies wanted technical representation at developer events that could bypass traditional marketing constraints. Early DevRel professionals were developers who could speak honestly about their products' strengths and limitations to peer audiences. This model worked because: - **Product ownership**: DevRel reported to product teams, not marketing - **Technical authenticity**: Practitioners were active developers - **Honest communication**: No requirement to tie activities to immediate revenue - **Peer credibility**: Speaking developer-to-developer, not company-to-customer ### Current Challenges Both speakers express concern about modern DevRel's drift toward traditional marketing: 1. **Organizational placement**: Moving DevRel to marketing departments creates pressure for measurable financial outcomes 2. **Career DevRel professionals**: People who specialize in DevRel skills but lack deep technical domain expertise 3. **Title proliferation**: Role ambiguity through confusing job titles and scope creep 4. **Authenticity erosion**: Pressure to present products in "best light" rather than honest assessment ### Technical Credibility Debate The discussion addresses whether DevRel professionals can maintain credibility while switching between different technical domains (frontend to databases, for example). Fred argues that learning new technologies is manageable for experienced practitioners, while Niall emphasizes the importance of genuine domain expertise and product enthusiasm. ## 🗒️ Notes #### ⏱️ [00:00:00](https://www.youtube.com/watch?v=PzHm7Q1X9as?t=0) Opening and introductions - Fred introduces episode 49, approaching milestone episode 50 - Two-year guest waitlist demonstrates healthy DevRel community interest - Weather affects mood and energy levels for content creation #### ⏱️ [00:04:12](https://www.youtube.com/watch?v=PzHm7Q1X9as?t=252) Niall's background and philosophy - 11 years at Camunda, 8 years in DevRel specifically - Started as software developer, transitioned to advocacy naturally - "Practically perfect in every way" - positive mindset approach - Originally DevRel meant honest developer-to-developer communication #### ⏱️ [00:08:45](https://www.youtube.com/watch?v=PzHm7Q1X9as?t=525) DevRel evolution concerns - Original model: developers sent by product teams to speak honestly to peers - Modern reality: marketing-driven roles with revenue attribution requirements - Avoids saying "DevRel" to other developers due to negative associations - Common reaction: "Oh, so you're marketing basically" #### ⏱️ [00:15:30](https://www.youtube.com/watch?v=PzHm7Q1X9as?t=930) Organizational department impacts - Product vs marketing placement significantly affects role perception and execution - Product placement: focus on user feedback and honest technical communication - Marketing placement: pressure for growth metrics and promotional messaging - Fred's experience maintaining boundaries within marketing organizations #### ⏱️ [00:22:18](https://www.youtube.com/watch?v=PzHm7Q1X9as?t=1338) Job titles and credibility - Niall dislikes his "Process Alchemist and Technical Evangelist" title - Title was imposed, not chosen, creating explanation burden - Industry shift from "evangelist" to "advocate" due to religious connotations - Title consistency matters for career progression and role clarity #### ⏱️ [00:28:42](https://www.youtube.com/watch?v=PzHm7Q1X9as?t=1722) Career sustainability discussion - Question: Is DevRel a sustainable career path? - Challenge: Maintaining technical credibility across different domains - Niall would likely move to similar technology company rather than different DevRel role - Fred: 15 years moving between different technical domains successfully #### ⏱️ [00:35:15](https://www.youtube.com/watch?v=PzHm7Q1X9as?t=2115) Technical expertise requirements - Debate: Should DevRel require deep technical expertise vs communication skills? - Ideal candidate: domain knowledge + communication abilities - Reality: Often choosing between technical depth and advocacy skills - Learning technology is easier than developing communication/relationship skills #### ⏱️ [00:42:30](https://www.youtube.com/watch?v=PzHm7Q1X9as?t=2550) Product enthusiasm necessity - Impossible to succeed in DevRel without genuine product excitement - Developers have strong "bullshit detectors" for inauthentic advocacy - Fred turned down lucrative offer due to lack of product enthusiasm - Caring about product impact more important than just technical competency ## 📚 References - [DevRel Show](https://www.youtube.com/c/DevRelShow) - Fred's ongoing interview series - [Camunda](https://camunda.com/) - Niall's employer, workflow automation platform - [TinyMCE](https://www.tiny.cloud/) - Fred's employer, rich text editor platform ## 🗣️ Paraphrase This DevRel Show episode captures a candid conversation about how developer relations has evolved over the past decade. Fred and Niall, both veterans with 11+ years in the field, discuss their concerns about DevRel's shift from authentic peer-to-peer technical communication toward marketing-driven activities. The core tension revolves around organizational placement and role expectations. When DevRel teams report to product organizations, they can focus on honest feedback loops and genuine technical discussions. When moved to marketing departments, they face pressure to demonstrate immediate financial impact and present products in the most favorable light possible. Both speakers emphasize that successful DevRel requires genuine enthusiasm for the product being advocated. They argue that developers can quickly detect inauthentic promotion, making it nearly impossible to succeed without believing in what you're representing. This creates interesting challenges for "career DevRel" professionals who might excel at advocacy skills but lack deep technical domain expertise. ## 📰 Newsletter **DevRel Evolution: The Authenticity Challenge** This week's DevRel Show featured a fascinating discussion between two industry veterans about how our field has evolved—and where it might be losing its way. Niall Deehan from Camunda and host Fred shared concerns about DevRel's drift from genuine developer-to-developer communication toward traditional marketing approaches. Key takeaway: The most successful DevRel professionals maintain genuine product enthusiasm and resist pressure to compromise on honest technical communication, regardless of which department they report to. If you're in DevRel, consider how organizational placement affects your ability to serve developers authentically. Worth watching for anyone navigating the balance between business objectives and developer trust. The discussion of career sustainability and technical credibility across domains offers valuable insights for planning your DevRel journey. ## ✅ Action Items #### DevRel - **Organizational placement audit**: Map how department placement affects DevRel authenticity and developer trust across portfolio companies - **Career pathway documentation**: Create guidelines for maintaining technical credibility when transitioning between domains - **Authenticity metrics**: Develop frameworks for measuring genuine developer engagement vs vanity metrics - **Cross-department relationships**: Build processes for DevRel success regardless of organizational placement #### Community - **Veteran practitioner interviews**: Capture institutional knowledge from early DevRel practitioners before it's lost - **Role definition standardization**: Work toward clearer industry understanding of DevRel responsibilities and scope - **Authenticity best practices**: Document successful approaches for maintaining developer trust in marketing-oriented organizations #### WordPress - **DevRel placement strategy**: Evaluate optimal organizational structure for WordPress.org developer relations activities - **Community feedback loops**: Strengthen mechanisms for honest technical feedback from developer community to product teams - **Contributor authenticity**: Ensure contributor relations maintain peer-to-peer rather than company-to-developer dynamics ## 🧪 Hypotheses - **Organizational placement hypothesis**: DevRel professionals in product organizations maintain higher developer trust and authenticity than those in marketing departments - **Domain expertise hypothesis**: Technical domain knowledge is more important for DevRel credibility than general advocacy skills - **Enthusiasm requirement hypothesis**: Genuine product enthusiasm is necessary (not just helpful) for DevRel success - **Career sustainability hypothesis**: Long-term DevRel careers require either deep specialization in one domain or exceptional ability to build authentic expertise quickly - **Developer perception hypothesis**: Developer audiences increasingly associate "DevRel" with marketing rather than authentic peer communication ### 📊 Methodology - **Longitudinal study**: Track DevRel professional career paths and perceived credibility across organizational moves - **Developer surveys**: Measure trust levels toward DevRel professionals in different organizational contexts - **Content analysis**: Compare messaging authenticity between product-led and marketing-led DevRel teams - **Outcome correlation**: Analyze relationship between DevRel placement and long-term developer engagement metrics ### ❓ Questions - How can DevRel professionals maintain technical credibility while transitioning between domains? - What organizational structures best support authentic developer advocacy? - Is the "career DevRel" path sustainable without continuous technical practice? - How do we measure authentic developer engagement vs performative metrics? - What role should revenue attribution play in DevRel evaluation? ### 🔮 Future Research - Industry-wide survey on DevRel organizational placement trends and outcomes - Longitudinal study of developer trust metrics across different advocacy approaches - Analysis of successful domain-switching DevRel professionals' strategies - Correlation study between product enthusiasm and advocacy effectiveness ### 💡 Implications - **Practice**: DevRel hiring should prioritize product enthusiasm and domain expertise over generic advocacy skills - **Policy**: Companies should carefully consider organizational placement effects on DevRel authenticity - **Education**: DevRel training programs need stronger emphasis on technical depth and honest communication - **Funding**: Investment in DevRel should account for long-term relationship building rather than short-term attribution ### 🧠 Learning Styles Assessment Reading level estimate: 12th grade (Flesch-Kincaid) #### 👀 Visual learners - **Present**: Conversational video format with speaker identification - **Improve**: Organizational charts showing DevRel placement options, career path diagrams, timeline graphics of DevRel evolution #### 🔊 Aural learners - **Present**: Full audio discussion with natural conversation flow - **Improve**: Chapter markers for key topics, audio summary highlights #### 🗣️ Verbal learners - **Present**: Clear definitions of DevRel terminology, analogies to traditional roles - **Improve**: Glossary of terms, comparison tables between old vs new DevRel approaches #### 🧩 Kinesthetic learners - **Present**: Real-world career examples and decision points - **Improve**: Interactive decision trees for organizational placement, hands-on assessment tools #### 🧠 Logical learners - **Present**: Cause-and-effect relationships between organizational placement and outcomes - **Improve**: Framework diagrams, decision matrices for role evaluation #### 🧑‍🤝‍🧑 Social learners - **Present**: Peer-to-peer conversation format between industry veterans - **Improve**: Discussion prompts for DevRel community groups, collaborative reflection exercises #### 🧘‍♀️ Solitary learners - **Present**: Individual reflection points about career decisions and authenticity - **Improve**: Self-assessment worksheets, personal mission statement templates #### 🌿 Naturalistic learners - **Present**: Organic evolution of the DevRel field over time - **Improve**: Ecosystem thinking about DevRel's place in broader tech industry evolution ### 📊 Accessibility Assessment #### Screen reader semantics - **Present**: Video title and description provide context - **Improve**: Full transcript with speaker identification, timestamp navigation, chapter headings #### Keyboard navigation - **Present**: Standard YouTube player controls - **Improve**: Custom transcript navigation, keyboard shortcuts for topic jumping #### Contrast and readability - **Present**: Standard video player interface - **Improve**: High contrast transcript option, customizable text sizing #### Text resizing and reflow - **Present**: Responsive YouTube interface - **Improve**: Dedicated transcript page with responsive design #### Media and captions - **Present**: Auto-generated captions available - **Improve**: Professional captions with speaker identification, downloadable transcript #### Forms and interactions - **Present**: Basic video controls - **Improve**: Enhanced navigation with topic bookmarks, note-taking interface ### 🌍 DEIB Assessment #### Cultural breadth - **Present**: Perspectives from Canadian and German-based practitioners - **Improve**: Include voices from underrepresented regions in DevRel, discuss cultural differences in developer communication #### Inclusive language - **Present**: Generally professional and accessible terminology - **Improve**: Define industry jargon more consistently, avoid assumptions about career privilege #### Neurodiversity support - **Present**: Conversational format may be engaging for some learners - **Improve**: Structured topic headers, consistent pacing, summary sections #### Representation - **Present**: Two male perspectives from established companies - **Improve**: Include diverse voices across gender, company size, career stages, technical backgrounds #### Psychological safety - **Present**: Honest discussion of career challenges and industry criticism - **Improve**: Content warnings for career anxiety topics, resources for support ### ✅ Logical Validity #### Strong reasoning - **Experience-based arguments**: Both speakers draw from 11+ years of direct industry experience, providing credible firsthand perspectives - **Causal relationships**: Clear connections drawn between organizational placement and role authenticity outcomes - **Pattern recognition**: Identification of industry evolution trends supported by specific examples #### Fallacies - **Anecdotal evidence**: Over-reliance on personal experience without broader industry data to support claims about DevRel evolution - **Survivorship bias**: Perspectives from successful long-term practitioners may not represent challenges faced by newer or struggling professionals - **False dichotomy**: Presentation of product vs marketing placement as binary choice ignoring hybrid organizational models #### Tone of voice - **Conversational and authentic**: Natural discussion style maintains credibility while remaining accessible to various experience levels ### 🛡️ DARVO Analysis No DARVO patterns detected. The conversation involves honest professional reflection and industry criticism without defensive tactics or victim/offender dynamics. ## 🎯 Conclusion This conversation reveals fundamental tensions in modern developer relations between authentic peer communication and marketing-driven outcomes. The speakers' concerns about DevRel's evolution toward traditional marketing highlight the importance of organizational structure and genuine product enthusiasm in maintaining developer trust. **Practical next steps**: DevRel professionals should evaluate their organizational placement's impact on authenticity, prioritize genuine product enthusiasm in role selection, and maintain technical credibility through continued learning and honest communication practices. The industry would benefit from clearer role definitions and better frameworks for measuring authentic developer engagement beyond traditional marketing metrics. ## 🔄 Refactor Appendix — devrelshow episode 49 - Niall Deehan from Camunda ### 📚 Literature Atoms #### Organizational placement fundamentally shapes DevRel authenticity and effectiveness > [!quote] > "When you put into uh that that department identically into a marketing department for example and again I can only speak to my experience you then need to re-evaluate what you are bringing to that department because now you are being paid by the budget associated with promoting the company positively to the people who will pay for it" **Context & use**: - Core tension between product-led vs marketing-led DevRel around 15:30 - Explains why departmental reporting structure affects role execution and developer trust - Critical for understanding modern DevRel organizational challenges **Tags**: #xref #devrel-structure **Highlight**: [view highlight](https://www.youtube.com/watch?v=PzHm7Q1X9as?t=930) #### Product enthusiasm is necessary, not optional, for DevRel success > [!quote] > "I think it's incredibly hard to do the job if you don't at least care or not necessarily care, but let's say have a good understanding of um why the product is something people should be excited about in some way" **Context & use**: - Around 42:30, discussing requirements for sustainable DevRel careers - Distinguishes between technical competency and genuine product belief - Addresses why "career DevRel" professionals struggle without domain passion **Tags**: #xref #devrel-authenticity **Highlight**: [view highlight](https://www.youtube.com/watch?v=PzHm7Q1X9as?t=2550) #### Early DevRel model prioritized peer communication over marketing outcomes > [!quote] > "The early uh sort of devril folks if you were a developer a software developer and you could talk and explain the technical aspects of what you were building really well you ended up sort of being the first cohorts into what became Devril" **Context & use**: - Around 8:45, explaining historical origins of developer relations - Contrasts authentic peer-to-peer model with modern marketing-driven approaches - Provides foundation for understanding current industry tensions **Tags**: #xref #devrel-history **Highlight**: [view highlight](https://www.youtube.com/watch?v=PzHm7Q1X9as?t=525) ### 🧠 Permanent Candidates #### Authentic developer advocacy requires genuine product enthusiasm over generic skills **Claim**: Successful developer relations depends more on authentic belief in the product's value than on general advocacy or marketing capabilities. **Evidence pointer**: [[#Product enthusiasm is necessary not optional for DevRel success]] **Scope & conditions**: - Holds when: Target audience consists of experienced developers with strong "BS detection" - Breaks when: Audience is less technically sophisticated or when short-term metrics matter more than trust **Links**: - [[Developer trust metrics]] — because evidence-for measuring authenticity - [[Career sustainability frameworks]] — because applies-in long-term professional planning - [[Marketing vs product alignment]] — because contrasts on departmental priorities ### ✏️ Fleeting Queue - [F1] Research industry data on DevRel organizational placement trends — validate anecdotal observations - [F2] Investigate frameworks for measuring authentic developer engagement vs vanity metrics ### → Things 3 - [ ] Survey DevRel community on organizational placement experiences and outcomes #things - [ ] Document organizational structure options for authentic developer advocacy #things --- # 📄 Full Transcript *Auto-generated from YouTube captions · timestamps roughly every 30 seconds · [watch on YouTube](https://www.youtube.com/watch?v=PzHm7Q1X9as)* **[00:00]** Heat. Heat. **[00:31]** Hello, hello, beautiful people. Welcome to another episode of I was going to talk about another show, but the terra show with Fred with Fred. I was going to say welcome to another episode of Backstage with Fred, which is a show I do I do at Tiny MC when I'm on the road. Uh yeah, no, it's a Dro show. It's the It's the right one. So, uh really happy to be here. always excited uh to do the Dell show. It's uh one of may my baby and actually episode 49 if I'm not wrong today which mean that like the next one **[01:01]** is going to be episode 50 which is some kind of like milestone. I mean like you know half uh so it's going that direction. I'm nowhere near uh to stop that show. I mean, I will continue to do that as long as I have guests because as I always say, that show obviously there's my name and kind of like my face on it because that's kind of my show, but like you could remove me from that show. It's all about the guests. They're the one making the show. So, as long I have as I have guests, I don't know how I like I'm not able to speak in English, **[01:32]** but as long as I have guests on my show, that show will continue. And let me tell you, my friend, so far so good. I think I have guests. Uh, and I'm not even lying here for the next two years uh, in the wait list. So, it's a good problem to have. It It's really sad though for uh, people that wants to join the show because I'm like, "Yeah, can you wait like about two years before coming on the show?" And hopefully he's still going to do that job while uh, that's going to be your turn. But anyway, I'm blabbering now again. Maybe I don't know, maybe I'm just happy like it's finally summer in Canada. We really had **[02:03]** bad weather until recently. Uh yesterday we started to have like summer weather and whether you like it or not weather affect your mood. Uh and now my mood is just more I don't know peppy. I don't know it's summer time. Anyway, super happy to be here. I have an amazing guest today. Nile. How is live? >> Practically perfect in every way. And uh you can't tell me any different. I I I feel that if it if you don't wake up in the morning believing that then it can only go, you know, can only get worse because my day can definitely get **[02:35]** worse from there. But it's still pretty good by that stage if you're already starting at quite a high point. So that's my usual rule of thumb. >> I like I like that. I like that. Uh and and you tell me if I'm wrong because I'm really bad with, you know, with names. Like I don't think we like we never met in person, but we're connected on LinkedIn for since since probably forever. Uh, so it's basically the first time we're interacting together. And >> you know what I do with my guests is that's usually to join 15 minutes before the show. So I can just give them like a little bit like, hey, let me tell you **[03:05]** what I sent you by email, but like just to be sure you remember like how the show's going to go. Uh, no real prep, but just like, hey, this is how we're going to do. First part it's discussion, second part is the demo and and just testing like everything is working well. And uh so I basically quote unquote know you for like 10 minutes and I just love the energy. I just love the energy and like just based on your answer the positive uh approach that you've done because uh you know I I don't want to go into into religion or philosophy be like **[03:35]** I'm Buddhist. Uh I follow the Tibetan Buddhist philosophy uh which is uh you know like basically the premise is like life is suffering which seems super negative when you think about it but that's a little bit true which doesn't mean that like I'm someone negative or someone that seeing like life is [ __ ] I just know that like there's always something happening but as you said if you have a positive attitude yeah things can go down but like if you start on a high note and you try to keep positive uh I think it's great. So I just wanted to, you know, highlight the fact that I **[04:06]** just love that approach. Uh it's so much more fun too. It's it's like it hyped the vibe too when the other person are positive instead of like when if I ask you like how are you? How is life? You're like yeah it's not going well. It's rainy outside. We don't know about our job is going to be secure and whatever. >> Yeah. And and don't forget as well, not only am I practically perfect in every way, it's also 6 PM my time. So, I've been doing pretty well all day. So, this is not only a starting point, this is **[04:37]** where I'm essentially like grounding my day to. No, I had a very lovely day today. And uh yeah, I um I I fully expect this to be a wonderful hour of of of your time, of course, and anyone watching, but uh because we got a really fun stuff that I really want to talk to you about because I think um one of the things that I was quite looking forward to you about is Devrell stuff in general. This is the Devrell show after all and because um I am in a really small team of myself and a few other folk, but no one else **[05:07]** would consider themselves like in Devril, right? So, I have a bunch of of interesting discussions, I think, lined up for you about just the concept of how you feel about Devril in general. We've both been in the industry for the same kind of amount of time, maybe you're a little longer than me. Um, and then we can maybe start talking about sort of a uh how the dynamic has shifted over the last little while because I'm interested in your opinion as well of course about uh if >> love it >> we all live in the bubbles of Devra in some cases and you wonder like is this how the whole industry is or is it just **[05:38]** what's going on in like the the connections that I have. So I'm quite looking forward to chatting about that. >> I really love that. Great ideas. I love when the guests come and like hey this is what I want to talk about. Uh but like before we even jump into that uh two questions for you. One what what are you drinking or and the second thing the second question is like who are you? Like tell like people that do not know you like who are you? >> I like how you prioritize those questions and you were right to prioritize what I'm drinking first when I'm I live in Berlin and I am drinking **[06:10]** an IPA uh from Burllo which is a relatively nice local brewery. Um not a small brewery but a local brewery. I wouldn't say it's the best craft beer in Berlin, but it's um the one I have and it's quite nice. I'd suggest if you like the kind of beer, you should uh give it a try. And who I am, which is again less relevant uh but still important. Who's who's drinking the beer is the question people are going to ask. So I'm Nile. So I um work as uh I work for Commund doing developer advocate stuff. I've I've been doing it for a long time. I've been with **[06:41]** Commund for for the last 11 years or so doing various things and I think just like most folks tend to fell into Devril kind of not by looking at the the what people do but doing it and then being told that's what it is that's what you've been doing and uh that happened quite a while ago. So I've been doing deval stuff for about eight years maybe and before that I was a software developer and uh then like I think like **[07:13]** the early this is this is my perception like the early uh sort of devril folks if you were a developer a software developer and you could talk and explain the technical aspects of what you were building really well you ended up sort of being the first cohorts into what became Devril, right? So that in that in that universe, Devril was trying to solve for a relatively small problem which was we **[07:43]** want our product team to be properly represented outside of the company uh in a way in which we can kind of skip around other departments. Now how do we do that? We send a developer who likes talking to a conference or something or to a meetup group or they talk to their peers and free of like the trappings of um talking points and uh pre-approved slides, right? You show code and you can have really honest conversations. And honestly, I was really drawn to Devril **[08:15]** easily for that. loved talking honestly to developers um who uh use the uh who use the software we were building and uh having a lot of honesty around that. It was a fantastic time. One of the things that kind of like disillusions me to Devril these days is that that's a really rare one, right? I'm not sure that really exists so much anymore. a developer who actually is sent by owned by the product team who is sent to speak **[08:47]** honestly about the software to not to users, clients, potential customers, but other developers, their peers. And I think that's a big movement that Devrell has had in the last 10 years that has really um made me feel like while I've stayed in this one lane, this whole big thing has happened in the meantime that has just reshaped it to the point where if someone like asks me, oh, what do you **[09:18]** do? I avoid saying Deborah. I will I will cry depends on their the context. Who are they? If they're a software developer who I'm interested in having a discussion about the nitty-gritty of software saying I'm I'm Devril I have found recently and when I say recently I mean the last maybe four years so it's a while right I have found the reaction is oh so you're you're marketing basically >> yeah yeah >> and so what kind of impression Fred do you have out of interest uh around that **[09:50]** same idea what what do you think first of all about the growth cycle I talked that resonate with you at all? >> I have so many things to say about everything you said. Um, wow. I don't know where to start. So uh the first thing I've seen that change a little bit also in the role where like like initially there was like hey you know with all respect for for traditional marketing that was not the way to approach uh you know developer with all respect from the sales team like developers are allergic to sales uh and we were like hey we need like developers **[10:22]** to talk to developers but as you said also remove from the like I don't know let's call them shackles of like the company or or like you know hey you need do it that way and you need to sell it with those words and you need to use those terms so like it's going to make sense for the business and it was like no let's just be honest. So uh sorry for the word but like since I do that job my my moto was always uh no [ __ ] Uh first because like I'm not that kind of person. Secondly because I don't think I can be successful in my role if I'm **[10:54]** trying to line or or talk about things that do not make sense for developer do not resonate with them. Uh I think it was a lot more exactly what you said at first. I think it depends on the company and or the people doing the job. So it changed obviously like as a general rule like as you said like I I feel the role change a little bit and again it can be so different from one company to the other. Um I think it's the first time I'm going to say that this but I think I'm really proud of like me keeping my ground on that like no this is how I see **[11:24]** the role. This is how I think the role is effective. this is how I think it can benefits the company if I do it in my own terms with my own vision of dev which is exactly what you talked about we we started with that where was like developer talking to developers I'm not part of engineerings or or most of the jobs I had I was not part of product uh but because I always came with the approach of like no I'm not I'm not going to lie I'm not going to I'm not going to be a salesperson if I do my job well like hopefully maybe developers will use our product or they become **[11:55]** users they become paid users or customers, but like that my goal is to help developer being successful. And uh again, hopefully, don't get me wrong, I like to have a paycheck, so hopefully they're going to be successful with my product. But if my product is not right for them, uh it's fine. If another product is also good to a competitor, I'm not going to lie about that. I may not go on the rooftop and say like, "Hey, use that other product." Like they're better with that specific functionality. But if we have a discussion with someone, like I'm going to be really honest about it. >> Yeah. I'll tell you why. That's um **[12:25]** that's something that really uh concerns me. So here's the thing about uh Deell is not part of um product right um and I've experienced this where the Devril department shifts around and the shift from product to marketing um made very little difference I think on the dayto-day of the people uh working right um but it had a profound impact on the perceived value of uh of of the team because when you're in product right uh **[12:59]** the goal is uh um very much well depends company like company again I can only speak my own experience which is which is what I will do the goal tends to be you are in a department a very technical department with a lot of technical people who are both interested in the feedback from the developers which is the ideal scenario a devro person should of course be a voice of uh of the end user the the developer user inside the the product the product and also So be able to get that information that the **[13:29]** devs are trying to say, hey, this is the way we see our the the stuff we're writing being used in a in the here's the best way to do it and go and like make sure that folks understand that because it's not always very obvious for whatever reason, right? So this made it a really really nice two-way street, okay? Because you really do end up with this embedding and everyone kind of works quite well with that. A key thing that's not there is any um illusion to a um uh a dissemination of marketing **[14:00]** talking points or more importantly a requirement to link the work you do to specific financial outcome uh which I think is no matter where you put devil is impossible. So when you put into uh that that department identically into a marketing department for example and again I can only speak to my experience >> you then need to re-evaluate what you are bringing to that department because now you are being paid by the budget **[14:30]** associated with promoting the company positively to the people who will pay for it because as lovely as marketing is they have no interest in telling someone who has no money how great the product is. Yeah. Because they are, you know, what value does that have? >> Um, and when I say what value, what immediate value does that have? >> There's no sort of long train on that. So then you find the activities you do, the things you're judged on end up being **[15:01]** quite uh tainted by this creeping uh pattern of judgment based on um growth and projections that the marketing department also believe in. So which makes everything you do less sincere. And so um I've never loved the idea I've actually well not never loved disliked intensely the idea of having to have what should be a completely productled **[15:35]** role put into a position where you need to have this terrible idea of standing in front of some a developer who uses the product and or who doesn't and tell them things that you know maybe are showing the product in the light but not the most honest light because you know that you probably it's better to show it to them in in the best light because that way they'll join the community or do something that's measurable right so that's how I felt I think most of well **[16:06]** that's how I perceive devro as a concept has gone which is why I don't tend to tell people that I'm associated with devrell because they make a link these days and again I'd love to hear your feedback on this yeah >> these days from that person does devril, that person does marketing, marketing are liars, that person's a liar. It's always a little more nuanced than that, but that I tend to get. >> Yeah. No, I mean I I agree with most of **[16:36]** what you said with uh a caveat uh in the sense that like it is like that in general. Uh and this is also uh why I lost some jobs because you know I was part of a marketing and we had interviews and you know you have interviews it's like I don't know if you're lucky it's just three or four interviews so you talk to maybe three or four people for let's say four hours so like you don't know each other but I'm still really always transparent about like this is my vision of devil this is how I usually wants or should be measured uh and I I don't want to be **[17:08]** tied to amount of money uh those are my reasons this is my approach it may be totally different from what your team does, but you need to live with it. And if you don't, I'm not a right fit for you. And please, when I say that, I'm really privileged. I've been doing that for a long time. Uh right now, maybe life is different like with with everything that is happening. But like it was a little bit and I'm not saying that like I'm so good. It's just because I've been doing that for a long time. I have a great network. Uh work at at great places that give me legitimacy even if if it means nothing in the end, **[17:38]** but like it was easier for me to get a job. I was able to filter jobs and be like, "No, this this is not a good fit for me." But some places, even if they were like, "Yes, okay, sounds good to me." They were still expecting me to be more like traditional marketing or more like a salesperson or more like another role or have a different approach after like a couple of months or a year. They were like, "Oh, yeah, Fred Fred is not changing his mind. Uh, okay, bye. Like, we we don't need you. We need someone else." uh it's also why I lost some jobs or I moved in like from other jobs uh once in a while because I was like no **[18:09]** this is not my vision but al so been lucky that I joined team that like because I rarely was like my perfect place as you said would be like it in product or engineering uh because of the nature of the role and there is a little less uh you know expectation from you to align with the goal of like marketing teams or other teams that may not align with de uh But also usually they don't have budget. So uh when you're in marketing at least there is the opportunity to have budget to do some stuff. But I've been lucky that like **[18:40]** most of the jobs I had uh like where I am right now uh marketing is doing an amazing job is doing an amazing marketing job but they also really understand my manager um she just left. So we'll see with the next one but my manager she was really like hey where are you for reasons? I know there's a different way for you to do things. I know there's different reasons and I was really clear about like yeah I'm not a salesperson. I'm also not a marketing person. I'm part of marketing. Uh but also I'm gonna have a different approach. So you know the first talk I did uh when I joined the company I **[19:10]** didn't use the template slides. I didn't use the marketing slides that were created. Some people were not super happy with that but my boss was like no there's a reason and I explained them why I do it that way. And people got in and now I mean like marketing is updating your website. They're like hey Fred like what do you think about that doesn't resonate with developer? and and I can go to the team and say like no you know what that line is [ __ ] I mean like like it may sounds right in your head a developer will look at it and it will say like no it's marketing [ __ ] so we changed and we updated so long **[19:41]** answer to say uh I agree with exactly what you said but it will depends on the in my experience again I'm just talking about my own experience in my experience it depends on the team and the people that are on the team and I've not always been lucky but I would say most of the time where I am right now so far so good uh people understand that like have a different approach. you also understand that like from my point of view developer relation is uh you can have short wins uh in terms of like you know you just talk about stuff and like hey that happens I'm still always like I **[20:11]** don't do product pitches most of the time I talk about other stuff that excite developers and but I'm still Fred from Tiny MC so maybe they're going to be like oh what the hell is Tiny MC and maybe they're going to be in a website maybe they're going to be curious maybe try it maybe they're going to become users and or customers but it's also a medium to long-term type of job because my primary role is to build relationship with developers. And maybe you don't need my product right now, but maybe your next job or your next project. Maybe you're going to remember me that didn't try to sell you anything that was really honest with you that uh you know **[20:43]** didn't try to like complete goals that don't make sense with my job. So anyway, I'm talking after that. uh just saying that like yeah I've been lucky that uh in some jobs I was even if I was still part of marketing um I was still able to basically do what I think my role should be and not be tied to metrics that will let's be honest poison my approach or my relationship with developers and to be successful no matter the department you are uh and after that I'm going to read **[21:14]** a question unless you have something you want to add right away about what I' I've done what I've said but um Um you know also to to be successful and even if you're not part of product or marketing you need a really strong relationship with those teams uh because you know the product I need to understand where we're going like what's the road map uh I need to be able to the engineering team and product to bring them the feedback from the developers when I talk to our users or people that try our product because as you said it's a two-way street for me was always a two-way street. Uh, it's also why and I want to talk a little bit about your **[21:44]** title at some point because first I like the first part and the second. No, did you say please don't? >> I hate my title. I think it was given to me as a joke uh to uh so I I actually rarely I I left it out of my intro kind of on purpose and I had this a funny enough I had a an I'd give a talk with a colleague of mine like on Tuesday at a guest lecture and I I asked him hey listen during the intros I'm not going to say my job title is that okay and I don't want you to do it either and he **[22:14]** said no problem and then the the the professor came up and then immediately introduced us by our titles and then question me about it. But no, I think it was uh yeah, I think it was meant to um humiliate me. And uh >> okay. >> Well, >> I like it. I like it. If I want to be honest, >> it's quite meaningless. And of all the things I don't like about being associated with sort of the the what is like the the newest version of Devril, I feel an obscure job title with with no **[22:46]** understanding of what this might be is one of those things that like I want people to know what I do and my job title doesn't do that at all. >> Yeah. Yeah. Okay. I get it. I was just excited about like the the alchemist part of it and also the the technical evangelist because like u you know I've been doing that rail for uh now maybe 15 years and when when I started the title we were all evangelists like it was either technical evangelist developer evangelist and at some and I loved it uh because first nobody known what I was doing so **[23:17]** it was a good icebreaker and they were like are you going to church or be something and I was like yeah that was a good icebreaker but the the the oil industry slowly switched to developer advocates because they felt like, yeah, we we we're not just evangelizing stuff. We're like, it's a two-way street as you said and also because some people were offended probably because of like the religious connotation of like evangelism, but like I always like that title. So, okay, we won't talk more about it. Uh >> I do like developer advocate was something that is two words. It's got developer in it. People can kind of **[23:49]** guess. He's pretty good. process alchemist and technical evangelist is an insane thing to call yourself and uh I understand that and uh unfortunately I need to explain to other people that I didn't choose it for myself uh which is something people think and I just need to get out there. >> I thought it was I thought it was the case because I'm like there is no in my mind I was like there's no way that HR was like so uh we going to hire uh what do we need to help the business being successful? Oh yeah, process alchemist. **[24:20]** I'm like, "No, I don't think ASR is going to do that." So, I was like, "Yo, Nile, choose a title." But like, now I know. Sorry. I was like, I was just like, "I need to talk about this because it was excited." And N was like, "Nope, please shut up." >> But, uh, okay, let's move to another topic. Uh, with that said, last thing about title, uh, >> I think no matter your title, it's probably unusful for like I don't care about titles at all. I know there's a lot of people that care about them, but uh you know like like my job right now um I lead a team so they gave me like senior developer relations manager. Uh **[24:52]** if I want to be honest, if I look at the other people on the chart and it's not because oh I'm so better or not better but uh like like compared to other people that does about the same job as me at a company where I am it should be director of developer relation. Do I care? Not at all. Some people care though. Uh so I think it's also why it's a little bit important because the day you want to find a new jobs uh people will like if if it doesn't work where I am right now and I want to find a new job like they won't think about me as like a director they won't think they will think about me as a manager. Even **[25:22]** if my day-to-day role is like a mix of IC stuff mix of management but also the big picture thinking about their role. Anyway, let's jump to uh oh yeah actually last thing before I move to the question. Daniel uh Andress was like I feel like all titles are made up these days. uh which is true and this is also one thing that annoy me a little bit with developer relation uh not the fact that that there's different titles but like developer advocate title can mean something totally different from one company to the other >> meaningless these days it's it's **[25:53]** hilarious how meaningless it is it's the only reason I had to get rid of that thing developer advocate no longer represented what I did because it was such a broad and misunderstood title that um better to have complete ambiguity than people making assumptions about what I can or what I am or am capable of. And so that if I had to choose, I'd probably keep my title over going back just based on the power of ambiguity can at least give you that at least people have to ask. Um so that's something but I totally agree with **[26:23]** Danielle there. >> Yeah. And uh I I just forgot one question. You wanted to have my my my opinion or or vibe or experience about it. Uh so far uh I didn't see people reacting negatively when I say I'm a developer advocate. Uh the thing that changed over the years is that people now have an idea what I do where in the past I was like okay let me let me explain you uh what I'm doing because you know when I started it was mostly big companies like only people who had like technical evangelist was like Microsoft, Apple, Google. My first job **[26:53]** was at Microsoft. Uh and after that, like a couple of years after, like a startup that had like 15 people, not even like a full-fledged engineering team to build the product that they wanted. They were like, "Hey, now our product is mature enough. We want someone to talk about it and and and I don't know, own the docs and do videos and stuff like that." And we're hiring developer advocates. So now more people know about it. Uh with that said though, obviously like some people may see a negative connotation about it. Uh the the things that I've always done in my life is that like I always feel like I looks like nothing compared to other **[27:23]** people. I'm always like my black t-shirt and my beard and I look like a hobo. But like once once I start to do my [ __ ] people are like oh yeah I think this guy know a little bit what he's doing and the title like is less important more than like oh I like your approach. I'm like oh you're not trying to sell me this. I'm like no it doesn't make sense for you. I'm like oh what do you think about that competitor? They're doing an amazing job. Like if you need them to do this this this go with them. If you need something else, oh, go with else. And uh this is my approach. So anyway, uh talk way too much, but that's also why I'm being paid. Uh so there's a question **[27:55]** from uh Neil Lee. Um I'm sorry. I'm just going to say uh there's a question from someone. >> Nan. Yeah. >> Oh, you're so much better. I don't know how like I struggle with names so much. It's why >> it's a classic German name that I'm I'm aware of. Yeah. >> Okay. >> Nulman. Yeah. It's >> wonderful. Thank you. And I Sorry. I apologize. I should stop trying to say the name of people. Uh because most of the time I I screw them up and I hate that. >> Mine is hard, but it's only four letters or five letters. I think I can never even remember myself. I think it's more than three anyway, but I have misspelled **[28:27]** my name multiple times. Um >> so yeah, do you think Davel, uh sorry, >> go ahead. >> Yeah, I was just going to read that question. So do you think Davel is a sustainable career? How can someone go from being a front-end developer advocate to advocating for vector database without losing technical credibility? That's uh good question. Big question too I think. So uh do you want to go uh first to your guest? >> Well the first thing I would say to that is uh well from my perspective um if I were to leave my current job I would not **[28:58]** become a developer advocate. Um I am primarily interested in the fundamentals of workflow automation and automation in general of stuff. that's kind of what I really care about and I get the most joy in general out of like building stuff that that that that can utilize that technology. So if it if um if I were to do this this this job, it would probably likely be I would move away from Devril to another company that does a similar **[29:28]** type of thing. Uh rather than move into a company that does Devril that I could do exactly what I do but for a different technology. Um that's partly due to the fact that my career was I was interested in this software first and then Devril kind of found me rather than move around. Right? So therefore I've never uh needed to I've never applied for a uh a Devril position rather in internally in my company. I was given that role because we were a very small company **[29:58]** when I started and I was there when we sort of we didn't even know what devell was uh when we started and then we got a a manager that was able to actually put manners on things and kind of had done deval and stuff like that. So that was that was a hope that was that was a nice uh transformation. But the um the the point is that for this question I would say that it's really hard to keep credibility. uh if your job is to speak to a technical audience about a very technical subject and you've come into a role without that technical knowledge **[30:30]** for example I think it's really really hard to sustain that because um I think it's if you can it's easier to stay within your technical expertise and move within the Devril community in that maybe if you wanted to do Devril primarily but I think that actually sort dedic it sort of showcases a an issue with Devril in general where you can end up with career Devril folks who end up **[31:00]** being very good at Devril, right? But they're they could then end up in the wrong technology >> that that they they they don't fully get don't really like they get hired first. They have a great track record for example of doing de stuff. they get hired into a a technology that they just never really click with. And if you can't understand or speak honestly about the technology that you're supposed to advocate for, it's not like marketing where you're kind of supposed to just learn to lie. >> You need you need to talk to people on a **[31:31]** fundamental level about how this works and and be able to give honest reaction. And that's why I always I I think so I often think about what how difficult it would be to do my job if the stuff I did wasn't good and wasn't um and in the past there's been there's been like a few releases where the software was not in great shape where it was way harder to do your job. >> But you know I still like the overall technology. I knew the potential. So you got to speak honestly about that. >> Yeah. Um yeah, and that again is much **[32:02]** easier if the department is not in marketing where you're being told here's how you're supposed to speak about the software. Doesn't matter that I can't do that yet or that it does it very badly, but this is we're talking about the future and I think um that can be a trapping as well. But yeah, that's my opinion on that's a very long answer to the question. >> No, that's good. That's good. Um I'm going to share my opinion too because um there's things are a little bit different from from what you answered. Um just to add on the last thing you said you know like like again I from my point **[32:32]** of view again it's it's not like black or white in terms of like oh marketing is just like like they ask you to do that or not like as an example when I joined Tiny MC they were like hey when we talk about Tiny MC we use the term rich text editor because this is how it is defined in the industry uh this is like I don't know there's also SEO implications stuff like that and I was like fine. So I'm like, okay, it's this my first job in in that specific area of expertise. So I'm like, I'm going to do that. And after my first event talking to developers, it was like no developers **[33:02]** know what is a rich text editor. Like everybody's like, so what is this exactly? And at some point I was like, oh, wait a minute. Uh, it's a wiz. And everybody's like, oh, okay, I know what it is. And now I can have a discussion with someone that already have like the the the light bulb flash over their head. I'm like, so I came back after the first event. I'm like, hey, you know what? uh continue to use rich text editor wherever it makes sense because we have like different target audiences mind their developer doesn't make sense and people are like oh that's different from what we're used to I'm like doesn't matter what I'm telling you is that rich **[33:32]** text developer rich text editor they do not know what that is when I say wiz awake they're like they understand so I changed my language and people are like okay awesome it makes sense for you so again it depends on the team of the people so I just want to be sure there's no nuance there and also uh if there's my marketing uh colleagues watching like I want you understand that. I understand there's difference and I I think we're doing a great job. Again, I'm not being a soccer. >> I'm speaking very frivolously about marketing as a concept, not individuals or any specific team >> and I understand too. I understand where it's coming from. Uh if I want to be **[34:04]** honest, uh and I'm usually always honest and for the better or worse in my life. Uh I'm always honest and I had really bad experience with marketing. I also had a really terrible experience with the sales team who were basically screwing me over because they were doing things that doesn't make sense for my audience. And I'm also happy where I am right now when I when we have a booth at events and I'm always with a salesperson. Why? Because I'm not going to be the one who's going to sell to developer but as a business we still want to sell to developer but they're doing an amazing team and I love their approach. They will never force someone **[34:35]** to say like hey they're on commission so like obviously they need to do more sales. want to have a proper salary, but like I really love the sales team. We have a tiny MC where they're like, "Okay, doesn't make sense for you." Fine, keep us in mind. Maybe in the future we're going to have a functionality that makes sense for you. Maybe in the future you're going to have a use case, but they're not pressuring people, which was not an experience I had with most people. So, there's also, it always depend on the people. It depends on the leadership team because they're basically the one who set the tone. To go back to your question, uh 520, this is what I'm going to call you. **[35:05]** Uh do you think the is a sustainable career? Uh I would say yes from my point of view. This one is a really personal question. I don't think there is a right answer. Uh in my case it is my career for the last 15 years. So I started also as a software developer. I was coding full-time talking to customers doing architecture but mainly coding. Uh I loved it. I miss coding full-time but also like when I put this on a scale between like devil job and like develop like like software engineers. the real job is a little bit higher for me because I'm also a big social extrovert **[35:36]** that love to help people being successful that love to be with people that love to talk to people that love to talk also way too much. So like for me it's it's good and this is what I'm doing for the last couple of years. Uh what you said though Nile it's true uh it's harder to move from one technology or one focus of technical area. Uh I've been doing that for the last 15 years mainly every jobs I was my product was totally different. So you know like the the last job I was in cloud native. This one is like rich text editor which is mostly JavaScript, react, angular focus. **[36:08]** Uh the one before when I was at Fitbit uh that was like you know smart watches and and you know targeted to health. Uh for me I liked it because that's a great challenge. Uh I never and maybe maybe it happened but like I've never perceived people that say like hey you're not uh you're not credible because you're switching uh like like different technology or focus of technology or type of product. Actually usually it's more positive. I'm like oh [ __ ] you're about to do that. With that said though, I want to like I still consider myself **[36:39]** technical, but if I want like I don't know why I always say if I want to be honest because I'm always honest and I feel like when I say if I want to be honest, it means that I was not on us before, but that's just an expression. Anyway, uh I'm not as technical as I used to. I'm still a developer. I can still code. I still understand code. I think I still have the credibility when I go on stage. And if it's not the case, please people on my room, let me know. If you watch my video, you're like, "That is [ __ ] Let me know. I want to know." But I'm not as technical as I was before. Why? because it's been 15 years that I didn't put something serious in production. Uh it's been 15 **[37:10]** years that like I didn't work full-time in a product. And there's things that you can learn when you're all day long it's about building software versus I learn technologies because I need to know about it because I need to create a tutorial because I need to record a video because I need to give a talk at a conference. So I still consider myself technical. So far nobody told me I'm not credible but maybe they just don't want to say it to my face. Uh but again I'm not as technical that I was when I was like 10 years full-time software developer. I'm still technical. I still **[37:41]** developer still call myself developer but again the reality is that I'm not building software in production for the last couple of years. So yeah uh going to your second kind of like followup question which I also liked. Uh also uh shouldn't Dell come from deep technical expertise? If that's the expectation, why not hire engineers or solution engineers with do knowledge instead of generalist devril professionals? Uh please go ahead and if you have I'm pretty sure you have something to say about this. Um, I think it's hard to **[38:11]** argue that if you were to just like it was Dev was built from scratch from somewhere along not too long ago really and that was from the people with domain experience that also had the ability to properly communicate that. I think those two factors should be true of most Devrell folks, right? You should have the domain experience and the ability to properly um explain or um he even yeah advocate **[38:43]** for the thing you're talking about if it's a fair thing to say. Um therefore I think in most cases folks would if they had a choice uh say we're looking for Devril and I think this is I think I saw this I see this around a lot. There's a lot of roles out there that are Devril skill set. Let's say they would have called Devril maybe five or six years ago that are not called Devril anymore because they are let's say those domain knowledge roles are the primary concern like we need somebody maybe a consultant **[39:14]** I don't know I'm not sure what kind of role like a solution arctic somebody who understands the stuff really really well and can explain it really well right but they don't necessarily call that devril for whatever reason >> and maybe it's because it's not in marketing so I would say to my my my answer to that question would be something Like yes, best case scenario, you find someone with domain knowledge who's able to either learn to or already able to express that domain knowledge in a way that is captivating and makes sense and makes people engaged. I think **[39:46]** that's fair enough. Um I don't think people always have that option. Uh I think is the other uh the other part of that. Um and I think that's maybe what happens. And also and again this is from my experience sometimes maybe this has doesn't happen anymore but folks would be put into devril from other departments they would just be like sort of plucked and like um we need somebody to do some stuff so you're devro now. >> Yeah. You did a lunch and learn one so now you're dev. >> Exactly. Yeah. And that could that could **[40:18]** be have been somebody with no domain experience but a very good present presentation style for example. And uh so there's there's loads of ways in which someone falls into this career. And I think if you were to write down what exactly are we trying to achieve, you would say let's get a professional with domain knowledge who can explain it correctly and hire them or find that person in the organization and convince them to uh to do that role. Um I think the alternative is just the next best thing. I think it's if you can't do the first one, but I could be wrong. **[40:49]** >> No, I mean uh I agree with everything we you said. I'm still going to have comments because, you know, it's it's like I just have to it's physically impossible for me to not say something about stuff uh that I have opinions on. Uh which is basically everything. But which doesn't mean that I have the only truth though. I always say that it doesn't mean I have the truth. Um, I agree like when when I hire developer advocates on my team, the perfect candidate is going to be someone who who who has the skills of developer advocates and have the dominant expertise because you right away bring **[41:19]** the the the the what developer advocates going to do the skills that like many engineers don't have because there is a lot of engineers that have like tremendous expertise and they're really like they know their [ __ ] like from in and out but they're not able to communicate probably to external people uh they don't want to be on a stage, they don't want to record videos, they don't want to write an article, they don't want to do those things because for them it's boring and or they're afraid of it and or they're just let's be honest not good at it. Uh so trying to find as you said trying to find like the perfect fit where like hey you have **[41:50]** that experience or expertise or you're able to do the de job plus you have the domain expertise best candidate >> most of the time it's not the case from my point of view I I think I wrote an article many years about that but like from my point of view what every other jobs consider as as soft skills you know being able to communicate being able to you know write stuff being able to to connect and and with people uh those things that are always great like Yeah, I want an engineer, a software developer that can build code, but I also want that software developer like like to be **[42:21]** able to work with their colleagues and communicate with them and help them being successful. Usually, it seems that like the soft skills or many other jobs is like it's a bonus to have that. From my point of view, developer relation, it's the hard skills you need to have that like it's the most important because from my point of view and maybe I'm going to sound pretentious here, the easiest part of the job is to learn the technology. Uh because it's also Yeah. Yeah. from my point of view is that uh because um you know uh anyway as a software developer you cannot just say **[42:51]** like okay I learned things at school then I'm done no if you've been in the industry for a long time you always have to learn so it it should be a little bit part of like who you are as a professional always trying to learn new stuff always having to learn >> uh some technology may not be like you may start to learn them like oh I'm bored of [ __ ] with that >> I actually do agree with you on the learning part it's actually not it's actually because I learning is is not um as relevant as caring, right? Because in developer advocacy is a little unlike being a developer on a product because a **[43:22]** developer on a product, you can probably do a pretty good job and not fundamentally care how it's used at the end of the day, right? I don't think that's that's such a hard thing to imagine. You get a ticket, you uh basically need to um build a solution for that ticket. And in a lot of cases, especially in larger companies, you don't even have a concept of how that fits into the whole product itself, right? So as a developer, I think you can learn the stuff on a technical level and uh not care about the product whatsoever or fully understand it. >> Now Devil is different. I think it's incredibly hard to do the job if you **[43:54]** don't at least care >> or not necessarily care, but let's say have a a good understanding of um why the product is something people should be excited about in some way. I uh not that it's impossible, but it would be much harder. So I think >> I would say it's impossible or or you like I would go to like you were for the lack of better word with my English, I would say extreme with a lot of like things you said and for once I was like this one should be extreme like in my from my point of view like it's it's **[44:26]** like don't get me wrong, you probably can fake it for a couple of months at some point you're not going to be successful. Uh I'm not saying like you need to be a workaholic. I'm not saying that like you need to dream about your product when you go to bed. No, no. I like my product. It's nice. It's a nice product, but it's also a job. Let's be honest. But I need to be excited about it. I need to understand the values because if not, you are jumping in the bullshitting part of like what you should not do. And developers, engineers, they're really they have like [ __ ] detector. This is why like and **[44:59]** and I'm saying that with all respect for traditional marketing ourselves, but this is why most developer allergic to uh you know traditional marketing and or uh you know even new ways of doing marketing or like the sales team because they had bad experience with people that wanted to reach their goal no matter what it takes no matter what they were saying which is not true for most team it's not true for my team if you're listening and you know it's right and you know that I believe that but uh I mean like this is the experience they have with most people so de I think the big difference is like **[45:30]** that we should not have to do that as we discussed since the beginning. We should not have to [ __ ] We shouldn't like and to be able to do that, you need to be excited. You need to believe it. Like I had when I was looking for uh a job last time, there's a company, amazing company, amazing people. They reach out to me and I'm like, "Hey, Fred, uh want to hire you." The offer would like like the the salary, everything was amazing. I was being able to build my devil team. I was not excited at all by the product. It's a great product. It solve issues that is good for people from my point of **[46:02]** view. I was not saying it's a bad product. I was just like there's no way for me to be excited about that. So I'm not going to be able to do my job well and I I didn't take I I did not even enter the process to like take the job because I was like no it doesn't make sense for me. Again I'm also coming from a really really privileged place where I was able to do that and not just take the first job that I have but uh from my point of view like every job is a job like like like I'm I'm not a workaholic. I do I work because I need a salary. Uh **[46:33]** at the end of the day, this is the only reason I would probably still do some of the stuff that I do as devil on my free time if I was full of money just because I was doing that before it was a job when I was a software developer. This is how I started. I was speaking in events. I was writing blog posts. I was writing meetups just because I love to do that. And at some point someone was like, "Hey, we can pay you to do that." I'm like, "Okay, sounds like a good deal." Uh so I would still probably do those things, but at the end of the day, it's a job. uh but I think that like specifically for developer relations because we are with the people we talk **[47:04]** to the people to developers you like you cannot fake that enthusias enthusiasm about the product you cannot fake that yeah like you really believe that it's like solving issues >> it's just that it's harder your job is so much harder if you have to do all of that understand the product >> talk about the product and pretend to like the product I don't know how anyone could do that sounds like a lot of that's a that's a workload code. Um, and I think um, it's not I I don't I can't imagine someone being able to accomplish that in a way that is effective. Um, I **[47:36]** think there you can watch someone stand on stage and go through the motions for sure. They can technically do their job, but not in an effective way. It's so hard to do that. Um, I guess it depends as well where your what your devril role is because a lot of them don't necessarily require you to actually be in front of anybody. It's probably a lot easier to lie and text. I'm not sure. Or to or to fame enthusiasm. Just ask um uh ask uh JBT or something too. Can you make me sound enthusiastic about this product? And then see what happens. **[48:08]** >> Yeah. It doesn't work when you're in front of people, especially with my face. My face cannot lie. So there's like like I like it's impossible. So yeah, you know, I understand. And just to clarify and after that, we're going to move to the Nemo part. We've been talking forever and as much as I enjoyed that uh like I don't think people will still watch us after 3 hours of talking which I'm pretty sure we could do. We're in a good in a good uh direction that yeah also you know about the about the new learning stuff I say that's the >> easiest part maybe the word is like the **[48:40]** simpler part more than easier because it still take time it's still >> the role of dev to learn the everyone who joins a technical role needs to learn the thing therefore it has the most um the easiest path to follow because almost every dev developer let's say a technical um marketing person, let's say a pre-sales person, stuff, stuff like that. They've all done that. So that's the easy part. I think you can definitely learn the technical aspects especially if you have a technical background. >> Yeah. And and and you know and for me it **[49:12]** plays in my favor. Like the last job I had I was in a startup uh I was it was in a cloud native uh space. So you know a lot of Kubernetes stuff and I did it just a little bit when I was a digital ocean but nowhere near to be like I'm an expert and like and it was a little bit newer at the time. Uh so when I started I was really honest with people. I'm like hey um it's not the first time I play with Kubernetes but let's call it the first time and I was like I'm not an expert yet but like I'm learning which is what everybody who is starting to use Kubernetes now is doing so we're going to be in the same journey. So it kind of **[49:44]** like played in my favor. It took me way longer than any other technology to call myself at least greatly knowledgeable about community not even an expert. It took me like couple months a year uh before my my my like co-founders at the startup who were really expert were like okay Fred you start to know your [ __ ] uh but like it took me a lot of time but during that time I also went to the same journey and like people were starting to use that technology and gave me other positive aspect to be able to do my job and and again I'm also always honest I didn't go on the stage and like hey so **[50:15]** I've been doing Kubernetes for 10 years no like I just started now uh so if I say something stupid let me know and and people laugh and we go like and and it's just working. So anyway, uh I'm liberating now. Uh great great questions. I appreciate that. Um >> yeah, thanks for uh thanks for thanks for discussing this uh controversial topic. Uh yeah, the last thing I'm going to say about that and I know it's been 10 times that I say that. Um I know that like uh sorry, in the past um I don't know if it's true anymore. I think I think the the industry kind of like get **[50:45]** back to it, but like at some point if you wanted to be a developer advocate, you needed to be a developer first and engineer first. Like there was no way for you to move to that role without it. You need because this is the the the beginning of developer relation. It was like developers, engineers that were like, "Hey, you know, I can talk to people and they were doing it." And at some point we started to see a role where like some people had no experience as software developer and they were like hired because they know how to communicate and like feel free people to disagree with me or or not. I I think we have the same **[51:16]** opinion here, but um I don't think it end up with like really great developer people, developer advocate people because uh and I say that with all of developers are really judgy. Uh so, you know, I can always being bra even if it's just 15 even if it's 15 years ago now, I can still say like, hey, I've been a full-time software developer and engineer for 10 years. I know how it is to work with customer. I know how what it is to put things in production. I may not know how it is to build with AI right now and have that pressure, but like I know a lot of like or I know it a **[51:46]** little bit because I do it, but like not in in like in the terms like being a full-time software developer and uh like I get that credibility because I've I've been through the nice thing of being a software developer, but also the shitty things of it. When once once you don't have it, uh I think it's a little bit harder. But again, as you said, it depends on the role. There are roles that are a little less technical, still call themselves developer advocates because they talk to developers. I'm still maybe a little like I still have the old tinking that's like I prefer to have someone that have a little bit of experience software development experience uh because they're going to talk to developers. But anyway, **[52:18]** >> I would uh completely agree with that. Um I I don't know how someone could do the job and not be able to have at least been a developer or be in the process of becoming a software developer. Either I think works. If the dev roll department is embedded with the product team, I think you have a chance of of of joining as a non-developer and then growing into the role because you're actively there and learning what developers are going through. But if you don't do either of those things, I don't I think you just call yourself something else. You're not what that is. You're um which is fine. **[52:49]** Just that's yeah, just to be something else so we should know. Yeah, >> I agree with that. >> Yeah. Who wants to watch me do a 20-minute demo in seven minutes? You can do it as long as you want. Uh so yeah, it's uh uh God, I have a I know it was around Kimunda. Uh so you know what? I'm a really bad host. I'm just going to let you introduce your company and and the demo are going to do and uh the screen is yours. >> Yeah, sure. Thanks so much. I'll be relatively quick. The thing I want to show is just kind of a fun thing that I **[53:19]** built a little while ago that showcases what command So command is a an orchestration um software where you basically design um uh what the state shows right which is what the state progression looks like and then you uh that gets executed in a um a visual medium. Uh it's really fun to build. Um the fundamentals of it are that it's designed in order to be a centralized point in a distributed um system and uh the idea is that command sits on a layer **[53:51]** uh which then orchestrates all the systems externally. So nothing is actually added to command layer. It is purely this the owner of state and the owner of state progression. That's the short part of that. And um this is a model I built because it's it's the new thing we're doing is that we are as part of a process. In the past processes were almost always predictable, repeatable, and deterministic. And um because of AI, uh that's all ruined because now things are supposed to be dynamic. Things are supposed to be a lot less rigid. Um but **[54:25]** we can still build that really easily. So actually what you're seeing here is a process with two agents that are specifically in charge of not really executing any of the tasks but simply choosing what should be executed. And there's some really really great side effects of that architecture. And I I'll showcase that with this little um front end that I have. This is like a local thing that I'm running. The actual commund instance is running in the cloud. So just as a FYI, I'll talk a bit more about that later on. And this is an **[54:57]** insurance claim process. We built this really um not too long ago and I really like the way it it works and the technology it implements. So I want to talk through what makes it unique as I build it and why I quite like building it. Um so my name as we all know is this um and I would like some uh work injury insurance. By far the biggest problem for the company we were working for was this type of insurance because I've had my bike stolen multiple times and uh the insurance policy is they give you money **[55:27]** and you're quiet, right? That's how it works. Work injury insurance or like I think it's called workers comp in the in North America is where I'm not sure what the French is. Fred, maybe you can tell me if there's a French equivalent of workers comp. Uh >> actually, I do not know. >> That's okay. What's the word? >> So, the idea is, of course, that I'm hurt, I can't work, and the insurance companies to pay me until I get better. Okay. So, I'm going to submit this. Um, **[55:58]** the process then is going to kick off. And it's got a few different agents. And the first agent is the is relatively standard. It's doing what you expect agents to do. Now what we're looking at is as things light up the agent is deciding what to execute. So you can see that it's already executed this task to get procedures and requirements. It's also executed the task to get my data, my customer data. It's queried that and it's got my insurance policy. Now these are already things that basically any AI **[56:29]** agent can do. The next thing it's done is actually much harder and that is that it's um funny enough sent me an email. Saying an email isn't hard, but waiting for a reply is really hard. So, if I take a look at um let's say I know um trying to find my yes, there it is. It did actually send me an email. It's good. So, the email looks like this. And it said, "Dear Nile Dehan, that's my name. You've submitted a thing. Uh we need to assess it. I need some stuff from you. Uh can you let me know?" So, **[57:00]** luckily I'm the kind of person who has a load of test data available. So, so a bunch of PDFs of my ID, details of my injury are all there. It's all very good and all all in the docs. Okay. Now, not only is at this point the business logic is that it's waiting for an email to come in, which I hope it does, it's also waiting in case no response happens. And how it does that is by utilizing um a **[57:32]** subprocess. So this agent has triggered a deterministic flow that at the moment has sent an email and then began waiting. This is where the engine's in charge of because all the am did was actually select the task to execute and then what the engine does is actually perform those tasks. The first three were tasks that simply queried external services. But this one's way more complicated. This one actually does a bunch of stuff. And in particular, this one here waits for an email to be sent. **[58:02]** Now, this thing here pulls the inbox every like 30 seconds or something. So, it'll be a little while before it actually finds the email. But in the meantime, I'm going to go back up here and I'm just going to take a look at what other stuff it can do. So, this is running on that subprocess. And the agent itself is only in charge of stuff in this scope because the process is quite large. And so certain agents have their tasks and their abilities and it's totally visualized of what actually gets executed. But also it has humans involved. **[58:34]** So we have here two different um people. >> One that gets the final report and one that gets like if they can't figure something out for some reason gets classifications. Now this thing is already finished. So what I expect I hope is I get a final report and then I'll be able to see the data that I submitted combined with the information it's got already in a predefined report that that this particular person needs. That's why it's taking a little long to trigger that task because the the LLM **[59:06]** itself is generating that data. And now we see it's triggered this user task. So now a user is involved. So they can then take a look at what the agent has said to us. And this is all the fun stuff. So we have our uh report generated on this day. No, it's about right. And uh yeah, information about me, including my definitely real phone number and apparently I live in Maple Grove now. >> Yeah, I was going to say at least it's not your real address. >> Yeah, I hope not. I I think it's got the **[59:37]** city and the country wrong. So that's a good start. Um, and then other bits and pieces about the insurance policy that it knows about and all sort of fun stuff. And then it goes down and here are all the checks it needs to make that it knows it needs to make. And then it's able to say, "Okay, that's good. I'm going to approve that. That's great." Now, um, I can also not approve it. The thing about that makes this unique is kind of not that interesting right now. The only thing I showed you that's relatively unique is the idea here of being able to call a subprocess with the **[60:07]** context of an agent. That's kind of unique. That's kind of fun. Uh, but this next agent is doing stuff that I really enjoyed building because this was a real problem they had to solve. This agent here, um, again, unlike most other insurance types, this is a very longunning agent. It runs for about three years, well, maximum three years until the policy runs out. And you would first think, well, that's too long for an agent that would bankrupt you. But the fact is that most of the time, the agent is actually not doing much waiting. And I'll explain what I mean by **[60:39]** that. First of all, it's asked me for some information. So, let's head back to my lovely email address. And let's see. Yes, I've got Oh, it's way more formal now. I'm no longer Nile. Dear Mr. Dean, so this agent is far more formal. Definitely wants to approach me in a more direct way. >> You You look like you're legit uh you have legit claims. So, now we're going to be polite with you. >> Exactly. Right. Yeah. This person looked at me and thought, "No, I'm not sure about this guy. Let's like make sure he gets through the uh the the process first and then we'll call him by Mr. DM. **[61:09]** So, it's asked me for how I'm getting on this sort of stuff. Now, this is important because the course of the Now, what I'll do is I'll quickly reply and luckily um I happen to keep a uh uh at all times um free text of exactly how I'm getting on at any time. Just happen to keep that. So, my typical day is blah blah blah. there. I've put kind of all the stuff they're asking for which they've detailed very nicely. I have just dumped into a big paragraph and I'm sending **[61:40]** that. Okay. >> So, we don't find that unusual. This is a normal thing to happen because of course this is what the the the client told us that that the user mainly their their main job this is this person up here. Their main job is to to find out how the patient is doing or how the the the client is doing right now as a baseline to determine how they get better. And that means that they need to try and get this big block of text thing into a more usable format to be able to **[62:10]** have a a consequential um action for the next response. And we can see that if we take a look at this thing here, it should trigger, I hope, but it's an LLM, so we don't really know. Yeah. So, this has come back And it can ask for clarification maybe. Okay, it is going to show the report. And we can see that it turned that text into something more usable, right? It's got it's parsed it together. This is not unusual. This is just a good thing an LLM does. And some positive and negatives. Great stuff. And I'm going to **[62:42]** say that's great. And now we're going to do something that most LLMs will have an incredibly hard time doing. Um, let's uh wait for 3 months and ask him again. Okay, so I've just told it how long to wait. That could be any amount of time depending on the case. It could be okay, let's see in a week after their hospital visit. But the thing we were told here that the LLM needs to dynamically wait **[63:12]** for an amount of time. And the way we do that is we use a BPN construction here that allows it to put in a wait time and then the agent so the engine then waits for that amount of time. So right now we are waiting for three months. Okay. And um that's pretty good. That means that in 3 months the agent will wake up. It will then communicate to the client and say hey last time you said this and that. how are you feeling now? And then **[63:43]** be able to report back on the progress of that person. It's pretty good, right? But >> so we're gonna you're gonna come back on the show in three months and we're going to see if >> Well, don't worry. Nile is not trustworthy. So, we don't need to go back in three months because in this case, Nile um is going to do something that's going to trigger this second thing here. Because one of the requirements we had, which I find really interesting, is while the agent is waiting to get back to someone, there is another department in this company, the **[64:14]** fraud squad, and >> they are checking up on folks. And as I said, Nile is not trustworthy. So, uh, we have a specific claim ID, which is here, which is a which is a unique identifier. And what I'm going to do is I'm going to say he wasn't giving a guest lecture. Nile was seen on Fred's Devil show. **[64:45]** Okay, this is not good for Nile. This shows that Nile is actually up and about. So I'm going to send this message and you can imagine like I'm sending this from my local system. So you can imagine that the fraud squad have their own system completely. >> And this is just a button they click on their system to say give the LLM additional context, >> right? You just send it as long as you have the application ID so you can find the right waiting instance. And what happens is that wakes the agent up and then the agent is like, "Oh, uh, I've **[65:17]** woken up from my slumber and I've got some new context to deal with." So then the agent needs to say, "Okay, what I do with that context?" And, um, they already because it's woken up now, it's given the the the the what's happened so far. So, it already knows it's ask Nile about stuff. And let's see if I get the Mr. Dehan response this time around or if I get my all three of my names which is how angry people usually refer to but no this is dear Mr. I hope this finds you well. Blah blah blah. Hey, uh, recently appeared on Fred's devil show **[65:48]** before scheduling quarterly. I got some clarification. Oh, no. The nature of my appearance. Okay, but don't worry. That was just my twin brother. He's like me but smaller. Okay. Anyway, so then we can continue the fun. So that agent then goes ahead and tries to solve that problem. The nice thing is that what we have here is a lot of agent technology solving a relatively hard problem that first of **[66:21]** all it it involves humans in a way that makes their job much easier which is really really good. But secondly it's it's totally visual and auditable. This is something that needs to be auditable and you can see exactly what runs. We have control of the state. you have all the variables and makes it very very easy to implement AI in places where they're very very heavily regulated and um >> yeah the fact that you put humans in the loop too which is something that is missing in many system that should probably be there especially in something as regulated as that uh yeah >> yeah absolutely in fact in this first **[66:53]** section here one thing you'll notice is the agent actually can't complete it unless it talks to a user and a user decides to reject or continue so they the agent has actually no decision making on whether someone should be accepted or not. The agent actually needs a human to do that. >> Love that. >> Yeah. And I think uh yeah, that's not bad. I did my I think I I managed to uh to complete that in in the in the a loted time there, Fred. So >> Oh, you had a as as I said, you had as **[67:23]** little as much time as you wanted. Uh I know we went over the usual like one hour that a book in people's calendar and I don't want to take too much of like your evening time but do you have time just for one last comment that may uh a user had that may require us to comments on it. Do you have still a couple minutes? Okay, let's do that. Uh Daniel uh you also had great input. Uh Daniel said uh every company on boards new folks and teaches uh their product but a general job those teams are so lean they don't have the time to teach **[67:54]** you those skills. So >> that's the thing. Yeah. In teams that I've been on, we've been definitely the the in in like the most functioning deval teams that I've been part of. Um they this they are very good at that. They have the people and able to bring people along best they can. Right. But this comment is absolutely right and it also showcases a big risk that Devril has in uh a **[68:24]** marketing department in particular in my opinion which is the value of the team as it is for doing things like this like helping on board new members of the team is never considered when for instance cost cutting needs to be taken into account that's when they'd look at Devril and think well why is it so big it's because everyone is doing a lot of different stuff here. There isn't there aren't individual roles here that are that are that are cut out. Even a a goodsized Devril team will have people **[68:55]** that are utilizing loads of different aspects of what they're good at. And I in an ideal scenario that involves enabling other members of your team because as Danielle quite rightly says, you don't usually have a lot of support from other parts of the department. If you're in the marketing department, that usually means you don't have access to a lot of technical people to help you understand the product and you rely then on the Devril um department to like help enable that and that can work. That can be really really good. Um but I think that what ends up happening is people **[69:26]** underestimate the um value of um uh those bigger Devril teams because they don't fully see the definitely in marketing departments. I think if you go into product again, you have that feedback loop thing that I can I've seen technical managers value heavily. So you have that additional thing, but that doesn't exist in the marketing department. You're not talking to the devs every day, right? You're not giving that feedback. You're giving the feedback to marketing and they're like, "Well, we can get that feedback ourselves. Maybe some other way if we get rid of Devril." So yeah, I think **[69:57]** this is a great um comment and a really really good um uh um uh assessment. >> Yeah. Yeah. No, no, I agree with that too. Uh the last thing I would add is that from my point of view, the the the little time I had people that could help me ramp up to the product and or the company and or uh technology. The company is good because like you know I want people to tell me what's the good how things work uh what's the processes the red tape and those kind of things that helps me to get started faster. **[70:27]** usually for the product or the technology. Uh I like to not having help and it's not because I'm so good. Uh it's just because I want to be like any new users. So what I usually do is like how like any new users I'm going to use the docs and I'm going to use the tutorials out there. I'm going to use the video out there. So I can know from like the first two three weeks maybe like hey what I think is missing. If I have suggestions about the docs as a new user, I can go to the joy or the pain of new users and uh if I want to get it **[70:58]** takes me more time to like you know get into it versus like oh uh like someone else another devil on the team who knows the technology real well or someone an engineer is going to spend a couple of hours with me to teach me to show me how it's working to help me. Uh obviously if I get stuck for for an amount of time I just ask help. I'm not stupid either. Uh I know I look like but I'm not. uh but at the end of the day uh by by being that kind of like you know uh I I I believe that Devril should be customer zero like there's a new release we should be the first one to try it test it to learn about it to know about it uh **[71:30]** because we need to usually create content about it but also like you know we talk to people but by doing that in a new job it really gave me the lay of the land about like what is missing for like like a user experience a developer experience when to join the company so again it takes me more time to go to that direction but I like to do that >> which not everybody who hire me likes need to do that. But that's my process that uh after many years I helped me really be successful in what I do. But um yep, on that note, I think it brings us to uh the end of the show. So uh any **[72:01]** last word, last sentence, something uh intelligent or not to say >> I can go with not intelligent. That's my default. And thanks thanks a million actually. No, there was a great discussion. I thoroughly enjoyed it. Um it was nice to get your perspective on topics that um yeah that I I think about a lot but I'm always interested in bouncing these off folks because yeah it's uh it's it's lonely where I am in terms of the Devril stuff. I don't have a lot of Devrell folk around me. So um it's good to uh to get the opportunity to bounce those off. So thanks for uh **[72:33]** for taking on these discussions. They are really good. >> My pleasure. Thanks to you for being on the show. I know uh you're part of like the the couple quote unquote first people that reach out or I reach out to you to be a guest and it took forever and everything was delayed and like it was complicated. Finally, we're about to go online. I think you're one of the last person now that the other people are aware that like it may takes time and like I'm not doing that every other weeks now and I'm not scheduling also a year in advance which is is what I was doing when I was not traveling because like it's fine like there's very little thing that's going to disrupt that. Now **[73:04]** it's not a reality. So anyway, thanks again for being on the show. It was a real pleasure. Uh true uh to have you on the show. It's also great u that we have uh you know it's great that we have some like common opinion but also like when we like there's some disagreement but we're like fine with it because that's life. We don't have to agree about everything and that makes a better show when like the answer is not always like hey I agree with everything you say. Uh so thanks for doing that. I really appreciate that uh when it's done in a respectful way and was done. So uh thanks to everybody thanks to everybody **[73:34]** who join us live. Uh thanks to everybody who joined. Uh I was going to watch the I don't know how to talk anymore. Uh how did people who will watch the recording? Thanks to you and uh I should probably write those things down because every end of the show I do not know when is my next episode. It used to be every two weeks and now the next one's going to be in one, two, oh actually in two weeks. Uh so yeah, my next show is going to be in two weeks. Uh I have another amazing guest. I'm going to announce that uh probably beginning of next week. uh you **[74:05]** should join us. It's going to be amazing. And on that note, I wish you a great evening, morning, afternoon, night if you're watching us at night. And see you in two weeks for the next episode. Bye everyone. >> Cheerio. Bye.