We've all been in that meeting. Someone proposes a solution, someone else proposes a different one, and within minutes the room has split into camps. People stop listening and start waiting for their turn to argue. Whatever decision comes out feels less like a conclusion and more like whoever had the most stamina won.

Laïla Bougria has spent over two decades in software engineering, much of it working in messaging and event-driven systems at Particular Software. Her story isn't a single incident — it's a pattern she's seen repeat across teams, companies, and years: smart people in a room, a decision to make, and a conversation that quickly becomes "my opinion versus yours." At Particular, Laïla learned to break this cycle through an RFC process that forces a different question before solutions are even compared: what problem are we solving, and for whom? That reframing removes a surprising amount of conflict before it starts. But what happens when two teams share a decision and neither is technically wrong? Or when you're convinced something is a mistake, and the team moves on without you?

This conversation digs into the emotional weight of architectural decisions — the gut reactions we dress up as rational analysis, the perfectionism that makes letting go feel like losing, and the personal practices that help you stay honest with yourself over time. Laïla shares how she builds evidence instead of winning arguments, why she runs personal retrospectives every six to twelve weeks, and what it taught her when she gathered evidence against a decision and found… nothing.

Key Discussion Points

• [00:01] The Pattern That Keeps Repeating: Smart people in a room, comparing solutions before they've agreed on the problem — and why it turns personal fast
• [00:04] Problem Before Solutions: How Particular Software's RFC process reframes decisions by requiring a shared problem statement before alternatives are discussed
• [00:06] "That's a Horrible Idea": Turning gut reactions into constructive questions about hidden assumptions and risks
• [00:09] When Two Teams Share a Decision: Navigating the give-and-take of event granularity between teams, and using coupling arguments that land because they serve both sides
• [00:14] Boundaries as Everyone's Job: Why service boundaries shouldn't be a few people's problem and how curiosity about the business domain surfaces issues early
• [00:18] Building Evidence, Not Arguments: The story of tracking bugs to prove a hunch right — and the equally important story of tracking evidence and finding none
• [00:25] Personal Retrospectives: A quarterly practice for resolving frustration, testing your instincts against reality, and genuinely letting go

Guest: Laïla Bougria Hosts: Andrew Harmel-Law, Kenny Schwegler, Andrea Magnorsky

Andrew Harmel-Law: So welcome back

to another edition of facilitating

2

software architecture and design.

3

That's what I've decided

to call it this week.

4

the usual people are here again.

5

So it's me, Andrew Harma Law,

and I'm joined by my usual

6

co-conspirators, Kenny and Andrea.

7

And today we've got Layla with us who

is gonna quickly introduce yourself,

8

I think, and then share some stories

with us around about the topic of

9

facilitating and collaborating on

software architecture and design.

10

Take it away later.

11

Laila Bougria: Thank you Thank you for

having me So yes my name's Layla I'm a

12

software architect and engineer I work for

a company called Particular Software where

13

we build in-service bus So I'm basically

very active in the messaging space that's

14

also been my specialty for I don't even

know how long anymore A while over a

15

decade at this point Uh I've been in the

software engineering industry for probably

16

two decades at this point Maybe I should

stop sharing now but No it's uh it's been

17

a fun ride Uh I've been active mostly

in the T net ecosystem and yeah I talk

18

it Conferences now and then to share a

little bit of knowledge and also run some

19

workshops on event different architectures

and things like that So that's me

20

Andrew Harmel-Law: And do you wanna

share one of the, like one of the,

21

the idea behind the podcast, I think

Kenny explained it right, is like share

22

stories about when things got a bit

complicated and then we ask you some.

23

Super interesting.

24

Well, hopefully interesting questions,

but have you got any stories that you

25

wanted to particularly share with us?

26

Laila Bougria: Right So I was reflecting

about this a little bit and and thinking

27

about okay which story could I tell And

I did reflect back on on something that

28

happened but as I was thinking about it

it it definitely wasn't a single A single

29

incident like that I think it's a sort

of a pattern that has been happening year

30

over year over year in many different

environments in many different teams But

31

the whole idea is basically regarding

when you get a lot of people in the room

32

especially when there's a lot of smart

people in the room And we have to make a

33

decision Either it's a design decision or

an architectural decision It doesn't even

34

matter there's a tendency to immediately

sort of start comparing possible solutions

35

against each other And that can in my

