Most decisions in software teams don't fail because people disagreed. They fail because people thought they agreed — and nobody found out for weeks. You leave the meeting feeling good about where things landed, and three weeks later you're having the same conversation, wondering how you got back to the start.

Michael Joyce, a technical principal at Thoughtworks, joined Andrea and Andrew with a story from an unusual vantage point: he worked as a solution architect inside a New Zealand agriculture company, left for the UK, and then went back to the same company four years later. Long enough that his designs were still running, and nobody knew he'd made them. He got both barrels — "I don't know why it does this," which he could answer by pulling up a design document nobody had ever seen, and, from the ops team, the first long-term praise of his career: when things fell over, the services just restarted and recovered. The systems survived. The reasoning behind them didn't.

The turning point in the conversation is a whiteboard. Michael was locked in a circular argument with a vendor architect, both of them making points to win rather than to resolve. He stopped, walked to the board, and wrote down what the other person had just said. The vendor architect looked at it and said: "That's wrong." Not embarrassed — genuinely surprised that what he'd said out loud meant something different once it was visible. They stopped arguing at each other and started looking at the same thing. Michael's clients have hit the same effect at scale: three months of talking about a decision, then one day in a workshop run by someone with no knowledge of the subject, and it was done. "That's what alignment is. It's not about having a conversation. It's about externalising it."

The subtler trap he names is the one that shows up when things feel like they're going well: valuing harmony over precision. Agreement is a nice feeling, so you stop writing, stop clarifying — and what got documented was one person's version of the agreement. This conversation explores externalisation as a facilitation move rather than a paperwork exercise, why precision is usually plain language rather than intricacy, why saying what something doesn't do matters as much as what it does, and why an IKEA wardrobe explains most broken professional relationships.

Key Discussion Points

• [01:00] Becoming an Architect by Accident: From giving opinions in London to holding the title in New Zealand, and finding the word itself a little strange
• [02:00] Something at Stake: Defending designs against vendors when your colleagues, not your next client, have to live with the result
• [04:00] Going Back to Face Your Own Designs: Four years later, the systems are still running and nobody knows they're yours — "I've never seen that design before, so we just went and implemented it"
• [05:00] Design the Project, Not Just the System: Why the biggest lever an architect has is team interaction, learning, and how the work starts
• [09:00] A True Partnership: The product manager who presented P&L to the board, visited customers, and took support calls — and the product folks who didn't want developers near customers
• [13:00] Intent and Radical Empathy: The one thing Michael kept from Crucial Conversations, and the difference between "I don't understand the decision" and "I don't agree with it"
• [17:00] "That's Wrong": The whiteboard moment that ended a circular argument with a vendor architect — and changed the relationship
• [18:00] Three Months vs. One Day: Why alignment isn't conversation, it's externalisation
• [20:00] Valuing Harmony Over Precision: How the nice feeling of agreement stops you documenting, and leaves you in disagreement without knowing it
• [22:00] Positive and Negative Boundaries: Saying what a service will do — and what it will not — because the grey areas are where understandings quietly diverge
• [25:00] The IKEA Wardrobe: They supply the materials and the handbook. They don't come to your house and build it

Guest: Michael Joyce

Hosts: Andrea Magnorsky, Andrew Harmel-Law

Hello, and welcome to Stories of Facilitating

2

Software Design and Architecture.

3

I'm with my, usual co-conspirator,

Andrew, we're missing Kenny

4

because he's on holidays.

5

our guest today is Mike.

6

do you wanna say hello?

7

Michael Joyce: Hi, how's it going?

8

Would you like me to tell

you a bit about myself?

9

Yeah, okay.

10

So I'm currently a technical

principal at Thoughtworks.

11

I've worked at Thoughtworks for about five

years, across two different continents.

12

And before that, I've worked

in a variety of organizations

13

in a number of different roles.

14

Enterprise architect, solution architect,

developer, those type of roles, yeah.

15

Andrea Magnorsky: Cool.

16

