WEBVTT

NOTE Sentence-level transcript of https://www.youtube.com/watch?v=wpOA-UXynoM

NOTE One cue per sentence. Cue ids are the line anchors on /transcripts/wpOA-UXynoM.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:16.480
This is the forward deployed engineering track in case you're in the wrong room.

s3
00:00:16.480 --> 00:00:20.960
Um as you already know, forward deployed engineering is one of the hottest topics in AI.

s4
00:00:20.960 --> 00:00:24.640
The most important companies on the planet are building out massive FTE teams.

s5
00:00:24.640 --> 00:00:28.800
So, think OpenAI, Anthropic, Google DeepMind, you get the idea.

s6
00:00:28.800 --> 00:00:38.880
Forward deployed engineering was pioneered by Palantir many years ago to embed really strong software engineers directly into their customers' orgs uh to implement customize their platforms around the nuances

s7
00:00:38.880 --> 00:00:40.520
of the real world.

s8
00:00:40.520 --> 00:00:51.480
So, today we brought in some amazing speakers from Anthropic, Cursor, Factory, Ramp, Decagon, and many more uh to talk about the current state of forward deployed engineering, how it works at their companies,

s9
00:00:51.480 --> 00:00:52.760
and where it's going.

s10
00:00:52.760 --> 00:00:56.160
Our first speaker Our first speaker is Eno Reyes.

s11
00:00:56.160 --> 00:01:01.600
He's the co-founder and CTO at Factory, which is building autonomous software engineering agents for enterprise teams.

s12
00:01:01.600 --> 00:01:06.160
Previously, he worked in machine learning and software engineering roles at Hugging Face and Microsoft.

s13
00:01:06.160 --> 00:01:08.120
Let's give it up for Eno.

s14
00:01:08.120 --> 00:01:10.120
[applause]

s15
00:01:11.400 --> 00:01:12.400
Yeah, hey everyone.

s16
00:01:12.400 --> 00:01:14.440
Excited to chat today.

s17
00:01:14.440 --> 00:01:24.880
Um and you know, basically I I my hope is that at the end of this you guys get a sense of some of the work that we're doing on behalf of our customers and with our customers,

s18
00:01:24.880 --> 00:01:34.880
and the role of what we call a deployed engineer should hopefully be a little bit clearer since I think that there are honestly tons of different models um for

s19
00:01:34.880 --> 00:01:38.160
uh for how this should actually operate inside of an org.

s20
00:01:38.160 --> 00:01:47.200
Um and so I think that when when we start I I I do think that there are some nuances in sort of like the Palantir era playbook.

s21
00:01:47.200 --> 00:02:04.479
Um and I generally the way that forward deployed goes is I I see that there are lots of different takes on sort of where forward deployed sits within the org, how much it interfaces with the actual product team or the engineering team, how much work is done on behalf of the customers versus

s22
00:02:04.479 --> 00:02:13.200
with them, and how much work is done on code itself or basically like in the software system versus with the humans and sort of strategizing, right?

s23
00:02:13.200 --> 00:02:23.320
And so, um generally, I think the there's um in this older model, a lot of the way that software needed to be built was you needed to go and access that codebase.

s24
00:02:23.320 --> 00:02:32.080
You needed to integrate directly in to data streams or software or products that basically you could only access behind the curtain of the customer.

s25
00:02:32.080 --> 00:02:41.160
And so, if you were building something that was heavily integrated into their environment, yeah, you kind of had the need to send and sort of parachute in individuals into the org.

s26
00:02:41.160 --> 00:02:53.360
Um but really that has transformed over time into a role that sort of forks out, and you see a lot of people who are sort of quote-unquote forward deployed engineers

s27
00:02:53.360 --> 00:02:59.120
or deployed engineers or applied AI engineers, and it's always it's always a little bit unclear.

s28
00:02:59.120 --> 00:03:03.560
Are they doing maybe professional services work on behalf of their customer?

s29
00:03:03.560 --> 00:03:08.200
Are they transforming like the product around an individual customer?

s30
00:03:08.200 --> 00:03:14.440
Are they just building entirely net new things in the customer's environment, maybe on top of your product?

s31
00:03:14.440 --> 00:03:23.560
Uh and I think that the the at least at Factory, we definitely do not want to be doing professional services work on behalf of a customer.

s32
00:03:23.560 --> 00:03:33.880
So, if a customer says, "I want to do a uh modernization of a codebase, uh and it's you know, I just got quoted from all of the big consulting firms, it's going to cost this much.