opinion cause a lot of friction because

36

then it's Becomes very quickly my opinion

versus that of a coworker versus that

37

of another coworker And then I've also

seen that you know people tend to become

38

very protective of their own ideas And

and then it becomes this sort of back and

39

forth when I don't really think that's a

productive way to think about The possible

40

ways forward and how to go about that So

as part of working at particular actually

41

we have a completely different way of

going about these things And it has even

42

though because we basically have a an a

different process to go about decision

43

making but that has influenced how I

think even if it's you know standing

44

on your feet type of a discussion and

also how I facilitate these types of

45

of meetings and It's still not easy

but I feel like it has given a lot of

46

positive steps forward so that's in short

47

Andrew Harmel-Law: Do you wanna,

could you maybe explain a little

48

bit, describe the approach?

49

'cause you're, I definitely

understand, can and relate to

50

that kind of, everyone rapidly.

51

Andrea sees this all the time, you,

that's very recognizable, right?

52

The one where everyone picks a,

picks a spot and then just fights

53

against everyone else from their spot.

54

But do you wanna maybe describe a

little bit about how the alternative

55

or an alternative could work?

56

Laila Bougria: Right

57

Andrew Harmel-Law: interesting.

58

Laila Bougria: So actually the the thought

process or the basis for my thought

59

process comes actually from our RFC

process So the whole idea is that when

60

we make bigger decisions that are more

impactful we write an RFC for it And the

61

whole idea is that we present multiple

alternatives and for each alternatives we

62

will list what are the assumptions that

we make In this specific scenario what

63

are the risks involved for this specific

scenario and also very actually before

64

we get into alternatives describe what is

a problem that we're trying to solve and

65

for whom are we solving this problem So

which stakeholder need are we addressing

66

by solving this problem Which I think

gets rid of a lot of friction to begin

67

with because most of the time there seems

to be a lot of misalignment around The

68

problem that we're trying to solve to

begin with So figuring that part out is

69

usually really helpful And the earlier

we can get to that the better but when it

70

comes to sort of having these discussions

around you know alternatives it's more

71

I think putting yourselves in a position

that there is no right or wrong proposal

72

And I think specifically it's important

to not start comparing prematurely

73

Kenny Schwegler: I think I always say

when when you get to good and bad then

74

you're your your first Step towards a

conflict bruise right Because you're

75

saying something is bad and something

is wrong I sometimes try to specifically

76

come up with bad examples or probably

examples that have high risk just to

77

find out what's what what it is that we

do want But I'm always to see how people

78

react to that Very very resistant Right

Do do you see that sometimes happening

79

still right Because we can make it

rational and on paper but as soon as it

80

already has like this thing in their mind

like no this is the only way to do it

81

Laila Bougria: Yes

82

Kenny Schwegler: could deal with fact

how would you get them to unlock and

83

see the other possibilities in that way

84

Laila Bougria: That's a good question So

first of all I sometimes feel that too

85

Like if someone brings up an alternative

and I'm like oh no that's a horrible idea

86

But one of the things I've learned is

when I get that feeling This is a horrible

87

idea is I think my younger innocent self

would've just said it That's a horrible

88

idea And now I think like okay wait why

do I think that this is a horrible idea

89

Because it it sometimes it almost feel

like feels like this gut reaction right

90

It's a horrible idea And I always try

to think about okay What assumptions

91

may this person be making that are not

being clarified that may be false or

92

what risks do I see in this solution And

then I think that if you just shift your

93

mindset from this is a horrible idea

to okay what are the hidden assumptions

94

here Or what are the risks Then I think

you're having a much more constructive

95

Conversation to begin with because it's

not well that's a horrible idea which

96

can feel like very almost like a personal

attack to the other person So it gets you

97

immediately out of the conflict mode So

it becomes a conversation about oh I yeah

98

I can see that idea I Could it be that

you're making this or that assumption

99

and then you start to have a completely

different conversation but Kenny there

100

was another part to your question too

is like if someone has this type of a

101

resistance like how would I react to that

And I think part of it I've al already

102

answered is by acknowledging That every

idea has a place and to rather rephrase

103

that as to okay and ask that person why

are you feeling so resistant to this idea

104

Are you seeing some assumptions that are

being made that you think are false Do

105

you see any risks that we haven't thought

of yet or that need to be surfaced And

106

I think that immediately deescalates

because it takes it away from you have a

