WEBVTT

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

NOTE One cue per sentence. Cue ids are the line anchors on /transcripts/zCJtYuqwm7E.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.560 --> 00:00:14.000
Well, welcome.

s3
00:00:14.000 --> 00:00:16.600
Um last day, I guess.

s4
00:00:16.600 --> 00:00:18.200
That's what happens.

s5
00:00:18.200 --> 00:00:23.840
Um I'm going to talk to you maybe not on the technical side, but more on the organizational side.

s6
00:00:23.840 --> 00:00:30.000
So, if you're here for any technology, you can still leave if you want to.

s7
00:00:31.480 --> 00:00:38.360
So, in 2009, um a lot of people were telling me the idea of continuous delivery was crazy.

s8
00:00:38.360 --> 00:00:44.760
And I feel we're in kind of the same era or kind of the same thing right now with a dark factory.

s9
00:00:44.760 --> 00:00:46.560
It will not work here.

s10
00:00:46.560 --> 00:00:50.160
That's what I keep hearing over and over again.

s11
00:00:50.160 --> 00:00:54.280
Um but what they're actually signaling to me, we're not ready yet.

s12
00:00:54.280 --> 00:00:56.960
So, it's not the technology that can't make it work.

s13
00:00:56.960 --> 00:01:04.080
It's not something they won't be able to do eventually, but they're just not set up for this.

s14
00:01:04.160 --> 00:01:13.080
And there's been a lot of conference talks here about optimizing agents with loops and harnesses and all those pieces, and I think that's great.

s15
00:01:13.080 --> 00:01:15.280
But eventually, we'll get there, right?

s16
00:01:15.280 --> 00:01:17.600
It's not that this is the rocket science.

s17
00:01:17.600 --> 00:01:24.880
And yes, we'll have to assemble this in a good way, but one day, this will kind of become commodity.

s18
00:01:24.880 --> 00:01:32.840
Somewhere maybe even going into one of the, you know, frontier labs that just offers this as a service and will kind of make this work.

s19
00:01:32.840 --> 00:01:38.080
Uh and that's not going to be the differentiator um for your organization.

s20
00:01:38.080 --> 00:01:41.000
So, I'm starting from there up.

s21
00:01:41.000 --> 00:01:48.320
Assume we're heading towards the dark factory, some kind of form of autonomous working within an organization.

s22
00:01:48.320 --> 00:02:00.400
Um what I've seen for the people adopting this within our organization, including here where I work at Tessal, it changes dynamic of the way you collaborate around us.

s23
00:02:00.400 --> 00:02:12.080
And for those familiar, there's like Conway's Law, like, you know, the way you organize yourselves and the tools, there is a relationship on how they interact and kind of work together on this.

s24
00:02:12.080 --> 00:02:22.120
But today, I'm not talking about like how do you become better with your agent, but it is about how will will change your team dynamics, your platform, and your organization.

s25
00:02:22.120 --> 00:02:25.200
So, that's what I'll take you through.

s26
00:02:26.240 --> 00:02:27.280
Enabling the team.

s27
00:02:27.280 --> 00:02:31.961
I assume most of you somewhere work in a team and that you're not somewhere a solopreneur

s28
00:02:31.961 --> 00:02:32.480
[music]

s29
00:02:32.480 --> 00:02:33.360
working.

s30
00:02:33.360 --> 00:02:45.520
So, it kind of works different than just you with your Claude code and a team working together around that with Claude or any of the coding agents there as well.

s31
00:02:46.680 --> 00:02:56.800
The narrative that I heard a lot is well, the developer eventually becomes more of a conductor and an orchestrator of agents.

s32
00:02:56.800 --> 00:02:58.080
And then I think that's fair.

s33
00:02:58.080 --> 00:03:06.120
That's been an evolution that we're on on the path where more like becoming the managers of the agent, they're kind of dealing with the agents.

s34
00:03:06.120 --> 00:03:12.840
Now, what I've seen is that if eventually a lot of developers told me, "We didn't sign up for this.

