We often assume that bad architectural decisions come from bad architects. But what if there are no architects at all—just a team of software developers trying to do their best, with no one in the room who knows how to facilitate a decision of that magnitude?

That's the situation Gien Verschatse found herself in early in her career. The team had just been pulled off a Phoenix project—a fresh-start initiative killed after six months—and reassigned to maintain a legacy system built on technologies that were outdated even then. Eager to modernise, Gien organised an EventStorming session to map the technical debt from an emotional angle: what frustrates you most? What makes your job difficult? The session was, in her words, an absolute disaster—she couldn't get people to step away from how the system currently worked. Meanwhile, a developer with a dominant personality pushed hard for an event sourcing implementation. It was cutting-edge technology, exciting, new. And that was enough. "The person who was the loudest in the meeting got their way. There was no plan. There was no sitting down and thinking this through. It was just 'this is the latest and greatest and we're going to do that.'"

The event sourcing system got built entirely alongside the existing codebase. The emotional wall of technical debt stayed untouched. QA didn't know how to test the new system. IT didn't know how to deploy it. People started leaving. Gien eventually left too—after a massive burnout, feeling like she'd failed. It took fifteen years and a career as a consultant to see it clearly: the problem wasn't the technology. It was that nobody in that room knew how to make architectural decisions together, and nobody was there to facilitate the ones that needed to be made.

This conversation explores what happens when dominant personalities fill the vacuum left by absent facilitation, why value-based heuristics are a more effective lever than emotional appeals, and what Gien—now co-author of a book on decision-making—would do differently today.

Key Discussion Points

1. [00:01] The Phoenix That Died: Gien's team is pulled off a promising fresh-start project and reassigned to a legacy system with outdated technology
2. [03:00] The EventStorming That Failed: An attempt to map technical debt emotionally collapses—the team can't imagine beyond how the system currently works
3. [04:00] The Loudest Voice Wins: A dominant developer pushes event sourcing through with no plan, no consequence-mapping, and no one with the skills to push back
4. [05:00] The Architecture That Solved Nothing: The new system is built alongside the old one; QA can't test it, IT can't deploy it, the technical debt remains untouched
5. [06:00] The Exodus and the Burnout: People leave one by one; Gien leaves after burnout, carrying a sense of personal failure that took years to reframe
6. [09:00] Quit Sooner: Gien's hard-won advice—it's okay to leave bad environments, and finding one is not a personal failure
7. [20:00] Digging Into the Preference: How Gien now uncovers the value-based heuristics driving strong positions—fear of skill obsolescence, career anxiety—without triggering defensive reactions
8. [22:00] Talking About Emotions Without Talking About Emotions: After 20 years in a male-dominated industry, Gien's approach to surfacing emotional drivers through values-based framing

Guest: Gien Verschatse, Evelyn van Kelle Hosts: Kenny Schwegler, Andrea Magnorsky

Hello everyone and welcome back to another,

2

episode story of facilitating

Software Architecture and design.

3

With me today is, hin za,

and, she'll tell us a story.

4

And with me are my

co-conspirator Andrea Mag Norski.

5

And we have Evelyn Van here as well still.

6

Hello.

7

Gien Verschatse (she/her): Hello.

8

Kenny Schwegler: very curious,

what story, you have to share.

9

Gien Verschatse (she/her): Okay.

10

Um, so my story is about something

that happened very early, in my career.

11

I think I have been working for, Two,

three years at that point in time.

12

so I got a job and I, started

out on a Phoenix sort of project,

13

like, we're going to do it better

and we're going to start over.

14

And so I was part of that

team for like six months.

15

but then the company decided to kill it.

16

they said that it's taking too long.

17

It's not going to be

sellable as a project.

18

So we're going to kill it and you're

going to work on the old product.

19

But the old product, had not been,

you know, modernized, very well.

20

It had very old, technologies.

21

It still had fbe, uh, things like that.

22

And even back then, that was

already pretty, outdated.

23

And so it wasn't an

emotionally sort of fun.

24

Change, at that point as well.

25

but at the same, you know, time, you

know, you have to make the best of

26

it, eh, because well, you know, you

have to row, with what you were given.

27

and so we had a, a team

lead and we had a manager.