s33
00:03:33.880 --> 00:03:36.440
Could you do this consulting work for us?"

s34
00:03:36.440 --> 00:03:44.040
Uh our goal is not to go and actually do that migration on their behalf, even if we happen to be using our product, right?

s35
00:03:44.040 --> 00:03:48.280
Um and that is because we don't think that that actually makes our product that much better.

s36
00:03:48.280 --> 00:03:55.760
Uh and ultimately, that is a great way way get I'd say a decent amount of revenue, but I don't think that that's the way that you can scale a business out

s37
00:03:55.760 --> 00:03:56.720
enormously, right?

s38
00:03:56.720 --> 00:04:04.120
And so, what we've done is we've instead said, we need deployed engineers to be the tip of the spear of the product.

s39
00:04:04.120 --> 00:04:06.959
And I'm going to do this and then go back.

s40
00:04:06.959 --> 00:04:18.040
But but really when we say the tip of the spear, what we mean is that deployed engineers are basically the stream of information from our largest and most critical customers

s41
00:04:18.040 --> 00:04:20.799
of the engineering leadership in that org.

s42
00:04:20.799 --> 00:04:31.320
The on-the-ground tactical engineers, their thought process about how software development and AI is actually happening at that org, and then flowing all of that information back into our product

s43
00:04:31.320 --> 00:04:37.280
to then rapidly adjust our product in order to then fit into the customer's environment better, right?

s44
00:04:37.280 --> 00:04:47.919
And so, factory really should be when it gets deployed, and I'll talk about what factory is in a second, but we want that to be effectively self-assembled inside of our customer's environment, right?

s45
00:04:47.919 --> 00:04:57.520
And then there's a lot of work that goes into understanding that customer's environment, what the flows that happen, and ultimately the ROI story.

s46
00:04:57.520 --> 00:05:05.960
And what factory really is to our customers is a set of building blocks for building a software software factory, right?

s47
00:05:05.960 --> 00:05:19.280
And so, when we say software factory, what we mean is there's this implicit process that every organization in the world sits on top of, where signals from the outside world flow in on one side, and those signals could be a lot of different things.

s48
00:05:19.280 --> 00:05:28.680
It could be customer conversations, it could be bug reports, it could be internal Slack or Teams conversations, it could be an executive saying, "We're going to build this thing," right?

s49
00:05:28.680 --> 00:05:30.480
All of these are signals.

s50
00:05:30.480 --> 00:05:42.320
Some of them have higher weight than others, and those signals flow in, and humans implicitly or explicitly then choose to then prioritize, triage, and build plans around those signals.

s51
00:05:42.320 --> 00:05:51.160
Those plans are then converted, typically by software developers, into changes into some source of truth, a code base, an engineering system.

s52
00:05:51.160 --> 00:06:06.120
Um and as those changes are actually executed on, they flow through a validation stage where people maybe review the code, they QA, they assess the security implications, they uh pass it through automated validation like SAST tools,

s53
00:06:06.120 --> 00:06:11.320
linters, type checkers, and ultimately when everything passes, they then ship and deploy.

s54
00:06:11.320 --> 00:06:14.120
And what do you do with deployed monitored software?

s55
00:06:14.120 --> 00:06:16.560
Well, it it generates more signals, right?

s56
00:06:16.560 --> 00:06:22.919
So, this implicit feedback loop is instrumented very poorly, to be honest, at most organizations.

s57
00:06:22.919 --> 00:06:33.919
And if you're able to take AI and actually transform each of these stages of the pipeline and build an understanding of what the workflow looks like at your org from each stage to each stage,

s58
00:06:33.919 --> 00:06:41.800
then you actually can get to the point where you have a a flow through from signal to deploy that has no human intervention.

s59
00:06:41.800 --> 00:06:46.040
Now, importantly, that does not mean that humans are not a part of engineering this system, right?

s60
00:06:46.040 --> 00:06:50.520
But it is that the flow of signal to deploy is uninterrupted by a human.

s61
00:06:50.520 --> 00:06:57.640
Um and that software factory concept is obviously not something that can just snap your fingers and it appears, right?

s62
00:06:57.640 --> 00:07:00.520
Instead, it requires an investment from the organization.

s63
00:07:00.520 --> 00:07:03.080
We we like to say this is built, not bought, right?

