In this episode of Stories on Facilitating Software Design and Architecture, we are joined by Paul Rayner, a seasoned consultant and expert in Domain-Driven Design and EventStorming. Paul shares a candid "war story" from his time as a tech lead that completely changed how he views leadership and influence. He recounts a well-intentioned refactoring session where he publicly critiqued a team member's code, aiming to teach better practices. The result was unexpected and severe: the developer felt shamed by the experience and quit shortly after.

This experience served as a harsh wake-up call about the "unseen authority" leaders wield and how easily the "blast radius" of our actions can damage team psychological safety, even when our motives are pure. Paul opens up about the "dominant blindness" that often affects technical leaders—where we fail to see how our rank amplifies our words, turning a simple suggestion into a crushing directive.

We dive deep into the power dynamics of technical leadership, exploring why simply having the "right" technical solution isn't enough. The conversation covers how to move from "fixing" people's work to facilitating their growth, why resistance should be treated as a valuable resource rather than an obstacle, and how methods like EventStorming can help externalize conflict.

Key Learning Points:

1. The Gap Between Intent and Impact: Why "I meant well" is never a sufficient excuse when a team member feels alienated or embarrassed by your actions.
2. Dominant Blindness: How leaders often underestimate the heavy weight of their rank and the pressure it puts on colleagues, especially when navigating contractor-employee dynamics.
3. Resistance is a Resource: Instead of pushing harder against pushback, view it as a signal to understand the underlying fears, threats, or misunderstandings driving the resistance.
4. Challenging Mental Models: Recognizing that when you criticize code, you are often challenging the deep-seated mental models and hard work of the person who wrote it.
5. Externalizing the Problem: How using visual tools like sticky notes (e.g., in EventStorming) can shift the focus from "me vs. you" to a collaborative discussion about the problem on the wall.

Hello and welcome to Stories on facilitating

2

Software Design and Architecture.

3

today we're here with our

guest, Paul, who will introduce

4

himself in a, in a, in a minute.

5

We're also here with, uh, the normal,

our normal crew, uh, which is of course,

6

Kenny, Andrew, and myself, Andrea.

7

So Paul, how about a little, a little

intro about who you are and what you do.

8

Paul Rayner: Sure.

9

Uh, I've been.

10

Developer most of my career and consultant

more recently, over the last decade and

11

a half, mostly specializing in domain

driven design and event storming.

12

So I do training and

facilitation in those things.

13

And then also probably more known

in the United States for starting

14

the Explore DDD conference,

which runs in Denver every year.

15

And uh, I'd give talks at conferences

and we're here in Melbourne.

16

Just having wound up and taught an event

storming workshop together yesterday.

17

Andrea Magnorsky: So,

which was really fun.

18

It was really nice to work with

you in running this workshop.

19

Thank you for, you know, working together.

20

Um, so today, uh, Paul is

gonna share a story with us.

21

so Paul is, what's, what's your story?

22

Paul Rayner: Yeah, well, yeah.

23

I was talking about this a bit

with Kenny and I think a good war

24

story is maybe one that we could s.

25

Lead off with.

26

So, I was a kind of architect, architect,

tech lead on a project that, um.

27

This was, I guess, late two thousands.

28

Um, and I'd been working with a team.

29

We had, uh, I was based in Colorado

where I am now, and we had developers in

30

Chicago and also in, uh, Buenos Aires.

31

And we were working on a

very complicated system.

32

It was the first.

33

System where I'd actually tried to

apply to domain driven design and test

34

develop, test driven development and

a lot of these kinds of techniques.

35

And, uh, I thought it would be a good

idea to get all the development team

36

on a call and pick some code and, and

kind of talk through how to refactor

37

code and how to improve it and make it

more expressive at the domain concepts.

38

So we did that.

39

I got, we got everyone on a

call and me as the tech lead.

40

Um.

41

You know, walk through, I'd pick

some code and, and just sort

42

of started doing extract method

refactorings and showing how to do

43

a bit of test driven development.

44

And that, not long after that call,

one of the developers quit, and

45

uh.

46

I didn't know what I'd done, but

it, it should be pretty obvious.

47

What I'd actually done is, um, one of

the contractors in our team in Chicago

48

was actually the code that he'd written

and he felt very embarrassed and

49

shamed by what I'd done because it of

implied to the rest of the team that

