We often assume that resolving a major outage requires centralised command and control—getting the right experts in a room, coordinating their efforts, and directing the recovery. But what if the most important thing an incident commander can do is resist that impulse entirely, and simply create space for the right person to surface?

That's the situation Liz Fong-Jones found herself in during a July 2018 Google Cloud outage that took down nearly every service—not just Google's own, but every customer running on Google Cloud. As incident commander, Liz had the war room assembled, the escalation path triggered, and the right teams on the call. What broke the incident open was none of that. It was an engineer nobody had thought to page, who called in unprompted, said "I think this was my change," and had already started rolling it back.

That moment was only possible because of something built long before the outage: a culture where people don't hide under their desks when things break. Liz traces how psychological safety gets constructed—not in crises, but in how organisations respond to smaller failures every day. She shares the quiet signals that reveal when it's missing (the call that goes silent after an acronym nobody understands, the junior engineer who never speaks), and the heuristics she uses to build it deliberately as a senior engineer.

This conversation goes beyond incident response to explore what it actually means to build resilient systems and resilient people—and why those two things are inseparable.

Key Discussion Points

• [00:01] The July 2018 Google Cloud Outage: Liz introduces her role as a volunteer incident commander and the scale of the incident—nearly every Google Cloud service down simultaneously
• [06:00] The Fix That Came From Outside the War Room: An engineer nobody had thought to page calls in, identifies their change, and has already started the rollback before the room knows what's happening
• [12:00] Why a Safety Feature Caused a System-Wide Failure: How a canary deployment designed to limit blast radius instead pushed metadata globally—and triggered a bug in every front end
• [17:00] Distributed Debugging and the Limits of Centralisation: Why the person holding the critical piece of information is rarely in the escalation room, and how you design for that
• [22:00] Psychological Safety Built Before the Crisis: Why the engineer's willingness to raise their hand depended entirely on how the organisation handles smaller failures day-to-day
• [28:00] The Quiet Signals That Reveal Fear: Silence after acronyms, juniors who never speak, decisions nobody will revisit—how Liz reads the room for safety
• [34:00] Design Ownership and Haunted Graveyards: Why accountability for running a system long-term requires input into its design—and what happens when it doesn't exist
• [40:00] Building Resilient People, Not Just Systems: If an organisation crushes someone when they make a mistake, they won't be resilient the next time something breaks—and something always breaks

Guest: Liz Fong-Jones Hosts: Andrea Magnorsky, Kenny Schwegler

Hello.

2

Good morning, good afternoon, good

evening, good night, wherever you are.

3

we're back to another stories

of facilitating software

4

architecture and design with me, my

co-conspirator, Andrea MCN Norski,

5

and today we have Liz Fong Jones.

6

And, I'm very curious,

about your story today.

7

Welcome.

8

Liz Fong-Jones: Thank

you for having me on.

9

So, this story is a, Google S3 war story.

10

So it was, July, 2018 and I had just

joined the Google Wide Incident Management

11

Program, as one of the volunteers.

12

my pagers started going off because

a bunch of Google Cloud was down.

13

People couldn't connect

to Google Cloud Backends.

14

they were just seeing timeouts

or error messages and.

15

People are not having a great time.

16

So I hopped on, to the incident

bridge and became the incident

17

commander for this incident.

18

so.

19

Many companies, have these kind

of centralized incident management

20

groups, that kind of handle overarching

response to very broad outages,

21

and Google is no exception to that.

22

at any time there are probably, I think

30 or 40 people scattered all around the

23

world, who are available at a moment's

notice to jump in, in case there's

24

some kind of widespread, incident that

no single team at Google can solve.

25

And one other useful thing to note here

is that I had previously, worked on the

26

piece of software that was implicated in

this, um, that I previously had worked on

27

the Google Front end, which is basically

the giant, giant, giant, reverse proxy

28

that handles requests for google.com.

29

docs@google.com.

30

Basically anything@google.com,

31

it flows through the, Google Front end.

32

So, was on this, uh, tragic, tragic

day, there was an alert that went

33

off that basically said almost every

single Google Cloud service is down.

34

Um, that the, that, you know, we're not

answering requests for cl cloud to go.com.

35

It didn't just affect Google services, it

affected services of every single customer

36

that was using Google Cloud as well.

37

and the set of teams that was

initially brought in, right, like

38

was obviously the team responsible

for, the Google front end, right?

39

Like both the development team for

it as well as the, traffic team,

40

the set of people who handle the

kind of load balancing and routing

41