107

horrible idea to okay there are some real

gaps in in this proposal that we need to

108

address And I think always bringing it

back to what is it that we're having a

109

disagreement about that is you know about

the idea about the implementation about a

110

solution instead of having a disagreement

with another person Immediately

111

deescalates the situation in my opinion

112

Kenny Schwegler: Nice Yeah So to to

follow up So Something that's in my mind

113

a lot because you work a lot with message

driven systems there's all usually I

114

am I'm with two teams or with several

teams and they need to communicate

115

with each other and that that can be

like okay here are my events Good luck

116

Laila Bougria: Mm-hmm

117

Kenny Schwegler: like no but I Consumer

and I just want I just want one event

118

So like a summary event for instance

Right And and there's this whole power

119

play and there's not even a right

or wrong decision because you could

120

use a summary event or you can just

say just give me all your events And

121

and so how do you deal with these I

I can imagine in with your expertise

122

that you get into this A lot of these

Conversation Right And it's two teams

123

against one another by default because

one like you build it and the other

124

team is like no here's just my event So

125

Laila Bougria: Yes

126

Kenny Schwegler: you probably face

this situation So that's question

127

one And and what then Right Because

there's no right or wrong there

128

Laila Bougria: Right

129

Kenny Schwegler: it's how I see it

130

Laila Bougria: So I always see these

types of collaborations as a game of give

131

and take So what I will try to do is for

example let's say we are in this case of

132

a of a sort of event that is much more

granular versus an event that is a summary

133

event And that makes it a bit more easier

is I for me that's already Possibly in

134

some cases kind of a smell in terms of

surface boundaries so I will try to have

135

that conversation that way and try to find

an incentive for the other team because of

136

course it's totally understandable right

Every team has their own deadlines they

137

have their own backlogs So I understand

when there's resistance from another

138

team to do something that is you know for

the benefit of another team because it's

139

Basically cutting into their own let's say

time budget so to speak So I think first

140

of all acknowledging that and not seeing

again something as a personal attack

141

It's more like well put yourself in that

team's position They probably have their

142

own deadlines they probably have their

own backlog and by just considering that

143

it Already deescalates because we can all

sort of find ourselves in that situation

144

and we've all sort of been there before

So that creates a level of understanding

145

But another thing I will try to do is

then to look at that and try to raise

146

my concerns So what are the concerns

that I have around for example consuming

147

a more granular event That we're just

gonna have to handle many more events

148

and I don't really care about consuming

all of that Or is it because there are

149

concerns around some things that may for

example introduce some type of coupling

150

for example let's say as an example I use

a lot Let's say that you have some credit

151

card service right And it's emitting all

of these transactions that are happening

152

on the service but there's another service

that just Wants to know I want to know at

153

the end of the month how much was spent

on the credit card right And then you

154

could have this team saying yeah but you

already have access to all of these events

155

on the card so why do I need to create

the summary event for you Well then you

156

could say well the problem is that now I

have to understand what a period means to

157

you That's something that is actually a

concern of your service And I don't want

158

to duplicate that type of logic into my

service because that would create coupling

159

between us And I'm sure you wouldn't want

me to copy that type of logic because then

160

if it changes I would have to change it

too And then we become tightly coupled

161

to each other and then we get other types

of messes right So it's it's also about

162

having those types of conversations of It

might take a little bit more work now but

163

it's going to protect your independence

or your autonomy in the longer term So I

164

always try to find these types of angles

165

Andrew Harmel-Law: so, I think that's

super interesting, Layla, because,

166

I think sometimes teams don't,

they're not aware of that, right?

167

They kind of just, they're not aware,

like somebody else worries about the

168

boundaries between them and the other

team and, and typically someone else

169

also worries about how long it'll take

another team to do the work versus how

170

long it'll take you to do the work.

171

And I think That's super interesting

'cause that's stuff that's is

172

usually someone else's problem.

173

Right.

174

But, but in the cases that you've

described, you're trying to bring that,

175

at least make them aware of that, which I

think is really interesting 'cause it's.

176

Andrea Magnorsky: we're trying to aim

towards autonomous teams, then considering

177

your boundaries as part of your day to

day needs to be, something, an activity.

178

And actually, this is where I was

gonna ask you, Layla, like how

179

do you help teams to, 'cause you

said, oh, it could be a symptom of.

180

Not greatly defined boundaries.