And so what is your story about today?

17

Michael Joyce: So I'm currently

working for a technology organization,

18

and I was looking b-back on my

career and I thought there was one

19

role I had which was-- stood out.

20

It was one where I was working for a

company that offered other types of

21

services and had an in-house technology

team, including an architecture team.

22

And I was reflecting on all

of the different types of

23

experience I got from that.

24

Actually being part of, of an

organization that's doing something

25

other than technology and the challenges

that you face and how different they

26

are, and sometimes how you get an

opportunity to do things differently.

27

As well, try different things

because the people around you

28

aren't part of our world as much.

29

Andrea Magnorsky: Yeah, they're

thi- they think differently.

30

Right.

31

Okay.

32

We are keen to hear your story

33

Michael Joyce: Thank you.

34

I'll start right off the bat by

finding it a little bit strange

35

to call myself an architect.

36

And the way I got into it was, I was

working in London, and I started having

37

architects come up to me and ask for

my opinion on things, and I started to

38

enjoy the conversation more and more, and

I thought, "This is a really easy job.

39

I just get to give my opinion about

things, and, and, they go away and

40

they thank me, and everything's great."

41

And then I left the UK and I came

back to New Zealand, and I became an

42

architect by title, and this is the

company that I was wanting to talk about.

43

And I've worked for that company

twice, which also has informed

44

some of my thinking around this.

45

When I first started working there, I had

an entirely different domain to learn.

46

It was a primary industry, an

agri-- agriculture-based industry.

47

And growing up in New Zealand, I should

have known a bit about it, but I didn't.

48

So I was one of two solution architects

in quite a large company, and I

49

suddenly got thrown in the deep end.

50

I had to actually start making decisions

about design and advocating for

51

designs that I was putting forward.

52

And there were some interesting

experiences there that I had with

53

vendors trying to challenge my designs.

54

And they were challenging them

because what I was putting forward

55

was a little bit more modern

than they were wanting to build.

56

They had their own capabilities,

and I was really challenging them.

57

I was making it a little bit

difficult for them to deliver for us.

58

I thought I was defending

the company at the time.

59

When I look back on it, I was, you

know, I have questioned whether

60

I was doing the right thing.

61

and some of that questioning came

about from just being challenged.

62

It was actually quite confronting

to, to have that for the first time

63

with that type of responsibility.

64

And I think it meant something different

because I was working for that company

65

because there was something at stake.

66

I wasn't just another vendor

going and selling something, doing

67

some work, and then moving on.

68

My colleagues around me were gonna be

relying on the solutions that we designed.

69

I left that company and then

moved to the UK, met Andrew.

70

I worked with Andrew for

a little bit in the UK.

71

And then when I moved back to

New Zealand, I actually went back

72

to work for the same company.

73

And that kinda closed the loop for me

as an architect because I'm not sure I

74

would recommend doing it to everyone.

75

But joining a company you've worked at

before as an architect, I think it was

76

approximately, oh, four years later.

77

Four years is long enough that the things

that you designed are probably still

78

there a-and the people there don't know

you and don't know you designed them

79

and have quite free opinions about them.

80

And it was great because

I got both sides of it.

81

I got the, "I don't know why it

does this," and I could quite

82

happily answer that and go, "It was

written down in the design here.

83

Here it is."

84

And they were like, "Oh, I've

never seen that design before.

85

That does make some sense.

86

I, I under-- Okay, I understand why you

designed it like that, but we didn't see

87

that, so we just went and implemented it."

88

And I also got the ops people going,

"Oh, it is a little bit of a challenge,

89

this architecture, but you know what?

90

It does recover.

91

When things fall over, we just have

to t-restart the services, the queues,

92

and it just-- it actually self-heals."

93

And it was, oh, wow, that's

actually the first bit of long-term

94

praise from an architecture I'd

ever received as an architect.

95

It achieved something that

it was designed to achieve.

96

And so if you th-- if you're brave

enough to go back to a company

97

and see how you did, do it.