s35
00:03:12.840 --> 00:03:16.560
We didn't sign up for better prompting, writing better specs.

s36
00:03:16.560 --> 00:03:17.680
We're engineers.

s37
00:03:17.680 --> 00:03:18.920
We're technical."

s38
00:03:18.920 --> 00:03:24.680
And that creates friction, like, is this the role that we really want to do?

s39
00:03:24.680 --> 00:03:33.280
There was a thing that came around which maybe is more context engineering that put a first step around like, "Hey, it's not just a prompt.

s40
00:03:33.280 --> 00:03:34.480
We'll test the prompt.

s41
00:03:34.480 --> 00:03:36.680
We'll kind of evaluate the prompt.

s42
00:03:36.680 --> 00:03:39.920
We'll kind of distribute the prompt and kind of optimize the prompt."

s43
00:03:39.920 --> 00:03:51.200
So, yes, there's a little bit of engineering, but still a lot of developers kind of felt empty just working kind of with a prompt and a specification as such.

s44
00:03:51.200 --> 00:04:02.960
What I've seen is that when we started introducing harness and loops and eventually more autonomous work within the whole organization, a new technical path opened.

s45
00:04:02.960 --> 00:04:14.800
All of a sudden, we were helping the agent with tooling, building tooling for the agent, and that kind of reignited some of the developers who kind of felt that it wasn't for them.

s46
00:04:14.800 --> 00:04:17.560
Now, all of a sudden, they were like, "Yes, we can do this.

s47
00:04:17.560 --> 00:04:18.519
We have that knowledge.

s48
00:04:18.519 --> 00:04:23.560
We're like somehow helping this even with a kind of programmatic way."

s49
00:04:23.560 --> 00:04:37.200
So, I I think that's interesting that the identity, where we say abstraction, abstraction, abstraction, technically, all of a sudden, the craft created some new location for more engineering stuff to go to.

s50
00:04:37.480 --> 00:04:42.680
Now, when I get the question, "Can we please help people?"

s51
00:04:42.680 --> 00:04:45.520
And there's skeptical people, what do they do?

s52
00:04:45.520 --> 00:04:57.040
And I always really say that these are really great people to engage in creating better context for the agent because you tell them, "Please improve.

s53
00:04:57.040 --> 00:05:00.520
Please put all your knowledge to improve the result of the agent."

s54
00:05:00.520 --> 00:05:02.080
And the same with the harness.

s55
00:05:02.080 --> 00:05:16.840
So, if you have those kind of more resistant people that like complain maybe about the quality that things were produced by just the vanilla kind of coding agent, use almost that anger, use kind of that skepticism

s56
00:05:16.840 --> 00:05:19.560
to kind of make it better.

s57
00:05:20.480 --> 00:05:34.680
And the big mentality shift, if I would advise a a a a company right now for their developers, is kind of stop fixing the code that the agent kind of produced,

s58
00:05:34.680 --> 00:05:36.640
but improve the system.

s59
00:05:36.640 --> 00:05:41.760
I'm I have I'm not the only one saying this in this event, but kind of that is the difference.

s60
00:05:41.760 --> 00:05:43.800
Like you kind of improve the system.

s61
00:05:43.800 --> 00:05:51.080
And I think it was Swyx uh a couple of years who said it, like stop building the thing, but build the thing that builds the thing, right?

s62
00:05:51.080 --> 00:05:56.600
So, we going on that abstraction where that is with context, with harness, with loops.

s63
00:05:56.600 --> 00:06:09.640
And that is kind of the change that a lot of people who are still very tightly in the loop, auto completion, prompting, that they kind of need to think about elevating this to the system thinking.

s64
00:06:09.640 --> 00:06:19.840
So, what we're really trying to do is minimize the human touches, but still with good engineering practices.

s65
00:06:19.840 --> 00:06:23.480
And some of the narrative that comes up more often in the beginning, we're like, "Oh, great.

s66
00:06:23.480 --> 00:06:27.480
I write code in a prompt, and then it gives a result, and we can keep going."