181

And let's face it, that's probably

happening like all the time.

182

Right?

183

And sometimes you can't do anything

about it, but sometimes there is

184

some wiggle room to, because they

realize that teams are moving slower

185

because they're lacking the autonomy.

186

And so when you do have to do boundary

work, how does that work for you?

187

Like what, what kind of

activities do you do?

188

And also, how do you find it?

189

'cause you, you talked about like,

well sometimes feelings give you, like

190

the, not just the personal problems,

which there definitely would be because

191

you have the power plants, but the

technical side effects of those bank.

192

Please.

193

Laila Bougria: Right Um absolutely So

first I want to just say that I was

194

thinking exactly the same thing as what

you said is I think service boundaries

195

shouldn't be a few people's problem I

think that's something that is owned by

196

the entire team and all of the teams that

are basically collaborating with each

197

other because the more people understand

those boundaries I think the more likely

198

it is that we surface those problems

earlier and otherwise it becomes this

199

thing that you don't care about and

then you would be less likely to push

200

back to consuming a granular event for

example and then creating this sort of

201

coupling So I just wanted to um add to

that But yeah when when it comes to Sort

202

of doing that service boundary work I

I've always and this is something that

203

is not something I've learned due to sort

of building event-driven systems but I

204

think it just comes from my own personal

curiosity I've always wanted to understand

205

the business I've always had really hard

time to actually write code if I don't

206

understand what the purpose of that Thing

is I it's just something that for me did

207

not compute And honestly I felt like in

the like especially in my junior years as

208

if I was doing something wrong because I

I felt unable to just well here are the

209

requirements Leila just build it And I'm

like but but but I have so many questions

210

and I don't understand this And how does

that work And why do we do this And and

211

I felt like really annoying and it took

years for me to realize that that was a

212

strength and not a weakness but Yeah I

think that's that's one of the parts is

213

that to continuously ask questions as to

why are things connected to each other

214

there's a lot of work that goes into

understanding these types of boundaries I

215

try to do that work early but it's also A

continuous job it never really ends right

216

Every time something changes you almost

have to re-question those things to make

217

sure you didn't miss something earlier

or if something changed And this is where

218

things get tricky because especially if

it takes you a lot of effort to define

219

service boundaries then people are like we

got them We will never touch these again

220

And reality It does not reflect that right

It's just that's not really how it works

221

one thing I tend to do is first of all if

we can have these conversations that at

222

least surface these maybe imperfections

or full out wrong decisions in terms

223

of our surface boundaries Sometimes we

can't immediately fix them because again

224

multiple teams are involved and it's also

not easy because some DA data might need

225

to be migrated and things like that It

can become quite complex and sometimes

226

the only thing we can do is work around

it But I think for for me it's always

227

been really important to surface it to

document it and to keep track of all of

228

the friction that we encounter because

the surface boundaries are off Because

229

in many cases what I found is That there

may be an agreement within the team that

230

service boundaries are off but for not

getting the budget to make those changes

231

for example and then collecting evidence

of what type of friction those errors or

232

in in the service boundaries are causing

us can basically act as better evidence to

233

have the discussion of okay now we really

need to prioritize that work Because this

234

bug or this discussion or this feature or

this coupling has been causing us issues

235

and then that makes it much easier to sort

of have that discussion So yeah I I build

236

evidence That's one of the things I do

237

Kenny Schwegler: One thing I

see and I I feel having myself

238

as well is perfectionism is the

enemy of design and architecture

239

Laila Bougria: Mm-hmm

240

Kenny Schwegler: try to come with and

we try to come with reason even though

241

we have our own personal opinion Of

course you think of a moment in the

242

past where you're like this needs to

be this needs to be this way But budget

243

teams other people thought differently

so you went with another decision

244

and that's sort of like a loss for

your for yourself I feel It's a loss

245

Laila Bougria: Yes

246

Kenny Schwegler: with that Can you

tell something about that Because

247

I think that's the most common

thing that that well at least

248

I I deal with right Letting go

249

Laila Bougria: Yes actually I can think

of two situations to be honest And one

250

of them I was actually working at a bank

for which I worked for five years And we

251

basically built a system that replaced a

mainframe To to say it in like a single

252

sentence right So it's an entire banking

system and I remember that there was a

253

piece of code that I could just look at it

from a distance and I'm like this is going

254

to be trouble But then you know the rest

