speaker-0: Hey, Tim Berglund here on my own occasional podcast. My guest today on this first episode is Eno Teresa. He and I briefly overlapped at Confluent, and then he went on to AWS, Alcyon, VM, and basically being an elite engineer in all those places, including Confluent. ⁓ now he's a first-time founder running a company called Trent, a startup focused on security for AI agents. We get into some of the tensions that are really at the heart of agentic development right now in these early days, which is that, sure, fine, we're faster than ever. I think everybody agrees with that. But things like security practices haven't caught up. And there's good reason to think that they might never. That's a gap that Eno's startup is, of course, trying to fill. We also talk about DevRel ⁓ in early stage startups, when to make that first hire, the importance of trust in DevRel in the age of AI, you know, questions like is a developer advocate the same as a field CTO? All this and more, let's jump in. Hey, you know, how's it going?
speaker-1: Good. Good to see you.
speaker-0: Good to see you. It has. It has. We were ⁓ talking recently and I just I ⁓ realized at the time it would be better if we were recording the conversation. It was just like I don't know. It was a good conversation. I thought we need to revisit this. So let's do it. But let's start off with ⁓ for anybody doesn't know your background, doesn't know what you're doing right now, what are you doing right now and How'd you get there?
speaker-1: Started a startup in the agentics space of course. ⁓ working on security. We wanna make those agents safe and secure. A lot of my background I've been an IC up to this point, so this is a first time founder. ⁓ previously well worked with you some at Confluent. It's lucky to overlap for a couple of months. Yeah. previously I was ⁓ an engineer at Veeam. at Alcyon, spent some time in AWS, confluent of course. Always an IC. Coded a lot. Still do. Yeah, now everything has changed. Probably for the second time. I was there in the on-prem to cloud and now cloud to a Gentec.
speaker-0: Yeah. ⁓ it's it's good to see more than one big shift. I I I really think this is the biggest ⁓ we're we're around the same age, but in our professional lifetimes, I think this is the biggest shift and it's happened within the last five or six months. ⁓ so we're we're still just kind of getting our feet under us with this changing landscape.
speaker-1: Yeah. Yeah, yeah, no, I I agree. We ⁓ listen, I dropped everything for this, yeah. It was ⁓ I said everything is changing. However, I did see some glimpses of this ⁓ back when ⁓ I was working on on my PhD at Carnegie Mellon. We built we built the first autonomous data center back then. So this was this was a long time ago. I'm not gonna mention the year. I was gonna say two thousand seven. Yeah.
speaker-0: Yeah.
speaker-1: So back then we were using I remember we took ⁓ we took a cool I'm a systems person, like an engineer, yeah, like I I build stuff, but we were very excited we took this machine learning course from I think it was Tom Mitchell back then. He's written that machine learning book and ⁓ we were like, Hey, let's just use this, let's apply this. But it wasn't LLMs, it was back then it was decision trees and neural networks and things like queuing theory and now it's LLMs and reinforcement learning. But a lot of things are also similar. I mean, back then we had mispredictions and errors and false positives, and now we have hallucinations. So ⁓ I had an early glimpse of this. I just many years ago I just didn't ⁓ at the same time things have still moved a l really fast this last twelve months, really. ⁓ I I am surprised, yeah.
speaker-0: Tell us a little bit about what ⁓ Trent is company, right? ⁓ it I think it kind of frames the discussion about developer adoption and and communities and things like that. So ⁓ agentic security, but dig into that a little bit for me and let's let's talk about how ⁓ you know where developer adoption fits into that. I I know you got questions for me too, so whatever.
speaker-1: Yeah, let's ⁓ let's also keep this simple because the Gente gives a loaded term. So the here's how this started in pretty much every place I've been as a developer. We've always we were always disconnected from any security teams. Yeah. So I think for AWS was probably the best place that had like ⁓ some solidified security culture. And there we're shipping services, we're trying to do them really fast, yeah, and and ship on time and and right at the Last minute this other team would show up, this security team, and they'll say, like, Hold on, you can't you can't do any of this, yeah.
speaker-0: Yeah, they they're they're just let you know.
speaker-1: Yeah. ⁓ have you looked at this checklist? And there was this big checklist of things and we were like, okay, we just want to ship some stuff out there. Right. And they were very disconnected from the developers. Developers were disconnected from them. and you know, everybody tried really hard, but then it became this on one hand we wanted a good security culture. We wanted to ⁓ you know, we always said security first, yeah. On the other hand
speaker-0: No, we haven't.
speaker-1: security always felt like a bit of an afterthought. ⁓ and then in startups I've been to, ⁓ they just they don't even have a security team. Yeah. So people are shipping software really fast. And ⁓ I did some I did some research back in the day and it turns out 70% of security problems happen before you even write your first line of code. So then yeah, so it's like if you get the design wrong, you get the architecture wrong, right? Okay. And ⁓ How do we think about that? What does that mean? So we have interesting tools nowadays like Cloud and and you know, we've heard of Mythos. But what does it mean when you get security wrong before you've even started writing the code? So yeah, that ⁓ that got us thinking. Fast forward to today, it's not about code, it's ⁓ it's more than code. Yeah, it's it's code, it's skills, it's MCP servers, it's agents. The definition of agents is in flux, things that are produced with lang chain or open claw. Yeah, and and it's it's quite interesting and quite complex. But but again, like going back to that culture of security, the question in our mind is we're certainly shipping things really fast, but what does it mean to have them also secure and safe once they are deployed in production? Yeah. So this is what start the trend. Okay. And and trying to to Help develop pro help developers, but it's this interesting question I'd love to explore with you, which is on one hand, developers really shouldn't care about security. They should just care about what they are excited about. Yeah. Yeah. On the other hand, we have this tension that we do want a culture where security does come first. So we can explore a little bit the tension, especially nowadays where we're using so many tools, yeah. And and resolving that tension, we're kind of right at the at the heart of it as trends.
speaker-0: I like it. I c I guess on the one hand, you don't want to have your solution be, well, let's just make everybody be good at security.
speaker-1: No no no, you don't want that. No one wants that.
speaker-0: You y w it it would be nice. It's just that that's not available to you, you know. it's it's more like what what are the developers that you have and the processes they're using and ⁓ you know, how can you find the levers that you've got then to make their systems more secure? And I that sounds like that sounds like the second one sounds like your approach.
speaker-1: Well it's ⁓ it's interesting. You can you can take an extreme there. You talk with developers, ⁓ I was one of them. And I mean they they don't get promoted based on security, right? They get promoted based on features. What did you launch? How many agents did you launch? Mm-hmm. And can we also I mean there's this challenge, can we make security invisible? It just trend, for example, produces an agent, maybe it it just fixes the security for you. But the problem is that if you go too far there, if you fix too much then what does it mean for the developers also learning about security, kind of appreciating those steps that that are really important in in the development of s of someone in their software engineering career as well. Yeah. So it's ⁓ it's an interesting tension. And today many people are skipping some of the intermediate steps. They go from idea to final product. Maybe they're using it using Lovable or Bold to produce that. Maybe they're vibecoding it. So what do we do about this part in the middle is ⁓ is quite interesting. And it needs to be done tastefully as well because again people have a job and they also want to go home after that, yeah, and they they don't wanna think about security like all the time.
speaker-0: Right. And the the as you say, they are more measured on we'll just say features. And in the current context, and I I don't know how long this is gonna last, but many developers are, we'll just say, preoccupied with what's my future? What does it even mean to be a person who writes software now? and speaking for myself, so I j la last night, adding some features to my personal website, which I'm I'm building with Claude Code, having a great time. It's not It's not merely a static site, like there's a there's a fair amount of actual code there. And I was thinking, hey, ⁓ comments. I need people to give the ability for people to comment. Let me write my own, you know, which nobody would say. It just you would it's not a chance you'd do a thing like that. Now I'm gonna. ⁓ I'm I'm in the middle of it. I've got an open spec proposal, looks good, about to start moving forward with it. Have I thought about security? ⁓ no, I'm putting a tremendous amount of trust. in Claude to get that right. It's all it's a fairly simple thing. It's you know it's Next.js and the stack is is fairly trustworthy, but I'm being the normal developer who kind of doesn't think that hard about that and needs that help. ⁓ so
speaker-1: Yeah. And it's it's this interesting thing, this it's not a paradox, but you have to hold two things simultaneously in mind, which is one everything about security, everything we've learned over this last fifty years is now encoded in in an LLM, yeah. So ⁓ low level code vulnerabilities, anthropic is gonna do it for you, it's gonna do a great job. So you don't have to worry about them. At the same time You know it's opened up a whole bunch of new attack surface areas. Just you have these agents, they're doing a lot. Maybe the code is is correct. But all of a sudden they are touching parts of the system they're just not really supposed to touch. So it's this interesting paradox where a lot of problems, a lot of the old problems in cybersecurity, are now being addressed and are now fixed or fixable with relatively low cost. And a whole bunch of new other problems are being opened. Yeah. And that's where there is the jump from code to well this code and this agent that you're deploying, it's it's really running and it's running with other agents and who really knows what it's doing? Yeah, I mean ⁓ you have a prompt to it and and you give it your files, you give it your your code to fix, right? And where does that all go? There's this ⁓ You know, back in the day we had this y we had data and we had compute. I guess in Kafka we had like the Kafka topics and we had the with the records that we produced there. Yeah. And now once those things enter once you do once you develop your your application and once you have a prompt there that sucks the data in, all of a sudden the compute and the data have been mixed together. That data is not part of the model. And it's it's kind of embedded in there, yeah? And teasing the depart is it's actually quite hard. So there's been this meshing of data and code which I also find quite interesting.
speaker-0: Yeah. Potentially difficult in terms of solving problems like security. So where maybe it's obvious, but how do you think about Devrel and security and Trent and ⁓ yeah, talk to me about the the you know, where you think developers fit in into the adoption of a thing like this in the place that we are right now, in this very strange environment we're in right now.
speaker-1: It is. And I and here I I I also have a question for you because I work in two worlds. And trend works in two worlds. May maybe three worlds. One of them is is the community. So we have ⁓ we have ⁓ big play in the in the in the community, so we have trend for open cloud, yeah, and there you have developers building these agents and deploying them. And there we can talk about DevRel and and getting people to understand the importance and and ⁓ the joy and the discovery of building these agents and and and securing them and and and I can think of that as DevRel. But then we also have an enterprise angle. And there I'm kind of curious what do you think this might sound like a silly question, but what do you think about the intersection of DevRel and something like a field CTO that we have more in the enterprise? Because they're it's developers in the enterprise as well, but they think more than just the code, they think more than just the the tools. They they just think differently. And actually, maybe this is the first time I've asked anyone that question, right? Like do you see DevRel more like in the in the space where developers are directly working with some of the concepts you've provided and and and then in the enterprise, what what do you do? Is that does it translate to a field CTO? Is that like even a bad question? Does the question even make
speaker-0: No, it makes a lot of sense. It makes a lot of sense. A developer advocate and a field CTO have a lot of similarities. A field CTO, it's not stupid at all. It it ⁓ it's close to home. So ⁓ a field CTO is like a supercharged S E in the the terms we do, sales sales engineer, sir, systems engineer, solutions engineer, whatever, you know, sales engineer.
speaker-1: Okay. So my question isn't stupid, that's good. No.
speaker-0: Technical person, and just for listeners, if you don't know the term, technical person who's involved in the selling process, glued to a salesperson to answer the the technical questions of the selling process. and a field CTO is like a real good version of that. That's that's the elite. and typically in an enterprise software company, a field CTO is in the go-to-market organization and and and maybe even in the the sales organization, and they're they're involved in selling. And typically a developer advocate is not, you don't put like quota numbers or anything like that on a on a DevRel team. ⁓ but the skill set is very similar. And like times I've when you're recruiting developer advocates, say you find somebody who's got technical skills or communication skills that look good, but they're not currently a developer advocate, they might ask, where does my career go after this? Is this a dead end? Can I am I just this person? you know, fluffy conference speaker for the rest of my life. Just not what a developer advocate is, but people think that. ⁓ people worry that when they're they're coming in. And I always say, being an S E is adjacent. You don't like this, just go be an S E. You might make more money. You know, you'll travel more. It'll be more stressful, but pay is great. ⁓ and and field CTO is a lot like that. So if you're a a a person who understands the technology deeply and is good with people A good communicator. Yep. Can put ideas together, tell a story. the the they're they're two sides of the same coin. Not everybody wants to do both jobs, but they're very similar.
speaker-1: And correct me if I'm wrong, but one of one of the things that I'm seeing, I don't I'd love to hear what you're seeing there, is that I'm seeing a lot of folks in the enterprise now with AI, people that didn't necessarily code before, people like product managers. ⁓ they are very open and curious to trying some of these new tools and to just playing around with it. So we have people saying, Hey, I'm ⁓ I'm deploying The equivalent of open club. There are different things in the enterprise. And all of a sudden I had, you know, I had these teams that were doing all the development, but all of a sudden, as a product person, I just want to put this thing together and do various things with it, like you know, query all my data, right? And and it so so the folks that were talking before with field CTOs are now doing a lot of development. And they're going through the journey of discovering. Well, ⁓ you know, what are some of the tools I have? What are some of the options I have? Discovering also some of the joy of ⁓ hey, I I'll try something small and and then ⁓ make it bigger. Yeah. And and I'm finding that really fascinating because then You know, there are similarities to to in that world in the enterprise with some of the work that I'm seeing from what I call traditional developers, more like in the open cloud community. Yeah. So that's ⁓ that's been that's been quite fascinating to watch. That that software engineering obviously it's a cliche to say it's been democratized, but it has led to this somewhat hybrid role that I'm seeing across, yeah. So like a hybrid like DevRel. field CTO and then and and product person in there. So yeah, that's ⁓ that's some of the stuff that I'm seeing.
speaker-0: I was, you know, a year and a half ago that ⁓ I started seeing our demos get a lot better. 'cause, you know, they
speaker-1: Yes. That's right.
speaker-0: Talk a developer advocate's gonna build, you know, you don't have time to invest in a big fancy front end or like maybe and the typical for Kafka things, there'll be some Grafana and you'll see some graphs or something, but you're just kinda connecting pipes there. You're not gonna build a custom front end or some cool custom data generator that's part of the story you're telling. You just have time for that. You know, nobody's gonna spend a month on a demo for a a a talk they're gonna give five, ten times. Well, you know, now there's we can move a lot faster on that stuff and and and have more fun there.
speaker-1: I built my first front end when we started the startup. we didn't have someone in the front end, so it's using V0. It's really good. I ⁓ yeah. I can be dangerous now and that but ⁓ I usually was more of a back end person, but I can pretend I understand front end as well. I mean the interesting thing is now and I I love your opinion there
speaker-0: That's what I'm talking about.
speaker-1: There is this gap between doing something really quickly and then deeply understanding it. I don't think I understand frontend or the concepts there, but it has been easy u using Vizero and other tools there. I mean we have a whole bunch of tools. It's not just VZero, yeah. I started with it. And one of the one of the interesting things as we're building the startups, we're hiring ⁓ various folks ⁓ with with various expertise is this Almost like jumping of this middle layer where you know you you start discovering something, then you learn a little bit more deeply, and then you get to that final product that you see and you love. It almost felt like I was cheating there a bit. Like I started and then I got like almost like an end product, but I didn't really understand anything in the middle. Right. Or or or or maybe I did, but not as deeply as if I had like handcrafted the the code, right? ⁓ What what's your what's your thinking there in terms of the I mean are are you are you seeing AI as kind of helping us that's a broad question. W t tell me a bit more about this like intermediate joy that people have in their discovery process. Like have we like short circuited that part or or or
speaker-0: I in terms of the joy, I don't think so at all. I think that's that's there's it's very real. And there's there's kind of two emotions ⁓ that I I hear come up a lot when I I listen to developers talk about agentic development. One of them is joy. ⁓ I can't believe I've I am having much more fun than I've ever had. I can't believe the kind of stuff I can build. People say that. That's me right now. ⁓ and then there's exhaustion. ⁓ I've got five agents running. I can't keep track of it. It's so addictive because I just get I think I just need to give it another little move it forward a little bit. I can't go to bed. You know, so there's these these kind of two competing reactions. Very interesting. ⁓ the second one, clearly, we're gonna have to manage. ⁓ we're gonna have to build some some tools around learning when to stop. ⁓ but I don't think that that joy is Cheap. ⁓ there's nothing short circuity about that. Being the thing that you want to make has always been what we're after. And it just took a real long time and a lot more suffering to get there. And now when you get to make something that much faster, you're still the the and I'm I'm speaking for myself and I think many software and it's and you know, I mean
speaker-1: The making.
speaker-0: It's been 15 years since I've earned my living as a software engineer. Okay. I'm it's this is the the the the part of a developer that never goes away. ⁓ you still see yourself as a developer, even though it's been a long time. ⁓ but I think most of us that's what we're in the game for, right? Because we want to make things. Some people are in the game because they really like crafting code. And I think those people are sad right now. And that's a re that's a true grief. Because that's not gonna be a thing that
speaker-1: That's fair. Yeah.
speaker-0: We get to do as much. but I think most of us just like to make stuff and we get to make stuff faster. Now the short circuiting or the shortcutting, I think we are in a process of discovery right now about how much of that shortcutting can we do. you know, the stuff I build for hobby projects, sometimes I read the code, sometimes I don't. I just want it to work. Sometimes I feel myself not even really wanting to read the open spec design document. You know, that's I'm like, come on, you gotta have some standards here, Tim. Read the markdown. You can do this. But I think how much how aware we have to be of the details, ⁓ we don't know yet. And I suspect that there is some early enthusiasm. that's causing us to say, ⁓ forget it. Just have an agent review the code. It's you you gotta move faster. You can't you can't block on PRs. I I I think that that will probably not work out well. And when there's real money on the table, we'll find that, yeah, we still kind of do need to know something about the code. But that takes months or years to learn that kind of thing as a community.
speaker-1: Yeah, and that's what we're finding with security. So they aren't these ⁓ AI native startups, they are developing really fast and then they want to make some money. They want to sell their product, their agent to the enterprise and and ⁓ sometimes whatever they have written is being classified as malware or blocked and the bigger enterprises are saying, No no no, you just you have kind of written and it kind of works, but the securities posture is really weak. Yeah, it's just You gotta harden it, you gotta make it compliant. And that's when they usually come to Trent and they're like, I don't know what that means, that security bit, but just just make it so that it's not classified as malware, yeah. Just make it so that we can actually sell it and make some money. Right. the ⁓ the question for us then it's more of ⁓ okay, so we'll do a one off. But what have we helped you in terms of understanding ⁓ you know, in terms of thinking about the culture around security and and the answers are nuanced. I mean sometimes you don't have to have a culture around security. Sometimes you just want to get something out there and and delight your customers and make them happy with, I don't know, selling flowers on the internet or whatever people do. And sometimes if you're doing something a bit more critical, then yes, you do need to ⁓ you need do need to build that ⁓ security, maturity model and program within your company and we help you a little bit with that as well. But the answer is nuance, yeah. I mean it's ⁓ no two companies are the same. ⁓ but also going back to what you're saying around filtering noise, one one of the things that's super fascinating right now is that together with all the tools we have given developers and and and ⁓ some people are saying like, you know, we've made everybody ten X. ⁓ it's it's probably more like two X. I think end to end is also more like sixty percent. Like ⁓ it's not it's not even to X, but ⁓ 'cause there is bottlenecks elsewhere, yeah. But that's a different story.
speaker-0: We don't we don't really know what those other bottlenecks
speaker-1: Yeah, we're measuring it. It's ⁓ yeah. Some things are are ten X, some are some are two X. ⁓ what's the Tell t tell me a bit more, like it it feels there are days when I feel like when I re when I remember Kafka, for example, or when I when I go back, there were there were a few kind of key voices in the community there producing content. I mean, you're you're pretty legendary there, right? I mean setting a really high bar for everybody else and and and nowadays it feels like almost like every developer with a with a tool and an idea is just producing content out there and On one hand it's it's really great. ⁓ I I put some more blogs out there with what I do. On the other hand, like how do you deal with all the noise, right? I mean there is ⁓ whenever we're hiring developers and training them in our team How do we find that w what's the what's the way to find that those those influencers, if you will, with that that bring the real value? Like how do you filter through the noise? How do you Yeah? How do you manage that? Well what what's your tips there? I mean I guess we c they they can subscribe to your podcast for sure.
speaker-0: I mean that's the thing. You should definitely end and ⁓ got a you know, substack or you can just go straight to Tim Brooklyn dot com.
speaker-1: That's right, there you go. Take a shortcut there.
speaker-0: That's right. and it's kinda it's ⁓ this is funny. So everybody listening, watching, you know, and I did not coordinate this question at all. But ⁓ I've got a a blog post I'm shipping today. Okay. ⁓ It'll be on LinkedIn, Substack, blah blah blah. ⁓ Timbergling.com indirectly addresses this. There's a part of it. So it's kind of an expansion on my my developer journey framework of of discover, understand, play, build, advocate. ⁓ this is the journey that developers go through when they're adopting a technology. ⁓ there are other DevRel leaders who've got, you know, slightly different spins on that whole thing. It's it's my take. It's it's I'm not the only one who's who's got that. But I think in the in the age of AI, as we like to say, trust becomes a lot more important because the marginal cost of cranking out a unit of content is close to zero. Yeah. Anybody can crap out blog posts. Some people are making tutorial videos with AI avatars. And I I I really think the technology is not there yet. I think that's terrifying. ⁓ in the present day, just with the quality of the the AI avatars. I think that's a super bad move. But there isn't a shortcut to building trust, the thing is. So you asked me what my my tips are. And I don't have tips because to build trust is Well y you have to experience someone as trustworthy. ⁓ saying trust me is usually what a bad guy in an action movie says at some point. You know, it's you can't just tell someone to trust you. That's not a thing. I mean, I guess Kyle Reese said, Come with me if you want to live in Terminator and that was an epic line. And you it was it was a very high stakes moment. ⁓ had to had to force I want to say Linda Hamilton, but that that wasn't the character's name. It had to force her to make a a choice. But Trust is experienced, right? You build trust because you experience someone who's trustworthy. And so ⁓ there isn't a shortcut. You do have to experience a we'll just say an influencer as a trustworthy voice who doesn't just shill for whatever it is they're being told to shill for, ⁓ isn't just saying the hypeest, clickbaitiest thing, but is really trying to help a community of developers along with some kind of frontier in their world. And you know, I look back at the various frontiers I've been a part of, they seem even Kafka seems small in comparison to AI now. but Is that person a trustworthy voice? Are they bringing value, educating, helping make sense of the world? And you just gotta pick the people who you have that experience with. There isn't a shortcut. There isn't an algorithm that's going to tell you. There isn't this one simple trick. ⁓ but it I think it does matter that, you know, you you curate voices that can help you. It's just like in your personal life. You know, you got people that you're close with. You have something you're going through that's a big deal, some big decision. Should I take this job? Should I relocate? Should my family move here? You know, who's close to you? Who's gonna advise you? Who have you experienced as trustworthy? I think in the DevRel world, ⁓ or more broadly, you could say the influencer world, there's that same thing. And you gotta look for those people who are are in it because they actually want to help shepherd a community across some kind of transition.
speaker-1: Interesting because we have this exact same question asked ⁓ in the security space. People say, Well, there's so many startups. What what is the moat? And I have now been through ⁓ I guess I worked in two startups and I've seen like the entire cycle. ⁓ the beginning, the journey, and the end, I suppose. And especially in this area in security, the the moat is are you gonna be there for the long term? and earn the trust? Or are you gonna be there just to do the what I call like the cherry on top, only the cool part? And then and then ⁓ declare it a success and disappear. So in many of the products we've shipped in the past, really ⁓ when when I look back, it's been Yeah, you can't you can't short circuit the trust. It's ⁓ something that compounds over the years, you gotta be there, help the community with like right now we're seeing ⁓ open cloud people ask about I mean some simple questions or some even complicated questions, but if we have some answers we try and help. And they try and help us in return, yeah. And that part a real moat in this era of doing things really fast i is is actually doing things ⁓ for the long term. And just sticking with it and then ⁓ ev even some of the the quote unquote boring things which Some of the enter let's face it, some of the enterprise stuff like in security is pretty boring. Like things like role based access control, right? I mean who wants to do that? ⁓ I don't wanna do it, but the customer wants it, right? You know little
speaker-0: says when I grow up I want to do our back, you know, but but it's a valuable thing that people will exchange money for.
speaker-1: Yeah, they will. They will. And we've seen this over and over again. Or or or models that belong to the customer with the data and the learnings belonging to them so that it doesn't go to like some of the bigger companies, right? Yeah. ⁓ all of that trust is trust and all of that can be earned over time. Right. So yeah, it's interesting. Let me let me put you on the spot there. We're we're a startup year one seed stage. Give me some advice. When when is the right time to hire the first DevRel person? Or what what are the conditions under which a DevRel person for lack of a better name if you have come up with a better name, let me know by the way. I will just say DevRel. What what are the conditions that they would be happy like in an early stage startup?
speaker-0: That that first hire is usually what I'd call a developer advocate. So it's the content creator, speaker kind of person.
speaker-1: Get the right name wrong, right? It just shows my ignorance. It's okay.
speaker-0: That's right. No, no, no. A lot of people say, when should I hire a DevRel? And it's pet peevamin. I'm like, I it's a DevRel leader. It's okay. It's all right. But a developer advocate. And that person might not be, you know, three years from now, when you're scaling your sales motion and you've got 300 people, that might not be the same person who leads the team, but they're a content creator, they're deeply technical, they're a good communicator.
speaker-1: There we go, I studied too.
speaker-0: ⁓ they'll travel some, you know. So that's the profile of the first hire. Usually that person should come from your existing community. That's a that's a good place. You gotta be careful if you're hiring from a customer, you know, make sure you have all the right conversations. But somebody who's already in love with your product, you you've got those fans out there who is in that advocate stage of their own adoption. ⁓ they make a good, passionate developer advocate. And ⁓ It we're we're also assuming, like you, ⁓ certainly like Trent, that there's a significant developer-facing surface area. So if you're gonna do it at the at the kind of A-round stage of life, ⁓ or C ev even seed, seed is is pretty early. Usually founders are doing it then, but at the A-round stage of life, you have to be sure that that developer adoption is key in your go-to-market, right? Like you're not really gonna be able to sell things. If developers customers are bought in. You have to know that. ⁓ and if you're an application, you know, early days of Salesforce, no, they don't need developer advocates. I mean, they got them now because they got APIs and they're a huge company and everything. But it it has to be that it has to be the case that even if developers don't write the check, they need to be believers, right? So it's usually an A-round kind of thing.
speaker-1: Yeah, but okay.
speaker-0: You know, in terms of a head count, 10, 20, 30, when you're in that size, you can you can start to think about a developer advocate. There's there's a a a delicate part of this job where nobody wakes up in the morning thinking about Trent. But lots of people wake up in the morning thinking about agents. And part of the mission, and I guess I'm just this is now just DevRel coaching for for Trent, and everybody gets to listen in.
speaker-1: Yeah.
speaker-0: Which is great. This is a fun conversation. Yeah. ⁓ part of the mission is when we say agent, so many people think, well, clawed code or whatever, you know, my my harness. Or maybe ⁓ open claw, you know. ⁓ they're they're thinking that kind of agent that's running on my laptop or the Mac Mini that I bought to to run things. ⁓ the agents I think you're talking about. are software written in the enterprise that are doing things with enterprise data. And this, you know, this is a it's a very different thing. It's agents that developers are creating. And so part of what you have to do is now create a differentiation between the common conception of my coding agent and agents that we're building. You could see this play out in debates online like MCP is stupid, all we need is CLIs. Yep. ⁓ now that is a statement that somebody makes when their entire experience of an agent is basically clawed code. ⁓ in the enterprise, it's not like that. So your developer advocate, number one, has to do that. Number two, because nobody wakes up in the morning worried about Trent, you have to just you have to r think about what are the things that people wake up in the morning worried about. And and this is developers now, not not the maybe executives that you're be selling to, but in terms of appealing to developers.
speaker-1: Yeah, yeah, yeah.
speaker-0: What are they worried about? And how's that connected to agent security? What part of that total addressable developer market really does have an anxiety about agent security? Maybe that's not the thing that they Googled or whatever or asked Claude about, ⁓ but there is a thing that they're thinking about and the content that this developer advocate creates, the talks that he or she gives, need to address kind of those organic concerns with Trent based solutions. And, you know, i they're not selling. It's it's just that they are there to make Trent famous ⁓ in a way that's valuable to that developer in the audience. So I think that's that's the move for that early stage DA there.
speaker-1: I love that. That's ⁓ that's a lot to think about.
speaker-0: So when you hire that person, ⁓ we just play this back.
speaker-1: I love that.
speaker-0: All right. You know, well, I think that's a great place to land the plane.
speaker-1: Awesome. Thank you.
speaker-0: My guest. We'll talk soon.
speaker-1: Take care. Thank you. Real pleasure.
speaker-1: Good. Good to see you.
speaker-0: Good to see you. It has. It has. We were ⁓ talking recently and I just I ⁓ realized at the time it would be better if we were recording the conversation. It was just like I don't know. It was a good conversation. I thought we need to revisit this. So let's do it. But let's start off with ⁓ for anybody doesn't know your background, doesn't know what you're doing right now, what are you doing right now and How'd you get there?
speaker-1: Started a startup in the agentics space of course. ⁓ working on security. We wanna make those agents safe and secure. A lot of my background I've been an IC up to this point, so this is a first time founder. ⁓ previously well worked with you some at Confluent. It's lucky to overlap for a couple of months. Yeah. previously I was ⁓ an engineer at Veeam. at Alcyon, spent some time in AWS, confluent of course. Always an IC. Coded a lot. Still do. Yeah, now everything has changed. Probably for the second time. I was there in the on-prem to cloud and now cloud to a Gentec.
speaker-0: Yeah. ⁓ it's it's good to see more than one big shift. I I I really think this is the biggest ⁓ we're we're around the same age, but in our professional lifetimes, I think this is the biggest shift and it's happened within the last five or six months. ⁓ so we're we're still just kind of getting our feet under us with this changing landscape.
speaker-1: Yeah. Yeah, yeah, no, I I agree. We ⁓ listen, I dropped everything for this, yeah. It was ⁓ I said everything is changing. However, I did see some glimpses of this ⁓ back when ⁓ I was working on on my PhD at Carnegie Mellon. We built we built the first autonomous data center back then. So this was this was a long time ago. I'm not gonna mention the year. I was gonna say two thousand seven. Yeah.
speaker-0: Yeah.
speaker-1: So back then we were using I remember we took ⁓ we took a cool I'm a systems person, like an engineer, yeah, like I I build stuff, but we were very excited we took this machine learning course from I think it was Tom Mitchell back then. He's written that machine learning book and ⁓ we were like, Hey, let's just use this, let's apply this. But it wasn't LLMs, it was back then it was decision trees and neural networks and things like queuing theory and now it's LLMs and reinforcement learning. But a lot of things are also similar. I mean, back then we had mispredictions and errors and false positives, and now we have hallucinations. So ⁓ I had an early glimpse of this. I just many years ago I just didn't ⁓ at the same time things have still moved a l really fast this last twelve months, really. ⁓ I I am surprised, yeah.
speaker-0: Tell us a little bit about what ⁓ Trent is company, right? ⁓ it I think it kind of frames the discussion about developer adoption and and communities and things like that. So ⁓ agentic security, but dig into that a little bit for me and let's let's talk about how ⁓ you know where developer adoption fits into that. I I know you got questions for me too, so whatever.
speaker-1: Yeah, let's ⁓ let's also keep this simple because the Gente gives a loaded term. So the here's how this started in pretty much every place I've been as a developer. We've always we were always disconnected from any security teams. Yeah. So I think for AWS was probably the best place that had like ⁓ some solidified security culture. And there we're shipping services, we're trying to do them really fast, yeah, and and ship on time and and right at the Last minute this other team would show up, this security team, and they'll say, like, Hold on, you can't you can't do any of this, yeah.
speaker-0: Yeah, they they're they're just let you know.
speaker-1: Yeah. ⁓ have you looked at this checklist? And there was this big checklist of things and we were like, okay, we just want to ship some stuff out there. Right. And they were very disconnected from the developers. Developers were disconnected from them. and you know, everybody tried really hard, but then it became this on one hand we wanted a good security culture. We wanted to ⁓ you know, we always said security first, yeah. On the other hand
speaker-0: No, we haven't.
speaker-1: security always felt like a bit of an afterthought. ⁓ and then in startups I've been to, ⁓ they just they don't even have a security team. Yeah. So people are shipping software really fast. And ⁓ I did some I did some research back in the day and it turns out 70% of security problems happen before you even write your first line of code. So then yeah, so it's like if you get the design wrong, you get the architecture wrong, right? Okay. And ⁓ How do we think about that? What does that mean? So we have interesting tools nowadays like Cloud and and you know, we've heard of Mythos. But what does it mean when you get security wrong before you've even started writing the code? So yeah, that ⁓ that got us thinking. Fast forward to today, it's not about code, it's ⁓ it's more than code. Yeah, it's it's code, it's skills, it's MCP servers, it's agents. The definition of agents is in flux, things that are produced with lang chain or open claw. Yeah, and and it's it's quite interesting and quite complex. But but again, like going back to that culture of security, the question in our mind is we're certainly shipping things really fast, but what does it mean to have them also secure and safe once they are deployed in production? Yeah. So this is what start the trend. Okay. And and trying to to Help develop pro help developers, but it's this interesting question I'd love to explore with you, which is on one hand, developers really shouldn't care about security. They should just care about what they are excited about. Yeah. Yeah. On the other hand, we have this tension that we do want a culture where security does come first. So we can explore a little bit the tension, especially nowadays where we're using so many tools, yeah. And and resolving that tension, we're kind of right at the at the heart of it as trends.
speaker-0: I like it. I c I guess on the one hand, you don't want to have your solution be, well, let's just make everybody be good at security.
speaker-1: No no no, you don't want that. No one wants that.
speaker-0: You y w it it would be nice. It's just that that's not available to you, you know. it's it's more like what what are the developers that you have and the processes they're using and ⁓ you know, how can you find the levers that you've got then to make their systems more secure? And I that sounds like that sounds like the second one sounds like your approach.
speaker-1: Well it's ⁓ it's interesting. You can you can take an extreme there. You talk with developers, ⁓ I was one of them. And I mean they they don't get promoted based on security, right? They get promoted based on features. What did you launch? How many agents did you launch? Mm-hmm. And can we also I mean there's this challenge, can we make security invisible? It just trend, for example, produces an agent, maybe it it just fixes the security for you. But the problem is that if you go too far there, if you fix too much then what does it mean for the developers also learning about security, kind of appreciating those steps that that are really important in in the development of s of someone in their software engineering career as well. Yeah. So it's ⁓ it's an interesting tension. And today many people are skipping some of the intermediate steps. They go from idea to final product. Maybe they're using it using Lovable or Bold to produce that. Maybe they're vibecoding it. So what do we do about this part in the middle is ⁓ is quite interesting. And it needs to be done tastefully as well because again people have a job and they also want to go home after that, yeah, and they they don't wanna think about security like all the time.
speaker-0: Right. And the the as you say, they are more measured on we'll just say features. And in the current context, and I I don't know how long this is gonna last, but many developers are, we'll just say, preoccupied with what's my future? What does it even mean to be a person who writes software now? and speaking for myself, so I j la last night, adding some features to my personal website, which I'm I'm building with Claude Code, having a great time. It's not It's not merely a static site, like there's a there's a fair amount of actual code there. And I was thinking, hey, ⁓ comments. I need people to give the ability for people to comment. Let me write my own, you know, which nobody would say. It just you would it's not a chance you'd do a thing like that. Now I'm gonna. ⁓ I'm I'm in the middle of it. I've got an open spec proposal, looks good, about to start moving forward with it. Have I thought about security? ⁓ no, I'm putting a tremendous amount of trust. in Claude to get that right. It's all it's a fairly simple thing. It's you know it's Next.js and the stack is is fairly trustworthy, but I'm being the normal developer who kind of doesn't think that hard about that and needs that help. ⁓ so
speaker-1: Yeah. And it's it's this interesting thing, this it's not a paradox, but you have to hold two things simultaneously in mind, which is one everything about security, everything we've learned over this last fifty years is now encoded in in an LLM, yeah. So ⁓ low level code vulnerabilities, anthropic is gonna do it for you, it's gonna do a great job. So you don't have to worry about them. At the same time You know it's opened up a whole bunch of new attack surface areas. Just you have these agents, they're doing a lot. Maybe the code is is correct. But all of a sudden they are touching parts of the system they're just not really supposed to touch. So it's this interesting paradox where a lot of problems, a lot of the old problems in cybersecurity, are now being addressed and are now fixed or fixable with relatively low cost. And a whole bunch of new other problems are being opened. Yeah. And that's where there is the jump from code to well this code and this agent that you're deploying, it's it's really running and it's running with other agents and who really knows what it's doing? Yeah, I mean ⁓ you have a prompt to it and and you give it your files, you give it your your code to fix, right? And where does that all go? There's this ⁓ You know, back in the day we had this y we had data and we had compute. I guess in Kafka we had like the Kafka topics and we had the with the records that we produced there. Yeah. And now once those things enter once you do once you develop your your application and once you have a prompt there that sucks the data in, all of a sudden the compute and the data have been mixed together. That data is not part of the model. And it's it's kind of embedded in there, yeah? And teasing the depart is it's actually quite hard. So there's been this meshing of data and code which I also find quite interesting.
speaker-0: Yeah. Potentially difficult in terms of solving problems like security. So where maybe it's obvious, but how do you think about Devrel and security and Trent and ⁓ yeah, talk to me about the the you know, where you think developers fit in into the adoption of a thing like this in the place that we are right now, in this very strange environment we're in right now.
speaker-1: It is. And I and here I I I also have a question for you because I work in two worlds. And trend works in two worlds. May maybe three worlds. One of them is is the community. So we have ⁓ we have ⁓ big play in the in the in the community, so we have trend for open cloud, yeah, and there you have developers building these agents and deploying them. And there we can talk about DevRel and and getting people to understand the importance and and ⁓ the joy and the discovery of building these agents and and and securing them and and and I can think of that as DevRel. But then we also have an enterprise angle. And there I'm kind of curious what do you think this might sound like a silly question, but what do you think about the intersection of DevRel and something like a field CTO that we have more in the enterprise? Because they're it's developers in the enterprise as well, but they think more than just the code, they think more than just the the tools. They they just think differently. And actually, maybe this is the first time I've asked anyone that question, right? Like do you see DevRel more like in the in the space where developers are directly working with some of the concepts you've provided and and and then in the enterprise, what what do you do? Is that does it translate to a field CTO? Is that like even a bad question? Does the question even make
speaker-0: No, it makes a lot of sense. It makes a lot of sense. A developer advocate and a field CTO have a lot of similarities. A field CTO, it's not stupid at all. It it ⁓ it's close to home. So ⁓ a field CTO is like a supercharged S E in the the terms we do, sales sales engineer, sir, systems engineer, solutions engineer, whatever, you know, sales engineer.
speaker-1: Okay. So my question isn't stupid, that's good. No.
speaker-0: Technical person, and just for listeners, if you don't know the term, technical person who's involved in the selling process, glued to a salesperson to answer the the technical questions of the selling process. and a field CTO is like a real good version of that. That's that's the elite. and typically in an enterprise software company, a field CTO is in the go-to-market organization and and and maybe even in the the sales organization, and they're they're involved in selling. And typically a developer advocate is not, you don't put like quota numbers or anything like that on a on a DevRel team. ⁓ but the skill set is very similar. And like times I've when you're recruiting developer advocates, say you find somebody who's got technical skills or communication skills that look good, but they're not currently a developer advocate, they might ask, where does my career go after this? Is this a dead end? Can I am I just this person? you know, fluffy conference speaker for the rest of my life. Just not what a developer advocate is, but people think that. ⁓ people worry that when they're they're coming in. And I always say, being an S E is adjacent. You don't like this, just go be an S E. You might make more money. You know, you'll travel more. It'll be more stressful, but pay is great. ⁓ and and field CTO is a lot like that. So if you're a a a person who understands the technology deeply and is good with people A good communicator. Yep. Can put ideas together, tell a story. the the they're they're two sides of the same coin. Not everybody wants to do both jobs, but they're very similar.
speaker-1: And correct me if I'm wrong, but one of one of the things that I'm seeing, I don't I'd love to hear what you're seeing there, is that I'm seeing a lot of folks in the enterprise now with AI, people that didn't necessarily code before, people like product managers. ⁓ they are very open and curious to trying some of these new tools and to just playing around with it. So we have people saying, Hey, I'm ⁓ I'm deploying The equivalent of open club. There are different things in the enterprise. And all of a sudden I had, you know, I had these teams that were doing all the development, but all of a sudden, as a product person, I just want to put this thing together and do various things with it, like you know, query all my data, right? And and it so so the folks that were talking before with field CTOs are now doing a lot of development. And they're going through the journey of discovering. Well, ⁓ you know, what are some of the tools I have? What are some of the options I have? Discovering also some of the joy of ⁓ hey, I I'll try something small and and then ⁓ make it bigger. Yeah. And and I'm finding that really fascinating because then You know, there are similarities to to in that world in the enterprise with some of the work that I'm seeing from what I call traditional developers, more like in the open cloud community. Yeah. So that's ⁓ that's been that's been quite fascinating to watch. That that software engineering obviously it's a cliche to say it's been democratized, but it has led to this somewhat hybrid role that I'm seeing across, yeah. So like a hybrid like DevRel. field CTO and then and and product person in there. So yeah, that's ⁓ that's some of the stuff that I'm seeing.
speaker-0: I was, you know, a year and a half ago that ⁓ I started seeing our demos get a lot better. 'cause, you know, they
speaker-1: Yes. That's right.
speaker-0: Talk a developer advocate's gonna build, you know, you don't have time to invest in a big fancy front end or like maybe and the typical for Kafka things, there'll be some Grafana and you'll see some graphs or something, but you're just kinda connecting pipes there. You're not gonna build a custom front end or some cool custom data generator that's part of the story you're telling. You just have time for that. You know, nobody's gonna spend a month on a demo for a a a talk they're gonna give five, ten times. Well, you know, now there's we can move a lot faster on that stuff and and and have more fun there.
speaker-1: I built my first front end when we started the startup. we didn't have someone in the front end, so it's using V0. It's really good. I ⁓ yeah. I can be dangerous now and that but ⁓ I usually was more of a back end person, but I can pretend I understand front end as well. I mean the interesting thing is now and I I love your opinion there
speaker-0: That's what I'm talking about.
speaker-1: There is this gap between doing something really quickly and then deeply understanding it. I don't think I understand frontend or the concepts there, but it has been easy u using Vizero and other tools there. I mean we have a whole bunch of tools. It's not just VZero, yeah. I started with it. And one of the one of the interesting things as we're building the startups, we're hiring ⁓ various folks ⁓ with with various expertise is this Almost like jumping of this middle layer where you know you you start discovering something, then you learn a little bit more deeply, and then you get to that final product that you see and you love. It almost felt like I was cheating there a bit. Like I started and then I got like almost like an end product, but I didn't really understand anything in the middle. Right. Or or or or maybe I did, but not as deeply as if I had like handcrafted the the code, right? ⁓ What what's your what's your thinking there in terms of the I mean are are you are you seeing AI as kind of helping us that's a broad question. W t tell me a bit more about this like intermediate joy that people have in their discovery process. Like have we like short circuited that part or or or
speaker-0: I in terms of the joy, I don't think so at all. I think that's that's there's it's very real. And there's there's kind of two emotions ⁓ that I I hear come up a lot when I I listen to developers talk about agentic development. One of them is joy. ⁓ I can't believe I've I am having much more fun than I've ever had. I can't believe the kind of stuff I can build. People say that. That's me right now. ⁓ and then there's exhaustion. ⁓ I've got five agents running. I can't keep track of it. It's so addictive because I just get I think I just need to give it another little move it forward a little bit. I can't go to bed. You know, so there's these these kind of two competing reactions. Very interesting. ⁓ the second one, clearly, we're gonna have to manage. ⁓ we're gonna have to build some some tools around learning when to stop. ⁓ but I don't think that that joy is Cheap. ⁓ there's nothing short circuity about that. Being the thing that you want to make has always been what we're after. And it just took a real long time and a lot more suffering to get there. And now when you get to make something that much faster, you're still the the and I'm I'm speaking for myself and I think many software and it's and you know, I mean
speaker-1: The making.
speaker-0: It's been 15 years since I've earned my living as a software engineer. Okay. I'm it's this is the the the the part of a developer that never goes away. ⁓ you still see yourself as a developer, even though it's been a long time. ⁓ but I think most of us that's what we're in the game for, right? Because we want to make things. Some people are in the game because they really like crafting code. And I think those people are sad right now. And that's a re that's a true grief. Because that's not gonna be a thing that
speaker-1: That's fair. Yeah.
speaker-0: We get to do as much. but I think most of us just like to make stuff and we get to make stuff faster. Now the short circuiting or the shortcutting, I think we are in a process of discovery right now about how much of that shortcutting can we do. you know, the stuff I build for hobby projects, sometimes I read the code, sometimes I don't. I just want it to work. Sometimes I feel myself not even really wanting to read the open spec design document. You know, that's I'm like, come on, you gotta have some standards here, Tim. Read the markdown. You can do this. But I think how much how aware we have to be of the details, ⁓ we don't know yet. And I suspect that there is some early enthusiasm. that's causing us to say, ⁓ forget it. Just have an agent review the code. It's you you gotta move faster. You can't you can't block on PRs. I I I think that that will probably not work out well. And when there's real money on the table, we'll find that, yeah, we still kind of do need to know something about the code. But that takes months or years to learn that kind of thing as a community.
speaker-1: Yeah, and that's what we're finding with security. So they aren't these ⁓ AI native startups, they are developing really fast and then they want to make some money. They want to sell their product, their agent to the enterprise and and ⁓ sometimes whatever they have written is being classified as malware or blocked and the bigger enterprises are saying, No no no, you just you have kind of written and it kind of works, but the securities posture is really weak. Yeah, it's just You gotta harden it, you gotta make it compliant. And that's when they usually come to Trent and they're like, I don't know what that means, that security bit, but just just make it so that it's not classified as malware, yeah. Just make it so that we can actually sell it and make some money. Right. the ⁓ the question for us then it's more of ⁓ okay, so we'll do a one off. But what have we helped you in terms of understanding ⁓ you know, in terms of thinking about the culture around security and and the answers are nuanced. I mean sometimes you don't have to have a culture around security. Sometimes you just want to get something out there and and delight your customers and make them happy with, I don't know, selling flowers on the internet or whatever people do. And sometimes if you're doing something a bit more critical, then yes, you do need to ⁓ you need do need to build that ⁓ security, maturity model and program within your company and we help you a little bit with that as well. But the answer is nuance, yeah. I mean it's ⁓ no two companies are the same. ⁓ but also going back to what you're saying around filtering noise, one one of the things that's super fascinating right now is that together with all the tools we have given developers and and and ⁓ some people are saying like, you know, we've made everybody ten X. ⁓ it's it's probably more like two X. I think end to end is also more like sixty percent. Like ⁓ it's not it's not even to X, but ⁓ 'cause there is bottlenecks elsewhere, yeah. But that's a different story.
speaker-0: We don't we don't really know what those other bottlenecks
speaker-1: Yeah, we're measuring it. It's ⁓ yeah. Some things are are ten X, some are some are two X. ⁓ what's the Tell t tell me a bit more, like it it feels there are days when I feel like when I re when I remember Kafka, for example, or when I when I go back, there were there were a few kind of key voices in the community there producing content. I mean, you're you're pretty legendary there, right? I mean setting a really high bar for everybody else and and and nowadays it feels like almost like every developer with a with a tool and an idea is just producing content out there and On one hand it's it's really great. ⁓ I I put some more blogs out there with what I do. On the other hand, like how do you deal with all the noise, right? I mean there is ⁓ whenever we're hiring developers and training them in our team How do we find that w what's the what's the way to find that those those influencers, if you will, with that that bring the real value? Like how do you filter through the noise? How do you Yeah? How do you manage that? Well what what's your tips there? I mean I guess we c they they can subscribe to your podcast for sure.
speaker-0: I mean that's the thing. You should definitely end and ⁓ got a you know, substack or you can just go straight to Tim Brooklyn dot com.
speaker-1: That's right, there you go. Take a shortcut there.
speaker-0: That's right. and it's kinda it's ⁓ this is funny. So everybody listening, watching, you know, and I did not coordinate this question at all. But ⁓ I've got a a blog post I'm shipping today. Okay. ⁓ It'll be on LinkedIn, Substack, blah blah blah. ⁓ Timbergling.com indirectly addresses this. There's a part of it. So it's kind of an expansion on my my developer journey framework of of discover, understand, play, build, advocate. ⁓ this is the journey that developers go through when they're adopting a technology. ⁓ there are other DevRel leaders who've got, you know, slightly different spins on that whole thing. It's it's my take. It's it's I'm not the only one who's who's got that. But I think in the in the age of AI, as we like to say, trust becomes a lot more important because the marginal cost of cranking out a unit of content is close to zero. Yeah. Anybody can crap out blog posts. Some people are making tutorial videos with AI avatars. And I I I really think the technology is not there yet. I think that's terrifying. ⁓ in the present day, just with the quality of the the AI avatars. I think that's a super bad move. But there isn't a shortcut to building trust, the thing is. So you asked me what my my tips are. And I don't have tips because to build trust is Well y you have to experience someone as trustworthy. ⁓ saying trust me is usually what a bad guy in an action movie says at some point. You know, it's you can't just tell someone to trust you. That's not a thing. I mean, I guess Kyle Reese said, Come with me if you want to live in Terminator and that was an epic line. And you it was it was a very high stakes moment. ⁓ had to had to force I want to say Linda Hamilton, but that that wasn't the character's name. It had to force her to make a a choice. But Trust is experienced, right? You build trust because you experience someone who's trustworthy. And so ⁓ there isn't a shortcut. You do have to experience a we'll just say an influencer as a trustworthy voice who doesn't just shill for whatever it is they're being told to shill for, ⁓ isn't just saying the hypeest, clickbaitiest thing, but is really trying to help a community of developers along with some kind of frontier in their world. And you know, I look back at the various frontiers I've been a part of, they seem even Kafka seems small in comparison to AI now. but Is that person a trustworthy voice? Are they bringing value, educating, helping make sense of the world? And you just gotta pick the people who you have that experience with. There isn't a shortcut. There isn't an algorithm that's going to tell you. There isn't this one simple trick. ⁓ but it I think it does matter that, you know, you you curate voices that can help you. It's just like in your personal life. You know, you got people that you're close with. You have something you're going through that's a big deal, some big decision. Should I take this job? Should I relocate? Should my family move here? You know, who's close to you? Who's gonna advise you? Who have you experienced as trustworthy? I think in the DevRel world, ⁓ or more broadly, you could say the influencer world, there's that same thing. And you gotta look for those people who are are in it because they actually want to help shepherd a community across some kind of transition.
speaker-1: Interesting because we have this exact same question asked ⁓ in the security space. People say, Well, there's so many startups. What what is the moat? And I have now been through ⁓ I guess I worked in two startups and I've seen like the entire cycle. ⁓ the beginning, the journey, and the end, I suppose. And especially in this area in security, the the moat is are you gonna be there for the long term? and earn the trust? Or are you gonna be there just to do the what I call like the cherry on top, only the cool part? And then and then ⁓ declare it a success and disappear. So in many of the products we've shipped in the past, really ⁓ when when I look back, it's been Yeah, you can't you can't short circuit the trust. It's ⁓ something that compounds over the years, you gotta be there, help the community with like right now we're seeing ⁓ open cloud people ask about I mean some simple questions or some even complicated questions, but if we have some answers we try and help. And they try and help us in return, yeah. And that part a real moat in this era of doing things really fast i is is actually doing things ⁓ for the long term. And just sticking with it and then ⁓ ev even some of the the quote unquote boring things which Some of the enter let's face it, some of the enterprise stuff like in security is pretty boring. Like things like role based access control, right? I mean who wants to do that? ⁓ I don't wanna do it, but the customer wants it, right? You know little
speaker-0: says when I grow up I want to do our back, you know, but but it's a valuable thing that people will exchange money for.
speaker-1: Yeah, they will. They will. And we've seen this over and over again. Or or or models that belong to the customer with the data and the learnings belonging to them so that it doesn't go to like some of the bigger companies, right? Yeah. ⁓ all of that trust is trust and all of that can be earned over time. Right. So yeah, it's interesting. Let me let me put you on the spot there. We're we're a startup year one seed stage. Give me some advice. When when is the right time to hire the first DevRel person? Or what what are the conditions under which a DevRel person for lack of a better name if you have come up with a better name, let me know by the way. I will just say DevRel. What what are the conditions that they would be happy like in an early stage startup?
speaker-0: That that first hire is usually what I'd call a developer advocate. So it's the content creator, speaker kind of person.
speaker-1: Get the right name wrong, right? It just shows my ignorance. It's okay.
speaker-0: That's right. No, no, no. A lot of people say, when should I hire a DevRel? And it's pet peevamin. I'm like, I it's a DevRel leader. It's okay. It's all right. But a developer advocate. And that person might not be, you know, three years from now, when you're scaling your sales motion and you've got 300 people, that might not be the same person who leads the team, but they're a content creator, they're deeply technical, they're a good communicator.
speaker-1: There we go, I studied too.
speaker-0: ⁓ they'll travel some, you know. So that's the profile of the first hire. Usually that person should come from your existing community. That's a that's a good place. You gotta be careful if you're hiring from a customer, you know, make sure you have all the right conversations. But somebody who's already in love with your product, you you've got those fans out there who is in that advocate stage of their own adoption. ⁓ they make a good, passionate developer advocate. And ⁓ It we're we're also assuming, like you, ⁓ certainly like Trent, that there's a significant developer-facing surface area. So if you're gonna do it at the at the kind of A-round stage of life, ⁓ or C ev even seed, seed is is pretty early. Usually founders are doing it then, but at the A-round stage of life, you have to be sure that that developer adoption is key in your go-to-market, right? Like you're not really gonna be able to sell things. If developers customers are bought in. You have to know that. ⁓ and if you're an application, you know, early days of Salesforce, no, they don't need developer advocates. I mean, they got them now because they got APIs and they're a huge company and everything. But it it has to be that it has to be the case that even if developers don't write the check, they need to be believers, right? So it's usually an A-round kind of thing.
speaker-1: Yeah, but okay.
speaker-0: You know, in terms of a head count, 10, 20, 30, when you're in that size, you can you can start to think about a developer advocate. There's there's a a a delicate part of this job where nobody wakes up in the morning thinking about Trent. But lots of people wake up in the morning thinking about agents. And part of the mission, and I guess I'm just this is now just DevRel coaching for for Trent, and everybody gets to listen in.
speaker-1: Yeah.
speaker-0: Which is great. This is a fun conversation. Yeah. ⁓ part of the mission is when we say agent, so many people think, well, clawed code or whatever, you know, my my harness. Or maybe ⁓ open claw, you know. ⁓ they're they're thinking that kind of agent that's running on my laptop or the Mac Mini that I bought to to run things. ⁓ the agents I think you're talking about. are software written in the enterprise that are doing things with enterprise data. And this, you know, this is a it's a very different thing. It's agents that developers are creating. And so part of what you have to do is now create a differentiation between the common conception of my coding agent and agents that we're building. You could see this play out in debates online like MCP is stupid, all we need is CLIs. Yep. ⁓ now that is a statement that somebody makes when their entire experience of an agent is basically clawed code. ⁓ in the enterprise, it's not like that. So your developer advocate, number one, has to do that. Number two, because nobody wakes up in the morning worried about Trent, you have to just you have to r think about what are the things that people wake up in the morning worried about. And and this is developers now, not not the maybe executives that you're be selling to, but in terms of appealing to developers.
speaker-1: Yeah, yeah, yeah.
speaker-0: What are they worried about? And how's that connected to agent security? What part of that total addressable developer market really does have an anxiety about agent security? Maybe that's not the thing that they Googled or whatever or asked Claude about, ⁓ but there is a thing that they're thinking about and the content that this developer advocate creates, the talks that he or she gives, need to address kind of those organic concerns with Trent based solutions. And, you know, i they're not selling. It's it's just that they are there to make Trent famous ⁓ in a way that's valuable to that developer in the audience. So I think that's that's the move for that early stage DA there.
speaker-1: I love that. That's ⁓ that's a lot to think about.
speaker-0: So when you hire that person, ⁓ we just play this back.
speaker-1: I love that.
speaker-0: All right. You know, well, I think that's a great place to land the plane.
speaker-1: Awesome. Thank you.
speaker-0: My guest. We'll talk soon.
speaker-1: Take care. Thank you. Real pleasure.
