There's a pattern that turns up in almost every struggling team: the problem gets named as technical, the technical fix gets applied, and nothing improves. The complaints come back louder, and the only thing that really changes is who gets blamed next.

We recorded this one differently. At DDD Europe, Andrea, Kenny, and Andrew spent the conference wandering the halls with a single question for attendees and speakers alike: what's the hardest part of facilitating software architecture and design? Nine people answered — Matthias Verraes, Zsófia Herendi, Stefan Hofer, Samantha Dellaert, Eric Evans, Henning Schwentner, Hadi Ahmadi, Alexandra Junghans, and Susanne Kaiser — and their answers sorted themselves into three groups: one about how organisations are wired, one about who's actually in the room, and one about the facilitator's own state of mind. Almost none of them was really about software.

Matthias mapped a "broken" core team and found the failure was economic, not technical — and surfaced it by inventing notation on the fly ("one red dot means I don't like working on this; three means I'd rather quit"). Eric Evans argued that fun is a diagnostic, not a perk. Henning Schwentner reminded us that without the right people you don't have collaboration, just modelling. Susanne Kaiser showed why the real negotiation is often with leadership, in a different language entirely.

This episode is a tour of the gap between technique and reality — the power structures, the missing domain experts, the curiosity you can't manufacture, and the question that outlasts every workshop: what needs to change for the insights to actually go anywhere?

Key Discussion Points

• [00:00] One Question, Nine Answers: The premise — roaming DDD Europe to ask what's genuinely hardest about facilitation
• [01:00] Matthias Verraes — The Problem Was Economic, Not Technical: A blamed core team, country profit centres, and externalised costs
• [04:00] "Put the Ugh on the Map": Improvised red-dot notation to make frustration, churn, and CEO access visible
• [07:00] Zsófia Herendi — You Can't Manufacture Curiosity: Leading by example when the room just sits and stares
• [09:00] Stefan Hofer — From Writing Code to Building Things: The mindset shift behind stepping into rooms full of people and sticky notes
• [11:00] Samantha Dellaert — Making the Bigger Picture Visible: Starting with a model of the whole so people can locate themselves in it
• [13:00] Eric Evans — Fun as a Diagnostic: Why enjoyment is information about whether the work is going well, not just a nice-to-have
• [19:00] Henning Schwentner — Get the Right People: Without real domain knowledge, it's modelling, not collaboration
• [22:00] Hadi Ahmadi — The Sociopolitical Layer: Why power structures cause the most issues, and studying outside engineering
• [24:00] Alexandra Junghans — Just Start: Teaching facilitation from the ground up; there's nothing to lose
• [25:00] Susanne Kaiser — Speaking Leadership's Language: Reframing three days of modelling as investment, not cost

Guests: Matthias Verraes, Zsófia Herendi, Stefan Hofer, Samantha Dellaert, Eric Evans, Henning Schwentner, Hadi Ahmadi, Alexandra Junghans, Susanne Kaiser

Hosts: Andrea Magnorsky, Andrew Harmel-Law, Kenny Schwegler

Hello, and welcome to this amazingly 3D, for us at least,

2

version of stories of facilitating

software design and architecture.

3

Wow.

4

That's the title that I use.

5

What about you?

6

Okay, Kenny, say some words.

7

Kenny Schwegler: Yeah.

8

We're here at DDD Europe, and

it's a special time because

9

We're all a speaker, and we

thought in this get-together,

10

we're just gonna talk with some

people around the conference here.

11

Mm-hmm.

12

See what they have for short

bite-sized questions, right?

13

Mm-hmm.

14

Andrew?

15

Yeah.

16

Andrew Harmel-Law: Yeah, exactly.

17

So we're gonna be wandering around

and asking unsuspecting conference

18

attendees, and maybe some speakers,

the question that Kenny said to find

19

out what they do for facilitating

software architecture and design.

20

Andrea Magnorsky: we're

here with Matthias.

21

Hello, Matthias.

22

Mathias Verraes: Hi.

23

Andrea Magnorsky: So Matthias,

please tell us, what is really

24

important to you when facilitating

software design and architecture?

25

Mathias Verraes: I have an anecdote.

26

this was from 2015, I think.

27

I was consulting at a company to do

modeling and domain-driven design