50

the code that he'd been involved in

was not up to par and, and, uh, and so.

51

I reached out to him and

apologized and, and then

52

apologized to the rest of the team.

53

And, uh, and fortunately he uncut came

back and, and, you know, was a, he had

54

been a, a key team member and continued

to be a, a core team member and.

55

And I remember at the time thinking

I was doing everything with the right

56

intentions and you know, the right

motives, but I just had a complete lack

57

of understanding, I think, of how that

would be perceived by the person that,

58

that had done that and, and how my.

59

Misuse of my power and authority actually

cause someone a lot of embarrassment and

60

shame, even though it was unintentional.

61

So, know, it, it was a real wake up call

for me about and, and, you know, being

62

aware of other people and the power that I

wield and, and, and also how to go about.

63

Cha changing hearts and minds and, and,

and, you know, coming alongside people

64

to, uh, try to show different ways

of doing things instead of, you know.

65

Taking an approach like I did, which

was clearly not a good way to go.

66

So that's my war story.

67

and I learned a lot that.

68

And it doesn't mean I haven't

made mistakes since, but yeah,

69

that was one of my bigger ones.

70

Andrea Magnorsky: I, I think it's,

it's also that you're, you're

71

talking about, um, not just.

72

The practice and you know, we, I think

it's clear to see for us here, the, not

73

just like the, the intention, but also,

uh, the, the, you're like, oh, the, the,

74

you're, you're bringing to the force.

75

Something that I think, uh, it's

a lot to do with decentralization,

76

which is understanding power, uh,

and power dynamics in an organization

77

and, and how important they are.

78

How impactful they are when,

79

When, you know, when you have

more, especially the more authority

80

you have, the, the more careful

you need to be about Yeah.

81

That effect.

82

And, and also why it's good to

decentralize that so that these things are

83

have, less damaging to, to certain degree.

84

Um, so I guess, I guess

that's the question.

85

Do you think in a, in a more

autonomous teams, like in teams

86

that work in a more autonomous

way, do you think this would've.

87

Been different if, if they had

more, kinda not just to do what they

88

need to do, but also responsibility

for the actions that they take.

89

Paul & Andrea: That's a good question.

90

It's hard to say.

91

I, I mean, I haven't really

thought through an answer to that.

92

I haven't been asked that question before.

93

In terms of decentralization

and autonomy, uh.

94

I look back over it, I mean,

I had a lack of empathy.

95

I did not take the time to think, how

would I feel if somebody did this to me?

96

And I don't know that if the

team had been, I mean, the team

97

was fairly autonomous and, and

power was fairly decentralized.

98

And I, I thought of myself as,

as like one of the peers, There's

99

other dynamics as that were in play.

100

Like I was an employee,

he was a contractor.

101

Mm.

102

Right.

103

Yeah.

104

And, and that adds another,

uh, complication to that.

105

then, uh.

106

don't know.

107

I've been in situations that,

that were decentralized, where

108

there was still a lack of empathy

and, and people said things that

109

they didn't really think through.

110

uh, maybe the blast radius is less.

111

Mm.

112

Yes.

113

Uh, but I don't, I I, yeah.

114

I wish I had a better answer.

115

And I think it's, it's good's a question.

116

We're exploring.

117

We're exploring this theory.

118

This is.

119

Kenny (Baas) Schwegler:

I, I have a thought there.

120

So you say lack of empathy and I think

I, I struggle a little bit in that.

121

I, I agree with the, the.

122

With that, but you can

never have enough empathy.

123

So it's very hard if you, you work with

different cultures, if you work with

124

different people, like you say, I, I

wasn't aware of it, but if you look

125

back at their experience, was there

any point that you, that that person

126

signaled in a way they didn't agree?

127

Right, because it's two way on one hand

I hear you were dominant blind, right?

128

You were blind to your, to your rank.

129

On the other hand, I always ask myself a

question when that happens to me, is that

130

what, what are some signs or something

that you can think back of like that

131

that person didn't agree, could act on?

132

Paul Rayner: Yeah, ahead of time.

133

I think I was just to.

134

The, the dynamics in terms of

employee and contractor and, and,

135

you know, I, I wasn't really his boss

necessarily, but, but you know, kind

136

of a certain seniority on the team.

137

And, and then think related to

that, just a lack of understanding

138