s67
00:06:27.480 --> 00:06:37.040
Where we now see, well, we're kind of instructing it through prompts, but we're also instructing this like, "Please do it with tests.

s68
00:06:37.040 --> 00:06:39.040
Please update the documentation.

s69
00:06:39.040 --> 00:06:39.800
Please do this."

s70
00:06:39.800 --> 00:06:45.720
All the things that we're saying to good engineers, we're now asking the agents to do.

s71
00:06:45.720 --> 00:06:53.000
So, if you still have people who kind of yoloing their way into this, I think you should tell them, "No, stop doing this."

s72
00:06:53.000 --> 00:07:02.520
Like, engineering practices still matter for you to maintain the system, and also for the agent to keep getting better at this.

s73
00:07:03.960 --> 00:07:15.400
What I started seeing in some of the more advanced kind of teams is that their rituals of "Hey, we're doing a planning, and we're doing a retro in a team."

s74
00:07:15.400 --> 00:07:19.080
That they weren't about like, "Hey, we had issues with the code."

s75
00:07:19.080 --> 00:07:22.480
But we're saying, "We had issues with the system."

s76
00:07:22.480 --> 00:07:29.400
So, on the retro part is like, "Hey, the agent went over and over hit this problem.

s77
00:07:29.400 --> 00:07:31.080
Can we fix the system?"

s78
00:07:31.080 --> 00:07:33.520
That's something you'll learn in the retro.

s79
00:07:33.520 --> 00:07:46.160
And on the planning side, what I started seeing is that things who were that were sufficiently scoped enough were easy to pick up by agents because they were well-defined

s80
00:07:46.160 --> 00:07:51.280
and what still was left for the humans were the things that weren't scoped out well.

s81
00:07:51.280 --> 00:08:00.080
So, we were like a split in the planning where we said, "These things can straight go into agents, well-defined, and the harness is getting better, and this is conversational

s82
00:08:00.080 --> 00:08:03.480
things that we need to decide as a team."

s83
00:08:04.200 --> 00:08:12.600
And what I find important is you there's a certain kind of cycle that developers go through.

s84
00:08:12.600 --> 00:08:18.200
Yes, they learn first about prompting, they get better, specs, context, harness loop.

s85
00:08:18.200 --> 00:08:20.800
Also, the industry is learning like that.

s86
00:08:20.800 --> 00:08:27.400
But, there is the lead of the team can say, "Well, stop prompting.

s87
00:08:27.400 --> 00:08:29.320
Make the context reusable."

s88
00:08:29.320 --> 00:08:30.240
Now, we got that.

s89
00:08:30.240 --> 00:08:31.360
Now, we jump to the next.

s90
00:08:31.360 --> 00:08:45.400
So, part of the team lead is putting that pace and almost that constraint and that directive in the team where it is doesn't work where you just say, "Go figure it out and do something on your own."

s91
00:08:45.640 --> 00:08:58.760
And one of the impacts of that is that if you start producing as a team more, the people downstream, GTM, people like that, they have a hard time keeping up.

s92
00:08:58.760 --> 00:09:00.720
Even users have a hard time keeping up.

s93
00:09:00.720 --> 00:09:02.720
So, you need to help them also with automation.

s94
00:09:02.720 --> 00:09:05.560
So, your harness doesn't stop at your coding.

s95
00:09:05.560 --> 00:09:09.200
It also is extended to those people as well.

s96
00:09:09.200 --> 00:09:16.880
And the same thing with kind of requiring uh like gathering requirements, the input might not come fast enough for your team.

s97
00:09:16.880 --> 00:09:22.280
So, that's another kind of piece that you need to tap into that workflow as well.

s98
00:09:24.040 --> 00:09:30.640
There's a lot of metrics that people are saying like, "Hey, is your like tokens spend and all that stuff?"

s99
00:09:30.640 --> 00:09:37.840
I started to believe in these two metrics kind of see on how to be more productive.