28

and one problem was that they

had, a team working on core stuff.

29

Andrea Magnorsky: Mm.

30

Mathias Verraes: Uh, but it

was always a huge problem.

31

It was always a mess.

32

They would always get

complaints from dependent teams.

33

and so I started investigating, asking

questions, and mapping everything

34

else that was not the architecture…

35

Not just the architecture, but,

like the social network, the value

36

creation network, these kind of things.

37

Mm-hmm.

38

And I uncovered that, this

team was building core stuff.

39

there were teams in each country that

were doing customer-facing, like small

40

customizations on top of the core stuff.

41

Andrea Magnorsky: Mm.

42

Mathias Verraes: These teams could

actually all make, commits in the other

43

team's core thing, and they would also

often just ask for feature requests.

44

And then all the other teams

would complain, of course, that

45

they broke something, but this

team got blamed all the time.

46

Andrea Magnorsky: Yep.

47

Mathias Verraes: And then I looked at

how the money worked, and all these

48

teams were basically profit centers,

working directly with customers.

49

This was just seen as a cost.

50

And these teams, at least some of

the big ones, had the ear of the CEO.

51

So they would be able to complain about

this team, and this team would only,

52

like, would only be mentioned to the

CEO when stuff was going wrong, which

53

was actually caused by all these-

54

Andrea Magnorsky: Yeah

55

… Mathias Verraes: different actors.

56

Andrea Magnorsky: A common pattern.

57

Mathias Verraes: Yes.

58

So, but by exposing that, we saw that

the legacy is not a problem with the

59

team itself or with the, the technology

or the software itself- Yeah … but

60

with the whole organizational structure.

61

I proposed, of course, to make this

team, first of all, shielded so

62

nobody could make commits anymore.

63

Everything had to be a request

that they could balance against

64

all the other needs, of course.

65

but then on top of that, the, the other

teams, the local teams, would have to

66

pay for feature requests so that they

had a, a revenue model and their…

67

Because their, their actual cost,

their profits are, are public in

68

the company, but their costs are

externalized to this one team.

69

So, unfortunately, they did not do it.

70

I did not have, the ear of the CEO.

71

but, it's like, there's always other

layers and things that you are maybe

72

not looking at if you're using a

narrow lens of event storming or

73

Wardley mapping or any, any tool.

74

There's the layers of, of, you know,

culture, social, networks value, money,

75

all these things that, that people think-

76

Andrea Magnorsky: So how did you facili-

what are the bits of facilitation you

77

had to do to navigate this kind of- Uh-

78

quite, first thing was, like, you

talked a lot about the discovery.

79

It's like, okay, I surfaced this.

80

Mathias Verraes: Yes.

81

Which is

82

Andrea Magnorsky: obviously super

useful 'cause then you can go

83

like, "This is what's happening.

84

What are we gonna do about it?"

85

Mathias Verraes: So how did I surface it?

86

Is that your question?

87

Yeah,

88

Andrea Magnorsky: yeah.

89

Mathias Verraes: Yeah.

90

part of it was just, you know, asking

questions and trying to find, like,

91

you know, how, how does this happen?

92

Like, because nobody has that

full picture at that point, right?

93

Yeah.

94

Nobody can, can tell you that.

95

Andrea Magnorsky: No, people are just

complaining and being frustrated-

96

Mathias Verraes: Yeah

97

… Andrea Magnorsky: you know,

98

Mathias Verraes: from

99

Andrea Magnorsky: every side,

100

Mathias Verraes: But I,

I put that on the map.

101

If somebody says, "Ugh," I say,

"Oh, what does this ugh mean?

102

Let's put that on the map."

103

"Yeah, I don't like working

with this, with this system."

104

Okay, let's have a new notation.

105

So I invent notation as I go along.

106

Andrea Magnorsky: Oh, cool.

107

Mathias Verraes: okay, we'll have

a notation now for, one red dot

108

means I don't like working on this.

109

Two red dots means I would really,

I really hate working on this.

110

Three red dots is I would rather

quit than working on this.

111

Andrea Magnorsky: Wow, okay.

112

Mathias Verraes: So you

can put that on the map.

113

That is valuable information.

114

Absolutely.

115

Uh, any kinds of bottlenecks, like, you