s64
00:07:03.080 --> 00:07:14.720
But what the platform that we've built basically provides to people are the canonical one model independent agent harness that you need to do this, because if you want to build a software factory,

s65
00:07:14.720 --> 00:07:24.600
if you choose to build that software factory in a vendor locked solution that has like one model available to it, uh that is going to not only be expensive,

s66
00:07:24.600 --> 00:07:34.040
but two, uh there's open questions about model independence and like what is the role of the model provider in dictating what you can or cannot build with your software factory, right?

s67
00:07:34.040 --> 00:07:45.120
Um and if you also don't own the traces, the data, everything that flows through your software factory, um then you're probably going to be in trouble as you start to want to evolve your software factory, right?

s68
00:07:45.120 --> 00:07:54.200
And so with Droid, the hardness that we build, you not only have model independence, but you also have access to every piece of data that flows in in and out of Droid, alongside

s69
00:07:54.200 --> 00:08:01.120
centralized governance and control at the enterprise layer to be able to dictate where what information flows where.

s70
00:08:01.120 --> 00:08:03.080
Um you can air gap Droid if you want.

s71
00:08:03.080 --> 00:08:15.720
Some of our partners um in, you know, the most secure uh environments, uh think finance, health care, uh gov, uh they air gap Droid and they run their software factories entirely contained.

s72
00:08:15.720 --> 00:08:20.320
Um One of our deployed engineers jokes that you could run Droid in a submarine if you wanted to.

s73
00:08:20.320 --> 00:08:21.840
And that's that's honestly true.

s74
00:08:21.840 --> 00:08:34.120
And so when we think about what the role of this deployed engineer is in that context, which I probably should have started with, um you know, you really need somebody who can go in and say, I understand

s75
00:08:34.120 --> 00:08:40.400
this new model of building software and I understand the building blocks and the pieces.

s76
00:08:40.400 --> 00:08:51.240
I can help enable building and constructing these software factories with your team, but I ultimately would like to one, make it so that our product effectively, you know, one click self-assembled

s77
00:08:51.240 --> 00:09:01.240
into your environment, which is needed when you have 45,000 people, maybe hundreds of thousands of uh of of engineers, maybe you have tens of thousands of code bases.

s78
00:09:01.240 --> 00:09:02.880
Uh you you've got to self-assemble, right?

s79
00:09:02.880 --> 00:09:07.200
You just can't manually install this level of of complexity.

s80
00:09:07.200 --> 00:09:12.560
Um and and also on the sort of like end loop, why do all of this, right?

s81
00:09:12.560 --> 00:09:20.480
I I would argue that there needs to be an ROI or an outcome story that is extremely clear from the beginning so that you can say, well, we know

s82
00:09:20.480 --> 00:09:30.880
every code change that flows through that gets AI code review, AI QA, AI security analysis is maybe 87% less likely to hit a bug.

s83
00:09:30.880 --> 00:09:41.800
And what that means is that we can reduce our our bug rate by X, that increases our customer satisfaction by Y, and that leads to revenue or growth or new business, right?

s84
00:09:41.800 --> 00:09:46.960
Something needs to flow from this software factory process to core business goals.

s85
00:09:46.960 --> 00:09:52.560
And that often is a complex story that requires engineering knowledge, it requires business knowledge.

s86
00:09:52.560 --> 00:09:59.760
And so, if those are the types of things that you think are interesting, that is what deployed engineers today are doing for us.

s87
00:09:59.760 --> 00:10:09.760
Um I've sort of outlined it a little bit here, but that teach the model step is super important because most organizations do not have an autonomy maturity model.

s88
00:10:09.760 --> 00:10:17.360
They do not have a road map, they don't have a conception of what it means to truly build an autonomous software organization, right?

s89
00:10:17.360 --> 00:10:20.920
I think a lot of people ask the question, what do the humans do in this world, right?

s90
00:10:20.920 --> 00:10:29.040
For us, we see an extremely clear role for humans in evolving, refining, and scaling software factories, right?

s91
00:10:29.040 --> 00:10:38.480
So, you basically the engineers at a company go from directly manipulating software to directly maintaining and managing a system that builds software.

s92
00:10:38.480 --> 00:10:44.400
And that sort of like upgrade in the level of abstraction that you operate at is actually very difficult.

s93
00:10:44.400 --> 00:10:48.200
And a lot of people find it extremely challenging.

s94
00:10:48.200 --> 00:10:55.680
I would argue that in fact most people, even very thoughtful software engineers, will have a learning curve in trying to shift.