98

I'm not sure I'll ever do it again.

99

so that was that company.

100

That taught me a lot about, being in

a company that you were designing for.

101

the second part of going to a company

like that is you get to try new things.

102

You get to do things differently

if you're not part of a technology

103

organization, because in some ways

you are the expert in your company.

104

You're not surrounded by opinions

that can potentially overwhelm you.

105

People are more willing to listen to you

so we tried different things and, and I

106

discovered my love for externalization

of decisions and developed that.

107

And the love for, as an architect,

realizing that it's the biggest

108

thing I could do to help a

project succeed was to design the

109

project and not just the system.

110

And by that, it was actually design

everything from, where-- how the team

111

were gonna interact, whether or not

people were gonna be sitting together,

112

what learning and development the entire

team needed, what sessions we were

113

gonna have to kickstart the project.

114

And so that was, that was a

bit of a revelation as well.

115

So I got to talk to people about photons

and digital cameras and satellites

116

and photosynthesis and all these types

of things just by being an architect.

117

So yeah, go and work for a company

that is not a technology company.

118

Be an architect or a

developer for that matter.

119

Andrew Harmel-Law: That's

super interesting, Mike.

120

Like I, I can…

121

Obviously, you mentioned

we used to work together.

122

What I think as a consultant,

one of the cool things is you get

123

to move around and see different

domains and different clients and

124

do different stuff, and the curse of

it is exactly what you said, right?

125

Like, has happened once, I'm very aware

as a consultant, right, I can wave

126

my hands around and tell people to do

stuff, and then I can disappear and,

127

and like you never see the long-term

impacts of, of like positive or

128

negative of what you've done, right?

129

Or a mix probably, right?

130

And I think it's very enlightening.

131

And then way I approach things

fundamentally changed again when I was--

132

I worked one place for four years, so

we were, we were shaking our fist and

133

cursing various things, and we were

like, "Who, what idiot designed this?"

134

And it turned out it was me or us

three years before when microservices

135

first came on the scene, and we were

like, "This is amazing," and then we

136

were running them four years later.

137

but I think it is, it's

really interesting, right?

138

And it's interesting that you

say that that then made you think

139

more about building the team and

how the team works and like not

140

just like a bunch of human beings

collaborating, but more explicitly…

141

'Cause there is, there's a, like,

like when you realize that there's,

142

there's a longer term impact and like

getting this knowledge into people's

143

heads, not just in your head and then

writing it down, as you said, right?

144

There's a power to that if they,

not just for the design of it, but

145

also the running and operation and

maintenance and other things of it.

146

Michael Joyce: Yeah, definitely.

147

I-- On that piece of work that I was

talking about designing with photons

148

and digital cameras, I got to see a

really, really junior developer go from

149

being very shy and not really speaking

up in stand-ups to doing a company-wide

150

presentation on how she'd use a

JavaScript-based GI-GIS tool, GIS library

151

to take images and to cut them up and

do analysis on them for photosynthesis

152

and just the confidence that you could

see this person gain and to be able to

153

trace that back to the purposefulness

with which we saw that person and

154

their place in the piece of work.

155

That was, that type of

thing was really rewarding.

156

Andrea Magnorsky: That

sounds, like quite a journey.

157

And, uh, I kind of want on this,

158

type of designing these

interactions and learnings and the

159

kickstarts, how did you do that?

160

Did you also do that, collaboratively?

161

Or

162

Michael Joyce: is

163

Andrea Magnorsky: what was the…

164

rewarding.

165

we should do more than

design the system because

166

Michael Joyce: Mm-hmm.

167

Andrea Magnorsky: social"?

168

Michael Joyce: Good question.

169

Yeah, it was, it was working with

a really amazing product manager.

170

I'd say one of the product managers

that represents it at its purest in

171

that this person was, presenting to

the executive team, to the board on

172

not just the roadmap, but also profit

and loss about a long-term strategic

173

vision from, for the, for the product.

174

They were also the person who would go