know, who's protecting access to the

116

CEO is something you could put on a map.

117

Andrea Magnorsky: Yep.

118

Mathias Verraes: you

make all these layers.

119

the customers always complain about

this, one dot, three dots, you know.

120

Andrea Magnorsky: Mm.

121

Mathias Verraes: you start

seeing clusters of stuff.

122

Andrea Magnorsky: Yep.

123

Mathias Verraes: the customers

always complain, it's not

124

being sponsored very well.

125

there's a lot of, churn in the team.

126

You see all these different factors

overlaid on each other and you

127

start to, okay, a lot of color here.

128

What's wrong, right?

129

What's happening?

130

Yeah,

131

Andrea Magnorsky: at least it gives

you a really visual way to kind of go

132

like, okay- Yeah … problems here.

133

Mathias Verraes: So then you see

that it's not just a technical

134

problem or a people problem or a-

Yeah … it's, it's systemic problems.

135

Yeah.

136

It's combination of, If you, if you

can surface that, then you don't

137

even have to solve the problem

most of the time because people are

138

now seeing, oh, that makes sense.

139

I never thought about it that way.

140

Andrea Magnorsky: Oh, I

like that as a heuristic.

141

It's like sometimes surfacing the

social issue is a way in which the

142

problem starts, solving itself.

143

Mathias Verraes: Yeah.

144

People solve problems.

145

We're problem solvers, but we solve

problems that we are That, that,

146

that are visible to us, right?

147

That's a, a natural instinct.

148

That's very normal.

149

It's availability bias.

150

Andrea Magnorsky: Maybe we need to do what

Einar suggested, with when it comes to

151

social dynamics and just maybe they should

throw a party so everyone gets together

152

Mathias Verraes: But, but,

but that as well, right?

153

Like, how do I surface these things?

154

Sometimes it's just going

to lunch with people.

155

Andrea Magnorsky: Yeah.

156

Mathias Verraes: sometimes it's

making sure that, some of the

157

people are not in the room.

158

Yeah.

159

Because people might be more

open about certain things if-

160

Yeah … their boss is not there.

161

Yeah.

162

Or, you know, someone they

see as a bottleneck to that.

163

Andrea Magnorsky: Absolutely.

164

Mathias Verraes: Uh, so

find ways of not just…

165

Uh, like I love to get

everybody in the room.

166

It's very pr- productive.

167

There's some chaos, and in

chaos, the new links exist.

168

Andrea Magnorsky: Yeah, and

then emerges and, convergence.

169

Mathias Verraes: But, but sometimes the

details and the frustrations and the

170

opinions- Yeah are, are a bit more hidden.

171

Andrea Magnorsky: Excellent.

172

Mathias Verraes: So I

put those on the map.

173

Andrea Magnorsky: Excellent.

174

Well, thank you, Matthias.

175

Thank you for your time and

for sharing this with us

176

… Mathias Verraes: my pleasure.

177

Andrew Harmel-Law: we've

got Zsófia with us.

178

Hi.

179

And Zsófia, we were wondering if

you could tell us, about maybe a

180

challenge that you've had with,

trying to facilitate sessions with…

181

about software and

architecture and design.

182

Zsófia Herendi: Well, that's

not one particular challenge.

183

It was, and has been very challenging

actually, because, yeah, dealing

184

with people, especially who are not

that curious and not willing that,

185

to participate in those modeling

sessions, in those developing

186

or shared understanding moments,

187

So there are a lot of people,

in my experience at least, who,

188

who didn't want to do that or

was, uh, neglecting to do that.

189

And for me, it's the most difficult

part to deal with those people.

190

Because It's on me probably, but I,

I really hardly can accept when, so

191

that other people don't really have

that same curiosity level than me,

192

Yeah.

193

Andrew Harmel-Law: Yeah,

194

Zsófia Herendi: no, I can imagine.

195

And it's just, it…

196

Yeah, it differs.

197

I need to accept it.

198

I need to approach the

situation a- accordingly.

199

Andrew Harmel-Law: have you got any

tips for, like, trying to change the

200

situation or make it easier, or…?

201

Zsófia Herendi: what I did

is I try to lead by example.

202

that's all.

203

And sometimes it stick for

people, sometimes it's not.