28

the manager used to work, in the

team and sort of got promoted

29

from senior developer, to manager.

30

team lead had also worked

there for a long time.

31

we had a very outdated, project,

and we had no architects.

32

Just to make this clear, everyone

was a software developer and most

33

of what we knew was from developing

software and it was almost a monolith.

34

We had a few services, but.

35

Not that much.

36

but we were very much domain-driven,

design, sort of, enthusiastic about it.

37

so I thought I'm gonna organize

an event storming, session to

38

sort of see, where we're at.

39

to together with sort of mapping all the

technical debt that was actually there.

40

I did that from an emotional point of view

is so going to the team and asking, okay,

41

what is the most frustrating, what is the

most bothersome, that we have, right now?

42

Um, uh, what annoys you?

43

What makes it difficult to do your job?

44

Things like, well, I dunno, any VB

and I have to actually program in it.

45

So that's quite difficult.

46

the event serving was

an absolute disaster.

47

Um, it was my first, I think I also

mentioned that one in the book, um,

48

at some point, um, because I could

not get people away from how it was,

49

so I wanted to see how we could do it

better, but I couldn't get people to

50

step away from how it worked right now.

51

Okay.

52

so that did not go well.

53

Um, and the, the wall of, of, you

know, emotional, technical death in

54

a sense, if I could call it that.

55

Um, we also wanted to tackle that,

but there it was one person who

56

also had a very sort of dominant,

character and or team lead.

57

It was the exact opposite.

58

Um, and our manager also.

59

Was a bit more dominant.

60

Also, did not really have the necessary

skillset are required in management

61

because you see that often when software

developers get promoted to management

62

positions, because they're very

good at their job, which is software

63

development, but it takes a whole

different kind of skillset, which they

64

don't have, and which people also don't

think you need to learn e because.

65

Well, you're supposed to be able

to do all of that communicating

66

and all that kind of stuff.

67

You're just supposed

to be able to do that.

68

So the meetings were always very tense.

69

already when we were

trying to, to modernize.

70

and this one person who was very

dominant, sort of, got their way.

71

So we were going to, implement

an event sourcing source system.

72

Um, but the thing was that, um, it

was implemented completely, next to

73

everything that was already there.

74

and so that that emotional wall

that, we have created was not being

75

tackled at all, because of that.

76

And no matter what I tried or, or

how we tried to, to change that,

77

basically we would only get relief

like two, three years later when we

78

could kill certain parts of the old

system and start using the new system.

79

Uh, and we also had a QA team.

80

and you know, the software was kept

on sites due to, very sensitive,

81

information, inside that domain.

82

And so, the it who had to deploy, just

got messages and it was so difficult

83

all the time, and they didn't know how

to actually do that because you had

84

queues now and, and you had all that

stuff, which you didn't have before.

85

and, you know, QA also didn't know how

to test it decently and how to do that.

86

and eventually what you

saw is that, you know.

87

People got fed up and started leaving,

the company, because, you know,

88

management was not that great either,

but even within the team, there

89

was just, there was no end to it.

90

This is not going to end.

91

We, we will never see anything better.

92

The job won't be easier.

93

and a lot of people, you know, left

because it just wasn't fun anymore to

94

be a software developer on that team.

95

I left too, after a gigantic burnout.

96

and I tried and I felt like I

failed, that I could not work in that

97

situation and that I swapped jobs.

98

but you know, now, all those years

later, being less emotional, it was

99

just, it was pretty toxic to work in.

100

And the architectural

decision that we made.

101

was just really bad and it, we

didn't think about it at all.

102

It just, the person who was the

loudest in the meeting got their way.

103

and there was no plan.

104

There was no sitting down

and thinking this through.

105

It, it was just a, this is the latest

and greatest and we're going to do that

106

and, you know, screw everybody else.

107

screw all the other teams

thinking about what actually

108

will this, this be like for it?

109

And qa, nobody gave us any thoughts.

110

Me neither because I was, you know,

very new at the job and I didn't really

111

know how to think about architectural

architecture and design and how to

112

make decisions like that because,

you know, there was nobody there

113

that knew how to do that either.

114

so that is pretty much, my story.

115

I don't think the company

still exists at this point.

116