of the team was like but we already have

255

the tests and this is already done And And

I'm like I could really see trouble And

256

they were like yeah but no but we have to

move on And and and and I was like okay

257

so move on And this is where I this is

an example of where I kept evidence So

258

every time a bug came in that was related

to that It was just being fixed Oh we're

259

gonna fix this scenario and now we're

gonna fix that scenario Now we're gonna

260

fix that scenario And I just kept track

of every time a bug came in and I just

261

didn't intermingle I was like okay it's

fixed Fine And at some point I think we

262

were at I don't know like almost 10 ish

bugs I just raised it and I said okay look

263

I don't wanna be like and I I I tried to

in those cases not use the I told you so

264

card Because that just doesn't really help

in terms of your relationships But just

265

to kind of raise it as look I I thought

we would have some problems there and

266

I've been seeing that we are seeing a lot

of bugs come in into this sort of area

267

and I've collected them I really think we

need to rethink this thing and see how we

268

can adjust it And I think by presenting

it that way it enabled Me to convince

269

the rest of the team to actually make

room for that And that's when we actually

270

refactored the whole thing And from there

it was mostly bug free So that was one

271

scenario Kenny but actually I also have

a completely different scenario where I

272

was like yeah this is this is wrong I'm

sure this is wrong And I was had to let

273

it go but internally hadn't really let

it go And it was like something that was

274

frustrating me So I was kind of doing

the same thing of okay let me gather

275

evidence around this And after a while I

saw there is no evidence which I think is

276

an equally good exercise because it was

proof to myself that I was wrong which

277

is fine But but basically a reminder that

you know even when we feel very strongly

278

or think very strongly about something

it's a kind of like this humbling

279

exercise of you're not always right

which I think is necessary for everyone

280

Kenny Schwegler: I like that especially

because as architects you do a lot based

281

on heuristics right On things that worked

in the past So I like the evidence I I

282

like that as a heuristic So also I Be be

evidence towards the wrongness because

283

sometimes you need to take a decision in

a moment based on like gut feeling maybe

284

which we call heuristics but it's great

that keeping evidence and see if you're

285

right or wrong That's I I like that Yeah

286

Laila Bougria: Yeah it's actually a

technique I use in many different areas

287

even let's say with like let's say

processes that you have in an organization

288

that you believe have friction right

Sometimes it can be like oh very

289

frustrating and you want to go and change

it immediately and you can Because it's

290

someone else's job Then sometimes also

it's also the distance that it gives you

291

right Because that's actually I would say

my technique of letting go it's like I

292

don't feel like I'm entirely letting go

because I'm keeping track but it does give

293

me a lot of distance and after a while

it gives me um sort of evidence either

294

for or Against myself but that gives me a

good insight into hmm what did I get wrong

295

or what could have gone differently here

296

Andrea Magnorsky: I just kind of think

it's, uh, I looked at two examples that

297

are superimposed and I think it takes

wisdom to acknowledge and, and, and kind

298

of have the level of introspection to

first build those processes for yourself.

299

And also then to acknowledge

other people's processes, but

300

also to just go like, okay, there.

301

You know, this works and I might not

like it, which is different from, it

302

doesn't work, and in fact, it might

work better than I could have done

303

because I'm not having that problem.

304

Laila Bougria: Yes exactly

Yeah I I think it's um

305

Andrea Magnorsky: I.

306

Laila Bougria: That's that's for me

a good way to learn because sometimes

307

we can have resistance about something

but if after a while and I think that's

308

where the distance is really essential

because we always say that people cannot

309

not be emotional right We are emotional

beings so sometimes we'll get upset

310

about something We feel strongly we're

motivated we're passionate whatever And

311

that can sometimes lead to a situation in

which we push too hard right So by also

312

by having that distance and waiting and

seeing how things are gonna evolve we can

313

also sort of learn of yeah like you said

Andrea I I got it totally wrong And what

314

can I learn from this To improve myself

and I think that has been definitely an

315

eye-opener a humbling one sometimes which

is also a good thing right It's like

316

Andrea Magnorsky: Nothing like that.

317

They just slapping you

right in your face, like

318

Laila Bougria: yes

319

Kenny Schwegler: But I think that's the

tension right I think most architects

320

or most people are like we need to make

a rational trade off process Yes And

321

there's emotions and past feelings and

we're dealing with complexity So we

322