204

But I stay curious, I stay enthusiastic,

let's say, when, whenever I do a session

205

or whatever I facilitate, even at my work.

206

So, even when people just, just sit

there and, and just looking at me,

207

I just try to be enthusiastic and

that's sometimes working, sometimes

208

not, but still, it is what it is.

209

It is me.

210

Like, I- Yeah … I really

like facilitation and also the

211

topics usually I am in, so.

212

Andrew Harmel-Law: Yeah, nice.

213

Zsófia Herendi: Yeah.

214

Andrew Harmel-Law: Right.

215

That's great.

216

That's- Thank you very much.

217

Zsófia Herendi: Thank you.

218

Kenny Schwegler: I'm here with Stefan.

219

You're a domain storyteller

inventor, right?

220

So you do a lot of collaborative modeling.

221

So I'm curious to know, once you

started, what was the biggest

222

challenge for you to do collaborative

software design or architecture?

223

Stefan Hoffer: I chose the profession

of software development because I like

224

computers, and suddenly I find mes-

myself, in rooms filled with people

225

and no computers, and we, we use sticky

notes and whiteboards and whatnot.

226

And, so that was a big challenge, like,

you know, going out of my comfort zone

227

and talk to people, interact with them.

228

But I had, great role

models, that, that helped me.

229

So I had, a chance to follow the footstep

of some other people that came before me.

230

And then what was a big motivator

for this shift and, putting yourself

231

out there is writing the code has

never really been the problem.

232

Mm.

233

So requirements, understanding

what to build, building good usable

234

business processes, supporting

users, that is the problem.

235

And once my mindset shifted there

from I need to write great code into

236

I need to build great things and

great solutions, then I was able

237

to open up to this challenge of,

interacting with people and, and yeah.

238

Kenny Schwegler: Yeah.

239

Um- So what would be a tip that

you might give to the listeners,

240

readers, watchers, Yeah … starting

or already in collaborative

241

modeling, doing collaborative model?

242

What helped you?

243

Stefan Hoffer: if you've never

done it before, find a local

244

meetup, a conference, whatever.

245

They usually have hands-on workshops,

so sessions at a very low barrier,

246

where you can try this stuff out.

247

It's really about trying it.

248

It's books, et cetera, help, but

eventually you need to do it yourself.

249

So that would be my, my recommendation.

250

Kenny Schwegler: Yeah.

251

And that's why these conferences,

like DDD Europe, Kandinsky,

252

Explore DDD help, I guess, right?

253

Yeah.

254

Exactly.

255

Yeah.

256

Because there's a lot

of hands-on material.

257

Yeah.

258

Thank you very much.

259

Stefan Hoffer: You're welcome Ag- Kenny.

260

Andrew Harmel-Law: I'm here with Samantha,

and- That's me … we were hoping you

261

can tell us about a thing that you found

difficult with trying to facilitate

262

software architecture and design.

263

Like, a, like a- Yeah … thing

that you've encountered.

264

Samantha Dellaert: Well, one of the f-

challenging things I found is, like,

265

all the way in the beginning, just

trying to convince people that it's

266

a thing that needs to happen, 'cause

people are so used to, like, developers,

267

domain experts, they're used to their

little bit of the, the whole, right?

268

And they don't see it

as a bounded context.

269

They see it, like, "I need to do a

little bit here, a little bit there,"

270

and they don't see the connections.

271

They don't see the isolation.

272

Right.

273

And then to get them to think about

how, like, is this interacting?

274

What is the, the bigger picture?

275

It's very difficult, I find,

for pe- for people- Mm-hmm

276

to get into.

277

Andrew Harmel-Law: That's so true.

278

Yeah.

279

And have you got any tips?

280

Have you ever managed to solve

this maybe sometimes or…?

281

Samantha Dellaert: Solving is difficult,

but I find if you can start with,

282

like, a model of the whole thing, so

you do maybe e- even just an event

283

storming for the big picture design,

and you can show, like, "Hey, these

284

are the things we think that exist,

and can you find your space in this?

285

And how do you think we'll…

286

Like, what part of this can we take, as

a separate bit that is more manageable?"

287

Mm-hmm.

288

And then what are the

connections with that?

289

And if they can visualize it,

because if it's just words, people