and kind of all these front end

pieces that are required to get your

42

request from point A to point B.

43

But when they realized that, it was,

you know, not just their own services,

44

not just Google Web search, but that

it was Google Cloud's customers,

45

that it, you know, there were, there

were dozens of services impacted.

46

they signaled a, a Google wide escalation

and that's where I got brought in.

47

so I was the, first incident

that I worked as part of the,

48

central incident management team.

49

it's a volunteer position I should add.

50

And it's not a full-time position.

51

you have other responsibilities too.

52

And this outage lasted about 30 minutes,

and a lot of what we were doing was not

53

necessarily hands and keyboard fixing,

but just communicating, keeping people

54

in the loop as to what was going on.

55

Communicating with executives,

communicating with stakeholders,

56

communicating with, Google cloud

reps who were having to explain to

57

their customers what was going on,

as well as, you know, doing some

58

air cover for the impacted team.

59

And what I think is really interesting

about this incident, that I

60

wanted to highlight here is that.

61

This incident was not resolved by, you

know, the set of people in the, in the

62

war room or on the escalation call.

63

finding the solution together and like

deploying the fix, the fix to this evolved

64

in parallel with the escalation room.

65

Um, and it didn't take people in

the escalation room fixing it.

66

Instead, we had someone raise their hand

and call into the escalation room, who

67

we would not have thought to tag in.

68

And they said, I think this was

my change that did this, and I've

69

already started rolling it back.

70

Right.

71

I think this was a really, really

classic example of two things, right?

72

Like it's an example of.

73

Distributed debugging where

everyone potentially holds the

74

answer to it in their head, right?

75

Like that you cannot kind of

centralization of your incident band.

76

And secondly, it's a really, really

important lesson about psychological

77

safety, This was not an environment where

the engineer might have hidden under the

78

desk or tried to cover up evidence of the,

of the change that they pushed because

79

they were afraid of being fired, right?

80

Like they.

81

in, right?

82

Like they, they called into

the bridge and said, Hey, like,

83

you know, this was my fault.

84

Right?

85

know, don't love the word fault, right?

86

Like, you know, we try to

be, you know, blame aware.

87

We try to emphasize that, you know,

the fact that you as an individual

88

can, you know, make a, can, make a

mistake, indicates that there's some

89

kind of systematic flaw on the system.

90

But regardless, right, like, you know,

this person felt safe enough to raise

91

their hand to self-correct the error,

and also to tell everyone else about

92

it so that we could stop, looking

around for the root cause, right?

93

and there's heap of details as to,

you know, how exactly it happened.

94

you know, and the best I can probably

do for you there is to point you to

95

the, public Google retrospective, which

goes into some degree of depth about it.

96

but I think, you know, from

a engineering leadership.

97

right?

98

Like the details of how this incident

manifested don't matter quite as much

99

as kind of the people lessons about

how you structure resilience and

100

how you structure incident response.

101

So I imagine that might raise some

questions for you, Andrea and Kenny.

102

What would you like to dive into?

103

Kenny Schwegler: Let Andrea go first.

104

Andrea Magnorsky: Oh, okay.

105

This is, this is,

106

Kenny Schwegler: of questions.

107

Andrea Magnorsky: this is awesome

because I, I, I love it that, kind of

108

hearing the story of it happening and.

109

You talked about two things.

110

First, you talked about rigid debugging

and the psychological safety needed

111

for this person to step up and say,

Hey, I think I know what's going on.

112

I'm running it back.

113

But you know, one of the first

questions is like, how did

114

you, how did you validate?

115

'cause I mean, until this person goes

and undo something, which could be just

116

revert last pr, literally undeployed.

117

But in the meantime, it could

be that that's not the course.

118

It could be one contributing

course, or, you know, they could

119

have been wrong, basically.

120

a what happened in the, in the

confusion stage would be my, my

121

question from a facts point of view,

and I have a follow up question.

122

Liz Fong-Jones: I think the symptom

that people observed was that, they

123

were either, you know, getting timeouts

or that they were getting responses

124

saying that, you know, none of the

front ends or back ends were healthy.

125

and it took us definitely, you're

right, it took us some time

126

to recover from this, right?

127

Like, you don't go from a hundred

percent down to a hundred percent up,

128

immediately when you deploy a fix.

129

but the thing that I think we

were able to validate was some

130

leading indicators, right?

131

this particular bug, was a bug that

caught that, that resulted in the

132

Google front ends that were serving

requests for, Google Cloud resources.

133

Those were crashing when they

