WEBVTT

NOTE Sentence-level transcript of https://www.youtube.com/watch?v=3ZlQk4-knWM

NOTE One cue per sentence. Cue ids are the line anchors on /transcripts/3ZlQk4-knWM.html. A cue ends where the next begins, or 2 s after its last word.

s1
00:00:00.080 --> 00:00:00.880
Hello and welcome.

s2
00:00:00.880 --> 00:00:06.080
Today we will be talking about deploying AI inside of a bank and how it is not an engineering problem.

s3
00:00:06.080 --> 00:00:08.000
Before we get into that, I want to introduce myself.

s4
00:00:08.000 --> 00:00:09.360
My name is Payeyton Gail.

s5
00:00:09.360 --> 00:00:11.679
I worked across many different fields.

s6
00:00:11.679 --> 00:00:14.480
So I started off at consulting at Accenture.

s7
00:00:14.480 --> 00:00:20.000
Before moving over to Bloomberg as a software engineer where I worked on a trade infrastructure team and a data platform team.

s8
00:00:20.000 --> 00:00:23.680
Then afterwards I would be at Google working on security and deployment.

s9
00:00:23.680 --> 00:00:30.960
And right now I am a founding FTE at a startup and writing the book on for deploy engineering with O'Reilly.

s10
00:00:30.960 --> 00:00:35.280
In this example, the system reviews client documents and drafts exceptions for an analyst.

s11
00:00:35.280 --> 00:00:40.239
The demo shows the intended workflow and everybody can see why it would be useful.

s12
00:00:40.239 --> 00:00:43.680
Then security asks, okay, which environment will host it?

s13
00:00:43.680 --> 00:00:51.760
The data owners ask who agreed to this use of documents and someone from risk asked who will review a wrong exception before it reaches the next system.

s14
00:00:51.760 --> 00:00:53.680
Those are reasonable questions, right?

s15
00:00:53.680 --> 00:00:56.320
Each question can change what we are allowed to build.

s16
00:00:56.320 --> 00:01:01.440
The team has already invested a design while several people responsible for that design have never seen it.

s17
00:01:01.440 --> 00:01:03.039
So in this case, the demo worked.

s18
00:01:03.039 --> 00:01:03.920
The model was fine.

s19
00:01:03.920 --> 00:01:05.760
However, it still did not ship.

s20
00:01:05.760 --> 00:01:13.600
I want to now show you how to uncover those decisions in week one so you can design a system with a credible route into production.

s21
00:01:14.320 --> 00:01:17.600
These four labels represent decisions your deployments depend on.

s22
00:01:17.600 --> 00:01:22.640
For each one, I want a person who can explain the decision, the evidence they need, and the next step.

s23
00:01:22.640 --> 00:01:23.840
So, let's start with data.

s24
00:01:23.840 --> 00:01:29.119
Data, who owns the source, who can grant access, who can approve using this in the workflow.

s25
00:01:29.119 --> 00:01:36.720
Those responsibilities may belong to different people, but being able to query a data set does not settle every question about how the application may use it.

s26
00:01:36.720 --> 00:01:41.360
For the model risk, find a person who can tell you which review applies to the intended use.

s27
00:01:41.360 --> 00:01:43.200
Ask what a previous submission looked like.

s28
00:01:43.200 --> 00:01:48.240
Learn who will own the system after launch and what evidence that owner will need to maintain it.

s29
00:01:48.240 --> 00:01:51.439
For third party risk, draw the actual dependency chain.

s30
00:01:51.439 --> 00:01:56.240
Include the model provider, the host arrangements, and your role in the operating service.

s31
00:01:56.240 --> 00:02:02.079
Find out which relationships have already been reviewed and which proposed changes require another decision.

s32
00:02:02.079 --> 00:02:06.079
For audit, ask someone, right?

s33
00:02:06.479 --> 00:02:10.720
For audit, ask what someone would need to reconstruct a consequential action.

s34
00:02:10.720 --> 00:02:11.920
Which input was used?

s35
00:02:11.920 --> 00:02:13.680
Which configuration produced the output?

s36
00:02:13.680 --> 00:02:15.360
What did the reviewer see?

s37
00:02:15.360 --> 00:02:17.120
And who approved the action?

s38
00:02:17.120 --> 00:02:21.280
Those are the questions that affect the records you need to capture from from the beginning.

s39
00:02:21.280 --> 00:02:29.360
Now imagine getting those answers after you built the whole entire system, a deployment boundary, a data path or action that may have to change.