of how to people to change.

139

you know, I, I at least was trying to show

rather than tell, but it wasn't done in a.

140

way that would actually have led to that.

141

I mean, it came up in today's

hands-on session this afternoon

142

of I'm, I'm teaching the same

techniques today that I, I was trying

143

to get across all those years ago.

144

And the same questions come up from people

like how, you know, my team is reluctant.

145

They, they, they wouldn't

understand the value of this.

146

How do I convince them?

147

And, and I told the same story.

148

I'm like, well, don't do this.

149

Right.

150

Um,

151

Andrea Magnorsky: well listen,

at least there's a, a, a story.

152

You got a lot out of.

153

As in, it would be sad if that

had happened and you would've

154

not learned anything from it.

155

Right.

156

So I think the fact that not only

you learn from it, but you're willing

157

to share it shows like, uh, sure.

158

It's like a good thing.

159

Multiple, not just learning and

sharing the, so other people learn it.

160

Kenny (Baas) Schwegler: I

think about the empathy.

161

That's why I'm saying it, even though

you learned, I, I had that many times

162

happening to me and it, it still happens.

163

Right.

164

And I think the important part, what I

hear from you is that you didn't step

165

into to your cognitive dissonance of

Yeah, but I had the right intention.

166

And I think that, that, that was a

big learning point for me as well.

167

I'm not sure for you as well, but, but

being that, being in, in that way, right?

168

I try to have the right intention

because that's what usually happens when

169

people step up to the, to the plate.

170

They're also propagated then in a way,

and you'll make mistakes, but then.

171

You can do two things, right?

172

You can say, well, but

you wanted this, right?

173

So you can, you can go that

route or you can go to the root

174

of, okay, how can we improve?

175

This is a very tri tricky slope

from, let's say you are in a team

176

coding and it's rather exact, right?

177

Coding is rather exact.

178

There, there's a, a solutions, and,

and then you step up to that plate

179

of technical leading something,

and then there's all this flakiness

180

going on there because people.

181

Yeah.

182

Paul Rayner: I,

183

yeah, I'm, I'm really not, not sure.

184

I, I think that, I mean, this was

a while ago, so I don't remember my

185

initial reaction, but, but certainly.

186

I, I expect that my initial reaction

would've been, well, I had the

187

right intentions, but then at the

end of the day, the other person

188

responded the way they did, and now

I need to, and whether or not they

189

overreacted is, is another question.

190

But I think certainly got my attention

and, and, and then, you know, I, I

191

was working hard to make it right.

192

And, and I think that's,

that's a pattern that I.

193

I try to do, it's like, okay,

I'm going to make mistakes.

194

And if you are in leadership,

you're going to make mistakes.

195

Yeah.

196

You're going, you know, you're

going to do things that people

197

are going to misinterpret or, uh,

you might do the wrong, the wrong

198

thing with the right intentions.

199

I mean, these, these things happen

and I think part of it then is,

200

well, what is, how, how do we fix

things when we, we do make mistakes

201

and how do we, uh, prioritize those

relationships and, and go about.

202

reconciling and, and, and so, you

know, actually giving a proper apology

203

instead of just, I'm sorry, you feel

bad, but actually like, no, I was wrong.

204

I did the wrong thing.

205

No, I'm sorry.

206

You feel the way.

207

Right.

208

And, and then, uh, actually.

209

Thinking about, okay, well how wide

is the blast radius of this socially?

210

And it, well, it's the whole team,

so I need to apologize to the whole

211

team, not just to this one person.

212

Andrea Magnorsky: Right.

213

Yeah.

214

'cause obviously this person quit,

but other people might have also.

215

Paul Rayner: Everyone else was there.

216

Andrea Magnorsky: Yeah.

217

Paul Rayner: So they

218

Kenny (Baas) Schwegler: Yeah.

219

Andrea Magnorsky: might have left

220

some of them

221

Kenny (Baas) Schwegler: It's

always when someone has a

222

feeling, someone else in a group.

223

But what, what I'm mostly curious

about is you, you went in, get

224

into a solution mode, right?

225

So you say, well, let's do this.

226

So that got that person embarrassed.

227

You solved that on

228

emotional

229

level, but was it solved on,

because it can still form

230

tension if that person still

231

didn't agree

232

with the approach you took.

233

Was, was it that they also didn't