encountered this unexpected input.

134

So when the developer deployed the fix

that resulted in those front ends no

135

longer receiving the invalid input,

the crashing stopped immediately.

136

Right.

137

We had other problems like, not enough

backends available to serve, right?

138

Like thundering herds.

139

too much pressure on the

backends that wore up.

140

But like over time we could start

to see the number of available

141

front end stabilizing, right?

142

Like, and that was kind of the sign

that we were on the right track.

143

but yeah, I think the other thing here

was that, you know, obviously it's a

144

lot better to have some kind of idea

of mechanism of causation, right?

145

Like if you, if something fixes itself

and you have no idea why, right?

146

Like, you have no idea whether or

not it's gonna come back, right?

147

But you have an explanation of,

oh, you know, this bad data tickled

148

this, this other bug, right?

149

Like, then that's something

you can actually validate.

150

That's actually something,

something that you can check.

151

Andrea Magnorsky: Yeah.

152

Okay.

153

Liz Fong-Jones: I think the other

thing here, right, like is if you

154

just default to reverting whatever,

whatever happened, you know that put

155

the system into an end stable state,

most of the time you will be correct.

156

You'll be able to return

things to a stable state.

157

That's not always a hundred percent

true, but it's definitely a good

158

default first thing to try, right?

159

Like we talk a lot about the idea

of instead of trying to fix forward,

160

right, just roll back, right?

161

Like you have a known working state

that you can hopefully get back to,

162

and that should ideally be the happy

path for trying to result things.

163

Andrea Magnorsky: Yeah.

164

Yeah, totally.

165

Um, I did wonder how, how did

you conceptualize all of that?

166

The, the other kind of questions

that I have, one is on the people

167

side and the other one is on the

design changes that might happen and

168

they're kind of interrelated, For

example, for, for something, for one

169

change to trigger so much failure

that kind of talks about like, hmm,

170

is the design actually quite right?

171

So I kind of wonder how the, the,

the people side of this design change

172

because of the incident trickle down.

173

I'm very curious about that.

174

Like how, how was the

kinda orchestration of.

175

The design changes happened really

after the incident, 'cause I'm

176

sure it wasn't like 10 minutes

later we changed everything.

177

Liz Fong-Jones: This was really,

really ironic, I think, right?

178

That a system that we had put in

place to limit the blast radius

179

of changes paradoxically caused

a a, a system wide outage, right?

180

So here's a little bit more technical

detail to kind of unpack that, right?

181

every functioning software

organization has some kind of

182

canary deployment system, right?

183

Like, you have some mechanism

of rolling out software to, you

184

know, 1% of 1% or even 0.1%.

185

I think this was even

supposed to be a 0.01%,

186

traffic experiment.

187

So worked on this team before, right,

like, you know, I had the requisite

188

context to keep in my head when this

person came onto the bridge, right?

189

Like, because I knew.

190

That there was a

development cluster, right?

191

The people who developed the Google

front end have the ability to

192

push their own binaries, right?

193

Like to a subset of the cluster

that serves a very, very, very

194

small subset of the traffic, right?

195

0.0001%

196

of the traffic, right?

197

But the challenge here was that

even though they had meant to

198

only serve, you know, the small

fraction of the traffic, right?

199

Like the assumption was if something

goes wrong with that, right?

200

Like you've only failed a vanishingly

small percentage of traffic.

201

What was not accounted for was the fact

that any host that appears in the, in,

202

in the list of available backends, even

if it's set to receive less than 0.1%

203

of the traffic, you still

have to have information about

204

it in the list of available,

backends to send the traffic to.

205

Right?

206

That if you are intending on running

a canary experiment, you have to give

207

information about which host is the canary

and what percentage of traffic to route

208

to that canary and that information.

209

Has to be pushed out globally.

210

and that's basically where, where,

where the problem was, right?

211

Like so, so a safety feature to test a,

a release before it went into production.

212

Even, even the, like server itself

didn't have any bugs, but the way

213

that it communicated information

about, hi, I'm available to serve.

214

that's what caused every single host

in the fleet that was talking to it

215

to try to get information on, Hey, you

know, what protocols do you support?

216

You know, I, you know, just on

the off chance I to route traffic

217

to you, that's the thing that

caused the, systemwide outage.

218

Andrea Magnorsky: Right.

219

And how did, like, did, was there

a design change because of it?

220

I mean, for.

221

Liz Fong-Jones: there have been efforts

at Google and Amazon and you know, pretty

222

much every single large hyperscaler