s40
00:02:29.360 --> 00:02:34.000
The useful move is to bring these people in and bring them into the design early.

s41
00:02:34.000 --> 00:02:39.280
Their responsibilities help us identify the system we can actually operate.

s42
00:02:39.599 --> 00:02:42.080
And here discovery is the engineering.

s43
00:02:42.080 --> 00:02:50.640
So now we want to talk about what discovery is and who we need to really find out to understand what exactly we need to build.

s44
00:02:51.360 --> 00:02:53.680
So you want to think every data set has an owner.

s45
00:02:53.680 --> 00:02:57.599
The work I did at Bloomberg on the data platform team made this concrete for me.

s46
00:02:57.599 --> 00:03:04.000
So building infrastructure for for an LLM meant understanding which data sets could be used and who could approve that use.

s47
00:03:04.000 --> 00:03:07.120
The idea we want to get across is that every data set has an owner.

s48
00:03:07.120 --> 00:03:10.720
My work at Bloomberg on the data platform team made this concrete for me.

s49
00:03:10.720 --> 00:03:17.280
Building an infrastructure for an LLM meant understanding which data sets can be used and who could approve that use.

s50
00:03:17.280 --> 00:03:19.360
Carry that into each bank deployment.

s51
00:03:19.360 --> 00:03:20.800
Honestly, any deployment.

s52
00:03:20.800 --> 00:03:24.800
So before designing retrieval, find the person accountable for each source.

s53
00:03:24.800 --> 00:03:30.159
Confirm the allowed use and the environment where the processing can actually start to happen.

s54
00:03:30.159 --> 00:03:33.040
If those answers change, your design changes with them.

s55
00:03:33.040 --> 00:03:36.799
Imagine the key on this slide stands for a real permission with a real owner.

s56
00:03:36.799 --> 00:03:42.239
We should be able to name that owner to know where exactly this key needs to come from.

s57
00:03:43.519 --> 00:03:50.239
When starting to scope out an architecture, a lot of the questions you may have can be answered by looking at the or chart.

s58
00:03:50.239 --> 00:03:51.519
Read the top row first.

s59
00:03:51.519 --> 00:03:54.720
Documents go into the model and an analyst reviews the output.

s60
00:03:54.720 --> 00:03:57.120
You can probably sketch that system in a few minutes.

s61
00:03:57.120 --> 00:03:58.640
Now read the row underneath it.

s62
00:03:58.640 --> 00:04:00.159
The documents have a data owner.

s63
00:04:00.159 --> 00:04:01.920
The model service needs a platform owner.

s64
00:04:01.920 --> 00:04:05.599
The analyst workflow needs someone who can confirm the relevant risk requirements.

s65
00:04:05.599 --> 00:04:08.239
And the last name still has a question mark.

s66
00:04:08.239 --> 00:04:10.560
That question mark is a dependency.

s67
00:04:10.560 --> 00:04:18.639
We have designed a workflow without finding the person who can tell us whether its intended use is acceptable and what evidence will be required.

s68
00:04:18.639 --> 00:04:23.919
So I would walk through this diagram with a sponsor or someone you trust and figure out, okay, who owns the documents?

s69
00:04:23.919 --> 00:04:25.680
Have they heard about this use?

s70
00:04:25.680 --> 00:04:27.840
Who can help us reach the appropriate reviewer?

s71
00:04:27.840 --> 00:04:30.880
Then I would confirm the answers directly with those people.

s72
00:04:30.880 --> 00:04:33.040
The real map will have more relationships than this.

s73
00:04:33.040 --> 00:04:36.160
A technical component may depend on several approvals.

s74
00:04:36.160 --> 00:04:38.320
Some decisions span the entire system.

s75
00:04:38.320 --> 00:04:42.960
The point is to make those dependencies visible while the design is still easy to change.

s76
00:04:42.960 --> 00:04:47.520
An unnamed owner becomes a specific task with a person responsible for resolving it.

s77
00:04:47.520 --> 00:04:52.639
That is how discovery starts turning uncertainty into an implementation plan.

s78
00:04:54.160 --> 00:04:58.720
And given that you may start to ask yourself, okay, Peyton, what sort of question should I be asking?

s79
00:04:58.720 --> 00:05:02.479
So here are some of the questions I would bring to a discovery call.

s80
00:05:02.479 --> 00:05:05.280
Where does the data live and who can approve reading it?