s100
00:09:37.840 --> 00:09:46.600
One is you start measuring how many human touches you still do to have the agent do the right thing.

s101
00:09:46.600 --> 00:09:53.040
That's supposed to go down the better your harness is, the better your context is, the better your guidelines are.

s102
00:09:53.040 --> 00:10:01.920
And on the other hand, if you're going from solo to shared system, that becomes a multiplier.

s103
00:10:01.920 --> 00:10:05.800
You fix something once, everybody gets the benefit.

s104
00:10:05.800 --> 00:10:16.680
This is not the multiplier from the one person becoming the 10x person, but the one change that optimized the agents has an impact on all the people.

s105
00:10:16.680 --> 00:10:25.200
So, that is kind of the part that we're all You can start that in a team working together within your repo, sharing the context, working on a harness.

s106
00:10:25.200 --> 00:10:28.560
But what you basically want to do is you want to scale this out.

s107
00:10:28.560 --> 00:10:32.280
So, you come into the realm of the platform people, right?

s108
00:10:32.280 --> 00:10:36.960
Because they're the typical shared organization working on this.

s109
00:10:36.960 --> 00:10:46.560
Now, the platform people, they might not be paying close attention because they're like infrastructure and cloud and working on like MCP gateway and stuff like that.

s110
00:10:46.560 --> 00:10:49.839
But there's new things like bubbling up there.

s111
00:10:49.839 --> 00:10:59.440
They need to think about like maybe skill registries or eval systems for your context and guardrails specifically for coding agents and identities and stuff.

s112
00:10:59.440 --> 00:11:04.440
So, they need maybe a little bit of a hand kind of growing to that role.

s113
00:11:04.440 --> 00:11:10.520
And that kind of central role, it's hard.

s114
00:11:10.520 --> 00:11:15.800
You need an owner to drive that program, but is it the platform team?

s115
00:11:15.800 --> 00:11:17.839
Is it developer experience team?

s116
00:11:17.839 --> 00:11:24.040
They don't typically own any of those pieces of the infrastructure and the other people don't really do the development.

s117
00:11:24.040 --> 00:11:34.320
So, there's somewhere a blend, but you need to kind of make sure that there's an owner driving this centralized piece and not just within your team.

s118
00:11:34.320 --> 00:11:36.720
Because you won't have paved roads.

s119
00:11:36.720 --> 00:11:38.280
And that's how I see it.

s120
00:11:38.280 --> 00:11:40.880
Reusable context across teams.

s121
00:11:40.880 --> 00:11:44.520
Why are we all inventing how we do the authentication system?

s122
00:11:44.520 --> 00:11:44.920
Right?

s123
00:11:44.920 --> 00:11:46.400
This is a shared component.

s124
00:11:46.400 --> 00:11:48.320
Let's put it in the registry.

s125
00:11:48.320 --> 00:11:50.800
Why are you building all your harnesses?

s126
00:11:50.800 --> 00:11:55.720
Well, if we're all using the same linters and the same security tools, that's a reusable component.

s127
00:11:55.720 --> 00:12:04.760
So, I think that will centralize similar to the paved path for cloud into that platform registry of reuse.

s128
00:12:05.480 --> 00:12:13.960
But, if everybody can put stuff like on the internet in a repo, it becomes a sprawl.

s129
00:12:13.960 --> 00:12:18.600
And it becomes a thing like, well, he has a skill, he's maintaining it.

s130
00:12:18.600 --> 00:12:22.200
That person is also has a similar skill and forked it.

s131
00:12:22.200 --> 00:12:23.200
Now, what I do?

s132
00:12:23.200 --> 00:12:25.400
Like, which one do I pick?

s133
00:12:25.400 --> 00:12:30.400
So, there is a kind of thing that you say, there's an owner for this area.

s134
00:12:30.400 --> 00:12:33.440
And they also care about making it testable.

s135
00:12:33.440 --> 00:12:40.440
They make sure that it's modular, that other people can extend kind of the context, for example, or the harness, that it's security scanned.

