WEBVTT NOTE Sentence-level transcript of https://www.youtube.com/watch?v=1OMHGsUZiqA NOTE One cue per sentence. Cue ids are the line anchors on /transcripts/1OMHGsUZiqA.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.639 --> 00:00:18.560 It's kind of an emotional thing to hear uh series of folks who've kind of been talking about how Palenter used to do things. s3 00:00:18.560 --> 00:00:33.920 Um it's funny in the olden days and this what this talk will be about is largely uh Palin's focus of FTE became a go-to market strategy but it wasn't that in the beginning how we were figuring out how to build foundry s4 00:00:33.920 --> 00:00:44.879 was through the lens of a product strategy and so my talk is going to be how we used FDE as a product strategy in 2013 to make the data platform that enabled Palunteer s5 00:00:44.879 --> 00:00:52.480 to then become the thing that Kevin Nat and all these folks were able to build on and it ultimately comes from like the background of something pretty simple. s6 00:00:52.480 --> 00:01:02.879 So my background is uh I started my career at Palanteer as a software engineer um really focused on horizontally scalable and storage solutions at a high level. s7 00:01:02.879 --> 00:01:07.840 Uh when we say forward deployed um I forward deployed to places like Iraq and Afghanistan. s8 00:01:07.840 --> 00:01:08.880 That's me in Bram. s9 00:01:08.880 --> 00:01:10.240 It's no longer there anymore. s10 00:01:10.240 --> 00:01:19.840 Uh but the idea was how do we take software and build it in the most critical environments to make it actually work for people that needed it the most. s11 00:01:19.840 --> 00:01:24.400 So forward deployed is actually a military term and we took it very seriously. s12 00:01:24.400 --> 00:01:34.560 Um my claim to fame from Palanteer is I built something called project frontline which was the rotation program that took our software engineers and made them forward deploy engineers. s13 00:01:34.560 --> 00:01:45.280 So the folks that you see at OpenAI, Anthropic, XAI, a lot of the FDs, about 350 of them went through a training program for how we got them to understand s14 00:01:45.280 --> 00:01:49.520 what we needed out of forward deployed product focused individuals. s15 00:01:49.520 --> 00:01:52.320 Uh built the same program at Citadel afterwards. s16 00:01:52.320 --> 00:01:59.040 So across the hedge fund, how do we build the right data products and software products to help portfolio managers generate alpha? s17 00:01:59.040 --> 00:02:03.920 Um this is a quote from the guy who named uh forward deploy engineering at Palanteer. s18 00:02:03.920 --> 00:02:15.040 It's from a couple days ago and um Sham is the CTO of Palunteer right now and I think this captures the entire essence of where my difficulty came from in the last talk which is s19 00:02:15.040 --> 00:02:25.040 the first fundamental truth of FTE is that this is not a role this is a product strategy how we discover the things to build are through the lens of forward deploy engineering. s20 00:02:25.040 --> 00:02:35.599 So looking at market caps of companies for how do we actually evaluate what contract size this is that wasn't how it actually happened but the core tenant and the core insight was s21 00:02:35.599 --> 00:02:44.879 an FTE is judged by their ability to be an extension of the product team to identify areas of opportunity and generalize product solutions out of it. s22 00:02:44.879 --> 00:02:54.239 And so this is the story of how we actually made project Frontline at Palunteer and what I'm using to build this function out at Kepler along with Susanna here is one of our founding engineers. s23 00:02:54.239 --> 00:02:59.360 Um back in the days, Palenter was first trying to get into big data. s24 00:02:59.360 --> 00:03:04.640 So around 2013, uh we had this idea that we wanted to store transaction information. s25 00:03:04.640 --> 00:03:08.239 And the product that came out of that was something called Phoenix. s26 00:03:08.239 --> 00:03:10.480 Phoenix was built totally in isolation. s27 00:03:10.480 --> 00:03:11.760 We didn't talk to customers. s28 00:03:11.760 --> 00:03:15.360 We didn't understand our financial banks or any anything else. s29 00:03:15.360 --> 00:03:24.879 What we did is we designed a system in perfect isolation that worked perfectly under certain circumstances and crashed and burned when we hit actual real data. s30 00:03:24.879 --> 00:03:26.239 And the situation was simple. s31 00:03:26.239 --> 00:03:33.680 We had a large scale financial customer and the idea was we're going to store your information in bucketed key spaces. s32 00:03:33.680 --> 00:03:37.280 Uh this is going to enable easy rolloff and easy retention. s33 00:03:37.280 --> 00:03:44.159 Now what we hit fairly quickly is a lot of banks and financial institutions have data that's not perfect. s34 00:03:44.159 --> 00:03:50.319 So when we hit a blank data value, it defaulted to the epoch January 1st, 1970. s35 00:03:50.319 --> 00:04:03.680 Our retention strategy made it such that what we wanted to do is actually take each 10-minute increment between January 1st, 1970 and 2013 and spin up a time bucketed window. s36 00:04:03.680 --> 00:04:16.959 The problem is Cassandra requires 5 megabytes per file handle, which means with the 2.3 million key spaces we generated to start up our server would require 14 terabytes of RAM and we were dead on arrival. s37 00:04:16.959 --> 00:04:18.479 There was no one else we could call. s38 00:04:18.479 --> 00:04:21.359 We were the only individuals and only institutions in the room. s39 00:04:21.359 --> 00:04:23.360 And we realized something fairly simple. s40 00:04:23.360 --> 00:04:29.280 The gap wasn't the fact that we had not looked for information about how customers use our product. s41 00:04:29.280 --> 00:04:37.360 It came from the ownership about co-building a piece of software without being directly embedded with a customer. s42 00:04:37.360 --> 00:04:41.040 The whole purpose of this talk is to convince you of one thing. s43 00:04:41.040 --> 00:04:44.240 Forward deployed engineering is a product strategy. s44 00:04:44.240 --> 00:04:48.560 Being an FD is an extension of the product function, not the go to market function. s45 00:04:48.560 --> 00:04:54.240 So what I'm going to do is walk through four things and four real stories that I learned at Palanteer and other places. s46 00:04:54.240 --> 00:04:59.919 what we learned from those experiences and how they informed building FTE at every other institution. s47 00:04:59.919 --> 00:05:03.040 The first starts from something fairly simple. s48 00:05:03.040 --> 00:05:08.000 Palenter was onboarding uh a large-scale dispatching and shipping company. s49 00:05:08.000 --> 00:05:13.600 We sat down with the VP of operations who generated a 47page requirements doc. s50 00:05:13.600 --> 00:05:23.039 What they wanted is a custom dashboard, 14 metrics, drill down alerts, this massive BI tool, a dev project that was estimated at three months. s51 00:05:23.039 --> 00:05:28.000 The kind of hilarious thing that happened in this process is we took them at face value. s52 00:05:28.000 --> 00:05:39.759 We spent four months scoping this engagement trying to understand exactly what this customer wanted before one of us actually showed up on site just by virtue of the fact that their family happened to live there s53 00:05:39.759 --> 00:05:43.600 and asked what's the first thing you do with this information Monday morning. s54 00:05:43.600 --> 00:05:52.720 The dispatcher said, "I check if trucks are trucks are late and then I call the dispatcher to ship a new inventory or new institution." s55 00:05:52.720 --> 00:05:58.479 The whole thing could have been simplified to a trivial Slack alert, which is what we ended up building. s56 00:05:58.479 --> 00:06:02.240 In 4 hours, we were able to solve this problem cradle to grave. s57 00:06:02.240 --> 00:06:08.560 The first move that we learned from forward deployed perspective is detect the real problem and ship the real thing. s58 00:06:08.560 --> 00:06:12.479 The vast majority of the time, people don't need massive BI dashboards. s59 00:06:12.479 --> 00:06:16.639 They don't need fully scaled designed pieces of software cradle to grave. s60 00:06:16.639 --> 00:06:20.400 They have a problem and they need that problem actually solved. s61 00:06:20.400 --> 00:06:28.319 And so the first thing that we learned is before you build anything, you as an extension of the product team need to understand three things. s62 00:06:28.319 --> 00:06:30.400 First, what are you trying to accomplish? s63 00:06:30.400 --> 00:06:34.800 Meaning what's the core goal in actually solving this problem? s64 00:06:34.800 --> 00:06:37.280 What happens after you have the solution? s65 00:06:37.280 --> 00:06:40.240 And how is the customer actually solving it today? s66 00:06:40.240 --> 00:06:51.360 every single one of these open uh AI or FD deployment companies are all approaching it in a slightly different way than how Palanteer did which is we have the people are going to go on site and build things. s67 00:06:51.360 --> 00:06:52.720 What do we build? s68 00:06:52.720 --> 00:06:56.240 So I think of this in terms of an XY situation. s69 00:06:56.240 --> 00:06:59.599 Customers describe solutions not problems. s70 00:06:59.599 --> 00:07:03.120 Your job as the FTE is to understand what the problem is. s71 00:07:03.120 --> 00:07:08.374 Customers don't know what happens next and your job as the FD is to define it. s72 00:07:08.374 --> 00:07:08.479 [snorts] s73 00:07:08.479 --> 00:07:15.680 My simple solution and takeaway is if solving the problem is under a day of work, just build it and ship it and close the loop. s74 00:07:15.680 --> 00:07:17.280 Don't make it a product strategy. s75 00:07:17.280 --> 00:07:21.919 Don't expand your product vision and bring in your PMs and everything else. s76 00:07:21.919 --> 00:07:26.800 If you can solve this problem in a short curtailed way, that's the first thing we did at Palunteer. s77 00:07:26.800 --> 00:07:28.400 That's how we started. s78 00:07:28.400 --> 00:07:32.960 The secret here is whoever defines the problem actually owns the solution. s79 00:07:32.960 --> 00:07:41.599 If we were able the virtue of the fact that we were able to look at the problem this shipping operator had define the solution and ship the actual solution s80 00:07:41.599 --> 00:07:47.440 meant that we were always the owners of that system and we were able to articulate what subsequent solutions looked like. s81 00:07:47.440 --> 00:07:54.000 By controlling what we're going to build and by controlling the narrative around the solution, you end up in a really powerful position. s82 00:07:54.000 --> 00:07:57.840 And this is why FDES actually become valuable in early sales. s83 00:07:57.840 --> 00:08:05.360 It's not because they are really good at talking to customers or we're not socially awkward software engineers as people seem to claim. s84 00:08:05.360 --> 00:08:18.080 It is because we actually solve the customer's problems in small bite-sized ways that wins us trust and that gets us access to the real problem that we can then use from a product strategy perspective to generalize. s85 00:08:18.080 --> 00:08:26.720 Foundry is a general product solution that we can use across a number of verticals that was informed by tens of thousands of hours of doing things like this in the field. s86 00:08:26.720 --> 00:08:28.720 Cool. s87 00:08:28.879 --> 00:08:30.560 Actions speak louder than words. s88 00:08:30.560 --> 00:08:33.839 This is a real situation also in Palunteer days. s89 00:08:33.839 --> 00:08:43.279 Um we had a data quality engineer who was viscerally adamant to a pipeline adamant about how to solve a pipeline stability issue. s90 00:08:43.279 --> 00:08:51.839 Every day we were dropping about a terabyte of information to someone's S3 bucket and it was putting a lot of pressure on on our own data pipelines. s91 00:08:51.839 --> 00:08:53.200 We had an easy solution. s92 00:08:53.200 --> 00:08:58.160 Instead of dropping huge numbers of CSVs, we can migrate everything to parquet. s93 00:08:58.160 --> 00:08:59.680 Makes it easier for our pipelines. s94 00:08:59.680 --> 00:09:02.399 Makes it easier for like your cost. s95 00:09:02.399 --> 00:09:04.480 Makes it easier from a compute perspective. s96 00:09:04.480 --> 00:09:08.399 But we had one engineer who was viscerally against this. s97 00:09:08.399 --> 00:09:10.160 We couldn't figure out why. s98 00:09:10.160 --> 00:09:14.080 Every time we'd bring this up over the course of about a year, she would push back. s99 00:09:14.080 --> 00:09:17.279 Whenever I'd ask, she'd say, "Park is way worse. s100 00:09:17.279 --> 00:09:18.000 It doesn't work. s101 00:09:18.000 --> 00:09:19.839 It doesn't make sense to me." s102 00:09:19.839 --> 00:09:27.440 We decided to actually go on site at this customer and watch her use our tool and do this workflow end to end. s103 00:09:27.440 --> 00:09:37.680 What we saw is she was downloading CSVs from S3 manually onto her Windows computer, double clicking them to open it up and doing a spot check of data quality. s104 00:09:37.680 --> 00:09:44.000 She could not do that with Paret files because Parquet didn't have a native reader that you could just open and view. s105 00:09:44.000 --> 00:09:51.200 kind of a hilarious problem if you think about it because she was so viscerally opposed to this without really understanding the benefit it would give her. s106 00:09:51.200 --> 00:09:52.959 That night we built a parquet viewer. s107 00:09:52.959 --> 00:09:56.959 She approved the migration in the next 2 days massively reducing data costs. s108 00:09:56.959 --> 00:10:01.600 I think the pipeline execution time went from 17 hours to about two. s109 00:10:01.600 --> 00:10:04.720 And what this teaches us it's actually something pretty simple. s110 00:10:04.720 --> 00:10:11.680 Uh when you are working with a user you are effectively an observer of what happens on site. s111 00:10:11.680 --> 00:10:14.560 An action speaks significantly louder than words. s112 00:10:14.560 --> 00:10:19.440 So you as an FTE should be looking for any task a user does more than once. s113 00:10:19.440 --> 00:10:30.959 Meaning if they're doing something the same day, same same time multiple times a day or they're doing something multiple times a week or multiple times an hour, that is a pattern and a hint that there's a problem and an opportunity. s114 00:10:30.959 --> 00:10:41.519 Anytime a user copies and pastes between tools, meaning if they're moving from one tool to another, anytime they're reacting this way, if the first thing you say is, "Hey, how do you feel about this problem?" s115 00:10:41.519 --> 00:10:44.800 And their reaction is, "Well, I have to." s116 00:10:44.800 --> 00:10:48.720 And this visceral exasperation, you know, you have an opportunity there. s117 00:10:48.720 --> 00:10:52.320 Anytime a user switches tools or tabs, it's an opportunity. s118 00:10:52.320 --> 00:11:06.000 And anytime a user pulls out their phone in the middle of a task, meaning they're going through a workflow using your software or anything else, and pull out their phone, it becomes pretty easy that this is an annoying problem or this software is taking too long. s119 00:11:06.000 --> 00:11:11.440 Your goal as an FTE is to make tomorrow, their tomorrow different from their today. s120 00:11:11.440 --> 00:11:14.880 And it starts with a question, what's the most annoying part of your morning? s121 00:11:14.880 --> 00:11:16.399 Every morning we all come into work. s122 00:11:16.399 --> 00:11:18.959 Every morning we all have something we need to solve. s123 00:11:18.959 --> 00:11:22.959 This all goes back to again FTE is informing your product strategy. s124 00:11:22.959 --> 00:11:31.440 You earn the right to extract user pain and define product strategy by solving small repetitive problems. s125 00:11:31.600 --> 00:11:35.760 Now the most valuable intel here is never going to be in documentation. s126 00:11:35.760 --> 00:11:40.160 We only saw Maria's uh challenge because we were badged onto their building. s127 00:11:40.160 --> 00:11:41.440 We were physically present. s128 00:11:41.440 --> 00:11:42.480 We were in Afghanistan. s129 00:11:42.480 --> 00:11:43.279 We were in Iraq. s130 00:11:43.279 --> 00:11:44.720 We were running around Soho. s131 00:11:44.720 --> 00:11:48.160 We were here in Palo Alto or in San Francisco. s132 00:11:48.160 --> 00:11:54.399 The vast majority of stuff that matters is only going to happen live inside of the walls of the office. s133 00:11:54.399 --> 00:12:01.360 Your badge on site at a customer site and your email address, your contractor email address, those are your data mining permits. s134 00:12:01.360 --> 00:12:09.519 The first thing every FTE should do is get access to customer information by getting in the room where things actually happen. s135 00:12:09.519 --> 00:12:11.519 Everything lives in that environment. s136 00:12:11.519 --> 00:12:13.279 And you can't survey your way to this. s137 00:12:13.279 --> 00:12:14.959 You have to be physically present. s138 00:12:14.959 --> 00:12:23.200 It's very easy to be a forward deployed engineer in name sitting in a nice conference room in New York, but that's not where the actual problems are and that's not where the solutions are. s139 00:12:23.200 --> 00:12:28.000 And the way I've heard this put and the way we threw it around a palunteer is residents get the truth. s140 00:12:28.000 --> 00:12:30.079 Go on site. s141 00:12:30.079 --> 00:12:34.399 Third, when you define the language, you control the narrative. s142 00:12:34.399 --> 00:12:38.800 We had a customer where I'm sure this occurs across pretty much everyone's company here. s143 00:12:38.800 --> 00:12:44.160 From a logistics perspective, everyone defines customers slightly differently. s144 00:12:44.160 --> 00:12:46.240 Sales members calls them customers. s145 00:12:46.240 --> 00:12:47.600 Ops calls them clients. s146 00:12:47.600 --> 00:12:49.360 Finance calls them billing entities. s147 00:12:49.360 --> 00:12:51.440 Devs call them org IDs. s148 00:12:51.440 --> 00:12:58.160 The way that we talk about the same entity in a customer is fundamentally different depending on what team you're in. s149 00:12:58.160 --> 00:13:00.480 That results in a huge amount of pain. s150 00:13:00.480 --> 00:13:02.480 It generally means integrations break. s151 00:13:02.480 --> 00:13:04.079 It means there's data quality issues. s152 00:13:04.079 --> 00:13:06.560 It means pipelines are constantly not working. s153 00:13:06.560 --> 00:13:09.120 And it ultimately comes back to a simple fact. s154 00:13:09.120 --> 00:13:10.399 We're all human. s155 00:13:10.399 --> 00:13:19.120 We define things differently because we operate in our environments and we understand how to talk about topics with people that are similar to us. s156 00:13:19.120 --> 00:13:20.959 It's a feature, not a bug. s157 00:13:20.959 --> 00:13:26.880 And so this idea of an ontology was kind of an accidental thing that Palunteer tripped into. s158 00:13:26.880 --> 00:13:35.279 And what it came from was not this understanding that by making everyone stick everything in elastic search and you know scheming everything we can solve every problem. s159 00:13:35.279 --> 00:13:42.880 came from the simple idea that we need to enable humans to operate in the domain that they understand best. s160 00:13:42.880 --> 00:13:49.680 And so when I say define the language, every organization is made up of two things, nouns and verbs. s161 00:13:49.680 --> 00:13:53.440 The nouns define the entities, the verbs define the operations. s162 00:13:53.440 --> 00:14:01.279 What FDES started eventually doing was building those nouns and verbs and figuring out what the terminology to use was. s163 00:14:01.279 --> 00:14:06.880 In a lot of these enterprises, users don't just adopt your product, they actually adopt your language. s164 00:14:06.880 --> 00:14:12.320 And what we were able to do is we're able to start defining the languages that we wanted people to use. s165 00:14:12.320 --> 00:14:17.760 I think in this case, we called them um uh c like I think we canonicalize on customers. s166 00:14:17.760 --> 00:14:20.560 In other situations, you canonicalize on ids. s167 00:14:20.560 --> 00:14:26.399 Something like DAU, daily active users can mean something very different to different people. s168 00:14:26.399 --> 00:14:28.639 For product teams, high quality DAUs. s169 00:14:28.639 --> 00:14:32.480 for anyone logging in from infosc just the number of people that logged in. s170 00:14:32.480 --> 00:14:37.120 All these phrases that we take for granted are illdefined by nature. s171 00:14:37.120 --> 00:14:40.720 And so when a user adopts your product, they also adopt your language. s172 00:14:40.720 --> 00:14:43.440 How many people are calling things skills right now? s173 00:14:43.440 --> 00:14:47.440 How many people are calling things MCPs that are function calls with prompts? s174 00:14:47.440 --> 00:14:49.440 And that matters. s175 00:14:49.440 --> 00:14:52.480 So third piece here, defining the ontology. s176 00:14:52.480 --> 00:14:56.480 Your job as an FTE is to understand what the ontology is. s177 00:14:56.480 --> 00:15:00.639 What phrases, nouns, and terms in an enterprise are overloaded? s178 00:15:00.639 --> 00:15:04.880 Meaning, what words are people using to describe the same concepts? s179 00:15:04.880 --> 00:15:07.920 Second, where do the integration points exist in the system? s180 00:15:07.920 --> 00:15:10.079 Are things going from Snowflake to data bricks? s181 00:15:10.079 --> 00:15:12.480 Are they going from Palunteer to Tableau? s182 00:15:12.480 --> 00:15:15.199 Are they going from Anthropic to SAP? s183 00:15:15.199 --> 00:15:17.760 Where do these integration points actually exist? s184 00:15:17.760 --> 00:15:21.760 And what are the translation layers where it goes from one term to the other? s185 00:15:21.760 --> 00:15:23.360 Naturally, what are the system boundaries? s186 00:15:23.360 --> 00:15:26.399 What are the systems of record you're never going to be able to switch out? s187 00:15:26.399 --> 00:15:30.000 And what words do people use when they're describing their issues? s188 00:15:30.000 --> 00:15:33.680 If someone is saying, well, in AI, my agent keeps failing. s189 00:15:33.680 --> 00:15:34.880 What is an agent? s190 00:15:34.880 --> 00:15:36.399 Like we can't even define FTE. s191 00:15:36.399 --> 00:15:37.680 We're trying to define agents, right? s192 00:15:37.680 --> 00:15:38.399 Are they prompts? s193 00:15:38.399 --> 00:15:40.720 Are they like series of steps? s194 00:15:40.720 --> 00:15:43.760 Understanding that viscerally becomes important. s195 00:15:43.760 --> 00:15:46.240 Your job is to define the terms. s196 00:15:46.240 --> 00:15:56.399 If you can define the terms in your own solution, you can build the ontology and you can have customers answer questions and think through things in your terms. s197 00:15:56.399 --> 00:16:02.320 So the the secret here is if you become the linguistic foundation, you're locked in. s198 00:16:02.320 --> 00:16:13.600 And simple examples are things like skills, things like MCPs, things like any of the terms that weren't a big deal a year ago but are now day-to-day in our entire econ entire ecosystem. s199 00:16:13.600 --> 00:16:23.279 And so when you are able to define the vocabulary that users use and codify that in your platform, you become the foundation under which every solution and tool is built on top of s200 00:16:23.279 --> 00:16:26.880 foundry enabled that ontology to be constructed and built. s201 00:16:26.880 --> 00:16:35.120 That then enabled the next generation of FTEEs, the go-to market FTEEs to go out there and just do data integrations and sell the product. s202 00:16:35.120 --> 00:16:40.000 We had to learn this the hard way when we were actually building it for the first time. s203 00:16:40.000 --> 00:16:43.040 Last thing here, ship fast but build for production. s204 00:16:43.040 --> 00:16:44.320 This is a true story. s205 00:16:44.320 --> 00:16:45.839 Um, they all are, I guess. s206 00:16:45.839 --> 00:16:49.600 But, uh, we had a customer that needed to run data retention. s207 00:16:49.600 --> 00:16:51.920 I decided to build a very quick script. s208 00:16:51.920 --> 00:16:56.160 It was in Groovy, if anyone knows that language, as a temporary fix. s209 00:16:56.160 --> 00:16:59.120 Um, it wasn't designed for prod by any means. s210 00:16:59.120 --> 00:17:04.319 Like, I just randomly hacked this thing together to solve an initial problem, but it made it there. s211 00:17:04.319 --> 00:17:06.480 12 months later, this thing was all over the place. s212 00:17:06.480 --> 00:17:09.280 It was a almost 100,000 person customer. s213 00:17:09.280 --> 00:17:17.919 Uh it was running in a number of places for my then and my nickname at Palanteer Nat's not here anymore but she can attest to this became venue.groovy. s214 00:17:17.919 --> 00:17:22.480 My wedding people showed up wearing a name the shirt venue.groovy. s215 00:17:22.480 --> 00:17:32.160 And so the the kind of funny thing here is we solved a problem in a very hacky way that did fix an issue but we didn't actually productize it. s216 00:17:32.160 --> 00:17:34.000 We didn't think through the end state. s217 00:17:34.000 --> 00:17:41.280 So we ended up in a situation where we were forced to support a very hacky product for years that was never actually productized. s218 00:17:41.280 --> 00:17:51.600 And so again when people say customer FTEES are forward deployed software engineers or customerf facing software engineers and your job is to make the customer successful that's not true. s219 00:17:51.600 --> 00:17:58.880 When you do that things like this happen so scripts and hacks can fix problems but they're not driving your product strategy forward. s220 00:17:58.880 --> 00:18:02.080 Meaning you're not doing your job successfully as an FTE. s221 00:18:02.080 --> 00:18:04.880 We have people that jobs are making customers successful. s222 00:18:04.880 --> 00:18:07.200 They're solutions architects. s223 00:18:07.200 --> 00:18:13.200 So calibrating what you ship becomes the last mo most important skill here as an FTE. s224 00:18:13.200 --> 00:18:16.559 First, am I going to get a 2 a.m. phone call about this in 6 months? s225 00:18:16.559 --> 00:18:19.280 If you are, you probably shouldn't ship that thing. s226 00:18:19.280 --> 00:18:22.400 Second, what is my trade-off for solving this problem quickly? s227 00:18:22.400 --> 00:18:25.840 Am I making the right decision for the product as a whole? s228 00:18:25.840 --> 00:18:34.080 Or am I just solving this customer's painoint in a way that's going to have potentially small wins but negative compounding challenges later on? s229 00:18:34.080 --> 00:18:37.840 Who do I hand this off uh to when I actually leave the customer site? s230 00:18:37.840 --> 00:18:38.960 Is it going to a customer? s231 00:18:38.960 --> 00:18:40.880 Is it going to another institution? s232 00:18:40.880 --> 00:18:42.720 Is it going to another FDE? s233 00:18:42.720 --> 00:18:44.160 What happens when this breaks? s234 00:18:44.160 --> 00:18:45.840 Am I going to be held responsible for that? s235 00:18:45.840 --> 00:18:50.880 Am I building something so missionritical that if something breaks, I'm going to be hated? s236 00:18:50.880 --> 00:18:52.080 what happens there. s237 00:18:52.080 --> 00:19:02.720 So, we need to solve problems, but we need to be aware of when we fold those solutions into the core offering and when we should just discard those solutions quickly. s238 00:19:02.720 --> 00:19:04.400 Here's the actual reality. s239 00:19:04.400 --> 00:19:06.480 Every hack goes into production. s240 00:19:06.480 --> 00:19:14.000 If you make someone's life easier, it will go into production and you will be responsible to support that hack in perpetuity. s241 00:19:14.000 --> 00:19:19.840 The most dangerous words in forward deployed engineering or engineering is this is just temporary. s242 00:19:19.840 --> 00:19:23.440 Anyone here who's been at a software company knows this is not just temporary. s243 00:19:23.440 --> 00:19:31.760 And we know that we're still writing running on 40-year-old cobalt code at some IBM mainframe because of a hack that was put in place. s244 00:19:31.760 --> 00:19:33.600 If it solves a problem, it's not temporary. s245 00:19:33.600 --> 00:19:35.280 It will live forever. s246 00:19:35.280 --> 00:19:42.160 So, as you're thinking from an FTE perspective, ship everything like it's going to run for 18 months because it probably will. s247 00:19:42.160 --> 00:19:51.360 and through the lens of again the product building focus should tell you a lot about what goes into the core product offering versus what wins you customer goodwill. s248 00:19:51.360 --> 00:19:58.320 So the cheat sheet that we all ran frontline people to uh through rather is the following. s249 00:19:58.320 --> 00:20:08.320 Most people who are trying to develop an FTE function treat it like a product management task and a customer success uh operational task. s250 00:20:08.320 --> 00:20:17.919 They take requirements, they schedule user research, they add insights, they run the processes without actually figuring out how you steer the product from the insights. s251 00:20:17.919 --> 00:20:23.919 The right FTEEs who enabled the creation of something like Foundry redefined the problem. s252 00:20:23.919 --> 00:20:32.640 They got badged on site and they flew to places like Afghanistan, like Iraq, like Somalia, like any of these places where we had to be where our customers were. s253 00:20:32.640 --> 00:20:36.799 I I have a friend who was spending time on an oil rig in the middle of the ocean. s254 00:20:36.799 --> 00:20:44.880 They shipped the fix before leaving the customer site to win the goodwill, but they owned the fix end to end in the product ecosystem. s255 00:20:44.880 --> 00:20:48.159 And they took those fixes and created product leverage from it. s256 00:20:48.159 --> 00:20:58.000 They were able to translate the problems they saw into nouns and verbs that they were then able to use to define the foundation of every subsequent problem that was solved. s257 00:20:58.000 --> 00:21:01.200 And finally, they were the ones who got the call when things actually broke. s258 00:21:01.200 --> 00:21:04.320 They were the ones who got in the airplane to fly everywhere else. s259 00:21:04.320 --> 00:21:10.080 The question is not what did they learn in the process, but what did they ship from the product perspective? s260 00:21:10.080 --> 00:21:12.400 The goal here is actually fairly simple. s261 00:21:12.400 --> 00:21:14.320 I'm going to wrap up with this. s262 00:21:14.320 --> 00:21:17.360 Product leverage is the only thing that wins you customers. s263 00:21:17.360 --> 00:21:22.720 It's the only thing that backs every Citadel portfolio manager trading hundreds of millions of dollars. s264 00:21:22.720 --> 00:21:30.240 It's the only thing that backs every decision being made in the war fighter ecosystem at Palunteer or in customer ecosystems at Palanteer. s265 00:21:30.240 --> 00:21:43.280 your job as an FTE and what we learned and what Kepler is doing is using FTEE as an extension of the product function to enable us to build products that are actually sticky and that solve problems. s266 00:21:43.280 --> 00:21:48.559 And if you were to take one thing away, please don't treat FTEEs as go to market extensions. s267 00:21:48.559 --> 00:21:52.159 You can do that when you're palunteer and have 20 years and unlimited money. s268 00:21:52.159 --> 00:22:00.000 You don't do that when you're an early stage company and you need to figure out what product will allow you to use those FDs to maximum degree. s269 00:22:00.000 --> 00:22:01.805 Thank you so much. s270 00:22:01.805 --> 00:22:03.805 [applause]