out and talk to customers in the field and

175

who would also have the team that handled

support calls and they would be on the

176

phones themselves listening to customers.

177

And so this person came with all

the passion for the product and

178

I realized that I had a really

great partner to work with.

179

they didn't know my world and

I was learning about theirs.

180

And so we agreed that we would

actually design this together.

181

And they said, "I'll give

you whatever you need.

182

I'll come and sit with the

team whenever you want.

183

We'll get R&D to come and sit

with the team if, if that's

184

what you're recommending."

185

And it was just someone from

the beginning that it w-- it

186

felt like a true partnership.

187

And we were focusing on the outcome.

188

We were focusing on working

software in the hands of, of

189

customers from the very beginning.

190

That was the thing that made it.

191

Andrew Harmel-Law: interesting actually

'cause, um, yeah, I was looking for

192

the heart emoji, but this, but this

recording tool doesn't have heart emoji.

193

But I think you're right, Mike, right?

194

Like, there is…

195

The two things that have fundamentally

kind of changed how I design systems

196

is running the systems that I designed

and like the second thing you've…

197

And we didn't prepare this.

198

The second thing is product management

and like understanding product managers

199

and kind of, and, and that kind of thing.

200

That's again, it's like building the

right thing, not building what you think

201

is important, but building what actually

someone has guessed is gonna have a value,

202

and then building it in a way that can…

203

It, it does both things very much

transform how you see your designs and

204

your software for the longer term, right?

205

Is that kind of…

206

Do you maybe wanna dig a bit

more into like how that's changed

207

how you think about stuff?

208

'Cause I think for me

anyway, that was a big, big

209

Michael Joyce: Yeah.

210

Yeah.

211

The, it does come into the way I see

architecture in general is that I think

212

we are the most privileged people ever.

213

We get to delve into

every domain in the world.

214

We get to learn about every

part of what humans do.

215

this domain that I was in, I, I know more

about that domain now than most people

216

on the planet, and I never would have

done so if I hadn't been an architect.

217

Going and watching the product manager

have to do an update to the executive to

218

go to a board showcase where we got to

show off the software, and then to also

219

be able to go on visits to see customers,

take developers to see customers and

220

just listen to the ideas, that was vital.

221

It was an interesting one at that company

because there were also product folks

222

that didn't want us near the customers.

223

That they were a little bit worried

about whether or not we could represent

224

the company well, I think, or that we

would cloud our things and actually

225

affect their roadmap, and that we

would, you know, flip the table on it.

226

it is those human interactions,

to answer your question, that have

227

been the biggest thing that have

changed how I deliver software.

228

Yeah.

229

Without that, it wouldn't work.

230

Andrea Magnorsky: it's funny, Also,

really nice to have a guest in New

231

Zealand because there's no latency.

232

So I actually finished hearing your

qu- hearing you, and I'm not talking on

233

top of you, which doesn't happen often.

234

But, so my, my question

here was, like, about…

235

I, I think we all, like, I, I…

236

We've all talked separately about

this quite a bit, but we never did

237

it, or not so much here in, in this

forum, which is the building and

238

the importance of trust, as, as a,

like, 'ca- 'cause with the, the…

239

What you're talking about

with the product people going

240

like, "Oh, I don't know if…"

241

and can you tell us about your

framing for trust when you go into

242

that project or, like, what is your

approach to, thinking about trust?

243

Not really kind of doing something

about it, 'cause I think it's

244

a framing first, isn't it?

245

It's like a what are your beliefs

246

Michael Joyce: I went on a course

once in London called Crucial

247

Conversations, and I remember one

thing reasonably well from the course.

248

Uh, sor- apologies to the

people who ran the course.

249

But the thing I, the, the, the only

real thing I remember is intent.

250

Is if you are having a conversation or

you're wanting to form a relationship,

251

explaining what your intent is,

is the single most powerful thing.

252

And for me, that goes along with empathy

The intent and empathy being broadcasting

253

your intent and being empathetic.