s136
00:12:40.440 --> 00:12:52.480
So, you build kind of a more centralized and the fact that it's secured and kind of maintained as something instead of just something I share around in my organization.

s137
00:12:52.680 --> 00:12:54.800
Now, that consensus is hard.

s138
00:12:54.800 --> 00:12:59.320
I'm not saying this is tabs versus spaces, but at times it feels like that.

s139
00:12:59.320 --> 00:13:07.160
If you have two developer teams having to have consensus on the how the way they work, that requires a lot of communication and brokerage.

s140
00:13:07.160 --> 00:13:13.760
So, you probably don't end up with one thing, but a catalog of three, four paved roads where they can pick off.

s141
00:13:13.760 --> 00:13:17.480
And they can still do their own, but that's on their own budget.

s142
00:13:17.480 --> 00:13:18.400
Right?

s143
00:13:18.400 --> 00:13:26.120
The centralized pieces will be maintained, and that is supposed to be the easy way of adoption to go there.

s144
00:13:26.200 --> 00:13:33.360
Now, if they do this blindly, we also want to make sure that they know what it costs.

s145
00:13:33.360 --> 00:13:38.840
Because if we visualize the cost, they might be eager to do some optimization in there.

s146
00:13:38.840 --> 00:13:39.360
Right?

s147
00:13:39.360 --> 00:13:43.240
And that kind of is part of the platform team is making that visible.

s148
00:13:43.240 --> 00:13:44.440
How much is he spending?

s149
00:13:44.440 --> 00:13:46.520
How much is that kind of like helping?

s150
00:13:46.520 --> 00:13:52.680
If I can reduce the number of iterations the agent has to run through, that is an optimization that I can run.

s151
00:13:52.680 --> 00:13:57.800
But if I don't visualize that and I just see the end result, then we don't know, right?

s152
00:13:57.800 --> 00:14:01.240
So, that is part of the platform team helping people.

s153
00:14:01.240 --> 00:14:13.480
And so, what I'm arguing is that we should somewhere move from the solo developer to the team shared kind of context and pieces to a multiplayer system in the organization.

s154
00:14:13.480 --> 00:14:17.440
And I think that's where the multiplication effect will happen.

s155
00:14:17.440 --> 00:14:17.760
Right?

s156
00:14:17.760 --> 00:14:24.320
Because you're have this flywheel of improvements that go into multiple directions.

s157
00:14:25.560 --> 00:14:31.680
Now, one layer higher, the VP of Engineering says, "How do I enable the organization?"

s158
00:14:31.680 --> 00:14:32.360
Right?

s159
00:14:32.360 --> 00:14:37.360
And that is that I you know, I can predict the story in your organization.

s160
00:14:37.360 --> 00:14:43.280
Hackathon, a lunch and learn, let's share the successes, have a shared Slack channel, have a champions program.

s161
00:14:43.280 --> 00:14:45.200
That's all generic transformation.

s162
00:14:45.200 --> 00:14:47.240
It could have been Agile that transformed like that.

s163
00:14:47.240 --> 00:14:48.240
It could have been DevOps.

s164
00:14:48.240 --> 00:14:49.560
It doesn't matter.

s165
00:14:49.560 --> 00:15:01.200
And on the other side, we know that the strategy of just, you know, give life to something and educate people, do something, let a thousand flowers bloom, it doesn't work.

s166
00:15:01.200 --> 00:15:11.280
So, what I'm advocating is that the kind of on the organizational is that you give the team leads and the platform that mandate to start doing that work.

s167
00:15:11.280 --> 00:15:14.720
And it's not the solo developer piece.

s168
00:15:15.200 --> 00:15:21.920
Now, finding people that help you externally is is mess.

s169
00:15:21.920 --> 00:15:29.800
Yes, we have all the titles, the new job titles, AI product engineer, forward deployed engineer, you know, there was a whole talk on this, agentic engineer, AI engineer.

s170
00:15:29.800 --> 00:15:32.320
It doesn't mean anything.

