In this episode Andrew Harmel-Law, Kenny (Baas) Schwegler, and Andrea Magnorsky discussed the difficulties of facilitating software architecture decisions, particularly when teams are hesitant to take responsibility. Kenny shared his experience at a growing company that needed to choose a new front-end framework (Vue or React) to scale from 8 to 115 developers. His goal was to empower the team to make a democratic decision, but they were mostly junior to mid-level developers who were uncomfortable with the accountability of a major choice.

Key Strategies for Facilitation

The discussion highlighted several methods for navigating this kind of indecision:

• Ask for consent: When the team felt too uncomfortable to decide, Kenny asked for their consent to make the decision himself. This approach still involved them in the process, and he ultimately chose React.
• Support the decision: After making the decision, Kenny asked the team what they needed to get on board with it. The developers requested training, which was then arranged. This practice, also known as "disagree and commit," ensures that even if people don't agree with a decision, they are given the necessary resources to follow through with it.
• Create a safe environment: People are often afraid to make decisions because of the potential for future negative consequences. Andrew pointed out that an architect can act as a "proxy" for the team, taking on the accountability to protect them.
• Understand Governance and Accountability: Andrea emphasized the importance of clarifying who is responsible for a decision. A good governance framework provides checks and balances to prevent bad decisions

Andrew Harmel-Law: Welcome back

to another episode of virtual DDD,

2

where we talk about, the facilitating

software architecture and design.

3

And I'm here today with Kenny and

Andrea and Kenny's gonna share

4

a story with us this time of

facilitating software architecture.

5

So Kenny is one of the co-authors of the

book called Collaborative Software Design.

6

Along with Gien and Evelyn.

7

And Kenny's had a lot of experience as

I consulted with all of these things.

8

So Kenny was gonna share one of his

experiences with us, and we were

9

gonna see what we could learn from it.

10

So over to you, Kenny.

11

Kenny (Baas) Schwegler: Yes.

12

Thank you.

13

So one thing.

14

What I like about all this is that we

really want to take very deep democratic

15

decentralized decision that's in your

book and mine book, and Andrea talks a lot

16

about that, but the road towards that is

not as easy as possible because there's a

17

lot of, authority in most of the companies

that people are starting is right.

18

My story was, a few years back, I was

in a company and, they were growing.

19

They had an investment and I was there

as an architect and I tried to facilitate

20

the architecture with the team, but the

team was also, a meteor junior skilled.

21

on one hand, you want to,

and this is always the case,

22

what I usually, see, right?

23

Architects are usually being promoted

because they're the person that knows.

24

The most.

25

So they got promoted and I don't

feel like that's a good thing,

26

but anyway, that's happening.

27

So what if you're in that position that

I was in, and then all of a sudden the

28

board comes to you and say, well, we need

to grow from eight to 115 a few years.

29

Right.

30

That was the challenge.

31

So then they were writing

only on vanilla JavaScript.

32

So, the appointment was okay.

33

we need to find a, front end.

34

Framework or language that can

grow with the company, right?

35

Vanilla GS is not that case.

36

So we looked in the market and the

market says it was either view or react.

37

So.

38

Decide Kenny, and I'm like, no, I'm,

I'm not gonna decide it because I'm not

39

developing actively in JavaScript here.

40

I went to the group, but the group was

a group of four or five developers.

41

You discuss this with them and say,

well, you know, this is the case.

42

We need to grow.

43

Uh, and, and this is an,

already a sort of autocratic.

44

In a way, right where

you, where you go in.

45

So not all decisions have to be full

advice or have to be full democratic.

46

I try to be democratic as possible,

but then you're getting into

47

this uncomfortableness like,

okay, we need to decide this.

48

in that case, there's

a lot happening, right?

49

Some people don't have any experience in

react review, someone has experience in

50

view, the rest has experience in react.

51

so how do you deal with this fact?

52

What I did was.

53

Give that conversation to the

group and try to talk with them

54

like, okay, what do we want?

55

Where do we want to go?

56

So I set up an A DR write down,

okay, it's either view or react.

57

What are the pros and cons?

58

But nobody had experience

about these pros and cons, and

59

we couldn't hire any consult.

60

There was one consultant,

and this was a react.

61

Expert.

62

it was a consultant and the person working

there was more of a view developer.

63

this is sort of like a confliction

thing because you don't want to

64

go with what the consultant says

because the consultants will move