254

And so when I was having a difficult time

in that organization with some of the

255

product managers, it was really, trying

to understand where they came from.

256

And so I see a trap that some of our

colleagues fall into, developers to a

257

degree, but also even BAs, where they will

say something along the lines of, "I can't

258

understand why they made that decision."

259

And I usually try and unpack it

with them and say, "What-- is it

260

that you don't understand a rational

way they made that decision or you

261

don't agree with the decision?"

262

'Cause those are two different

paths you can, you can go down.

263

And so trust for me comes about being

able to be radically empathetic and

264

not liking what you're hearing, but

truly wanting to understand why someone

265

is making a decision they're making.

266

And if you do that and the person can

un- can see that you understand them,

267

even then when you disagree with them, at

least they trust that they're understood.

268

And if you make your intent very

clear, that lays over the top

269

that you're-- they understand why

you're trying to challenge them.

270

And so that type of

communication is trust for me.

271

Andrea Magnorsky: it's funny how

that comes so often, isn't it?

272

Like, this thing of like, why

would they do, you know, the

273

why, why would they do this?

274

And it's like I told them

about, you know, it…

275

And you have this conversation

from product devs, yourself,

276

and you think it yourself.

277

You're like, "Why would

someone do this thing?

278

We discussed this.

279

We specially talked about this,

and yet they did the thing we

280

agreed that you weren't gonna do.

281

What's this?"

282

And it's like, well, okay.

283

And the unpacking, I think the

unpacking thing, and I, I'm, I'm,

284

maybe I'm, I'm too much of a fan, but

I think, writing down certain decisions

285

is, is like where it really helps.

286

And well, we talked about it here,

so, I can see how we lost something.

287

but at least you, I think the going

to check maybe gives you like a, some

288

room to, Hey, we actually did hear you.

289

We just couldn't do it, because reason.

290

or we decided anyway for it because

of this, you know, accepted because

291

X, Y, Z, despite your reason.

292

And it's like, well, we had to

make a trade-off, and that was it.

293

Sorry.

294

and then it could be like, oh, actually,

this is bigger than you thought.

295

Oh, okay.

296

So how do you-- do you write it down?

297

Do

298

Michael Joyce: Yeah, you-- yeah.

299

Andrea Magnorsky: 'Cause conversations

are, time-consuming and synchronous.

300

Michael Joyce: conversations

also don't end.

301

I-- one of the things that I

noticed in that organization and

302

several others since is I think I

mentioned externalization before.

303

And so that was another thing I

learned by having to really care

304

over a long time about something was

what works and what doesn't work.

305

Why does this thing

keep coming back around?

306

Why are we discussing the

same thing again and again?

307

And I had this moment with an architect

from the vendor where we were struggling.

308

We were, we were trying to come to

a conclusion and make a decision,

309

and we were almost trying to one-up

each other, and we were doing the

310

thing where you're making a point

just to try and win the argument.

311

And I said, "Hang on a minute," and I…

312

"Let's, let's use the whiteboard."

313

And I started-- I wrote up what this

person said, and they were adamant until

314

they saw me write it up on the whiteboard.

315

And then they didn't focus on me anymore.

316

They looked at the whiteboard,

and they said, "That's wrong."

317

And they weren't, embarrassed.

318

They were just surprised by what

they'd said out loud, meaning

319

something very different to it

written down in front of them.

320

And it changed the nature

of the conversation.

321

It changed the relationship.

322

And so that for me is the most

powerful thing and something that

323

I've seen done to great effect.

324

We've had a lot of success with our

clients who've said things like, We've

325

spent three months talking about this,"

and a day in a workshop with one of our

326

colleagues running a workshop for them

with no knowledge about the subject.

327

They said, "We got more done in that

day than we got done in three months

328

trying to make a decision on this."

329

That's what alignment is.

330

It's not about having a conversation.

331

It's about externalizing

it from everyone else.

332

From everyone.

333

Andrea Magnorsky: does that mean

just, is, is it just putting it on