s95
00:10:55.680 --> 00:11:02.920
The people who I think are are well suited for this are DevEx people who have already been thinking about enablement of other developers.

s96
00:11:02.920 --> 00:11:09.440
I think product managers who want to become very technical very quick can become really great at doing this.

s97
00:11:09.440 --> 00:11:15.967
And I think that generally like people who are used to to working on teams where

s98
00:11:15.967 --> 00:11:16.600
[clears throat]

s99
00:11:16.600 --> 00:11:25.160
high quality dev environments were a priority, you will you will get some of the canonical things necessary to enable these agents to succeed.

s100
00:11:25.160 --> 00:11:31.360
Um I haven't really talked about this last one, which is design the workflows.

s101
00:11:31.360 --> 00:11:41.200
And I will get to that in a sec, but I I think that when I say tip of the spear of the product, like keep in mind I really do mean everything that is happening inside of factory.

s102
00:11:41.200 --> 00:11:52.160
So, our product encompasses enterprise controls, the droid harness, the workflows that run on top of it, the observability tools, the cost controls, the auto model routing, the quality of the harness.

s103
00:11:52.160 --> 00:12:02.800
Like, all of these are pro- potential opportunities of improvement that you will discover when you work very closely in these varied or diverse orgs like how to solve.

s104
00:12:02.800 --> 00:12:07.880
Um, so making a code base agent ready, right?

s105
00:12:07.880 --> 00:12:10.040
This is a very challenging thing to do.

s106
00:12:10.040 --> 00:12:18.040
Uh, most organizations have some degree of consistency in how they've chosen to build deterministic validation loops inside of their company, right?

s107
00:12:18.040 --> 00:12:24.840
So, your code base runs linters, type checkers, uh, it might run some security scans, and it's like check mark.

s108
00:12:24.840 --> 00:12:26.240
Like, it passes or it doesn't.

s109
00:12:26.240 --> 00:12:28.400
The end end test, they pass or it doesn't, right?

s110
00:12:28.400 --> 00:12:29.000
Or they don't.

s111
00:12:29.000 --> 00:12:36.760
Um, what agent readiness really is is it's a measure of how many of these deterministic validation loops are present inside of your code base.

s112
00:12:36.760 --> 00:12:45.720
Uh, when you have a huge volume of these feedback loops, uh, agents are able to operate for greater periods of time on more complex tasks without human intervention.

s113
00:12:45.720 --> 00:12:49.680
So, we have like a product that we call missions, which I'll also touch on in a sec.

s114
00:12:49.680 --> 00:13:00.280
But, missions is basically an extremely elaborate harness built around the concept of working on extremely difficult knowledge work problems that are validatable, right?

s115
00:13:00.280 --> 00:13:09.800
And so, the quality of the output of these very long-running harnesses of advanced agents is directly proportional to the degree to which you can validate their work.

s116
00:13:09.800 --> 00:13:16.080
And so, if you introduce the ability to validate at scale, then you introduce increasing autonomy to the org.

s117
00:13:16.080 --> 00:13:23.360
So, what we'll look at is we have tools that help scan all of these things, but often times, uh, the change is not so simple.

s118
00:13:23.360 --> 00:13:30.240
Uh, for I'd say maybe 30 to 40% of the low-hanging fruit, you click droid, please fix all of this and it'll go in and it'll fix it, right?

s119
00:13:30.240 --> 00:13:33.760
But for the other 60% some of them involve workflow changes.

s120
00:13:33.760 --> 00:13:40.040
Sometimes humans are not used to the degree of I would say like nitpickiness of these automated systems.

s121
00:13:40.040 --> 00:13:52.280
And so you have to sort of be aware of the concerns, the the humans, you have to think about like the way that people are currently developing systems and say, "How do we introduce some of these more extreme validation strategies

s122
00:13:52.280 --> 00:13:57.000
without interrupting the dev flow of the humans who are involved in the work?"

s123
00:13:57.000 --> 00:14:06.480
Um and and I mentioned missions because really I think this is one of the more end game of the agent era at least, pre-software factory era.

s124
00:14:06.480 --> 00:14:16.360
But the more end game of the agent era style harnesses where it's simply a long running harness that has almost no human intervention except for the planning stage, right?

s125
00:14:16.360 --> 00:14:20.320
Where you go in and you say, "I would like to have this very bounded task.

s126
00:14:20.320 --> 00:14:24.880
I know that I want to solve this task and here is what solving this task means.