to about how do you test and validate

223

global changes and recognize that

global changes are very, very dangerous.

224

I think the thing that was missed here

though was that the list of backends for

225

a, for, for a important service like this

was in fact a globally distributed set.

226

I.

227

So I, I think basically, right, like

yes, you know, in general too, when

228

you're working with a global system to,

to perceive more carefully, to, right,

229

like have automatic rollback, right?

230

Like to detect crashes.

231

But if you are not aware that you

should be looking for that right,

232

then I, then I think it's a lot,

it's, it's a lot harder to test that.

233

I think the other factor

is right, like, you know.

234

Backwards compatibility, right?

235

Like I, I think that if you test things

to make sure that things are forward and

236

backwards compatible, that you're going

to have a lot better of a time than if

237

you are out software in a, in a way where

you can send an input that's that some,

238

that something else re or send an output

that something else rejects as an input.

239

So that kind of goes seal Unix philosophy

of be liberal in what you accept,

240

be conservative in what you output.

241

Kenny Schwegler: I what I liked what

you said is if you want to really

242

create resilience, you also need to

create resilience in humans, right?

243

Liz Fong-Jones: Yep.

244

E exactly.

245

Kenny Schwegler: uh, I

really like that quote.

246

Never thought about it in that way.

247

So, what I guess you created

there was psychological safety for

248

that person to jump on the call.

249

So I, I have questions if you look at

the system, so how, how did management

250

or, or leadership reacted to, that

person calling in first and of

251

course saying, Hey, it was my fault.

252

What, what?

253

Can you remember?

254

What was the reaction at that point?

255

Because I think that's, there's

very much to learn for other

256

organizations there as well.

257

Liz Fong-Jones: I think that you know.

258

The number one thing that executives

at Google try tried to do, right?

259

Like is to stay out of the way, right?

260

Like they don't want to pressure

the team, they at the same time have

261

a responsibility to make sure that

an outage is being addressed with

262

sufficient urgency, that it's being

given the resources that it needs, right?

263

so.

264

When you have, you know, executives

join joining the bridge, right?

265

Like, you know, they're not going to

personally speak up and like, you know,

266

intimidate the person even from having

said, you know, Hey, like, you know,

267

I recognize that and thank you, right?

268

Like, the thank yous

happen afterwards, right?

269

Like, you know, even when the

person came onto the bridge, right?

270

Like, you know, I as an instant

commander was not like, you know,

271

in immediately like, you know.

272

Worried about this person's feelings.

273

I was just like, thank

you for that information.

274

Now let's see whether we can

validate whether your fix worked.

275

Right?

276

Like what time did you say

you landed that fix, right?

277

Like, you know, where, where

can I see it rolling out?

278

Right?

279

Like so much in motion at the same time

280

Kenny Schwegler: Yeah, so at the

time you're focusing on fixing

281

the problem, so you say thank you.

282

Of course, every information, every

transparency is of course helping

283

you, create that goal, in the moment.

284

And afterwards, what, what, what

is done afterwards to make sure

285

that, you know, if there's still

repercussions afterwards, then

286

Liz Fong-Jones: Exactly

right, like you know.

287

Kenny Schwegler: to

speak up in the moment.

288

Liz Fong-Jones: Thorough

retrospective processes, right?

289

Like making sure we're learning

from it, making sure that they know

290

that it wasn't their fault, right?

291

Like that, you know, there

are systematic changes that we

292

need to make across the system.

293

and then, you know, just making

sure that we're all debriefing and,

294

you know, talk, talking about it.

295

And, um, so I, I think,

right, like there are.

296

You know, thing, right?

297

Like we're having this conversation today.

298

Um, but you know, you can

imagine in the, you know, weeks

299

after this incident, right?

300

Like, you know, every, every

Google team had like at least one

301

representative, like join, join one of

these kind of learning sessions, right?

302

Like where we talk about major

outages, made major incidents, right?

303

And this outage.

304

Was one of many incident that we

discussed in these observative, right?

305

Like we don't only talk about the

high profile incidents, right?

306

Like we talk about individual learnings

that you can have from any team, right?

307

Just because this incident was

high profile not mean that it was,

308

you know, like unusually worthy of

being of, of, of, of like learnings.

309

Every incident you can

learn something from, right?

310

Like, and I think that's important too.

311

Is that, you know, you have to

have a culture of continuous

312

improvement, and you cannot just

do this for the large incidents.

313

You have to do it in the,

in the smaller instance too.

314

Kenny Schwegler: Yeah.