334

the board, or do you have any more

tricks up your sleeve that you can…

335

Like, is this your, your

default pattern, or do you have

336

a few depending on situation?

337

Or maybe, you know, how do you…

338

Basically, what's your mindset

339

Michael Joyce: Bye.

340

Andrea Magnorsky: what are your tools, I

think is my, my general line of questions

341

when someone says, "Oh, I have this.

342

This is the, the concept that

I, I ground everything in."

343

And, Kenny likes to call this

a container, which is totally

344

not an overloaded word at all.

345

but it's a Dutch thing, so it's

like the idea is like, oh, this word

346

that helps you unpack things, and so

you have a mindset and a philosophy

347

perhaps, and then you have maybe tools.

348

can you walk us through

this, tree of container

349

Michael Joyce: Absolutely.

350

So when I think about externalization,

I was obviously thinking about

351

that specific example and a, a

very much an interpersonal working

352

relationship and trying to overcome

a, a challenge between myself and a

353

person from another organization who's

incentivized slightly differently.

354

We both had the same goals, but they had

the, need to prove to be valuable to the

355

organization because we paid them and

there's a contractual relationship there.

356

I was in a different situation because

I was an employee and therefore

357

not as at risk in, in some ways.

358

My views were a little more protected.

359

And so that was one version

of it, and that was very

360

much one-on-one and personal.

361

But when I think about externalization,

I've also been thinking about why do

362

decisions stick and why don't they?

363

Why do you sometimes come around

to the same decision and the two

364

people who were, or three or four

or a team who are involved in the

365

decision have very different views

on what the decision actually was?

366

And I've seen a, a trap that I've fallen

into and others fall into, and that's

367

even if you are starting to document

things, valuing harmony over precision.

368

And so I've seen people stop too

quickly when they're documenting

369

a decision, a design or something

else because people are starting to

370

agree and it's a nice feeling, and

we wanna wrap things up with harmony.

371

And so where that's come back and bitten

me is if I haven't been quite sure that

372

what we've documented is precise and

accurate enough, I'm almost always right

373

because it was the other person's view

of it that was documented, not my own.

374

And now it doesn't mean I was right

about the outcome, but it means that

375

we were, we're in disagreement at the

end and we didn't know it until later.

376

Andrea Magnorsky: Right.

377

Okay, so you're saying something

like, if you're not very precise,

378

you're, you know, because consensus

is a lot more comfortable,

379

Michael Joyce: Hmm.

380

Andrea Magnorsky: go with the

consensus, but actually you decide,

381

but actually you figure out later

that you didn't really agree.

382

Michael Joyce: Absolutely.

383

Yeah.

384

Yeah, absolutely.

385

And, sometimes precision

feels like intricacy.

386

I think sometimes it's much better

described as plain language.

387

State what you mean Be very precise with

what you mean and what you don't mean.

388

And so, you know, tools and

techniques, saying what something

389

is as important, but also saying

what it is not is just as important.

390

So drawing both positive and

negative boundaries around

391

things is just as important.

392

saying what something does do, what

a service will do, saying what it

393

will not do, what it is responsible

for, what it's not responsible for.

394

And so the, the gap, the gray areas

between those things are often

395

where people's understanding of

things fits, and where you can think

396

you're agreeing, but you're not.

397

Andrea Magnorsky: Yeah, it's funny

that you mentioned that 'cause I just

398

started doing this, "Doesn't do X," but

for like d- l- like plans for the week.

399

Michael Joyce: Ah,

400

Andrea Magnorsky: this, and it could,

let's say, something like start

401

guideline, like do some work on

guidelines for, I don't know, say,

402

observability or something like that.

403

So there's some sort of

like long-running task.

404

but it doesn't mean I will fix this 35.

405

So yes, starting to write guidelines.

406

This means inter-interview people, about

what they're currently doing, or perhaps

407

do some analysis on some repositories

about what's going on there, o-other

408

tasks related to creating a guideline.

409