s127
00:14:24.880 --> 00:14:29.600
I will now basically push a lever of inference until the task is complete, right?

s128
00:14:29.600 --> 00:14:38.120
And so that is actually unbelievably competent at solving problems where like is complete is verifiable.

s129
00:14:38.120 --> 00:14:48.800
So if you can frame any problem as the set of verification uh systems that need to validate it, then you can solve that problem with AI today.

s130
00:14:48.800 --> 00:15:01.040
Uh and we've seen this work on some pretty insane problem spaces like migrating, you know, 30, 40, 50 million plus line code bases uh fully autonomously, um working on advanced

s131
00:15:01.040 --> 00:15:22.120
uh like deep learning strategies around biomed, health care uh sort of problems, uh financial institutions that optimize equity research where you can actually build models of different equities and sort of analyze and compare and and build sort of a system that can then back prop and or trade on top of the those equities.

s132
00:15:22.120 --> 00:15:31.960
Um like it it's mind-blowing to me every day what I what I hear people are using with these tools, but it is not something that you can just download, install, and hit play, right?

s133
00:15:31.960 --> 00:15:34.200
It does require agent readiness.

s134
00:15:34.200 --> 00:15:40.600
So, if your code base isn't agent ready, you won't see any of the success of the most capable AI systems in the world today, right?

s135
00:15:40.600 --> 00:15:52.240
So, this is why we want people to go in and help our customers and say, "Hey, look, you can solve this actually very difficult problem, but it is going to require a different form of investment than you were thinking.

s136
00:15:52.240 --> 00:15:58.000
Less so solving the problem, more so preparing the environment for verification of the problem."

s137
00:15:58.000 --> 00:16:03.080
And by the way, if you're familiar with how these models are actually trained, like this makes total sense, right?

s138
00:16:03.080 --> 00:16:07.000
They they get dense reward when they get post trained on all these complex tasks.

s139
00:16:07.000 --> 00:16:08.880
Models need dense reward.

s140
00:16:08.880 --> 00:16:17.120
These verification signals form the basis of that reward that they use to keep them on track over a long-term goal-directed problem.

s141
00:16:17.120 --> 00:16:26.440
Um So, I sort of mentioned this earlier, but but I think that the the core goal for us really is to say, if we can hand over a model

s142
00:16:26.440 --> 00:16:38.000
to you of how this should this transformation should go, then we should theoretically be able to say, "Let's do this in a couple of different places, and then let your team actually scale this out across the company."

s143
00:16:38.000 --> 00:16:44.600
I always use the analogy of if you're familiar with Walt Disney's Epcot, the the theme park.

s144
00:16:44.600 --> 00:16:53.240
Like basically that theme park was created originally Disney wanted to create like a master planned exemplary city.

s145
00:16:53.240 --> 00:17:03.320
He said, "Look, if I can create a city that is the future city, then I can use that as a model to the rest of the world cities, and they can develop entirely new forms of transportation

s146
00:17:03.320 --> 00:17:04.560
and flourishing."

s147
00:17:04.560 --> 00:17:06.000
And it became a theme park.

s148
00:17:06.000 --> 00:17:17.360
But, what's interesting is that in that small example, a lot of other cities actually did cite some of the ideas that he was writing down and sharing about what like centralized urban transit should look like.

s149
00:17:17.360 --> 00:17:25.000
And now you have like some more contemporary cities built in the last 50 years that basically modeled after that toy example.

s150
00:17:25.000 --> 00:17:34.360
Um what we want to do is we want to make sure that we get some of that lesson that if you have a working example of a city of the future, of a code base of the future,

s151
00:17:34.360 --> 00:17:35.960
um people are smart.

s152
00:17:35.960 --> 00:17:36.520
They're clever.

s153
00:17:36.520 --> 00:17:39.320
Humans will look at that and they'll say, "Man, that's really cool.

s154
00:17:39.320 --> 00:17:42.200
Let's bring that to my part of the code base, right?"

s155
00:17:42.200 --> 00:17:47.880
But if you build too much of an advanced example, then people will say, "That's a theme park.

s156
00:17:47.880 --> 00:17:50.160
That is not at all how the rest of the world works.

s157
00:17:50.160 --> 00:17:54.560
I just can't see how that would apply to the way that we currently work today, right?"