s81
00:05:05.280 --> 00:05:09.280
Who has stopped it in a similar project before and why?

s82
00:05:09.280 --> 00:05:13.520
Which existing controls could cover this workflow and who owns them?

s83
00:05:13.520 --> 00:05:17.759
Where will this production run and who are the administrators for that environment?

s84
00:05:17.759 --> 00:05:21.280
Who signs the relevant risk review and what have they signed before?

s85
00:05:21.280 --> 00:05:25.759
What obligation is the sponsor personally worried about and who can explain it?

s86
00:05:25.759 --> 00:05:27.280
Notice what I want to leave with.

s87
00:05:27.280 --> 00:05:30.960
It's either names, decisions, or next conversations.

s88
00:05:30.960 --> 00:05:35.520
If someone says security will be fine, ask will actually review the design and when you can meet them.

s89
00:05:35.520 --> 00:05:36.479
Then close the loop.

s90
00:05:36.479 --> 00:05:40.880
Send each owner a short description of the proposed use and confirm what they need from you.

s91
00:05:40.880 --> 00:05:45.520
By Friday, the people whose decisions the deployment depends on should know the project exists.

s92
00:05:45.520 --> 00:05:48.880
That gives scoping a much firmer starting point.

s93
00:05:48.880 --> 00:05:52.880
And once all that is done and we know who owns the decisions, I can scope the work.

s94
00:05:52.880 --> 00:05:56.960
When the customer cannot write or give out the spec, I rely on these three things.

s95
00:05:56.960 --> 00:06:00.400
Shadow, draft, and shrink.

s96
00:06:00.400 --> 00:06:03.199
For example, at Bloomberg, I worked on a system that handled cash flows.

s97
00:06:03.199 --> 00:06:04.960
That work had to reconcile.

s98
00:06:04.960 --> 00:06:06.880
That gave me a concrete place to start.

s99
00:06:06.880 --> 00:06:09.039
So, it started with following.

s100
00:06:09.039 --> 00:06:11.759
For example, at Bloomberg, I worked on a system that handled cash flows.

s101
00:06:11.759 --> 00:06:15.360
The work had to reconcile and that gave me a concrete place to start.

s102
00:06:15.360 --> 00:06:18.160
Follow the flow and the people responsible for it.

s103
00:06:18.160 --> 00:06:20.880
I use that approach when a sponsor wants AI for onboarding.

s104
00:06:20.880 --> 00:06:29.199
Sit with an analyst, watch which systems they open, where they make a judgment, and when they ask for permission, ask what happens when a document is missing.

s105
00:06:29.199 --> 00:06:30.720
Write down the actual sequence.

s106
00:06:30.720 --> 00:06:32.880
That is the beginning of your specification.

s107
00:06:32.880 --> 00:06:36.080
Now, imagine we are building the document exception assistant.

s108
00:06:36.080 --> 00:06:40.880
This is a hypothetical example, but I would still put these three lines in front of the sponsor.

s109
00:06:40.880 --> 00:06:42.400
One, review the documents.

s110
00:06:42.400 --> 00:06:43.840
Two, draft the exceptions.

s111
00:06:43.840 --> 00:06:46.240
And three, analyst submits.

s112
00:06:46.240 --> 00:06:48.160
Then I would make each line specific.

s113
00:06:48.160 --> 00:06:50.160
Which documents can the analyst access?

s114
00:06:50.160 --> 00:06:52.800
Is it access approved for this processing?

s115
00:06:52.800 --> 00:06:54.080
What should the model produce?

s116
00:06:54.080 --> 00:06:57.840
And that'll be a highlighted passage, a draft form or both.

s117
00:06:57.840 --> 00:06:59.039
And who checks the draft?

s118
00:06:59.039 --> 00:07:00.639
And also who submits it?

s119
00:07:00.639 --> 00:07:04.960
For first version, suppose the output is a highlighted exception and a draft form.

s120
00:07:04.960 --> 00:07:08.000
The analyst checks the source, edits the form and submits.

s121
00:07:08.000 --> 00:07:10.639
That is the boundary someone can correct.

s122
00:07:10.639 --> 00:07:13.199
I would also propose a success criteria.

s123
00:07:13.199 --> 00:07:17.440
So either less review time with no increases and misconceptions.

s124
00:07:17.440 --> 00:07:22.880
We still need to agree on how to measure that against the current workflow because that again right is the whole point.