65

and that there's all these sorts of,

66

things that you need to

take in consideration.

67

So, what I gave them as an

assignment is like, okay, here's

68

a new feature for the front end.

69

Consultant with a few of the

people, they both write one in view

70

and one in react, and just see,

okay, what are the differences?

71

But once there were, I remember

there were two that didn't really

72

care which way they were going, so

it got all into one medior's, hands

73

and that medior needed to decide.

74

And that felt very uncomfortable

for the medior, and.

75

it says, yeah, I felt very uncomfortable

making this decision now and write it

76

down in the a DR that I took the decision.

77

Because if it's gonna grow, and

people come in and I say it's

78

view and they're like, what a

stupid decision, that you made.

79

So eventually what I did, but I'm

very curious what you would do.

80

But what I did eventually is at that

point, They got into what we call

81

in the book shadows, like, yeah,

I feel uncomfortable, uncertain.

82

I'm a meteor, I'm not yet grown

enough to make this decision.

83

so I told them, okay, then

I'll take the decision.

84

So ask for consent.

85

Do you want me to take the decision?

86

Then I'm fine with taking the

decision based on what you are saying.

87

Eventually we choose for react.

88

Or I choose for react of course,

because I thought, okay, if it's I'm

89

taking this away from this person,

what I did then of course is what

90

do you need to go along with this?

91

Well, that person needed training.

92

So we arranged for all the developers to

get some react training, in this case,

93

but yeah, that uncomfortableness, If you

come in and there's all these different

94

politics at play and you want the team

to take, this is what a lot of technical

95

people want to get into technicality.

96

They say, well, you know, I want people

to take democratic decisions or decisions

97

with the group, but then they stay silent.

98

They feel uncomfortable.

99

So I'm very curious in my way, I try to

get into that uncomfortable, make it safe

100

for them to speak up and then ask for

consent so that I can take the decision.

101

But I'm very curious.

102

About your thoughts, right?

103

So I'm not against autocratic

decisions as long as you try to get

104

consent, connect with the group.

105

And I think that's, especially

for new architects, right?

106

That usually don't have

mandates in a company because

107

they're not building stuff.

108

How are you gonna navigate that web of.

109

And I think that's one of

the real challenges I still

110

face to this day, right?

111

That I faced recently again, right?

112

Thinking, well, a decision is

theoretically okay to go A, you know,

113

the people want to go b i'm curious

how, how you are dealing with that fact.

114

Andrea Magnorsky: I,

guess, from heuristics.

115

So if I was, there, there's obviously

a few options and I'm pretty sure

116

that we've gone through a few

of the options ourselves, right?

117

So if you're going through

this enabling, at least.

118

Make room to hear all the

options there, so that's one way.

119

It's like what you said you did right?

120

You're like, okay, I actually

want to hear your opinions.

121

so if you're doing that, one

of the hard balances is that

122

some people don't wanna talk.

123

Because they don't wanna talk not

because there's any inherent problem or

124

because they lack experience, because

honestly they don't want to get involved.

125

And it's been a hard lesson for

me to learn that then that's okay.

126

And I am curious to hear about that

aspect too, of like pushing people

127

to say what they think means that.

128

They are really trying to get away from

actually saying they're thinking about it.

129

They're like, you know what?

130

This, and I think this the, do you

want me to take the decision is

131

something that I wish I learned earlier.

132

So that's one option.

133

The other option, guess it's

also just gonna save one.

134

Push it back, go like, well, we

need to make this decision, but

135

you're saying that we shouldn't hire

contractors that's anti ethical.

136

Can we get some consultants to

help you, help the team learn both.

137

Like learn enough so they can

make a better informed decision.

138

Because in reality that you know, if

you're trying to build for the future,

139

then can we, can we invest on it?

140

Kenny (Baas) Schwegler: That's the whole

enablement team from team topology.

141

Andrea Magnorsky: Yeah.

142

Kenny (Baas) Schwegler: better decision.

143

Andrea Magnorsky: another,

area in which I push back.

144

And a third option that is

also possible is like, can we

145

build, can we actually pause,

temporarily and spend time learning?

146

So.

147

Kenny (Baas) Schwegler: Yeah.

148

Andrea Magnorsky: So we split

the, how many people there are.

149

Try to choose the people that

are, you know, if someone is

150

kind of for you and kind of for

react, put them in the other team.

151

Kenny (Baas) Schwegler: Yeah,