s158
00:17:54.560 --> 00:18:09.520
So it's kind of a delicate balance that you have to walk of building something that demonstrates the future is achievable enough, but ultimately does not scare away uh an org who is thinking, "Man, what is going to be the cost of transforming at this pace,

s159
00:18:09.520 --> 00:18:10.280
right?"

s160
00:18:10.280 --> 00:18:15.240
Um I always think about that quote, you know, the the future is here, it's just not evenly distributed.

s161
00:18:15.240 --> 00:18:20.760
Um there are some code bases, and I I say code bases, not even companies, that are truly remarkable.

s162
00:18:20.760 --> 00:18:24.280
They are effectively uh beginning to run on autopilot.

s163
00:18:24.280 --> 00:18:37.400
Uh we ourselves have roughly 15 to 20% of what we call like autonomy, and our autonomy ratio is like in the upper 80%, which means the ratio of actions done by humans to AI systems before interruption, right?

s164
00:18:37.400 --> 00:18:48.160
So our own code base is fairly agent-ready, pretty autonomous, um but uh the code bases of some of our customers are actually even more autonomous because they operate in more constrained

s165
00:18:48.160 --> 00:18:49.360
uh ways, right?

s166
00:18:49.360 --> 00:18:55.360
So it's it's sort of like a uh it is not obvious like who gets 100% autonomy first.

s167
00:18:55.360 --> 00:18:58.400
I would argue it's probably very contained internal tools.

s168
00:18:58.400 --> 00:19:02.080
Like we have something we call like legal droid, which is our legal workflow.

s169
00:19:02.080 --> 00:19:14.560
That is effectively 100% autonomously maintained, but our like core harness, uh we do not yet have validators that can validate some of the hard visual problems of a like terminal based harness.

s170
00:19:14.560 --> 00:19:19.240
Uh Things like flickering are really hard to catch in a verif- in a verifiable way.

s171
00:19:19.240 --> 00:19:21.960
So, we're unable to close the loop on some of those challenges.

s172
00:19:21.960 --> 00:19:28.320
It's an engineering task to build the system that can verify some of those very hard problems.

s173
00:19:28.320 --> 00:19:38.640
And that might give you a picture into sort of like the weird world of the future where humans are sort of visually our advantages in being visual, our advantages in having context of the outside world

s174
00:19:38.640 --> 00:19:42.320
provide us a lot of work to do in order to build these systems.

s175
00:19:42.320 --> 00:19:44.040
So, who's great at this?

s176
00:19:44.040 --> 00:19:47.760
I If you are a former founder, for sure you should do this.

s177
00:19:47.760 --> 00:19:58.120
I think it's like the quickest way to basically build out I mean each like stage of the SDLC that Droid has, we think is a billion-dollar business.

s178
00:19:58.120 --> 00:20:02.360
Like just code review, just incident response, just QA, just testing.

s179
00:20:02.360 --> 00:20:07.560
Like each of these you will help define basically the nature of these products.

s180
00:20:07.560 --> 00:20:11.640
If you are someone who is used to tech communication, right?

s181
00:20:11.640 --> 00:20:21.400
If you are fluent in AI, you understand how to speak to every level, you have business acumen, you have executive presence, that is another great example of someone who should do this.

s182
00:20:21.400 --> 00:20:35.280
And if you are a systems thinker, if you love designing systems, if you love closing loops, modeling data, and understanding how the flow through a potentially extremely complex org should look, then you are also someone who would thrive at doing this.

s183
00:20:35.280 --> 00:20:40.000
So, if all of this seems interesting, hopefully it does.

s184
00:20:40.000 --> 00:20:42.320
Please do reach out.

s185
00:20:42.320 --> 00:20:44.280
And you can reach out to me directly.

s186
00:20:44.280 --> 00:20:46.360
I'm just Yeah, I'll say it.

s187
00:20:46.360 --> 00:20:47.240
It's on the slide.

s188
00:20:47.240 --> 00:20:49.480
I'm eno@factory.ai.

s189
00:20:49.760 --> 00:20:53.880
And so, you can just email me directly or you can apply on our careers page.

s190
00:20:53.880 --> 00:20:57.240
It's called engineer, {comma} deployed.

s191
00:20:57.240 --> 00:20:58.840
So, that's the role.

s192
00:20:58.840 --> 00:21:03.600
Hopefully this is interesting and gives you a taste of what we're doing at Factory.

s193
00:21:19.229 --> 00:21:20.320
[music]

s194
00:21:20.320 --> 00:21:22.320
Woo!