315

That's a great, that's, uh, great.

316

Yeah.

317

I, I remember one time at a small

company where a developer made a

318

mistake and it cost a company like,

10 thousands of euros, which was big.

319

Steal for that company.

320

and I

321

Liz Fong-Jones: You can joke about like,

you know that incident costs you $10,000.

322

Why would you fire the employee that

now has $10,000 worth of learning?

323

Kenny Schwegler: yeah, we didn't.

324

So I talked to the manager

because I was a tech lead.

325

I said, the manager was fine.

326

He was like, oh, it happens.

327

And I said, can you please

call the developer because,

328

the person is in stress.

329

Liz Fong-Jones: Exactly right.

330

Kenny Schwegler: me

331

Liz Fong-Jones: Yeah.

332

Kenny Schwegler: your,

333

Liz Fong-Jones: recognition, right?

334

Like you can give people a bonus, right?

335

Like, you know, right.

336

People may be like, you know,

why would you give a bonus to

337

someone who, who screwed up?

338

But the answer is, they didn't screw up.

339

Right?

340

Like, you know, the sys the system let

them down and they had the best possible

341

reaction to that was to, to, you know,

immediately roll back and also to call in.

342

Kenny Schwegler: But, but yeah.

343

And, and what I, what reminded me of

your, people also need to be resilient.

344

And that's what I saw happening the

moment, the manager called that.

345

Dev, it's fine.

346

No, you know, you did great and,

everyone failed, everyone together.

347

Made sure I, I can't remember the exact

thing, but it was very heartwarming.

348

Right.

349

And you saw that person, like, if I think

about resiliency, you saw that person

350

moving back to the original state, and

be more resilient so, so that's, yeah.

351

I like that metaphor of humans

also need to be resilient, so.

352

Andrea Magnorsky: And

have you ever been in a.

353

A situation that is kinda also

an incident, but what you think

354

should have happened didn't happen

as in like the opposite thing.

355

Have you experienced the opposite of that?

356

Liz Fong-Jones: Thankfully I've been on.

357

Teams that have kind of

psychological safety.

358

I think the thing that I do see

happening more often is not necessarily

359

in in the heat of the moment of the

incident, but often it's challenging

360

to get investment in reliability.

361

Before there is the, the

362

Andrea Magnorsky: Yeah.

363

Liz Fong-Jones: incident, right?

364

Andrea Magnorsky: Yeah.

365

Liz Fong-Jones: rather

not have the incident.

366

Right?

367

Like I, and, and I think that it

is potentially a problem, right?

368

Like it when you have, you know, all

of the praise and awards, the people

369

who do the firefighting and not the

people who prevent the fire from

370

even breaking out in the first place.

371

Right?

372

And I think that I've seen organizations

struggle with technical debt.

373

I've seen organizations prioritize

short term over the long term, right?

374

And that I have to keep in mind

is that it's very, very difficult

375

to expose safety as a signal aside

from Right, like outages, right?

376

Like, you know, we talk about the,

the triad of, of of cost surface

377

area and, and safety, right?

378

You can, you can, right?

379

Like, you know, you, you can, you

can drag it, drag the around anywhere

380

in that kind of try point space.

381

But if you stress safety too

much, it'll suddenly snap.

382

You don't really have an indication there.

383

Kenny Schwegler: Yeah, it,

it reminds me also, a little

384

bit about this, this person.

385

Showing this Superman, clip where

first Clark Kent goes to this little

386

boy standing at, at one of the

waterfalls and say, Hey, watch out.

387

Don't fall down.

388

And nobody believes Clark Kent.

389

And then all of a sudden the boy drops,

Superman comes in, saves the kid, and

390

then everyone's praising Superman, right?

391

While Clark Kent could have like, well

be careful not make that incident.

392

So how would you.

393

How would you know you are in a

psychological, safe environment?

394

What's, what are the key signs you

look for or see, or red flags even?

395

So how, how would you, what

are some heuristics you have?

396

Liz Fong-Jones: I think that has

a lot to do with, how do we talk

397

about smaller failures before

there are bigger failures, right?

398

Like, how do we make sure that we

have a culture of continuous learning?

399

are people, punished

for speaking out, right?

400

Like, you know, even on things like,

you know, hey, like, you know, I

401

might miss slip this deadline, right?

402

You know, or, Hey, we're really

behind on story points, right?

403

Like, I think that's kind of the

primary prime, you know, smaller

404

steps that you, that you take, right?

405

Like in order to then have

the psychological safety in