290

can't comprehend it too easily.

291

Yeah.

292

So I find that w- that helps a lot.

293

Andrew Harmel-Law: That's fantastic.

294

Thank you very much.

295

You're welcome.

296

Andrea Magnorsky: So we're here

with Eric Evans, and, we're

297

talking about facilitating, well,

software design and architecture.

298

And the question for you, Eric, is, you

know, you, prefer to, I, I assume, work

299

with people and design software and,

and ar- and do architecture with people,

300

but maybe you could do it not that way.

301

So why do you do it

the way that you do it?

302

And maybe you can explain

how you do things.

303

Eric Evans: So for a start,

I think it is a lot more fun

304

designing with other people.

305

Like creative, you know, a creative

session at a whiteboard, imagining all

306

the possible designs and everything.

307

It's really one of the most fun things.

308

And then the other thing is,

though, that it just doesn't work.

309

I mean, I remember when I was starting,

and most of the time we did not have that.

310

I was, you know, a junior programmer or

even a senior programmer or leading a

311

te- And we would get assigned a feature

or something and program the feature

312

without any real interaction with

anybody, and the results were terrible.

313

Andrea Magnorsky: Yeah.

314

Eric Evans: And so I guess

originally I did it because it

315

just seemed like the only way we

ever got anything to actually work.

316

But I would say that now if I…

317

So that's my real answer, and

then I would say it's actually

318

genuinely a fun thing to do.

319

Andrea Magnorsky: But Eric,

nobody cares about fun anymore.

320

Eric Evans: Yeah,

321

Andrea Magnorsky: but- We all care

about just money and delivering fast.

322

Eric Evans: Yeah,

323

Andrea Magnorsky: okay.

324

I'm being cynical, by the way.

325

Eric Evans: But delivering fast

comes from doing smart things, and

326

I think that humans have all kinds

of useful instinctive feelings in

327

our brains, like, that guide us.

328

Like, you know, if you see a dangerous

snake, your, your brain reacts with fear

329

and so on, and that's, that's because for

millions of years, you know, that, people

330

who didn't react that way didn't do as

well as the ones who did react that way.

331

And I think that the sense of

fun is a really useful guide.

332

Andrea Magnorsky: Mm.

333

Eric Evans: I think doing

things that are fun, i- there's

334

usually some value in there.

335

Like, I really believe

that, and I think it's…

336

You know, I have a pretty long

career at this point, and, uh, if

337

Andrea Magnorsky: I- Well,

like 10 years, 'cause, right?

338

Eric Evans: Oh, only the last

10 years counts, of course.

339

But the…

340

But it does go back before

there just a little bit.

341

And, just a couple years further back.

342

But anyway, during this time, if I

reflect, I would say that most of the

343

really valuable things were in fact-

344

Andrea Magnorsky: Really fun … all

345

Eric Evans: really fun.

346

Yeah.

347

And i- the projects where it

was just a terrible drudgery,

348

generally didn't work out so well.

349

of course, every project, no matter

how fun and how collaborative,

350

whatever, everything has its drudgery.

351

You go through those little crunch

periods and stuff that's not fun.

352

I don't mean to say you should be

having fun every minute of every

353

day, but I do think that matters, and

I think it's, it's a useful guide.

354

It's something people should

listen to in their own head.

355

Andrea Magnorsky: Hmm.

356

Eric Evans: And, so collaborating

with domain experts, right?

357

That's one of the things that we just

have to do, whether we like it or not.

358

But I think-

359

Andrea Magnorsky: Might as well

enjoy it while you're doing it.

360

Eric Evans: Yeah, yeah.

361

Yeah.

362

And, um, and it's probably a guide

to how well it's working, right?

363

Like, try to find the fun in it.

364

Try to engage them in a

way that's fun for them.

365

All this really helps.

366

It really, really helps for one thing- Hmm

… because you need them to come back.

367

You need them to do it more.

368

And now we're collaborating with

AI agents, so, you know, at least

369

that's probably my most common

form of, of, collaboration right

370

now, is, I spend hours, you know,

talking to Cloud Code or something.

371

Andrea Magnorsky: Hmm.

372

Eric Evans: And it follows something

of the same pattern, I would say.

373

Though it is really, of

course, quite different.

374