It doesn't mean, going and fixing

these three issues that people raised.

410

It means it would be included in

the guideline, and that it should

411

addre- it should be addressed by the

guideline, but it won't be resolved.

412

And it, it's just saying that, that

I, I was like, "Oh, it's obvious

413

To me, it is like, well, if you're

writing about this, that doesn't

414

mean you can solve it instantly.

415

That won't happen this week.

416

In fact, it, it needs-- You need, if you

need to solve it this week, you need to

417

do something to address the, the, this

right now, if it's like a real problem

418

Knowing that this a lot, better solution

is coming in the future that is more

419

considered, that will take this as input.

420

And it was funny how the whole thing

changed from, yeah, yeah," and then

421

kind of, yeah, feeling that people got,

get let down to being very explicit and

422

set, like setting these expectations.

423

So, yeah, I think you're,

you're totally right.

424

I, I think

425

Michael Joyce: yeah.

426

Andrea Magnorsky: is such

a dangerous, comfort, o- on

427

agreement 'cause, you can just…

428

It makes you go round and

round nice roundabout.

429

Michael Joyce: Yeah, and it doesn't matter

as much when you've got decisions that you

430

can undo in a, in, in an hour as a team.

431

a team thrives on a f-- a silent

form of consensus where people

432

who don't really mind just go

along with it because they're--

433

they don't have a strong opinion.

434

But where things do matter and consensus

just makes you go round and round

435

and round it, it's The challenge.

436

I thought of an a-analogy for that scope

question when it comes to what we're

437

talking about being very precise, and

so I've just made up an IKEA wardrobe.

438

And I was just thinking from IKEA's

point of view, or IKEA I think

439

it's pronounced, if I was trying

to be a little more accurate.

440

the-- they supply the materials,

they supply a handbook to

441

how to put it together.

442

They don't come into

your house and make it.

443

And I think that I was hearing your

dis-- your, example about what y- the

444

work you've been doing, and I thought

the difference between promising to

445

come up with a roadmap and a plan, you

know, or maybe a strategy and saying

446

that you're going to help them implement

it is the difference between saying,

447

"Here's the book that I wrote for you.

448

Here's the plan that I wrote for

you," and the actual day-long

449

construction of wardrobe.

450

Yeah.

451

And, and being responsible for if

you damage any of it along the way.

452

So being very precise.

453

Andrea Magnorsky: you,

454

Michael Joyce: Yeah.

455

Andrea Magnorsky: your or your fingers

or whatever while you're really, you

456

know, your DIY skills are put to test.

457

Michael Joyce: Yeah.

458

I, I have decent DIY skills, and I

still damaged the wardrobe a little bit.

459

Only my daughter and I, know

where we did, and yeah, we glued

460

it back together and we're good.

461

Andrea Magnorsky: I, I think

we all have stories like that

462

about IKEA furniture, I think.

463

they're fun.

464

As, as like also it gives

you with a story, right?

465

You've, you built it and then you're like,

"Oh, and then there is this little thing.

466

Look, it's over here."

467

And you can tell your friends

about it, and they're like, "Wow,

468

that was a really boring story."

469

But you know, that's, that's

why they're f- they're friends.

470

You can tell them your boring

stories and your really good stories.

471

Michael Joyce: Absolutely.

472

Family just don't listen

to either of them.

473

Andrea Magnorsky: they, it's probably.

474

Yeah,

475

Michael Joyce: They've heard

them a dozen times before.

476

Andrea Magnorsky: anyway, this

has been absolutely great.

477

I, I really enjoyed this,

and I hope you did, too.

478

Michael Joyce: I did.

479

Thank you very much.

480

Andrea Magnorsky: Oh, most welcome.

481

And on that cheerful note,

we're gonna, close this episode

482

of, Stories of Facilitating

Software Design and Architecture.

483

Thank you, Mike, for joining us

today, And, yeah, see you next time.

484

Thank you so much.

485

Michael Joyce: Thank you too.

486

Bye.