152

Andrea Magnorsky: so you

153

Kenny (Baas) Schwegler: right?

154

Andrea Magnorsky: Yeah.

155

So that you get, yeah,

like let them build.

156

But, you know, spend, it's

not like a little experiment.

157

It's like, no, actually, you know.

158

a maybe let's say a couple of

weeks that there is no, if there's

159

a team of four people, you're

like, listen, this is four people.

160

They actually need time.

161

don't just learn stuff.

162

We're not in the matrix.

163

Maybe this is a very old reference

for some people, but you know,

164

where you can just plug in.

165

Hopefully not.

166

so that will be my, the

three options that I,

167

Kenny (Baas) Schwegler: Yeah.

168

Andrea Magnorsky: when in

that situation, I've been in.

169

it's not, it's strict.

170

It's not, it's not easy.

171

Kenny (Baas) Schwegler:

I forgot the second one.

172

What you said was very important.

173

I stood into the, into the team

and I said, today, we're not gonna

174

leave until we made a decision.

175

I think that's a, that was a good one.

176

Andrew Harmel-Law: I think so.

177

The hard thing is building.

178

So things I realized while I was kind

of doing this and experimenting with

179

this more and more was that while

it gives everyone the opportunity

180

to decide, not everyone wants to

decide, just to Andrea's point, right?

181

Some people just don't want,

they're like, it's fine.

182

I'm not at that place in my career,

or I don't feel that this is

183

something that I have anything to

contribute to, and I'm happy to go

184

with whatever everyone else decides.

185

So forcing people to decide when

they don't want to, that's hard.

186

But then the kind of flip side is,

and, I wrote about this in my book

187

because it is one of the things

that frustrated me, which is why I

188

ended up writing the book, but like.

189

We're very good at coming up with all the

opinions, all the pros and cons we can

190

have, you know, we can have very strong

opinions and we can also, when properly

191

facilitated, we can remove the emotion

and we're pretty good at getting down.

192

Technologists pretty good, usually at

getting down to like the concrete facts.

193

But because of accountability, because

we know, the power that software can

194

have, we've seen, we live in code

bases where someone made an accidental

195

decision three years or seven

years before, and now it's causing

196

thousands of pounds of pain per day.

197

So people are terrified to actually

take the decision, say, I vote

198

for this, or vote for that.

199

And so like what you said, Kenny

is definitely a thing that I've

200

done where I'm, or even with

people's opinions, sometimes they

201

have an opinion, but they're not

confident being the name against it.

202

So I've offered to say, look, I will.

203

This is a relevant piece of information.

204

I can add it to the a DR or I can

add it as advice, as a comment or

205

something and I won't acknowledge you.

206

but then we've put this piece of

information into the mix 'cause I think

207

it's super important and like, I think I.

208

More generally, I've used ADRs to call,

like you can bring stuff to the surface.

209

'cause you can say, right, there's

just this thing that nobody's, nobody's

210

thinking about or talking about.

211

Let's write it down.

212

Let's bring all of this

stuff into the open.

213

And then I think the context

becomes most powerful, right?

214

It's like, why is this

decision happening now?

215

What is important about it?

216

And I think the last point, like

you said, the people and the skills

217

and the time you have available and

all of those things are important.

218

Important context.

219

And this is one of the examples in in the

book that we've got, and it's actually

220

was Pete, hunter, who's, who's open gi,

who hopefully we can get on and speak to.

221

one team wanted to pick an entirely new

framework because they were like, we

222

know it's suitable, but also we'd love

to just like, for our benefit, it would

223

be cool for us to learn a new technology.

224

It feels like a good fit.

225

We think we've done the

right, right homework.

226

And it will be suitable for this.

227

We know we don't have any skills, but we

also think that would be APL a plus point.

228

And I was like, that looks like a

disaster, but it turned out to be perfect.

229

Bringing all of these things

in and making people feel safe.

230

And like you said, Kenny, you can proxy

for those people to protect that safety

231

until they realize that, that there

isn't gonna be negative consequences

232

because there is always that shadow

stuff and the, the kind of surrounding

233

patriarchal kind of hierarchy.

234

You did what, it's your fault, therefore

this disaster is, is comes down on you.

235

People are still worried to do that, so.

236

Kenny (Baas) Schwegler: yeah, it's also a

bit, and the reverse is also true, right?

237

As an architect from a start,