But yeah, that would be my answer.

375

Andrea Magnorsky: That's your answer.

376

And so, imagine, maybe a, a

young and naive Eric many years

377

ago, but he's here right now.

378

So it's like you, but you were m-

time, you know, time traveled to here.

379

Your clone of you being 22- … is

time traveled here, and they, he

380

hears, he hears, collaboration good.

381

What would…

382

And he goes like, "Oh, this

sounds kind of interesting."

383

So what would be your tips to young Eric?

384

Eric Evans: Oh my goodness, young Eric has

a lot of learning to do- I know, right?

385

… around all this.

386

Yeah.

387

I think, yeah, I don't know.

388

That's an interesting question.

389

I hadn't thought about that.

390

But, actually, I mean, I wasn't

in software when I was 22.

391

I, you know, I didn't actually

study that in college.

392

I had a math physics degree, and then

I went off and traveled a little bit-

393

Andrea Magnorsky: Of course

394

… Eric Evans: in South America for a while,

and then I went back to grad school, uh,

395

and then eventually got into software.

396

So, yeah, I, I guess I wouldn't have been

talking to young Eric about how to, how

397

to participate in a software project.

398

Andrea Magnorsky: Well, what

would you tell him anyway then?

399

Eric Evans: Oh.

400

Well, what happens when you're

22 stays where you're 22.

401

I would say, "Don't do that

thing," which 22-year-old me

402

knows what I'm talking about.

403

Andrea Magnorsky: But so, so s- … so

darkness, secret around 22-year-old.

404

Yeah,

405

Eric Evans: yeah.

406

Andrea Magnorsky: Okay.

407

Cool.

408

Eric Evans: There are, there's some

things we just don't talk about-

409

Andrea Magnorsky: Good to know … me

410

Eric Evans: and 22-year-old Eric.

411

Andrea Magnorsky: Yeah.

412

That's awesome.

413

well, thank you so much, Eric.

414

Eric Evans: Thank you.

415

Andrea Magnorsky: Thank you

for being at Virtual DDD.

416

Eric Evans: All right.

417

That was a lot of fun.

418

Kenny Schwegler: Our next person today at,

DDD Europe and his stories of facilitating

419

software architect design is Henning.

420

Oh, no.

421

Hi, Henning.

422

Hey, Danny.

423

Thank you very much.

424

And now I see double.

425

So my first question to you is that we

ask everyone, is name me a challenge that

426

you had when you're trying to facilitate

software architecture and design.

427

Henning Schwenter: Yeah.

428

So when I facilitate software

architecture and design, for me

429

that typically means understanding

processes, so collaborative modeling.

430

And for me, this challenge has

always stayed the same, and

431

that is get the right people.

432

So if you don't have people that,

have real domain knowledge, if you

433

have only proxies or only developers

or only managers that think what's

434

happening but that do not really know

what's happening, then how much…

435

No matter how much collaborative

modeling you're gonna do, it will

436

not help to get to the real process.

437

And when you don't understand the

real business, then you will not

438

be able to build great software

to support the real business.

439

Yeah.

440

Kenny Schwegler: It will be easier

collaborative modeling alone, right?

441

Because you don't have all these numerous-

442

Henning Schwenter: Yeah.

443

You don't have…

444

You, you can only model.

445

You don't have you don't need

the collaboration, right?

446

Kenny Schwegler: Yeah, yeah.

447

So what's one tip that you would give to

our, viewers, listeners, Yeah … readers

448

that you think, "Well, this really

helped me," or, "I still use to this

449

day- Yeah … to help me move forward"?

450

Henning Schwenter: So I'm a programmer.

451

I came into programming because I wanted

to do something with computers, right?

452

And then I learned, well, programming

is at least as much about people

453

as it is about bits and bytes.

454

And so what I would recommend, especially,

younger people that come into our

455

profession, is, to not forget that

and to see, hey, it's not only that I

456

have to learn the newest technology.

457

So currently, of course, you wanna

do something with AI, and tomorrow

458

it will be another hype topic, and,

yesterday it was a different hype topic.

459

That's might also be interesting

to know these technologies,

460

but do not focus only on that.

461

Focus also on the other part, on this

understanding, people, understanding

462

what they are doing, because that will