Um, I, I know at, at some point.

117

there was like one person still

maintaining the product because it

118

was still used, by certain customers.

119

but the company, you know, because

it didn't really get any better, the

120

company invested in, another similar

product, that they acquired, basically.

121

Kenny Schwegler: Yeah, so

do you wanna go, Andrea?

122

Andrea Magnorsky: yeah, just sounds

very like, you know, you're left

123

and burnout and, it feels like a

very, kind of sad ending thing to,

124

to a story and what it worse still.

125

It wasn't just you, it was like

all these other people as well.

126

So I guess you're sharing this because

you're trying to say, Hey, you, this

127

doesn't need to be the way, what

are, if you could come back to, you

128

know, if you could time travel and

deliver like, t-shirt side slogan to

129

pass him, what would the T-shirt say?

130

Gien Verschatse (she/her): Leave now.

131

But depending on how much I go

back in time, obviously, because

132

now a, you all those years is 15

years later or something like that.

133

I don't know why I stayed.

134

Like you try to make

the best of something.

135

but I didn't have the

skills to go against.

136

people who had a very dominant

sort of, quality, to them.

137

And I dunno why I tried so hard

to make this work at the moment.

138

They killed the Phoenix Project, which

is why I took the job in the first place.

139

I'm not, I'm not, I

wouldn't say don't try.

140

it's just that quit sooner.

141

It's okay to quit.

142

bad environments, bad situations, and try

to find a job, where you think, you know,

143

it's more about collaboration instead of

the loudest voice in the room, where you

144

have a manager, you know, that actually,

listens to the teams and things like that.

145

It's not, not a bad thing to do.

146

I felt like a failure then.

147

Right now.

148

I should have left soon.

149

Kenny Schwegler: Is that

a, is that a rat flag?

150

In a way, a very dominant

authoritarian, nowadays they call

151

it, CV driven, development, right?

152

I, It made this whole survey why

people choose technology and it,

153

it's like, yeah, to pimp my, resume.

154

Resume is the English word.

155

I think.

156

but, but it would that now be a

red flag for you if you're in the

157

same situation where you're like,

well, I, there's nothing to do here.

158

And, and my manager once said,

you pull a dead horse to water,

159

it still stays at that horse.

160

So, yeah.

161

Gien Verschatse (she/her):

actually a good one.

162

it's not, the dominant

character is not a red flag.

163

Per se, 'cause you know, I have, I, I

have friends, that are quite dominant.

164

I have, people I've worked with in

the past who also are, quite dominant.

165

Eh, they take up a lot of space, in

collaborations and conversations.

166

and it doesn't necessarily

have to be a bad thing.

167

it's that if everyone, if, if, if

the environment and the the culture.

168

Allows that to become something

toxic, then you have a problem.

169

and also because this person did have

quite good technical skills and you

170

know, it was based on how good or you

technically, whether or not you had

171

something to add, I would say that

would be the red flag, not the dominant.

172

Uh, things in the, uh, not things, but

not the dominant people in the room.

173

But how does the company, how does

the team, how do you deal with it?

174

'cause you can deal with it in

a healthy way and you can deal

175

with it in an unhealthy way.

176

And if you feel like this is unhealthy,

which I very much felt 'cause I

177

had a burnout in that situation,

then you should, you know, that's

178

a red flag and you should leave.

179

Evelyn van Kelle: So if that situation

would occur now, like with all the

180

experience and, and the years that

you, that you have now, like you

181

would enter that same situation,

but as the person you are now.

182

What would you do differently?

183

With like a leaf early.

184

Okay, sure.

185

But like with that, that specific, person.

186

Well, how would you, how would

you approach that in now?

187

Gien Verschatse (she/her): I think

first of all, I would, be like, okay,

188

this is one option that we have there.

189

There are other things that we can do.

190

Um, E and i, I would, put their,

proposal next to all the other

191

things that you can do architectural

wise to improve the legacy system.

192

I would also dig a hell of a lot deeper

in the consequences because it's only

193

when you started doing that that you

realized, oh, actually, you know.

194

What is really bothering people?

195

What makes the job unpleasant, like is

not being tackled at all, because of this.

196

and I would, you know, notice that

sooner with the experience that I had.

