WEBVTT NOTE Sentence-level transcript of https://www.youtube.com/watch?v=RVxym6mmIns NOTE One cue per sentence. Cue ids are the line anchors on /transcripts/RVxym6mmIns.html. A cue ends where the next begins, or 2 s after its last word. s1 00:00:01.309 --> 00:00:03.309 [music] s2 00:00:12.640 --> 00:00:13.760 It's nice to be here. s3 00:00:13.760 --> 00:00:14.480 I appreciate you all. s4 00:00:14.480 --> 00:00:15.280 My name is Gia. s5 00:00:15.280 --> 00:00:17.400 I'm a deployed engineering lead at Cognition. s6 00:00:17.400 --> 00:00:26.640 And today, hopefully, what you'll take away from this is that how we deploy Devin in the field is very much a function of how we view deployed engineering at Cognition. s7 00:00:26.640 --> 00:00:31.000 So, how the four deployed motion makes AI engineering actually real. s8 00:00:31.000 --> 00:00:36.240 Before I start, how many people like have heard of Devin or like know of Devin? s9 00:00:36.240 --> 00:00:36.600 Oh, cool. s10 00:00:36.600 --> 00:00:38.120 And I'm not talking about like the Devin of today. s11 00:00:38.120 --> 00:00:43.240 Like, I'm talking about the Devin back in 2024 when we first released and it was like, "Oh, SweepBench 13%. s12 00:00:43.240 --> 00:00:44.720 We're so We're so back." s13 00:00:44.720 --> 00:00:46.640 And as engineers, we were like, "We're so cooked." s14 00:00:46.640 --> 00:00:50.600 But, I mean, after a week, everyone's like, "Oh, this is actually like not that useful." s15 00:00:50.600 --> 00:00:54.440 Um "I would only use this if I was desperate and out of ideas." s16 00:00:54.440 --> 00:00:55.880 That's 2024. s17 00:00:55.880 --> 00:01:00.520 Uh and let it be said that we have a sense of humor because we took this and we ran with it. s18 00:01:00.520 --> 00:01:03.200 I'm sure you've seen all these ads around SF. s19 00:01:03.200 --> 00:01:05.080 We're actually good now. s20 00:01:05.080 --> 00:01:13.960 So, the reason why we're good is I'll talk a little bit about the product surface area a little bit just to give you folks a little bit of context for who s21 00:01:13.960 --> 00:01:18.080 might not have used Devin before, uh who might not have exposure to something like Cognition. s22 00:01:18.080 --> 00:01:21.480 So, if you've used Flood Code, we also expose a CLI. s23 00:01:21.480 --> 00:01:26.920 If you've used something like, you know, Cursor, Windsurf, we also expose an interface such as an IDE. s24 00:01:26.920 --> 00:01:31.160 Uh actually, how many people know of Windsurf or have used Windsurf in the past? s25 00:01:31.160 --> 00:01:33.120 Sweet. s26 00:01:33.120 --> 00:01:36.320 So, I come over from the Windsurf side after the Windsurf acquisition. s27 00:01:36.320 --> 00:01:38.160 Um great times. s28 00:01:38.160 --> 00:01:44.320 And then, what we're actually known for, specifically, is for Devin Cloud or the Devin Cloud agent. s29 00:01:44.320 --> 00:01:49.920 And I'm not going to bore you to death talking about like all the components and features and everything that comprise of the actual product. s30 00:01:49.920 --> 00:01:51.280 I'm not here to sell you on that. s31 00:01:51.280 --> 00:01:59.920 What I am here to sell you on is we are one of the premier software engineering functions across the enterprise, and we're actually able to deliver impact on a global scale. s32 00:01:59.920 --> 00:02:01.680 What do I mean by that? s33 00:02:01.680 --> 00:02:04.479 We can take a pause and take a look at this figure. s34 00:02:04.479 --> 00:02:14.840 So, internally at Cognition, over the last 6 months, for better or worse, we might have been behind on hiring, but using our agent, we were able to ship almost an order of magnitude more s35 00:02:14.840 --> 00:02:18.480 good quality robust PRs across the organization. s36 00:02:18.480 --> 00:02:24.160 So, it's a step function increase in the amount of engineering leverage that we can have by deploying our own agent. s37 00:02:24.160 --> 00:02:25.240 You don't have to take our word for it. s38 00:02:25.240 --> 00:02:41.880 If we take a look If we can take a look at the specifics of how we're actually being consumed, how we're being utilized across the enterprise, it's a parabolic growth of how companies are adopting our agent, deploying our agent, and using it in multiple different use cases and multiple different scenarios. s39 00:02:41.880 --> 00:02:42.920 So, what does it mean, right? s40 00:02:42.920 --> 00:02:44.600 Like, how does this actually happen? s41 00:02:44.600 --> 00:02:48.000 Well, it can only happen with the forward-deployed engineers at Cognition. s42 00:02:48.000 --> 00:02:51.440 And I'm going to frame up the problem from like a couple of like buckets, right? s43 00:02:51.440 --> 00:02:53.680 So, there's two circles in front of you on the screen. s44 00:02:53.680 --> 00:02:57.160 One of them can represent the domain of a product, right? s45 00:02:57.160 --> 00:03:02.640 As a business, as a software engineering organization, obviously, you have a product. s46 00:03:02.640 --> 00:03:10.560 You obviously also, on the other side, on the left-hand side or right-hand side for you guys, you specifically have like a bucket of problems that you're looking to solve, right? s47 00:03:10.560 --> 00:03:18.320 You have a product, you have problems that you're trying to solve, and the intersection of these two, or whatever you would call it, is the product-market fit. s48 00:03:18.320 --> 00:03:18.560 Right? s49 00:03:18.560 --> 00:03:25.080 Hopefully, you have a pretty good overlap in the sense that whatever it is that your company does, you can actually bring value to customers. s50 00:03:25.080 --> 00:03:30.880 And hopefully, whatever problems the customer has, you can solve with your company's stuff. s51 00:03:31.200 --> 00:03:42.560 So, the forward-deployed motion at Cognition essentially aims to maximize the overlap between the products that we typically build and the problems that we're experiencing across the enterprise. s52 00:03:42.560 --> 00:03:43.560 So, what does that mean, right? s53 00:03:43.560 --> 00:03:52.120 The first fundamental concept that I would like to convey is that forward-deployed engineers at Cog deeply understand the problem space at hand. s54 00:03:52.120 --> 00:03:53.000 And specifically, right? s55 00:03:53.000 --> 00:04:02.520 Like if we think of the problem of software engineering, and I'm just going to like mask the features at the bottom, we don't really care about those, but if we think about when you go ahead to take some sort of codebase, s56 00:04:02.520 --> 00:04:10.280 some sort of implementation, and you need to like build features, you need to maintain that software, uh you need to like review, deploy, maintain that software. s57 00:04:10.280 --> 00:04:15.280 All of these steps, all of these functions have a lot of business value behind them, right? s58 00:04:15.280 --> 00:04:23.280 You can only do like it would be great if we could build from zero to one and just like prompt stuff and not worry about like legacy code, but that's not the reality of the situation. s59 00:04:23.280 --> 00:04:32.600 It would be great if our product engineers or our product managers could just take user stories and say like these are the things that we need to build in order to get value and revenue. s60 00:04:32.600 --> 00:04:34.400 And then we come to coding. s61 00:04:34.400 --> 00:04:38.800 Coding itself, at least from our perspective, is a mostly solved problem, right? s62 00:04:38.800 --> 00:04:47.040 These models are so good now that like with any type of context, with enough context engineering, you can get the code blocks that you really care about. s63 00:04:47.040 --> 00:04:51.000 But the problem isn't like writing code faster, that's usually only 20% of the problem. s64 00:04:51.000 --> 00:04:53.520 The problem really just becomes like how do you test this code? s65 00:04:53.520 --> 00:04:55.520 How do you review and deploy this code? s66 00:04:55.520 --> 00:04:57.840 And how do you maintain this code across the enterprise? s67 00:04:57.840 --> 00:05:00.080 So, that's the premise of the problem. s68 00:05:00.080 --> 00:05:07.560 Now, I will predicate that by saying that like we also have the solution, I'm not going to bore you to death about talking to you about the solution, but for deployed engineers s69 00:05:07.560 --> 00:05:11.960 at Cognition, we map Devin's capabilities specifically to the customer problem. s70 00:05:11.960 --> 00:05:20.160 So, if the software development life cycle is extremely complex, deploying the agents for with like no specific direction, you're straight up just token maxing. s71 00:05:20.160 --> 00:05:20.240 Right? s72 00:05:20.240 --> 00:05:25.720 Like you were wasting tokens, you were burning you were burning spend, you're not getting any tangible outcomes. s73 00:05:25.720 --> 00:05:30.880 So, we try to identify, when we partner with customers, when we take meetings, and for example, right? s74 00:05:30.880 --> 00:05:36.760 Like my day might look like four or five hours of customer calls, and then four or five hours of like actual hands-on keyboard work. s75 00:05:36.760 --> 00:05:44.160 Those four or five hours of calls actually allow us to understand very deeply what strategic initiatives are the highest leverage for the business. s76 00:05:44.160 --> 00:05:44.880 Right? s77 00:05:44.880 --> 00:05:46.200 Once Once identified that, right? s78 00:05:46.200 --> 00:05:52.760 How can we automate ourselves out of the job in the sense that we set up the agent in a way that it runs all of the automations for us, right? s79 00:05:52.760 --> 00:05:55.040 We don't have to be there manually triggering the agents. s80 00:05:55.040 --> 00:05:58.920 It can respond to like specific alerts, specific events. s81 00:05:58.920 --> 00:06:04.920 But most importantly, as forward deployed engineer, how do you measure the return on investment? s82 00:06:05.240 --> 00:06:06.520 And it's very ambiguous. s83 00:06:06.520 --> 00:06:12.400 And it's an unsolved problem because the company that will solve this will be um you know, $5 trillion market cap. s84 00:06:12.400 --> 00:06:17.360 So, specifically, our forward deployed engineers will embed in the customers ecosystems, right? s85 00:06:17.360 --> 00:06:20.280 We take a look at, you know, the backlog of stuff that needs to be built. s86 00:06:20.280 --> 00:06:22.600 We take a look at the remediations that need to be done. s87 00:06:22.600 --> 00:06:29.280 We take a look at all of like the delayed code that never ships or the test that nobody writes uh or the automatic triage of specific alerts. s88 00:06:29.280 --> 00:06:34.080 And we map our product capabilities into those problems. s89 00:06:35.040 --> 00:06:45.480 That being said, if we all do our job and we solve the customers problems 100% and the customer is very happy, that is only half of the equation, right? s90 00:06:45.480 --> 00:06:50.480 Not only do we have to solve the customer's problem, we also need to solve for our product. s91 00:06:50.480 --> 00:06:51.600 What do I mean by that, right? s92 00:06:51.600 --> 00:06:56.520 If we are taking it union of like the problems that the customers have and the products that we are building, right? s93 00:06:56.520 --> 00:06:59.600 Solving the problem only shifts like part of the Venn diagram. s94 00:06:59.600 --> 00:07:08.800 But in order to get that true feedback loop where we unify like the maximal overlap between what we're doing and what the customers need, that is forward deployed engineering at Cockroach Labs. s95 00:07:08.800 --> 00:07:16.640 So, the second part of this that I want to emphasize is that at our company, we map the customer problems back to the capabilities at hand. s96 00:07:16.640 --> 00:07:18.200 Now, how do we do that, right? s97 00:07:18.200 --> 00:07:24.000 A lot of engineering challenges come in similar shapes um from the field, right? s98 00:07:24.000 --> 00:07:28.480 We have the highest fidelity evaluation set that comes back from our customers, right? s99 00:07:28.480 --> 00:07:30.120 We are in the field every single day. s100 00:07:30.120 --> 00:07:31.320 We are hearing about the problems. s101 00:07:31.320 --> 00:07:33.720 We are hearing about whatever the customers are doing. s102 00:07:33.720 --> 00:07:38.240 And we have to take that context and bring it back to product in a sensible way. s103 00:07:38.240 --> 00:07:42.720 So, what are the ways in which these enterprise challenges, you know, manifest? s104 00:07:42.720 --> 00:07:47.520 are they common across the entire enterprise or are they unique to a specific user? s105 00:07:47.520 --> 00:07:54.080 Should like workarounds or like hacks or bugs in in in what we're building become features, right? s106 00:07:54.080 --> 00:07:59.240 Because ultimately what we want to do as a company is we want to de-risk our road map. s107 00:07:59.240 --> 00:08:08.200 At the end of the day, it would be great if like I as an engineer knew exactly what to build to get Y percentage of revenue from particular customer. s108 00:08:08.200 --> 00:08:14.600 And that's exactly what the problem is that we're trying to solve for because we are ultimately at the end of the day the heralds of the change, right? s109 00:08:14.600 --> 00:08:16.520 We are the bridge between products. s110 00:08:16.520 --> 00:08:24.360 We are the bridge between problems and the feedback is actually like half of the loop that makes the next deployment better than the previous deployment. s111 00:08:24.360 --> 00:08:34.880 So, if we think about the T-shape or personas of the folks that we hire, and for a deployed engineer, it's just so it's so flexible in terms of how you actually define it. s112 00:08:34.880 --> 00:08:36.719 Like, are you a sales engineer? s113 00:08:36.719 --> 00:08:38.599 Are you a solutions architect? s114 00:08:38.599 --> 00:08:39.800 What are you, right? s115 00:08:39.800 --> 00:08:43.760 So, if you think about all of the skills that FDEs typically are expected to have, right? s116 00:08:43.760 --> 00:08:45.240 You probably want to go wide. s117 00:08:45.240 --> 00:08:51.440 You probably want to have, you know, good people skill, like business skill, good process, customer skill, or even technology, right? s118 00:08:51.440 --> 00:08:55.839 In order to be deployed in the space, you need to know like what whatever the tech is. s119 00:08:55.839 --> 00:08:59.680 So, we also look for very deep spikes across people, right? s120 00:08:59.680 --> 00:09:10.080 Folks at Cognition deployed engineers at Cognition, we will hire them from like product management backgrounds if they have a really good sense of like how products are supposed to fit into each other, right? s121 00:09:10.080 --> 00:09:16.120 Because if the cost of software engineering is going to zero, you actually need to know how to like design a product that makes sense. s122 00:09:16.120 --> 00:09:17.480 Cuz you can just prompt it. s123 00:09:17.480 --> 00:09:25.360 But we also hire folks that are like founders, software engineers, but specifically like very spiky in the technology domains, right? s124 00:09:25.360 --> 00:09:33.920 It's fine if you don't have like the strongest business sense, that can be learned, but it's also very hard to teach like technicality and being the expert in the room while you're on the job. s125 00:09:33.920 --> 00:09:37.880 So, there's a couple of personas that we specifically hire for. s126 00:09:37.880 --> 00:09:42.120 Good customer engineers or deployed engineers do everything, right? s127 00:09:42.120 --> 00:09:47.040 Like they can map the product back to road map, like they can solve the customer's problems. s128 00:09:47.040 --> 00:09:52.560 Great customer engineers are able to actually have that relentless curiosity for why. s129 00:09:52.560 --> 00:09:57.560 So, at Cognition, we always ask ourselves, "Why are we solving this problem? s130 00:09:57.560 --> 00:10:00.680 Does this problem matter to the to the business as a whole? s131 00:10:00.680 --> 00:10:05.560 And can I communicate this back to the road map in a way that like improves the problem for everybody else?" s132 00:10:05.560 --> 00:10:13.160 But we also are The second mantra that we subscribe to is that you have to be relentlessly tied in to the customer, right? s133 00:10:13.160 --> 00:10:15.080 They are our lifeblood at the end of the day. s134 00:10:15.080 --> 00:10:21.360 Making them successful is the only way that you can survive as a business and become the obvious choice for an enterprise partnership. s135 00:10:21.360 --> 00:10:26.600 So, these are the two mantras that we specifically subscribe to as uh deployed engineers at Cognition. s136 00:10:26.600 --> 00:10:33.200 So, previously, um the first approach to deployed engineering was just, you know, token maxing, right? s137 00:10:33.200 --> 00:10:41.400 Uh the next era that I'll talk about is intelligent orchestration, but with like outcomes that you can actually measure, and I'll give you guys some examples. s138 00:10:41.400 --> 00:10:53.080 So, previously, like a year, maybe a year and a half, two years ago, uh the target or KPI for whatever deployed engineers were trying to do is maximize token usage, right? s139 00:10:53.080 --> 00:10:54.880 It was It was like the perfect time. s140 00:10:54.880 --> 00:10:56.240 Didn't have to worry about budgets. s141 00:10:56.240 --> 00:10:57.440 Everything was subsidized. s142 00:10:57.440 --> 00:10:59.320 You could just like run anything you wanted. s143 00:10:59.320 --> 00:11:04.480 But now, the problem has really shifted into the delivery space, right? s144 00:11:04.480 --> 00:11:13.640 A lot of organizations that we work with, some of the largest and most regulated enterprises in the world, they really care about, "Are we getting true value out of this solution, s145 00:11:13.640 --> 00:11:17.200 or are we just burning tokens for no reason, right?" s146 00:11:17.200 --> 00:11:21.400 And that is one core differentiator that I need to call out between us and some of the other platforms. s147 00:11:21.400 --> 00:11:23.760 You can make engineers like 10x faster. s148 00:11:23.760 --> 00:11:24.320 That's fine. s149 00:11:24.320 --> 00:11:25.480 That's still valuable. s150 00:11:25.480 --> 00:11:33.280 But can you make an organization 10x faster, including every single person that might be technical or non-technical uh across the company? s151 00:11:33.280 --> 00:11:36.280 That's when you unlock the true value of being the partnership. s152 00:11:36.280 --> 00:11:42.160 And that's why like single point tools that are just like CLIs or just IDEs, they fail to do that. s153 00:11:42.160 --> 00:11:48.600 So, let me just give you some proof points of how we've operated across the enterprise. s154 00:11:49.960 --> 00:12:00.280 So, at Cognition, um when we run the agent and the agent has like a specific trace or trajectory or like the agent does something, we call that a session. s155 00:12:00.280 --> 00:12:01.440 A session itself, right? s156 00:12:01.440 --> 00:12:10.800 We have metrics that allow you to derive how many engineering hours you can actually generate and how much how many engineering hours are actually productive that users are running. s157 00:12:10.800 --> 00:12:10.960 Right? s158 00:12:10.960 --> 00:12:16.320 So, one of these examples is a case study where we embedded ourselves within a customer for 3 months. s159 00:12:16.320 --> 00:12:17.560 We brought them on board. s160 00:12:17.560 --> 00:12:23.720 And functionally, over the course of those 3 months, we delivered about 150% like plus headcount. s161 00:12:23.720 --> 00:12:30.520 So, if you thought about like a project that you're trying to ship or something that you're trying to develop or a migration that you're trying to go through, imagine having s162 00:12:30.520 --> 00:12:34.960 150 extra coworkers doing that with you by your side. s163 00:12:35.400 --> 00:12:38.040 You might just say, "Hey, this actually just kind of looks like token maxing, right? s164 00:12:38.040 --> 00:12:41.600 Like you're just giving me a metric that says it's just, you know, engineering hours. s165 00:12:41.600 --> 00:12:43.200 You're like running a bunch of different sessions. s166 00:12:43.200 --> 00:12:48.240 Like, how do we know that these sessions are true, meaningful, and valuable?" s167 00:12:48.240 --> 00:12:55.839 So, the second part of that is, okay, we can think about how we've reduced timelines for delivery projects on an order of magnitude. s168 00:12:55.839 --> 00:12:59.000 So, about like 82% reduction across like delivery. s169 00:12:59.000 --> 00:13:06.240 So, if you subscribe to the agile deliver agile development methodology, obviously like you have tickets, you have sprints, like you have things that need to be built. s170 00:13:06.240 --> 00:13:12.480 If you look at every single metric that you measure before you bring in Devin and after you bring in Devin, you can take a look at that. s171 00:13:12.480 --> 00:13:17.520 We can compress this timeline by a factor of like 82%. s172 00:13:17.520 --> 00:13:28.080 So, across the board, whenever we get developed, whenever we get deployed, and fully activated within the customer environment, not only do we deliver a massive scale in terms of like engineering capacity, s173 00:13:28.080 --> 00:13:33.200 but we also reduce the time to value in terms of bringing things to market. s174 00:13:33.440 --> 00:13:36.880 Now, the third part of that is, hey, but I actually really care about the numbers, right? s175 00:13:36.880 --> 00:13:39.720 I actually really want to see how many PRs are you actually shipping? s176 00:13:39.720 --> 00:13:41.000 Like, is this meaningful? s177 00:13:41.000 --> 00:13:42.360 Does this actually make sense? s178 00:13:42.360 --> 00:13:51.640 So, if you think about dissecting the numbers a little like one dimension further, and you want to just look at like the raw PRs that people are ripping across the enterprise, s179 00:13:51.640 --> 00:14:00.120 we deliver almost double the amount of PRs that engineers were able to do with single-point tools and before you brought in an agent harness like Devin. s180 00:14:00.120 --> 00:14:09.800 So, there's three proof points of anonymized case studies in which we are able to deliver value at scale and across like various different problem domains. s181 00:14:10.960 --> 00:14:14.480 What I'll say is these aren't like, you know, private case studies. s182 00:14:14.480 --> 00:14:16.840 We have a bunch of different public case studies as well. s183 00:14:16.840 --> 00:14:19.680 So, we partner with companies like Nubank, right? s184 00:14:19.680 --> 00:14:25.120 If you folks have ever gone to Latin America, you can understand that, you know, the there's a lot of developers there. s185 00:14:25.120 --> 00:14:27.280 There's a lot of projects that are tangentially related. s186 00:14:27.280 --> 00:14:30.160 So, specifically, like we can say that there was an ETL migration. s187 00:14:30.160 --> 00:14:32.400 They had 50 engineers staffing this migration. s188 00:14:32.400 --> 00:14:38.040 We were able to deliver this within, um, I think like 1/3 of the timeline. s189 00:14:38.040 --> 00:14:40.839 Just with Devin autonomously. s190 00:14:40.920 --> 00:14:42.080 We have another bank, right? s191 00:14:42.080 --> 00:14:45.920 We have another use case where we work with one of the largest banks in Latin America. s192 00:14:45.920 --> 00:14:49.040 They were trying to migrate like the tax identification system. s193 00:14:49.040 --> 00:14:50.800 I know, like rocket science, right? s194 00:14:50.800 --> 00:14:57.000 Um, but the idea is that we were able to deliver this with half of the amount of effort actually required. s195 00:14:57.000 --> 00:15:05.760 So, if you think about like legacy languages like COBOL, if you think about things like JCLs, you think about things that like people don't learn anymore just because it's like not fun and not interesting, s196 00:15:05.760 --> 00:15:13.480 we're able to operate across some of the most complicated codebases in the world and deliver results that actually matter. s197 00:15:13.520 --> 00:15:23.480 And last but not least, obviously like if we think about the built card, um, specifically, we're able to actually merge like an order of magnitude more, um, in terms of like PR acceptance rate. s198 00:15:23.480 --> 00:15:27.760 We deliver like 10x per sub like worth of engineering talent like every single week. s199 00:15:27.760 --> 00:15:32.880 And then we're actually able to, you know, generate the weekly output of like over 10 engineers at the organization. s200 00:15:32.880 --> 00:15:34.440 Built has great engineers, by the way, right? s201 00:15:34.440 --> 00:15:36.040 These guys are so cracked. s202 00:15:36.040 --> 00:15:41.880 So, if you take one of these engineers and multiply them by 10, you just imagine the amount of returns. s203 00:15:41.880 --> 00:15:49.160 So, what I'll say is I'll I'll probably like round off this talk by just saying that at Cognition, we don't just, you know, embed ourselves in the customers. s204 00:15:49.160 --> 00:15:53.320 We don't just, you know, propagate feedback back to everybody else. s205 00:15:53.320 --> 00:16:00.800 But, the core values of the company are things and principles that we subscribe to not internally to the company, but external to the company as well, right? s206 00:16:00.800 --> 00:16:02.760 It's really fun being on the winning team. s207 00:16:02.760 --> 00:16:09.960 It's really fun when you come into an organization and say, "We can actually deliver so much cool stuff and like make people our champions, right? s208 00:16:09.960 --> 00:16:16.320 Whoever deploys Devin within the organization, they can show results that are essentially unmatched across the board." s209 00:16:16.320 --> 00:16:17.680 And we go for it all, right? s210 00:16:17.680 --> 00:16:19.080 We leave nothing on the table. s211 00:16:19.080 --> 00:16:22.511 We've deployed somebody in Brazil for like 10 months. s212 00:16:22.511 --> 00:16:23.821 [laughter] s213 00:16:23.821 --> 00:16:23.960 [snorts] s214 00:16:23.960 --> 00:16:27.040 To to live next to one of the customers to just make them successful. s215 00:16:27.040 --> 00:16:29.080 So, we're down for the mission. s216 00:16:29.080 --> 00:16:30.800 And it's it's more about like correctness, right? s217 00:16:30.800 --> 00:16:37.880 Like if if there are engineering practices that we want to fix, if there are things that we want to flag and raise, like these are all things that we take back to product s218 00:16:37.880 --> 00:16:39.720 and there's no ego involved. s219 00:16:39.720 --> 00:16:41.800 At the end of the day, we are all in the same boat. s220 00:16:41.800 --> 00:16:45.040 We're on the same mission and we're just shipping. s221 00:16:45.040 --> 00:16:46.360 And everybody essentially is go-to-market. s222 00:16:46.360 --> 00:16:50.440 I know forward deployed engineering is kind of like this fuzzy thing where it's like, "Am I part of sales? s223 00:16:50.440 --> 00:16:51.280 Am I part of post-sales? s224 00:16:51.280 --> 00:16:53.440 Like what do I actually do as an FDE?" s225 00:16:53.440 --> 00:16:59.280 But, everybody is go-to-market because the target is to make the customer successful at all costs. s226 00:16:59.280 --> 00:17:03.160 And at the end of the day, we just do things because every second counts. s227 00:17:03.160 --> 00:17:15.319 So, if you're interested in, you know, forward deployed engineering at Cognition, being the intersection between some of the hardest problems in this world, being part of like all of the software disruption at scale, and then being on the other side s228 00:17:15.319 --> 00:17:18.520 of these problems, we should talk. s229 00:17:18.520 --> 00:17:20.680 Thank you.