agree on the approach you took?

234

Because that can be an another level of.

235

Messiness.

236

Right?

237

Because if, if now you reconcile,

but you still go your way, that can

238

end up with sort of like, even though

your your way might be the least

239

worst solution, I always say, right.

240

It it, it can, it can.

241

How, how did you cope with that?

242

Did, did you, did you his ideas in,

or, or how did you get him to go along

243

Paul Rayner: You know,

244

Kenny (Baas) Schwegler: see?

245

Paul Rayner: so honestly

it was so long ago.

246

I can't remember now.

247

Kenny (Baas) Schwegler: do it

248

Paul Rayner: I'd like to,

249

Kenny (Baas) Schwegler: how would you

250

Paul Rayner: like to think I

said, so what do you think?

251

And all of that, but I

really, I, I don't remember.

252

That would be more my

preferred approach now is to.

253

solicit advice and, and you really

want people to change, you have to meet

254

them where they're at and, and kind of,

and, and really hear their concerns.

255

And so I would try to

do that more these days.

256

If someone's pushing back, then I.

257

Why are they pushing back?

258

And there's a, there's a

great article by Dale Emery.

259

Uh, resistance is a resource where he,

uh, elaborates why people resist change.

260

And, and so being able to

what is the resistance?

261

Is it somebody who's feeling threatened?

262

Is it somebody doesn't understand?

263

Is it, you know, any one of these

number of reasons that, that somebody

264

might be, be pushing back that.

265

That article does a great job of

explaining that that's actually

266

a signal that you should,

uh, understand and mm-hmm.

267

And, and explore as a way of moving

forward, rather than just detecting the

268

pushback and then pushing back harder.

269

Kenny (Baas) Schwegler: I've, I've heard

a Dutch anthropologist say resistance

270

is just someone else's opinion.

271

Paul Rayner: Yeah.

272

Kenny (Baas) Schwegler: Yeah.

273

Paul Rayner: Yeah, I think so.

274

Kenny (Baas) Schwegler: That's it.

275

Someone's just propagating, wanted

to propagate their opinion usually.

276

That, that was really learned for as well.

277

This concept that you, that you're

saying was really learned for me as well.

278

Yeah.

279

Andrew Harmel-Law: I think there's

one thing I was wondering about, um,

280

Paul, the, because this, so this,

one of the things that interest

281

me a lot about software is I.

282

Fundamentally, like we're all, we, we

have all these mental models and then we,

283

we are understanding of what the problem

is, and then we turn that into code.

284

And at an architectural level that's

kind of easier because there's less in

285

the current ways of doing architecture,

there are less people at the top

286

who are doing architecture, right?

287

And then they kind of do their

work and they pass it down to.

288

Pass it down, like with the stress and the

word down to like the development teams.

289

And they kind of just do it,

but they don't just do it.

290

Right.

291

They have their mental models.

292

They have like, you know, this

person had their ideas of this

293

code that, that they'd created.

294

Right?

295

And they obviously, what they

had in their head probably

296

largely reflected what they did.

297

And there were probably other

people who did other bits.

298

I think it's 'cause one of the parts

of architecture is kind of trying

299

to come to the shared mental model.

300

But as, as you've been saying, right, the.

301

Trying.

302

Challenging people's code is one thing,

but challenging their mental models that

303

turned into the code is another thing.

304

And then kind of trying

to facilitate that thing.

305

That's a big, especially if you're

emotionally related to your code, right?

306

Like, I thought really hard about this and

this is my best solution to this problem.

307

And then you're like,

here's a different way.

308

Or even maybe not a different way, maybe

even a worse way, but a way that we more

309

all commonly understand in which DDD is a

great way for getting to that kinda stuff.

310

Do you think.

311

How much do you think you are

challenging this person's?

312

Again, maybe it was quite a long

time ago, but like when you see this,

313

'cause I've seen this in the past.

314

How much do you think you're fundamentally

challenging this person's, maybe not

315

worldview, but their understanding of

the problem and all of the work that

316

they've done to try and get to this?

317

'cause I feel I see this a lot, right?

318

It's very easy to do architectures.

319

And the less you engage with

the people who are gonna build

320

it, the better, because they're

not gonna push back on you.

321

But what you really wanna do is

collaborate with them and get all of

322

that pushback, and then get it into the

code and get that pushback and stuff.