and that's what you want to.

238

Of course enabled towards the teams is

that the teams get more understanding

239

of the system wide context.

240

That's also a discussion

that's usually there.

241

so teams might also make,

I think you went into that.

242

Teams might also make decisions.

243

We're gonna put it in our own surface.

244

So let's say we're gonna put it in our

own model it, even though it's really a

245

different system, but we're gonna model

it in our system because we have, we.

246

Our team has this ecosystem of libraries

in that system and making it separate

247

takes too much problem, much work.

248

And then, well, you as an architect

are like, but it's a different surface.

249

Right?

250

You should.

251

And I remember that that

conversation happened and, and,

252

and then advised against it.

253

And then there's this whole,

okay, what are we gonna do now?

254

Because we know for sure that

It makes your life easier.

255

As developers, we understand,

but it's the feature.

256

So what I usually see in media, bias

comes in and I say, well, What's the

257

problem with making this decision?

258

But they haven't lived the experience

of long, long term architecting systems,

259

Andrew Harmel-Law: Yeah.

260

Yeah.

261

Kenny (Baas) Schwegler: a whole,

there's a whole conflictuous

262

or tension there as well.

263

Andrew Harmel-Law: Yeah.

264

Kenny (Baas) Schwegler: Teach these

people to understand something

265

that they need to go through first.

266

But you, if you make that decision,

it's gonna be a ramification decision

267

because it's, can we only do this

for significant design decisions?

268

Right.

269

Andrew Harmel-Law: Yeah, I heard there's

a quote, someone I worked with, someone

270

who apparently walked up to Eric Evans.

271

So this might not be true.

272

Eric probably knows if it is really,

but they said, what is the thing that

273

makes people want to do DDD, and the

answer was, they need to felt the pain.

274

'cause otherwise it's just

a collection of patterns.

275

Right?

276

and that is systems architecture, right?

277

It's like, it's very easy to make.

278

Kind of the job is to see the whole

system, to see the longer term

279

horizon and all those kind of things.

280

Right?

281

Whereas the people who are

making the point decisions,

282

which is what you want, right?

283

Loads of small, incremental decisions

aren't supposed to have that.

284

They're supposed to be more local,

more immediate, more, you know,

285

smaller time horizon and stuff.

286

But you do need, like, you know,

like Ron would talk about like

287

the STS social technical systems.

288

Oh, Kenny's left room.

289

Like you want the whole

system used by Andrea.

290

So, but getting that is hard.

291

Andrea Magnorsky: I'm sure that

Kenny's, departure was accidental,

292

so he might join us again.

293

And I think I, I'll bring this again

when he joins again, but I think we're

294

implicitly talking a lot about governance,

and I think that deserves, attention.

295

Like all decisions kind

of have this governance.

296

And I think when people start

thinking of centralized architecture

297

or the advice process or anything

like that, people immediately listen

298

thinking, but who's responsible?

299

I think even making explicit who's

gonna have governance is probably

300

something that needs to be discussed.

301

compliance is something that is

kind of ortho to dash as well.

302

Andrew Harmel-Law: Yep.

303

Andrea Magnorsky: this is the

normal work that we live in.

304

Right?

305

I like it that we're talking

about it implicitly, but we

306

should mention it also explicitly.

307

Andrew Harmel-Law: It's

the thing I get asked.

308

Look, something I get asked all the

time when I go to clients is like,

309

Hey, what's the governance framework?

310

And I think governance come

brings with it a lot of stuff.

311

Maybe baggage from a technical

perspective, which is bad.

312

It's like how the old hierarchy

used to impose itself.

313

But I think like maybe in

today's political world, right?

314

Checks and balances and kind of

things feel like a good thing, right?

315

Maybe.

316

'cause otherwise one thing can go off

in a, in a really bad direction just

317

for the benefit of a few without,

you know, bringing in the thinking

318

about the benefits for everyone.

319

but what's interesting actually, as well,

I, I did a bit of research for this.

320

So like, things like the toga

framework and the Open Agile

321

architecture frameworks, they

acknowledge the fact that.

322

Agile development practices have changed

things, and they're like, we don't mind.

323

Pretty much it says in the open, agile,

architecture, sorry, open architecture.

324

Open agile architecture framework.

325

It's like decisions can be anywhere

as long as the accountability

326

for the decision sits next

door to the responsibility.

327

So the person deciding

is also accountable.

328