actually don't know what's gonna happen

and what's the right decision now because

323

as as my dear friend says if we are

clairvoyant it would all be very much easy

324

architecture We don't need to do it But

we're not clairvoyant unfortunately So

325

there's this lot of emotions past things

happening and they're there And I what

326

I like about what you are just saying is

at least have a process to continuously

327

recheck yourself against what's happening

now And turn don't don't step into the

328

socalled fallacy And I think if teams

actually do that By default as a team

329

we would be making very better decisions

or architecture that adapt I guess

330

Laila Bougria: Right So talking about

processes to kind of close the loop on

331

this I actually have a process For myself

of having like quarterly retrospectives

332

and I have these notes of things like

these that I've been keeping track of so

333

let's say that in the meantime I use it

as a data point collection type of thing

334

I don't spend brain cycles thinking about

it I just note it down and then every

335

six weeks 12 weeks whatever works best

for you I just go through the list and

336

every time there's something I can just

throw off the list like in the sense of

337

Hmm either I don't feel as strongly about

this anymore I just I changed my mind

338

over time Or it could be like I thought

there was a problem here It doesn't look

339

like there is a problem here and then

it allows me to move on But by circling

340

back to it you're basically kind of also

resolving your personal feelings around

341

it and really letting go So yeah that's

my advice to anyone who's listening to

342

have some kind of a process like that

343

Andrea Magnorsky: That's beautiful.

344

Also, it allows you to learn

where, where were you wrong?

345

So it's like not only you can let it

go and go, like, actually that was

346

probably a, a false positive or a.

347

The opposite, but, but you are able

to kinda, sometimes you might be able

348

to go like, actually I was looking

for type of bugs, X, Y, Z, whatever.

349

It's, and then that didn't happen, or

it happened in a different way, but

350

you're like, oh, what is the signal?

351

And then you can close, close it.

352

So it's like, not only can you drop it,

but also you cana Activate the learning

353

and, and kind of you even have notes

about it is great 'cause you could

354

Laila Bougria: Yes

355

Andrea Magnorsky: that,

that you did ages ago.

356

Very

357

Laila Bougria: Yes Yeah absolutely Yeah I

call them personal retrospectives I mean

358

we too we tend to do retrospectives in

group but I find them very very helpful on

359

a personal level as well Like what was I

frustrated about six months ago And then

360

you look back to it and you're like ah Is

that what I was frustrated about really

361

So things like that can really it

lightens things up and it allows closure

362

of of things that otherwise the last

thing you remember about something

363

is that frustration and this kind of

mitigates that it provides this sort

364

of checking point with yourself of

like oh it's like it was actually not

365

that bad or something like that So

366

Kenny Schwegler: And we all have

that And if people think oh I don't

367

have that Think the last time that

that you're hungry right And you eat

368

maybe a little bit too much and then

in retrospect you're like nah have

369

done that I shouldn't have stuffed

my face with that And I guess that's

370

with certain decisions as well being

371

Laila Bougria: Yeah

372

Kenny Schwegler: about decision but

later on you're like eh was just an

373

emotion or a certain other thing So

374

Laila Bougria: Actually I find that

in architecture we see this all the

375

time because like you said a lot of

architects sometimes also make decisions

376

based on gut or heuristics like you said

but those heuristics are usually like

377

emotional So if something didn't work in

an environment it doesn't mean that it

378

won't work in this environment So Again

like all of the the context is completely

379

different and and by doing this sort of

retrospective you can sort of think about

380

okay why didn't this work in a specific

scenario And that then allows you to

381

sort of not completely rule it out in

the future in a different environment

382

Kenny Schwegler: Yeah it's the same

Like if I go to my school here I take

383

the bike but I shouldn't do that in

many other countries Uh when I was

384

a child Context changes a lot So uh

385

Laila Bougria: Yes

386

Kenny Schwegler: Thanks Thanks for your

stories and thanks for being on the show

387

Laila Bougria: Thank you for having me.

388

Kenny Schwegler: listening Yeah And for

people who listening like subscribe I need

389

to say this spread the word Hopefully this

would very helpful to you um good thing

390

to know we'll be all at DDD Europe so

talk to us about these stories You have

391

your own stories we would like to know

392

Andrea Magnorsky: Cool.

393

Kenny Schwegler: see you soon

394

Andrea Magnorsky: Thank you.

395

Bye-bye.