323

Paul Rayner: Yeah, I agree.

324

Andrew Harmel-Law: What's the.

325

Paul Rayner: uh.

326

think of the five dysfunctions

of a team and the idea that just

327

going for consensus really people

are saying yes when they may no.

328

Mm.

329

Andrea Magnorsky: Or silence

when they may like, oh my god.

330

Paul Rayner: Right.

331

And I think that's part of

what you're describing and I.

332

I, I think it's much better

now to hear people's concerns,

333

to validate their concerns.

334

To the real collaborative aspect of

modeling is, uh, Eric Evans would

335

always talk about, like, model it three

different ways, that's something I try

336

and emphasize in when I teach domain

driven design is, okay, you come up

337

with an idea, so try to look at it.

338

Three different ways, or if you have

disagreement between two people, over

339

two different approaches, then at least,

at least come up with three different

340

options on the table, because then it's

not, you know, me versus Kenny, right?

341

In terms of his approach or my

approach, or me versus you Now.

342

Now we've got options on the table that

we can consider, I've actually found that

343

to be a really good diffuser of these

types of things because It's, and, and

344

event storming is like that as well.

345

Like we were talking yesterday, there's

something about externalizing those

346

internal mental models sticky notes and

then being able to stand up together.

347

Yeah.

348

At a wall and, and, and a con looking at

a very concrete, looking at something and

349

pointing at something and saying, well,

what about this and what about that?

350

And what if we rearranged it this way

351

Andrew Harmel-Law: Yeah,

352

Paul Rayner: this doesn't make

353

Andrew Harmel-Law: but this is it, right?

354

Like it is, like Andrea said, it is

like, this is, I think, the genius

355

of events or one of the geniuses.

356

It is concrete 'cause it's on a

sticky note on a wall, but it's

357

written in someone's handwriting

and you might have three things that

358

are similar and different types of

handwriting and it's sticky notes

359

so you can like move them around.

360

And I think it, like, it

confronts that head on right.

361

Kenny (Baas) Schwegler: Well, there's

362

Andrew Harmel-Law: This is what we

think, oh, we, we all think different

363

things and like, oh, like that's.

364

Kenny (Baas) Schwegler: also

a meta to event storming, so

365

with which I've seen, right.

366

Because event storming also propagates

that you're doing it in one way, which

367

maybe someone doesn't, isn't, isn't

able to express it in an event storming,

368

but with, with a storytelling, right.

369

So I, I once was at a conference

with three facilitators in one group,

370

and we all each used our own tool,

but it worked in the end because.

371

What you're saying, Paul, it

wasn't about the approach, it's

372

about, oh, we can interact with

the model with each other's models

373

Front.

374

their way.

375

And, uh, I've seen that happen often

on the meta level as well, that

376

we say, no, we, you really need to

do this in an event storming way.

377

Well, but I want to do, okay, let's on.

378

As long as you visualize it was, uh, yeah.

379

Paul Rayner: Yeah.

380

One of the best things I ever heard

was, I, I remember years ago teaching

381

a DDD class in Paris, around the

time of DDD Europe, and one of the

382

attendees said, you know, this event

storming thing, I mean, it's good,

383

but I much prefer domain storytelling.

384

And uh, you know, and I'm

like, great, well at least now,

385

you know, post I don't care.

386

Kenny (Baas) Schwegler:

You're collaborating.

387

Paul Rayner: Right.

388

Like,

389

Kenny (Baas) Schwegler: Yeah.

390

Paul Rayner: know.

391

Andrea Magnorsky: Yeah.

392

But I think that there's a, that's

a really valid thing, but at the

393

same time it's like knowing both.

394

And at some point maybe they prefer

that and at some point they might

395

go, you know what, I prefer them

domain storytelling, but for this

396

group when coming is gonna work.

397

Yeah.

398

Really?

399

'cause I, I also have

referenc them swap over time.

400

Right.

401

Kenny (Baas) Schwegler: So, so my, my, my

wife, uh, has a background in anthropology

402

and, and about this, uh, thing right where

you meet someone of where they are and she

403

said, told me from a culture perspective,

and that really settled with me, right?

404

You, you can, people are okay with

changing as long as it's a different

405

differentiator of themself or a

differentiator of their model.

406

But if you like, really change the model.

407

Like there, that's not acceptable.

408