s171
00:15:32.320 --> 00:15:40.240
You cannot judge whether what the kind of the maturity of this because nobody's really that mature.

s172
00:15:40.240 --> 00:15:47.200
But it's a signal when you put a job posting out there that people might with the new intention will be looking there.

s173
00:15:47.200 --> 00:15:51.240
But it's not a validation of the skills as such, right?

s174
00:15:51.240 --> 00:15:57.520
So that is challenging for people um kind of hiring people.

s175
00:15:57.720 --> 00:16:10.760
Now, they come to the interview and I heard stories about uh people using AI to reflect uh in their ears be response to the interview person and stuff like that.

s176
00:16:10.760 --> 00:16:22.520
I think what what I hear from most companies is they say first step is we give them an exercise and we want them to really go nuts on the AI to solve this.

s177
00:16:22.520 --> 00:16:25.880
You know, if they have help from AI, that's all good.

s178
00:16:25.880 --> 00:16:32.000
That shows you kind of like how much they can kind of leverage the AI to do this.

s179
00:16:32.000 --> 00:16:38.080
Now, after they pass this, you do a walk-through and you actually say, "Please explain me what happened.

s180
00:16:38.080 --> 00:16:40.080
Why is this a good idea?"

s181
00:16:40.080 --> 00:16:45.400
That's where you are testing the taste and the engineering skills on why they're doing this.

s182
00:16:45.400 --> 00:16:47.960
First part AI, then engineering.

s183
00:16:47.960 --> 00:16:51.440
And this third thing is how do you collaborate?

s184
00:16:51.440 --> 00:16:52.560
Are you willing to share?

s185
00:16:52.560 --> 00:16:54.960
Are you open or are you a solo player?

s186
00:16:54.960 --> 00:16:57.800
That's another signal that you tap into.

s187
00:16:57.800 --> 00:16:58.240
Right?

s188
00:16:58.240 --> 00:17:05.640
But that fits into that whole thing of like making it shareable, making it reusable, making it engineering grade within our organization.

s189
00:17:05.640 --> 00:17:13.959
Those are the people that you look for, not people who studied ML or AI, not people who are like experts per se at the coding.

s190
00:17:13.959 --> 00:17:15.480
There's a blend on this.

s191
00:17:15.480 --> 00:17:25.560
Now, you might not find a person who has all three, which is okay, but at least you know, like, hey, they're very savvy on this piece, but then for the other piece, they need mentoring

s192
00:17:25.560 --> 00:17:27.160
and they need tutoring.

s193
00:17:27.160 --> 00:17:33.160
But, like, don't put all the three pieces into one kind of saying like they're junior or they're senior.

s194
00:17:33.160 --> 00:17:36.600
They have like different skills on there.

s195
00:17:36.880 --> 00:17:46.680
Now, the VP of Engineering has to defend this and they would uh have to make the case, right?

s196
00:17:46.680 --> 00:17:49.080
Well, we have X amount of licenses that we sold.

s197
00:17:49.080 --> 00:17:52.800
We have faster delivery, maybe they they can promise, but hard to prove.

s198
00:17:52.800 --> 00:17:56.800
We have quality that improved, again, hard to say.

s199
00:17:56.800 --> 00:18:09.760
But, similar to what I said with the metrics of how effective are your agents, you can show that how much turns and how much improvement that you're making on that journey.

s200
00:18:09.760 --> 00:18:12.640
And same thing, how much there is reuse.

s201
00:18:12.640 --> 00:18:24.280
So, it's an easier way to kind of show metrics than comparing productivity with and without agent decoding that help you in kind of those discussions as well.

s202
00:18:24.280 --> 00:18:36.160
And so, when people say, uh the vendors are charging completely nuts, so we're going to limit the spends, you shouldn't say like, let's limit all the spends.

s203
00:18:36.160 --> 00:18:53.720
Your reflection should be, let's optimize the spend and help them kind of reduce that uh in a good way, where that's as simple as saying, pick the right model, educate them on the model, but also on like giving them better context and harnesses because that will make your cost go down there as well.