197

And it would also bring that up as

something not positive, negative about

198

going for that implementation and saying,

okay, if we still want to use all these

199

technologies, what is a different way

that we can actually approach that?

200

which actually also relieves some of these

frustrations that the developers have.

201

Or we don't put all our eggs in the

same basket and we tackle some of

202

these, you know, unpleasantness.

203

Right along next to it, you don't

have to dedicate a hundred percent, to

204

just, you know, event source system.

205

Andrea Magnorsky: there's something

else, I found with people.

206

I work with a few people that

remind me of this person.

207

Gien Verschatse (she/her): Mm-hmm.

208

Kenny Schwegler: I think we all do.

209

I think we all do.

210

Andrea Magnorsky: we'll, I think

we all have, and, and sometimes

211

this, this, this behavior comes

from a lot of insecurity and, and

212

sometimes cannot talking, about it.

213

In a more, not like

saying, Hey, like a clip.

214

It sounds like you're insecure.

215

Uh, that doesn't work.

216

But, but if you cannot try to

address the, what, like start

217

prodding at the underlying course.

218

Course.

219

Like, sometimes I felt

like I have good, outcomes.

220

I'm not saying that that's the, the

only way, but if you're, if you're

221

in a position where like, okay, I

wanna try something sometimes kind of.

222

put a coaching hat on and dealing

with the, the, I hear you.

223

You're worried about us not being able

to, complete this, or I hear that you are

224

trying to pay your mortgage, e either of

those in a, especially the mortgage one.

225

Slightly more subtle ways.

226

Can help, but, it depends a, on the

person, especially when there's no strong

227

management, I, I feel, I feel that,

yeah, it's a tough situation to be in.

228

Gien Verschatse (she/her): Yeah.

229

And I mean now when I go to companies, I'm

a, I'm a consultant most of the time, so

230

I enter in a different sort of position.

231

And that also made me realize that, well,

you know, it was between colleagues.

232

We were all colleagues.

233

And so as I said, no one knew how

to make architectural decisions.

234

We did not have that knowledge.

235

No one really had that, role, but

also nobody was facilitating this.

236

I was facilitating some of it, but

still I had a lot of skin in the game.

237

So I had opinions.

238

And we go back to a facilitators do

need to stay neutral, once in a while.

239

Well, not once in a while,

but most of the time.

240

and as a consultant, I sometimes

have to sort of, still give advice.

241

So I can't stay a hundred percent

neutral, there, but I don't eliminate,

242

any of the other people's ideas

or, or how it is there either.

243

So I feel like having someone like that

would've been very beneficial, because I

244

was just a colleague with other colleagues

who are trying to make the best, of a

245

not so pleasant legacy system basically.

246

Kenny Schwegler: I had that experience

before where I was, facilitating.

247

So Scru master role and an engineer

quite work well because, you

248

know, I had my opinion and you're

getting into old situations now.

249

Writing the book with you.

250

I learned many things,

but I have two questions.

251

Did this story your healthy obsession?

252

Decision making.

253

So that's, that's question number one.

254

And question number two is, I, I, I

learned and started using a lot of the

255

ProCon fixed list that you talk about,

and also the theory about decision

256

making where you talk about, well,

a decision has information as input.

257

It has, options as input,

but also preference.

258

And what I hear from your story, and that

would be my question, is that this person.

259

I assume it's, he had, had preferences.

260

So how nowadays would

you make that visible?

261

Right.

262

Usually, you already mentioned if you

just do, and I've done this before, do

263

the pro con fix list with the group.

264

That already helps tremendously, right?

265

Because then you go factual into the

options and that will already set the

266

stage, but sometimes there's still

this preference underneath that people

267

can, that can dominate the group.

268

So how would you, how would you,

so that's just question number two.

269

So question number one,

this is trigger your healthy

270

obsession with decision making.

271

And question number two, how do

you deal with the preferences

272

nowadays to make that visible?

273

Gien Verschatse (she/her):

I wish I could say yes.

274

but there wasn't one thing

that triggered my, my healthy

275

obsession with decision making.

276

It was, it was the worst.

277

Like that was the worst.

278

I, I, I did ever have.

279

Uh, it was burnout and, and, and leaving.