406

case something major happens.

407

I think, making sure that we're

listening to feedback, especially, right?

408

Like, you know, in the.

409

Category of right, like there's no

such thing as a dumb question, right?

410

Like, I think that it's important

for people, especially newcomers to

411

the team that like I, as a senior

even try to model this, right?

412

Like that it's okay to ask

questions that might seem obvious to

413

someone who, who knows the answer.

414

that way, right?

415

Like we emphasize that we're all,

we all have things to learn, right?

416

Like that, that there's kind

of no perfect expertise.

417

Kenny Schwegler: It reminds me of,

starting aikido and, and then going

418

with a black belt and saying to

the person having a black belt, oh,

419

sorry, you need to train with me.

420

And then the black belt said

to me, no, not at all, because

421

I can learn so much from you.

422

because, and this is, I think

what you're saying, right?

423

There's always learnings in new

people and, and I think that's.

424

One thing to notice for now.

425

Andrea Magnorsky: I really like

those three things that you said.

426

It's like, the, your, your heuristics

for the psychological safety.

427

It's like, can we talk

about smaller things?

428

Can people talk about problems and

are, if people feel like they can't

429

ask them questions, that, that kind

of fear and silence, you know, you

430

know when you're in a call and people

go like, and they're like, how to go?

431

Liz Fong-Jones: You know, says an acronym

you don't know, and like no one on the

432

call knows and everyone stays quiet.

433

Right?

434

Like, you know, that's,

that's potentially a problem.

435

Andrea Magnorsky: Yeah.

436

Yep.

437

Yep.

438

Kenny Schwegler: You

439

Andrea Magnorsky: Yeah,

440

Kenny Schwegler: for like juniors

le talking less than seniors, right?

441

Is is that something

442

Liz Fong-Jones: Yeah, definitely

making sure that everyone has an

443

opportunity to give their opinion.

444

Give their input, right?

445

Like ask why we did something.

446

You know, maybe that's a sign

that we're missing documentation.

447

Andrea Magnorsky: absolutely.

448

And how do you feel about the

collaborative design techniques?

449

You know, like what are your default

collaborative, practices, basically?

450

Liz Fong-Jones: Yeah.

451

I think that when we are designing

things, it's important to that teams

452

own software products and therefore that

teams own designs, not individuals, right?

453

Because you know that

individual may transfer teams.

454

They may leave the company.

455

Right?

456

Like, so I think it's important that the

people who are going to be accountable for

457

running the system in the long term input

into it, have feel ownership of it, right?

458

Um, you know, yes you can have a

lead author of a design, right?

459

Like, but, but I think that the broader

team that surrounds it needs to be in

460

the loop, needs to have an understanding

of the system, needs to understand

461

why the decision was made, right?

462

Like, and I think kind of combining

those two things, which design

463

psychological safety, right?

464

The ability to ask why did

we make the decision, right?

465

Like, you know, what are the

conditions under which it might be

466

okay to revisit it rather than, oh,

that decision was made 10 years ago.

467

I don't know why I don't

feel comfortable changing it.

468

Right?

469

Like, you know, it's, it's

happened so long ago that we've

470

forgotten and who knows it?

471

You might blow it up by

changing that, right?

472

So it's kind of this concept of

like a haunted graveyard, right?

473

Like no one daress.

474

You know, step foot in haunted

graveyard because there's just,

475

you know, spooky stories of the

last person who did that disappear.

476

No one can remember anyone ever

walking in the haunted graveyard.

477

Right.

478

think that when we treat design as kind

of a living conversation, right, when

479

we are looking at production, right?

480

Like when we're looking at things

to have an understanding not just

481

of what was the system as designed,

but also what's the system as built?

482

How's it behaving?

483

Right?

484

And I think that's true regardless of

whether, you know, you were designing with

485

an AI team made a human team made, right?

486

Like, I think either way, Like

it's, it's this group of people

487

who support the software.

488

Andrea Magnorsky: They build the theory

like Peter nor say, alright, cool.

489

That's, that's very like, I like that

design as a living conversation very much.

490

Kenny Schwegler: Thank you.

491

I think this was, this was it.

492

Our, bite-size story.

493

So thank you, for joining us.

494

Liz, thank you for telling your story.

495

I think, a lot of people can

relate to it and hopefully get some

496

learnings out of it themselves.

497

So if you're listening to

this, watching this, reading

498

this, please like, subscribe.

499

So, uh, more people can.

500

In these conversations and

hope to see you next time.

501

Bye-bye.