s125
00:07:22.880 --> 00:07:25.360
It is a proposal until we have an agreement.

s126
00:07:25.360 --> 00:07:28.080
Take the draft to the sponsor and the control owners.

s127
00:07:28.080 --> 00:07:30.000
They can cross out a document type.

s128
00:07:30.000 --> 00:07:33.440
They can change the reviewer or they could just, you know, flat out reject the output.

s129
00:07:33.440 --> 00:07:37.440
Each correction gives a decision we can build around.

s130
00:07:37.840 --> 00:07:42.319
So once the workflow is complete, scope becomes a series of approval questions.

s131
00:07:42.319 --> 00:07:46.800
So now let's grow our hypothetical system one step at a time.

s132
00:07:46.800 --> 00:07:49.759
First, it summarizes a document that the analyst already has.

s133
00:07:49.759 --> 00:07:53.840
We will still confirm whether that existing access covers its use.

s134
00:07:53.840 --> 00:07:56.000
Next, it reads from a second system.

s135
00:07:56.000 --> 00:07:59.039
Now, there's another data path and somebody needs to approve it.

s136
00:07:59.039 --> 00:08:02.639
Next, after that, it drafts a response that a customer will see.

s137
00:08:02.639 --> 00:08:07.039
Who checks the content and which will review the applies that we can use.

s138
00:08:07.039 --> 00:08:09.199
Finally, it sends a response automatically.

s139
00:08:09.199 --> 00:08:10.479
Who owns that action?

s140
00:08:10.479 --> 00:08:12.400
What happens if it sends something wrong?

s141
00:08:12.400 --> 00:08:14.560
And how do we stop it and recover it?

s142
00:08:14.560 --> 00:08:16.720
Those are the four different engineering scopes.

s143
00:08:16.720 --> 00:08:20.560
The applicable reviews depend on the institution and the use case.

s144
00:08:20.560 --> 00:08:24.560
So I would confirm them with people who own those decisions.

s145
00:08:24.560 --> 00:08:27.360
Then I ask which increment creates the useful value today.

s146
00:08:27.360 --> 00:08:31.599
Could I draft inside the analyst's current workflow to solve enough of the problem?

s147
00:08:31.599 --> 00:08:33.039
If so, start there.

s148
00:08:33.039 --> 00:08:41.919
Confirm that the existing control really fits and build the smallest useful version or the MVP with a credible path of approval.

s149
00:08:42.000 --> 00:08:43.360
That brings me to autonomy.

s150
00:08:43.360 --> 00:08:49.839
I start with the least authority that the problem solved then ask what task can be proven as evidence to give the system more.

s151
00:08:49.839 --> 00:08:54.399
So when working on cash flows at Bloomberg I thought about automation a lot of the time.

s152
00:08:54.399 --> 00:08:57.760
So every automated step needs a control and somebody owns a number.

s153
00:08:57.760 --> 00:08:59.519
I carry that discipline into AI.

s154
00:08:59.519 --> 00:09:04.640
So find the consequential action name its owner decide what happens when the system is wrong.

s155
00:09:04.640 --> 00:09:08.880
So for example in a hypothetical exception workflow the submission is that action.

s156
00:09:08.880 --> 00:09:14.320
An analyst reviewing the draft needs the source evidence and visible uncertainty to make a real judgment.

s157
00:09:14.320 --> 00:09:19.040
A review button only helps if the person can actually check the work.

s158
00:09:19.040 --> 00:09:22.800
So when thinking about autonomy, I want you to read the ladder from bottom up.

s159
00:09:22.800 --> 00:09:26.880
Suggest means the analyst receives a recommendation and chooses what to do with it.

s160
00:09:26.880 --> 00:09:30.320
Draft means the system prepares something the analyst checks and submits.

s161
00:09:30.320 --> 00:09:32.160
That is a highlighted step.

s162
00:09:32.160 --> 00:09:35.839
Acts with approval means a person authorizes each action before it happens.

s163
00:09:35.839 --> 00:09:39.760
Acts means the system operates within limits that have already been approved.

s164
00:09:39.760 --> 00:09:42.160
Each step changes the consequences of an error.

s165
00:09:42.160 --> 00:09:47.120
However, it also changes which controls must work and which reviewer needs to be convinced.

s166
00:09:47.120 --> 00:09:49.920
I would start at the lowest step that creates value.

s167
00:09:49.920 --> 00:09:51.360
Then collect evidence from there.