always help no matter what the, technology

463

will be tomorrow or in 10 years.

464

We will still have to understand our

users, our subject matter experts.

465

Kenny Schwegler: Yeah, and this is

what I heard last week at a keynote

466

as well, people discovering AI now.

467

It's like, "Hey, you know what's handy?

468

Understanding the problem domain."

469

Exactly.

470

So domain-driven design is

still, still relevant in this.

471

Thank you very much.

472

Henning Schwenter: It was a pleasure.

473

Andrew Harmel-Law: I'm here with

Hadi, who's another attendee

474

at the DDD Europe conference.

475

Hi.

476

so Hadi, what is some kind of challenge

which you've experienced when you've been

477

trying to work with others to facilitate

software architecture and design?

478

Hadi Ahmadi: in my experience, the

most challenging part is always

479

working with people and the, you know,

sociopolitical aspect of working,

480

especially if you're working in a

big companies, real enterprises.

481

The way people work with each other,

collaborate with each other, and, I,

482

I always find that part especially the

most challenging part, especially for me,

483

because I have an engineering background.

484

I think most of us have

the engineering background.

485

Yeah.

486

So we are always into codes and pa-

patterns and, you know, computer stuff.

487

Yeah.

488

But when it comes to working with people-

489

Andrew Harmel-Law: Yeah

490

… Hadi Ahmadi: and, we were just

talking about the power structures

491

before the- Yeah, yeah, yeah … uh,

and, and they are really what causes

492

the most issues in my experience.

493

Andrew Harmel-Law: cool.

494

And have you got any tips that

you've learned, things that work

495

sometimes to, to maybe not get rid

of them because you can't get rid

496

of them- but to like work with them?

497

Hadi Ahmadi: For me, the biggest

tip that, is that try to get some

498

studies out of software engineering.

499

Andrew Harmel-Law: Mm.

500

Hadi Ahmadi: Because being in the

software engineering is always about

501

coding and designing and implementing.

502

But when you go outside and

you study about, people, study

503

about language, study about…

504

That, that's actually how I got into DDD.

505

Like, yeah.

506

Yeah, yeah, yeah.

507

Okay,

508

Andrew Harmel-Law: cool.

509

Yeah,

510

Hadi Ahmadi: yeah,

511

Andrew Harmel-Law: exactly.

512

Yeah.

513

So like paying attention to things bigger

514

Hadi Ahmadi: than software engineering.

515

Yeah, yeah, yeah.

516

Exactly.

517

Okay, cool.

518

Yeah.

519

Andrew Harmel-Law: No,

that's really interesting.

520

Hadi Ahmadi: Yeah.

521

Andrew Harmel-Law: Thank you very much.

522

Hadi Ahmadi: Thanks.

523

Andrea Magnorsky: Hello,

welcome I'm here with Alexandra.

524

Alexandra Junghans: Hello.

525

Andrea Magnorsky: so Alexandra, we

wanted to ask you, can you tell us about

526

m- why should we do facilitative work,

when we're doing software design and

527

not just kind of tell people what to

528

Alexandra Junghans: do?

529

Because we are all human beings.

530

I teach students at the University

of Applied Sciences in Switzerland,

531

in Lucerne, and, I want to plant

these seedlings that working as a

532

software engineer is not sitting alone

in your room, it's interacting with

533

people, it's trying to understand what

their needs are, it's communicating,

534

it's writing down, forming a model.

535

And I think, collaborative

techniques like big picture event

536

storming, so, are a great way to

engage my students into modeling.

537

Andrea Magnorsky: That's amazing.

538

And, do you have any tips for people

that might be struggling to get started

539

or they don't know, you know, maybe

they work in a place that nobody

540

does collaborative things, like, and

they think that something is missing.

541

What, what do you…

542

Do you have any kind of suggestions

on how to s- swap to better-

543

Alexandra Junghans: Sure.

544

Just do it.

545

Just start.

546

I'm a beginner as well.

547

I'm already living, so many things have

to happen that I can be here, so what…

548

There's nothing to lose.

549

We can just start.

550

Andrea Magnorsky: That's an

amazing way to, think to close on.

551

Thank you very much for

joining us at Virtual

552

Alexandra Junghans: DDD.

553

You're welcome.

554