s204
00:18:55.000 --> 00:19:01.320
The debate around smaller and bigger teams, yes, it's nice to have like one person who can do it all.

s205
00:19:01.320 --> 00:19:02.640
That's the ultimate dream.

s206
00:19:02.640 --> 00:19:04.680
They can do everything.

s207
00:19:04.680 --> 00:19:09.720
Typically, they're paired with a complementary skill, maybe PM, design, and so on.

s208
00:19:09.720 --> 00:19:15.480
Okay, then we need a backup if one of them is on holiday so that amounts back to three.

s209
00:19:15.480 --> 00:19:20.200
And then maybe somebody has to care about production and tickets coming in.

s210
00:19:20.200 --> 00:19:28.640
Could be the same people if you're really productive, but yeah, you know, you lose speed of features if you're still doing bugs and that depends a little bit on your quality.

s211
00:19:28.640 --> 00:19:37.080
And then there's the junior you want to get on the road as well to kind of make sure they're still learning what good looks like in one of those three areas.

s212
00:19:37.080 --> 00:19:46.000
So, I think we're still limited in the way in an organization that we're not going to each team being a solo or one or two.

s213
00:19:46.000 --> 00:19:48.840
Yes, a lot of experience, but I think that is the thing.

s214
00:19:48.840 --> 00:19:53.800
Now, we keep investing in actually education for that piece as well.

s215
00:19:53.800 --> 00:19:58.720
So, one of the final things is the dark factory, which is probably a dim factory.

s216
00:19:58.720 --> 00:20:01.640
You have to see what risk you're willing to take for what features.

s217
00:20:01.640 --> 00:20:14.840
So, not all features will become autonomous, but you can invest more in auditing like problems, like who changed the code, verifiers that kind of check whether that code was useful and when it fails,

s218
00:20:14.840 --> 00:20:17.040
you invest in situational awareness as well.

s219
00:20:17.040 --> 00:20:29.600
So, there's a whole spectrum from being a micro manager to being on a autonomous approval that everything kind of is correct, but you make the decision on what your risk level is.

s220
00:20:29.600 --> 00:20:32.520
And I think your mode is capturing the knowledge.

s221
00:20:32.520 --> 00:20:32.720
Right?

s222
00:20:32.720 --> 00:20:41.520
The knowledge you're putting now into skills, you're in your context, and maybe in your harness, the way you kind of restrain this, your business context.

s223
00:20:41.520 --> 00:20:47.080
And for me, that kind of brings continuous delivery actually to continuous learning.

s224
00:20:47.080 --> 00:20:55.160
And if you ask the question of how fast can we swap in swap out something new, that's your reactive mode.

s225
00:20:55.160 --> 00:21:06.160
And if you can improve that ultimately, it's not about making the whole system more reliable, but can I keep it reliable while changing more of the system.

s226
00:21:07.000 --> 00:21:13.360
I'm working on a website that kind of where I try to list some of the agent enablement patterns that I described.

s227
00:21:13.360 --> 00:21:16.800
I couldn't list them all within this time.

s228
00:21:16.800 --> 00:21:18.080
Tell me what you're missing.

s229
00:21:18.080 --> 00:21:20.360
I'm trying to source social kind of stories.

s230
00:21:20.360 --> 00:21:29.080
So, if you have a story of how things are going in your organization, please tell me and I am happy to put on a link in there as well.

s231
00:21:29.080 --> 00:21:33.560
And if you're interested in kind of the slides, happy to share those.

s232
00:21:33.560 --> 00:21:39.480
And I think if there's one takeaway, it's not the solo player that will win the game.

s233
00:21:39.480 --> 00:21:43.720
It's kind of like at the different levels how we improve our organizations.

s234
00:21:43.720 --> 00:21:48.049
Thank you very very much for listening and I hope it was useful.

s235
00:21:48.049 --> 00:21:50.049
[applause]

s236
00:22:03.770 --> 00:22:05.770
[music]