s168
00:09:51.360 --> 00:09:53.200
Are the reviews overriding the drafts?

s169
00:09:53.200 --> 00:09:54.560
Which failures keep recurring?

s170
00:09:54.560 --> 00:09:56.399
Can people recover when something breaks?

s171
00:09:56.399 --> 00:09:58.880
Use those observations to make the next authority decision.

s172
00:09:58.880 --> 00:10:02.240
A model does not become more capable by itself.

s173
00:10:02.240 --> 00:10:06.320
Answer how much authority this particular workflow should give it.

s174
00:10:06.320 --> 00:10:10.320
So now let's make that concrete with the same hypothetical exception assistant.

s175
00:10:10.320 --> 00:10:19.040
Suppose the initial request is an agent that reads client documents, decides which ones fall outside of policy, and files exceptions automatically.

s176
00:10:19.040 --> 00:10:25.279
In that design, the model's judgment can become an operational action without an analyst checking each case.

s177
00:10:25.279 --> 00:10:27.600
Now keep the model and change the action boundary.

s178
00:10:27.600 --> 00:10:32.079
It highlights a likely exception, points to the relevant source, and prepares a draft form.

s179
00:10:32.079 --> 00:10:36.160
The analyst checks the evidence, corrects the form, and chooses whether to submit.

s180
00:10:36.160 --> 00:10:37.920
Follow that sequence on the slide.

s181
00:10:37.920 --> 00:10:39.760
Model, human, submit.

s182
00:10:39.760 --> 00:10:42.800
I'll take that design to the people we found during discovery.

s183
00:10:42.800 --> 00:10:45.120
Can this use the analyst existing workflow?

s184
00:10:45.120 --> 00:10:47.680
Does the approved data access cover the processing?

s185
00:10:47.680 --> 00:10:49.040
Which controls apply?

s186
00:10:49.040 --> 00:10:51.360
And what evidence do the reviewers need?

s187
00:10:51.360 --> 00:10:56.880
Human review does not guarantee approval and it does not determine a regulatory category on its own.

s188
00:10:56.880 --> 00:11:00.399
We still have to confirm the intended use and the required reviews.

s189
00:11:00.399 --> 00:11:04.800
The useful question is whether this drafting version solves enough of the problems to ship first.

s190
00:11:04.800 --> 00:11:10.480
If it does, we can collect evidence about errors, overrides, and recovery while operating within that boundary.

s191
00:11:10.480 --> 00:11:14.079
The next decision about authority can draw on what happened in real use.

s192
00:11:14.079 --> 00:11:17.440
That makes the evaluation part of the operating plan.

s193
00:11:17.440 --> 00:11:19.839
And that brings us to our fourth promise.

s194
00:11:19.839 --> 00:11:26.959
An evaluation the risk team can use for evidence, which really just means the ones they're responsible for managing.

s195
00:11:26.959 --> 00:11:35.760
At Google, the question I needed answered was what happens when the system breaks, who notices, what stops, who takes responsibility, how long will it take to bring back up.

s196
00:11:35.760 --> 00:11:39.040
For an AI deployment, I want the same concrete account, right?

s197
00:11:39.040 --> 00:11:43.680
The intended use, a threat model, the failure modes, and a response plan.

s198
00:11:43.680 --> 00:11:47.600
Show me the controls working when the model gets something wrong.

s199
00:11:47.600 --> 00:11:50.959
Name the person who receives the alert and can stop the workflow.

s200
00:11:50.959 --> 00:11:54.800
That gives a practical way to evaluate our example.

s201
00:11:54.800 --> 00:11:58.959
So going back to our lovely example, the hypothetical exception assistant.

s202
00:11:58.959 --> 00:12:04.240
If it invents an exception, the analyst checks the source passage and rejects the draft.

s203
00:12:04.240 --> 00:12:08.880
If extraction produces unreadable text, stop and request a clean file.

s204
00:12:08.880 --> 00:12:13.120
If it misses exceptions, targeted offline cases help expose that weakness.

s205
00:12:13.120 --> 00:12:15.360
They do not detect every live miss.

s206
00:12:15.360 --> 00:12:17.279
Keep affected work under manual review.

s207
00:12:17.279 --> 00:12:20.959
For each failure, name the detection path, the fallback, and its owner.

s208
00:12:20.959 --> 00:12:23.200
Put those decisions in an evidence pack.

s209
00:12:23.200 --> 00:12:25.519
These five files make the review complete.