Kenny Schwegler: Hello, and I'm very happy

that we catch Suzanne here at DDD Europe.

555

You gave a talk.

556

Yes.

557

And- a workshop, two

days … and a workshop.

558

Yeah, two days.

559

And, yeah, about actually

architectural for flow.

560

Mm-hmm.

561

So our question is, of course, when

you do all these collaborative things

562

or making facilitative design and

architectural decision, what's one of the

563

most challenging things you experience?

564

Susanne Kaiser: one of the

challenging thing is to bring the

565

right people at first in the room

to have this conversation that,

566

that, to explore the d- the domain

together and also to sell the…

567

It's kind of like they're selling

the idea that it's an, an investment

568

right now, a time investment, and, but

that's is beneficial for to understand

569

your problem domain first before you

then going into the solution space.

570

And sometimes specifically for management,

they are sometimes pretty reluctant

571

to, to, to support this financially

from, from the budget, since they

572

only see 15 people are gathering in

the room for three days and, they

573

are not working on their backlog.

574

And so they see that it's a missing

opportunity, and in fact, it's just

575

like it's gaining opportunities, right?

576

So we exploring the domain together in

order to derive a better solution for

577

problem domain that we want to solve.

578

And I guess they don't see sometimes

the gap between, like how I see it

579

from software architecture perspective

and how it is perceived from the

580

management level that it's more like

a cost instead of like an investment.

581

And that is something that I

find sometimes challenging.

582

and so whenever like, then

specifically software engineering

583

teams, approach me, like, "How

shall we then, then this communicate

584

with management to get buy-in?"

585

It's more like that I try to switch

into their language and to figure out,

586

like, okay, what are their outcomes

they want to achieve, and how does it

587

connect, with what we want to achieve?

588

Because we have the same goal in, in the

end, but we speak different languages.

589

And how we can then align them to that

we have the same common picture, uh,

590

same common goal we want to approach to.

591

So is this…

592

That's what I would say is the

s- sometimes more challenging-

593

Kenny Schwegler: Yeah

594

… Susanne Kaiser: getting a leadership

buy-in than working to collaborating with

595

the software, software development teams.

596

Kenny Schwegler: And that would

be also your tip then, right?

597

Yeah.

598

Find their pain-

599

Susanne Kaiser: Exactly … and

600

Kenny Schwegler: then you can

create a shared gain, I guess.

601

Exactly.

602

Susanne Kaiser: And they can…

603

Switching into their, their language.

604

Kenny Schwegler: Yeah.

605

Susanne Kaiser: And, so I also, like to,

to point out or to, reference then the

606

Accelerate book, for example, where we

have this link what, how, how much impact

607

software delivery performance have on,

productivity, profitability, market share.

608

So these are then, uh, um, numbers or

that it's a language that the management-

609

Yeah … better can, can better grasp.

610

And going from there, like

how is this connected?

611

Or with the papers like how, how software

quality correlates with defects and that

612

has a, the, like a decrease and, and, and,

and, yeah, it has a, a direct impact on

613

your, on your, business outcomes and how

to connect our world with the bu- with the

614

With the words that, the upper

management or leadership then can, can

615

translate and, uh, uh, yeah, refer to

616

Kenny Schwegler: Well done.

617

Thanks for your tips.

618

Susanne Kaiser: Thank you-

619

Kenny Schwegler: And,

620

Susanne Kaiser: uh- … for

621

Kenny Schwegler: having me here

Yeah, and hope to see you in

622

a future recording as well.

623

Yes.

624

So this is the- Absolutely, my

pleasure … official invite.

625

Susanne Kaiser: Uh,

626

that's the

627

Kenny Schwegler: official invite.

628

This is official then.

629

I'm happy to be, to, to be on

your- Perfect … on this channel.

630

Thank you.

631

Hope to hear a story from you very soon.

632

Susanne Kaiser: Yeah.

633

Thank you.

634

Kenny Schwegler: Bye-bye.

635

Susanne Kaiser: Bye-bye.

636

Andrea Magnorsky: What is the story

that changed your architecting

637

and software design career?

638

That is the question for you.

639

Thank you so much for listening

to us, um, saying words.

640

All the best season.

641

Andrew Harmel-Law: Thank you.

642

That's brilliant