So you want to meet them here

instead of what, what you are saying.

409

And, and that really by me, right?

410

People can, if they are really doing

something with UML, okay, let's start

411

doing UML, but then collaboratively in

another way because, well, that's what

412

Right.

413

doing, so let's do more of it than, uh,

414

Andrea Magnorsky: I think, I think

actually I have, have a slightly

415

different mental model when it comes

to that and that mental model is that

416

people will, uh, will be okay with

certain level of change as long as

417

you don't attack their core beliefs.

418

Obviously nobody has their core

beliefs printed on a nice, handy,

419

you know, list on their forehead

or, or their arm, unfortunately.

420

But person might have been, my core

belief is that I hate testing or not.

421

Who knows?

422

Or the, I love this

pattern and this language.

423

And by doing that, you, you touched

on, or you said something that

424

touched on their core beliefs.

425

And I think, I think I like to

think of Thomas Coon and the

426

structure of scientific revolution

and you know, this is the person

427

that thought of paradigm shifts.

428

You talked about how people

changing and, and someone to change.

429

They need to change their core,

some aspect of their core beliefs.

430

Some, some, some of them are like

really close to like being alive

431

and other ones are like professional

life, emotional life, and they have

432

less or more levels of, of depth.

433

But I think when you talk on one of those,

you, they need to do the, the work of

434

wanting to want that belief to change.

435

and, and they do that, that movement from.

436

don't like Let's say this

person didn't like testing.

437

I'm completely making it up.

438

So let's say they were like testing.

439

I don't like it because reason, they,

they saw it and this really annoys them,

440

and in fact, really being annoyed by it.

441

have been the reason why it was okay and

they learned about testing, et cetera.

442

So this might have been a tipping point on

being ready to change their core belief.

443

Or maybe it was like, I think everyone

that does testing is horrible and

444

turns out that you were really

nice to them, and that is like, oh,

445

actually that's not true anymore.

446

So I need to reevaluate that

core belief and move it.

447

So this core belief idea is kind of what

helped me this behavior in some ways.

448

Like, well, if I was really attached to

this idea and it was part of who I am.

449

Which is similar to what

you're saying, isn't it, Kenny?

450

Um, thing of how do you move forward

on something that is something that

451

is nearly your identity, right?

452

Kenny (Baas) Schwegler: It's

a different model, a different

453

Andrea Magnorsky: Yep.

454

Kenny (Baas) Schwegler: which I agree

455

Andrea Magnorsky: Yeah.

456

Kenny (Baas) Schwegler: Going back to

457

Andrea Magnorsky: Yeah.

458

It might be useful to, to other people to.

459

Andrew Harmel-Law: Yeah, that's, and

that actually reminds me there's a talk.

460

I think it's not my, my most famous

blue sky skeet, I think that's what

461

they're called, which isn't very famous,

but it's been like retweeted a lot.

462

It's just me quoting Gien

I'm gonna say that wrong.

463

Apologies.

464

Heen, but Heen at for quite good, right?

465

Heen at, um, did a talk about

decision making at, uh, new Craft

466

in Paris last week, I think.

467

And it was basically like

the thing we should spend the

468

most time on is the context.

469

It's not the solution,

it's not the options.

470

It's like where do we all start

and where does the problem start?

471

We don't, 'cause we're like, let's fix it.

472

And like, but spending time.

473

Um, and like just judging by the number

of people who've reshared that people

474

are like, yeah, that's, and it's true.

475

Like, we don't, I don't do it.

476

I'm like, let's get past this

boring context piece where

477

we actually are right now.

478

And like the actual, like, let's

forget understanding the problem

479

because that's probably less exciting.

480

Let's figure out how to solve it.

481

Kenny (Baas) Schwegler: I think that's it

482

Andrew Harmel-Law: And, and, yeah.

483

Yeah.

484

Andrea Magnorsky: Think that, do

you have any closing thoughts or

485

something you wanna share with us?

486

We, without them to kind of take it away.

487

Paul Rayner: Well, just grateful to be

here, uh, grateful to do the workshop

488

with you and thanks to, uh, both of

you for, uh, the time to talk today.

489

This is, this is really great.

490

Andrea Magnorsky: Well, thank you

so much for coming and well, super

491

good to do the workshop together.

492

Great to see you too as well.

493

And see you next time.

494

I.