s210
00:12:25.519 --> 00:12:29.839
Intended use, record users, boundaries and prohibited actions.

s211
00:12:29.839 --> 00:12:44.959
Data lineage, records, each example source and use approval, failure modes, records detection and fallback, results by segment, record coverage and errors controls, record reviews, thresholds, stopping rules and owners.

s212
00:12:44.959 --> 00:12:48.240
So with all of this, we generate the evidence with each evaluation run.

s213
00:12:48.240 --> 00:12:56.560
alongside it preserve the input prompts model version configuration output reviewer action that lets us reconstruct the historical decision.

s214
00:12:56.560 --> 00:12:59.279
Calling the model again later may produce a different answer.

s215
00:12:59.279 --> 00:13:01.120
So we preserve what actually happened.

s216
00:13:01.120 --> 00:13:04.320
A reviewer can then expect that supporting record.

s217
00:13:04.320 --> 00:13:12.240
So now we can take a look to see like what exactly is being used to organize that result which is in the fourth file.

s218
00:13:12.240 --> 00:13:18.000
For a hypothetical workflow, I would separate clean documents, scans, rare exceptions, and new document types.

s219
00:13:18.000 --> 00:13:22.800
Measure the errors and control behaviors in each group, then lead with the weakest result.

s220
00:13:22.800 --> 00:13:25.360
An average can hide a serious gap in one segment.

s221
00:13:25.360 --> 00:13:30.800
If a group has a little evidence, say so and restrict that use until you have enough.

s222
00:13:30.800 --> 00:13:33.200
This tells reviewers what the results support.

s223
00:13:33.200 --> 00:13:36.959
And it also brings us back to our week one decisions.

s224
00:13:36.959 --> 00:13:41.200
Now, just rounding everything up by Friday, I want five answers.

s225
00:13:41.200 --> 00:13:44.160
Is the data owner engaged and aware of this project?

s226
00:13:44.160 --> 00:13:47.200
Are the production environment and its administrators named?

s227
00:13:47.200 --> 00:13:50.720
Can the sponsor describe the workflow without saying AI?

s228
00:13:50.720 --> 00:13:55.519
Can the smallest useful scope fit existing controls confirmed with their owners?

s229
00:13:55.519 --> 00:14:00.000
Do we know the risk signer and what happened to the person that signed last time?

s230
00:14:00.000 --> 00:14:02.000
Use those answers as a planning heristic.

s231
00:14:02.000 --> 00:14:04.880
Four or five yeses suggest a credible path to ship.

s232
00:14:04.880 --> 00:14:07.680
Three means unresolved decisions need owners and dates.

s233
00:14:07.680 --> 00:14:14.959
Zero to two means resolve this decisions before committing to delivery, including possibly shrinking scope or even redefining scope.

s234
00:14:14.959 --> 00:14:19.040
This score does not predict approval, but it does tell us where to spend the next week.

s235
00:14:19.040 --> 00:14:23.519
And here is what I would carry into these next conversations.

s236
00:14:24.240 --> 00:14:29.120
So to wrap this up, what I want people to walk away with is that discovery is the engineering.

s237
00:14:29.120 --> 00:14:31.120
Draft the spec, then shrink it.

s238
00:14:31.120 --> 00:14:33.600
Give the system only the authority it needs.

s239
00:14:33.600 --> 00:14:36.240
Build the evidence pack in sprint one.

s240
00:14:36.240 --> 00:14:37.360
The demo worked.

s241
00:14:37.360 --> 00:14:38.639
The model was fine.

s242
00:14:38.639 --> 00:14:40.079
It still did not ship.

s243
00:14:40.079 --> 00:14:41.199
So what do we do?

s244
00:14:41.199 --> 00:14:43.839
We go find the people.

s245
00:14:43.839 --> 00:14:46.399
Thank you for going through this presentation with me.

s246
00:14:46.399 --> 00:14:47.839
My name is Peyton Gail.

s247
00:14:47.839 --> 00:14:52.000
I am a founding for deployed engineer writing the book on FTE for O'Reilly.

s248
00:14:52.000 --> 00:14:55.839
And yeah, love to talk about FTE and everything related to it.

s249
00:14:55.839 --> 00:15:02.639
If that's of interest, you can find me on LinkedIn or my website painting.com has all of my information.

s250
00:15:02.639 --> 00:15:07.920
Thank you again for watching today and yeah looking forward to