And if you as the facilitator like Kenny

is, or we, you know, you were around here.

329

Reminding people.

330

It's like, if you make this, you are

accountable and then that can lead to the

331

conversations that Kenny's had, right?

332

Some people are like, I don't feel ready

to be accountable and like, okay, I will

333

help proxy you and I will, make sure

that, it's a sound decision based on

334

what we know at the time, and based on

all of these, help balance the criteria.

335

One thing, like we said, as an architect,

one thing is you just get better

336

at doing this more and more because

your gut feel, not your intellect.

337

I think like your gut feel is to like,

this feels good or this feels bad.

338

We've had more, 'cause we've

just seen more of these things.

339

Andrea Magnorsky: I think this is where

I like the ality ideas from Barry Riley,

340

Kenny, while you were gone, we made

explicit the fact that we're speaking

341

of governance and also the relationship

between it and also compliance.

342

so the, just catching you up.

343

So you have any thoughts on that?

344

On like how.

345

Kenny (Baas) Schwegler: I think the

relevant point there, what Andrew said,

346

and I think that's it's a guilty pleasure.

347

I'm okay with people

taking decisions for me.

348

we usually for, we're like on the negative

side, like, okay, but they took a decision

349

and I don't like it, but sometimes, right.

350

I always say if someone takes

me on a holiday and they decide

351

everything and I'm okay with it.

352

a guilty pleasure.

353

I'm fine if people decide for

me and that should be spoken

354

about as well, that it's fine.

355

Like don't need to take the decision.

356

We can go anywhere as long as, and that

was in the previous episodes, as long as

357

we connect with people's what they want.

358

Right?

359

Well, I've heard this is your

thoughts, but we went this way.

360

Second thing is, as long as they can rent

and they can express their emotion freely.

361

It can also be the opposite.

362

You make a decision for them

and they're, they're not okay

363

with that, and that's fine.

364

but let them rent without

going in defensive mode.

365

And then at the end you

say, yeah, I know, right?

366

You try to really empathize with their

situation, and then you ask them, what do

367

you actually need to go along with this?

368

Because we're gonna do this, but

I want you in and I want to know

369

what will make your life easier

going along with this decision.

370

Andrew Harmel-Law: What do you

need to be along to go along?

371

Like people are like, people throw around

the phrase disagree and commit, but they

372

rarely go, what do you need to commit?

373

They're just like, no, I'm the most

senior person, and it is gonna be limiting

374

to your career to say, I don't agree.

375

Kenny (Baas) Schwegler: Yeah.

376

And that's, that's the uncomfortableness.

377

Oh yeah.

378

Like eight out of, I had

that one, seven out of nine.

379

we are gonna go for this,

and two are like, okay.

380

And then when you ask the question,

what do you need to go along, they

381

say, well, in this case it was a

decision about, trunk based or not.

382

And they're like, well, we

are front end developers and

383

Andrew Harmel-Law: Yeah, it's always front

384

Kenny (Baas) Schwegler: and,

okay, so that's what you need.

385

You need to first understand how

feature flagging works in the front end.

386

Yeah, yeah, yeah.

387

Okay.

388

Let's add that to the decision.

389

Right.

390

We're gonna do trunk based, but first

we're gonna investigate how this

391

works on the front end side and then.

392

Next week they were battling the PO

for going along with that decision.

393

Andrew Harmel-Law: And different, like

frequently, like you said, the different

394

context is the thing that makes PE

not always right, but frequently it's

395

just they're in a different place.

396

they're looking at things from a

different perspective or they're

397

different starting location.

398

It's a super, like if you're like, what do

you not, you know, why can't you commit?

399

You're like, oh, your

context is totally different

400

Kenny (Baas) Schwegler: and that's

401

Andrew Harmel-Law: from S.

402

Kenny (Baas) Schwegler: talks about

with our proco fix list, right?

403

If you have a con, how can we

actually fix that, that we're

404

not dealing with the problem?

405

Or neutralized problem.

406

Andrew Harmel-Law: Yep, yep.

407

So yeah, thanks for

everybody for, uh, joining.

408

Thanks, Andrea and Kenny for

chatting with me and sharing all

409

of that really interesting stuff.

410

And I'm looking forward to having

another chat about interesting

411

decisions and facilitating

software architecture and design.

412

Kenny (Baas) Schwegler: Thank you.

413

Andrea Magnorsky: See you next time.