280

But I kept hitting very similar things.

281

Yeah.

282

Like, Andrea immediately said like,

oh, this does not sound unfamiliar.

283

I think Evelyn also said that

this does not sound unfamiliar.

284

And the, there has to be a better way

to do all of that is because, at regular

285

intervals you go into meetings and you

hit these dominant people in the room.

286

And who yells the loudest, eh, sort of.

287

Gets their way.

288

And, you know, that's, that's,

a repetitiveness of, of that

289

is what, gave me a healthy

obsession, with it, basically.

290

So that's, answering question

number one, and I already forgot

291

question number two, Kenny.

292

Kenny Schwegler: Is, is so,

293

Gien Verschatse (she/her): Yep.

294

Kenny Schwegler: yeah, I hear this person

had a preference for event sourcing.

295

I also have preferences.

296

Right.

297

And, especially with someone

who's being dominated.

298

How would you make that explicit

that, that preference of a decision.

299

Gien Verschatse (she/her): Yes.

300

So I, I would dig more into why

this strong reaction towards this.

301

back in the day, it was, it

was quite a while, while it

302

was beginning of my career.

303

So event sourcing was quite new.

304

back then, and, and like right now I

can understand that e we got kicked

305

off a Phoenix project, which was

using quite the latest, trends and

306

technologies into something e so, you

know, which didn't have that much new.

307

And if, you know, your

skills are very easily, um.

308

Perhaps lead in, in, uh, this

market as a software developer.

309

And so I think it also came somewhere

from that, from, from being scared that

310

if I ever try to find a new job and I have

to work years in this very old system,

311

I won't be able to find, the new job.

312

so I would a dig more into

a wider strong reaction.

313

A go a bit too.

314

Trying to find the value based heuristic

in behind this very strong preference.

315

Eh?

316

like, I find it more important that my

skills stay up to date than actually

317

tack tackling the emotional, hardships

that the team has is sort of a

318

value-based, thing that's behind it.

319

And so I would look more at that

as well to make it explicit.

320

Because very often people don't always,

I mean, not many people sit down

321

and think, okay, what are my morals?

322

What are my ethics?

323

Which values do I have in life?

324

Which heuristics do actually,

you know, drive that.

325

I think all four of us in this room, um,

have done that and we do understand more.

326

Where these emotional and these

preferences actually start coming from.

327

Or if we don't understand, we have the

tendency to figure that out for ourselves.

328

But most people don't have that.

329

And most people, don't really

analyze their emotions.

330

they definitely don't understand

the values or, or ethics or

331

morals that are pushing them.

332

Um, and so I think that.

333

Looking a, formulating those value-based

heuristics and making them understand

334

that, okay, like this is how you see the

world and this is where it is coming from.

335

And then you are able to say, but do

you understand that this person has

336

a completely different heuristics

because different values are pushing it?

337

it makes it easier to have conversations

and you're not talking that big about

338

emotions, which also doesn't scare people.

339

'cause you're talking about

value-based heuristics and preferences,

340

which is basically we're talking

about your emotions, but in a

341

way that people don't quite get.

342

You're talking about their emotions.

343

Um, so yeah, I think that's, uh, yeah.

344

So after 20 years in the software

industry, which is male dominated, I

345

have found a way to talk about emotions

that isn't really talking about emotions.

346

Kenny Schwegler: Cool.

347

Yeah.

348

Andrea Magnorsky: now to finish,

349

Evelyn van Kelle: I think

that's a great ending on.

350

Kenny Schwegler: No, but I think it, it

shows the importance of, uh, hopefully

351

we can change that, that, uh, we do.

352

So thanks.

353

This, uh, this was another story.

354

Thanks for sharing your story, Heen.

355

to the rest of you please, and here's

my, like, subscribe to, to our podcast,

356

YouTube, or any way give us feedback.

357

we also have a descrip, descrip,

sorry, a Discord channel where you

358

can join us, where you can start

talking about, these stories, but

359

also more on domain driven design

or, software design and architecture.

360

so I hope to see you there.

361

give us some feedback thanks again

for, listening, watching, reading

362

in, and, until next time, bye-bye.

363

Andrea Magnorsky: Hi.

364

Thank you.