We tend to trust diagrams. Four boxes, four arrows, four services — that feels like shared understanding. But when Vanessa Formicola started asking basic questions about a team's architecture, the boxes came apart in her hands.

What the team called four services turned out to be four deployments of one codebase — the same code with different entry points, barely modularised, with the services quietly intercommunicating underneath the API calls that made them look separate. And this was a medical product. The team owned everything from the app entry point down to the core business algorithms, critical IP scattered across a system nobody could change safely.

Vanessa describes herself as an engineering leader and a sociotechnical architect, which she explains like this: if you bring her a technical problem, she'll start poking around in your people issues, and vice versa. That instinct is the whole story here. The team wasn't incompetent — they were clever people in a high-growth environment that never gave them space to stop and ask what they actually owned. So rather than opening with a redesign proposal, Vanessa ran a series of workshops as the person in the room who didn't know anything. They mapped business capabilities, technical capabilities, and what she calls "real estate" — the stuff you own that has nothing to do with your domain. In parallel, she took ADRs into the company's weekly architecture forum. Only then did they draw a North Star. A year and a half of decoupling followed. Issue time halved. Sprint predictability improved by about 40%.

But the outcome Vanessa values most isn't in those numbers, and neither is her most portable idea: the Social Decision Record. Same format as an ADR, but for organisational decisions — whose test strategy do we adopt, how do we share PR reviews, who lands which developer. In this team, there were more SDRs than ADRs. This conversation explores what that ratio tells us about architecture work, why "just tell me what to do" is a signal about the environment rather than the person, and how career frameworks and quarterly review cycles end up designing your architecture without anyone noticing.

Key Discussion Points

• [00:01] Poking Around in Your People Issues: Vanessa on why no problem gets solved by looking only at technical architecture or only at organisational dynamics
• [02:00] Four Deployments, One Codebase: The discovery underneath the diagram — same code, different entry points, API calls that misled everyone
• [04:00] Capabilities, and the Real Estate You Didn't Ask For: Domain analysis that separates what you own, what you should own, and what you're just carrying
• [06:00] Bringing ADRs to the Forum: Shifting how decisions were communicated to the teams that depended on this one
• [07:00] If We Were Designing This Now: The North Star conversation, and separating the stable medical domain from feature-driven, BFF-style services
• [12:00] "Just Tell Me What to Do": Why this is disillusionment or fear rather than laziness — an organisational issue, not an architectural one
• [15:00] Twenty Lines, Not Twenty Pages: The RFC that would take three months, and why ADRs let people engage at the depth they want
• [22:00] Social Decision Records: Applying ADR rigour to organisational decisions — and why this team ended up with more SDRs than ADRs

Guest: Vanessa Formicola

Hosts: Andrea Magnorsky, Kenny Schwegler

Hello and welcome to another episode of Stories of Facilitating

2

Software Design and Architecture.

3

today we are here with my usual

co-conspirator, Kenny, we're joined

4

by the amazing Vanessa Formicola.

5

Vanessa

6

Vanessa Formicola: Thank you.

7

Welcome, everybody.

8

So I'm Vanessa Famicola.

9

I'm an engineering leader and

social technical architect.

10

That means that whatever role I actually

hold, I try and solve problems from

11

both a technical and people perspective.

12

That also means that unfortunately or

fortunately, if you have a technical

13

problem, I'll probably start poking

around in your people issues and

14

organizational issues and vice versa.

15

I found this unfortunately

to be necessary and true, in

16

most companies I've worked in.

17

I've worked in very different companies.

18

I've worked in big corporate

companies like Microsoft.

19

I've worked in consultancies where,

you know, you see very different

20

clients, and even in startups like,

Flow Health, where I worked, recently.

21

And what you find is that no problem

that you can solve, in my opinion,

22

in my experience, just focusing

only on your technical architecture

23

or only on your people issues.

24

usually you have to find, you know, a

balance to understand how to address it.

25

what I'll be talking about today, like a

story, of an experience that I had that

26

I thought was very shaping, is about how

a team who had, very difficult technical

27

legacy issues actually had a lot more

of, like, people issues and technical

28

issues to solve, and how I try and s-

help them, leading them to the solution

29

So, this team owned…

30

So this was a small team at the

beginning, and it became rather

31

large towards the end, so more

like, uh, size of three, let's say.

32

they owned the key domain of the product,

so you can imagine the stakes of that,

33

and also the entry point of the product.

34

though, although it was a great

team of individuals, as a team, they

35

weren't working as well, and the actual

situation of the software was dire.

36

and they were very slow.

37

So I was asked to try and improve,

the, the velocity of the team.

38

So what I- one of the first things I did,

you know, with meeting the people was

39

also start having a series of workshops

to try and just, you know, be the silly

40

person in the room that doesn't know, and

please help me understand what's going on.

41

And we started with a

number of workshops on this.

42

one of the first discoveries was

that given an original monolith that

43

they had of the product, they had

stripped out a piece, to which they

44

referred to as four different services.

45

So in the first instances of

the workshops, people talked

46

about four separate services.

47

I had to dig in for quite some time

to actually understand what they

48

referred to as four services were,

yes, four deployments, but it was

49

one code base of services that it was

exactly the same code with different

50

entry points, and they weren't even

modularized as much as you can expect.

51

Like, the code was actually

intercommunicating.

52

So we went from a diagram, as you

can imagine, and picture of, like,

53

four services to an interconnection

of internal and external.

54

So there were still API calls that,

you know, were there to mislead

55

you in thinking that they were

separate services, and internal

56

collaboration of these services.

57

What made it worse was the high

stakes of the kind of services.

58

So these services went from the entry

point, so the, the apps, to the actual

59

core domain, and they had everything

in between in terms of key business

60

domain, this was a medical domain,

and- App domain in multiple flavors.

61

So i- it was understandable that

actually all delivery took ages because

62

you actually had to go through all

of this to be able to go through it.

63

Now, what I understood there was that

y- there were some clear red flags of

64

things I would've changed, but I also

understood that if such clever people

65

up to that point had not redesigned

it in a certain way, had not picked

66

up on that immediately, we needed

to work on the actual foundation of

67

understanding of what were the issues.

68

So instead of trying to say, you know,

you probably want to consider a separation

69

of concerns, you want to think of

redesign, we wanna think of this, we

70

started discussing it from two aspects.

71

So there were some actions that I took

externally to the team, because clearly

72

there were many dependencies with other

teams outside, and actions internally.

73

So let's start with the internal ones.

74

Internally, I started discussing with

them and doing workshops, so this

75

is different formats over a period

of time, identifying, A, our domain.

76

So first of all, to try and, join

the team in the direction of what

77

we actually owned and what it meant.

78

So domain analysis, and that's

where I started to pick up

79

that mishmash of domain.

80

Business capabilities,

technical capabilities, and the

81

difference with real estate.

82

So what was the purpose of that?

83

Was to help them understand- The fact

what we actually owned independently

84

on how it was implemented, and to be

able to have the conversation of how

85

we would like this to be, you know,

how would this make things better?

86

So through the business capabilities,

we discussed things like, okay, so

87

these are the key responsibilities,

but some of these sound very different.

88

You know, some of these are understanding

of key business domain, and some of

89

these are understanding of how the app

works, and those are different things.

90

in technical domain, we understood how we

actually owned very key algorithms of, you

91

know, IP of the company, which was spread

around multiple services and people needed

92

access to them, but we had them scattered

around, you know, and difficult to access.

93

And also, unfortunately, and this is

something that happens in teams too,

94

and it's distracting when you're trying

to do this, we own services that have

95

nothing to do with this domain, but we're

actually, you know, part of the system

96

and I call that generally real estate.

97

So you need to know what you're

responsible for, what you should be

98

responsible for, what, you know, what's

your actual job, you know, what are the

99

capabilities you're providing, and what

are some key things that you own that

100

maybe your product manager can't discuss

as well, but you need to protect and,

101

and make sure that you can discuss.

102

this conversation helped us have the right

conversations of what direction to take.

103

At the same time, I went to public

forum, so we had a weekly public forum

104

of, architecture for the entire company,

and I discussed the architecture

105

advisory forum and started to try

and change that in that direction.

106

of the key changes was to actually

discuss architecture through ADRs,

107

which they did completely differently.

108

And this for me was a big entry point

to be able to, A, present some of

109

the changes that we will do next,

but also to be able to have better

110

collaboration with the other teams.

111

So you can imagine that such domains

are at the middle of many interdependent

112

teams, and therefore we needed a

better way to communicate what changes

113

we wanted to do, and also try and

spread some of the good practices

114

that we introduced afterwards.

115

So at this point where I actually

tried to change the system, and I

116

mean externally and internally, build

awareness, lead them to the solution,

117

we started discussing how would we

like this architecture to be, right?

118

So if we were doing it now in a

sensible way, not, you know, all

119

new technologies, if we were doing

it now, how, how would we have

120

what would our North Star architecture be?

121

And that naturally brought out

the conversations of all that I'd

122

built up over a period of time.

123

So some key things were we wanted to

separate the business domain, which

124

changed very rarely and required a

different level of attention from the

125

app domain as a very, very high level.

126

Clearly there were multiple domains

inside, but as a very big, big

127

architectural separation, we needed

to understand that how you represent

128

things for tools is very different

than algorithmic business domain.

129

Again, it was medical, so things that

didn't change that often, but they

130

were very critical and had to be super

secure and super sensitive So having

131

this was one of our, our first ADRs

that we also presented to the company,

132

that people started picking up, was

first of all understand whether you

133

are building for a feature or you are

changing the key business that you have.

134

And the second aspect was to, in this

new North Star architecture, was to

135

actually separate services and say, "Okay,

some of these services are core domain.

136

Some of these services are potentially

back-end for front-end models of services

137

that are there to help you shape different

features, different functionality,

138

different channels of communication."

139

This is a very high level.

140

Clearly, we could have done multiple

iterations of this to go even

141

better, but we're talking in a

situation where we have none of that.

142

So we always, always have to look at, you

know, where we are and where we can go.

143

So this was fundamental because it

helped all our collaboration with other

144

teams, so we were able to discuss in

terms that other people understood,

145

you know, what we were talking

about, why we wanted to shape things.

146

And also, it was, a good preamble

for the work that we did afterwards.

147

So we started a program of

refactoring over a period of time,

148

you know, this lasted for a long

time, decouple these services.

149

First it was from four to two,

and then we had two domains and

150

try and split it to redesign.

151

So slowly breaking internal dependencies

and strengthening external ones and so

152

on until we got to a place that was much

better than before, but not perfect.

153

So through this, I found

multiple value for the team.

154

first of all, there was

a clear, delivery value.

155

So the issue time halved pretty

much over a period of time when we

156

started doing, those refactorings.

157

Clearly, this was over a period

of, like, a year and a half, right?

158

Slowly through our delivery.

159

also, predictability of the, of the,

of the sprint improved, like roughly

160

40%, A, we have a better understanding

even when we were talking features,

161

but also we started decoupling, right?

162

Which also sometimes you really

have to do the technical work to

163

allow people to do the things.

164

But what I found most valuable,

not that this isn't, is was able to

165

actually shift the, the feelings of

the team towards ownership of a domain.

166

We own this medical domain.

167

We own this functionality, and

therefore you approach it differently.

168

So the technical decisions of the new

features we did afterwards already fit

169

into a model of, in any case, a dynamic

North Star that we changed over a period

170

of time, but it gave people direction.

171

So even our architecture

discussions afterwards were a bit

172

more linear because it was more,

"Okay, are we changing direction?

173

No.

174

Then therefore it should be around here."

175

And another big value that I found

was easy onboarding of new people.

176

It was easy to say, "We own this.

177

This is what we do.

178

This is the problems we have.

179

This is the plan we have."

180

And whenever there was a shift of

functionality, let's say we had less work

181

or we needed to change focus, I always

had a full backlog of work that people

182

can fall back to of refactoring work.

183

So we had a direction of stuff to work on.

184

And all of this to me was, a

winning combination to, A, grow the

185

individuals, improve the velocity of

the team, improve the architecture.

186

Of course, I would have wanted to do,

you know, a lot more, maybe redesign more

187

things, but we were able to be infectious.

188

So other teams when they

collaborated with us, when we did

189

workshops together, we were able

to say, "Look, we tend to do this.

190

You know, this is our area.

191

How can we design it this way?"

192

A- and it helped.

193

It helped kick off that stream.

194

So I find that, you know, just

discussing separation of concerns

195

at the beginning would have not led

to the same result, and if I hadn't

196

tried to actually make them feel like

the team that owned that, then what

197

And help them understand what they

own, they're not just services, of

198

these architectural changes would have

actually worked the same way, I think

199

Kenny Schwegler: Yeah.

200

Very recognizable also from,

the last couple of months.

201

I, I keep getting sometimes the

feedback of engineers, they don't care.

202

I, I just want you to

tell me what I need to do.

203

Is that some behavior

you saw here as well?

204

And did that shift

after your, your change?

205

I'm very curious because that's most

of the-- one of the biggest arguments.

206

Yeah, yeah, but engineers just want to

code, and they just want to do what…

207

You just need to tell them what to do.

208

That, th-this whole struggle

209

Vanessa Formicola: I've had that

experience, not in this team.

210

This was an extremely opinionated

team, very product-driven, the

211

most product-driven and less

best practices-driven team I

212

had, which is an interesting mix.

213

It's something I had not faced before.

214

Um, what I find though, that what

you mentioned, I've seen often.

215

So people want to be told

what to do, and that happened

216

often when I was a consultant.

217

Unfortunately, I think that happens when

people feel under threat, and I don't mean

218

you specifically, but sometimes when you

have contractors or, or consultants coming

219

in, they feel that if they don't align…

220

So either they fight it too much, maybe

more than what they would sensibly

221

do, or they feel they have to align

to survive, so at some point they're

222

like, "Just tell me what to do."

223

And that is definitely an

organizational issue, and it's

224

definitely not an architectural issue.

225

And I, do believe that we- when we

look at that, we need to understand a

226

bit more they think the consequences

are to challenge something, and

227

whether it is laziness, which is

rare in my opinion, and it's more

228

disillusionment, like this is gonna…

229

You know, this person is gonna go away in

a month, like, why would should I bother?

230

Or fear, toxic environment.

231

You know, those are the things I

would look for in, in those cases

232

Andrea Magnorsky: Yeah, 'cause

it's a form of disengagement.

233

It's like, you know what?

234

I'm, I'm…

235

You know, you obviously

have strong opinions.

236

I told you what I think.

237

You're not listening.

238

Just tell me what to do.

239

basically, but they don't

tell you the first bit.

240

They're like, "Just tell me what to do

because I want a good performance review,

241

because I went the extra mile last time

and you didn't reward me, maybe for

242

multiple, reviews, and I'm just tired.

243

I'm just tired of you not seeing me."

244

that could be…

245

That, that's like something

I definitely have seen,

246

maybe too much.

247

you know, you said something about the

feelings that, that you were able to kinda

248

give this team the feeling of ownership,

and you mentioned quite a few things

249

that might have contributed to that.

250

And I was wondering, what do you

think were maybe the top three

251

things that help you help them,

them this feeling of ownership?

252

'Cause I, I get the feeling maybe

a little bit of the ADR process and

253

kind of having visibility on decisions

generally tends to help quite a

254

bit, but I'd love to hear your take.

255

Vanessa Formicola: So I think

the first one was awareness.

256

especially when you're in a high,

high-growth environment, you have less

257

time to sit back a second and say,

"Okay, what do I actually own today?"

258

unfortunately.

259

And I think if people are not really

aware of the diversity of what they

260

own, some people have never had

conversations about business capabilities,

261

technical capabilities, it's very hard

for them to even do the next step.

262

It's like, this service works, it

has this quality level, whatever

263

number tooling they're using, and

maybe that's the world they've known.

264

So first of all, is awareness.

265

Understand what you have, what boundaries

you have, what it means to have that.

266

Because then naturally you start seeing

the dissonance of where the problems are.

267

So awareness, the first thing.

268

The second thing was to

make things more concise.

269

So ADRs were actually a key win.

270

So nothing wrong with RFCs.

271

They have worked.

272

They do work sometimes, but I do find

that people would want to know what

273

decision you're proposing, and then they

want, you know, enough context, and then

274

they want an opportunity to go and deep

dive more if, if they want to, right?

275

So every person has a different

level of how much they want to know.

276

when you have to start with like

often, and I'm sure other people do

277

it differently, right, but 20 pages

with like three months of discussions.

278

So I've worked in places where they

said, "Okay, we pu- we published the RFC.

279

I think in three months we'll,

the conversation will be done."

280

And they, they weren't joking.

281

Um, and you, the ADR, whether, you know,

peop- some people might end up in that

282

situation, is not designed to be that

way, and people who use ADRs tend to

283

try and avoid that kind of scenario.

284

b- saying, "Okay, what we decided to

do is in, I don't know, 20 lines, and

285

then if you wanna know more, there's

this, and if you wanna know, let's

286

talk about it," and then, helped.

287

So clarity.

288

And then I think the third part to me was

to actually have a concrete action plan.

289

So we had milestones that we'd

change over a period of time, but

290

it was like, okay, so if we…

291

What do we start first?

292

And deciding together, okay, sh- we

start from this area, these two services.

293

Okay, what benefit would it bring?

294

Okay, how do we break it down?

295

over a period of time people

saw that we had a plan, and

296

the plan changed massively.

297

to go from, should refactor this, or

when you have some time refactor this,

298

to actually backlog ready to a point,

mission to do that, made a difference.

299

So these to me were the three key points.

300

Awareness, good approach to communication

with other people, and third was a actual

301

concrete plan with the same responsibility

that we had for delivery on it.

302

And that is why I talk about how we

need to fix problems holistically,

303

so technically and socially.

304

of

305

Kenny Schwegler: Yeah

306

Vanessa Formicola: worked if I only

discussed, "Look, this architecture

307

is not separating concerns."

308

I think if I only tried to change

the method or only tried to make the

309

pe- the team feel like the team, it

would've been a lot of good feelings

310

for a couple of weeks, but it wouldn't

have led the result at the end.

311

By the end, I felt that they would…

312

They felt the ownership of the

team as much as I did, if not more.

313

It lived independently from me.

314

And that was a mixture is because

I was working on multiple fronts

315

Kenny Schwegler: Yeah, and that's for

me is, if you look at RFCs or ADRs, I

316

don't really matter which one you use,

but in both ways, it's you need to talk

317

technical because a business process

change, as you say, right, which is

318

more of a how do they do the work, will

impact your technical choices, but your

319

impact, your technical choices will also

impact that, and it will impact behavior.

320

So I feel like, unfortunately,

architecture got a bit tainted, but,

321

business people also impact architecture,

and engineers impact architecture, and

322

that needs to be facilitated and changed.

323

Did, did you run to any,

anything against that?

324

Vanessa Formicola: So

325

Kenny Schwegler: in, no, this

is a technical thing, let

326

the engineers just solve it.

327

Because I feel like you, you, you

mentioned they don't use the best

328

practices, which was a weird thing,

and yet they were product-minded.

329

They had four services, but for some

reason, if you, if you follow Conway's

330

Law, right, you ha-- they have the four

services, they were product-minded,

331

then you would expect the code would

also be more dis-- well, decoupled.

332

So I, I'm very curious at that point.

333

Vanessa Formicola: Multiple answers there.

334

So let's try and see, and

remind me if I unpack fast.

335

So this

336

Kenny Schwegler: Yeah.

337

Vanessa Formicola: I think was peculiar

because they were product-minded, but

338

not in the best practices way that you

just assumed, rightly like I would.

339

As in you're thinking DDD and

modeling, what I am thinking is were…

340

And, you know, in some ways

it was very healthy though.

341

So they were thinking about new

features, they were thinking about,

342

you know, how to deliver more, and it

wasn't from a technical perspective.

343

They were more than comfortable to cut

technical corners, while often I had,

344

uh, conversations with developers who

absolutely didn't want to, not cut

345

corners, but, um, you know, were very

rigid towards different approaches

346

that weren't necessarily, you know,

the cutting edge technology and so on.

347

They were completely willing to cut

any best practice which I wouldn't

348

be comfortable with in favor of

delivery, which is a sub- it's, a

349

configuration that I've not seen before.

350

But- If we talk about actually modeling

your system according to the product,

351

that wasn't even- that was completely,

an, an alien idea, and that's why

352

it was new and discussed there.

353

So this is the context of the team.

354

Brilliant people, just had different

kind of experiences, and in the

355

context of startup, so it, it…

356

there's a, it's a different

environment I want us to understand.

357

Brilliant people, though.

358

then when we talk about business

and influence, so I have spoken a

359

lot actually about how other factors

your architecture quite directly.

360

Andrea before mentioned

the career framework.

361

Career framework is one of the biggest

culprit of things in architecture

362

that you don't expect to see.

363

People behave according to the,

the, the, performance review cycle,

364

and they will introduce things

and do things according to that.

365

And in one of my talks specifically, I

call it Seven Sins of Architecture, I

366

go through all of these patterns that

I've seen of why people do things for

367

reasons that have absolutely nothing

to do with what you would talk about

368

with your colleagues about tech.

369

So, career, career, cycles have massive

impact on how sometimes we design things,

370

and this is true at multiple level, not

only individual, but organizational level.

371

So when you have quarterly reviews and

you have quarterly deliveries, everything

372

has to fit into the quarter, and you

start designing features independently

373

from from stages, and assuming that

all teams have the same delivery cycle.

374

And although I understand the

value of some of these things,

375

architecture has a different nature.

376

So then your architecture needs- starts

to be quarterly, you know, designed.

377

So there's those things.

378

There's other things.

379

So my team in particular, this one, had

so many shocks of people moving in and

380

out, and it grew, so I merged in two

different teams and then split out, and,

381

uh, it was quite a dynamic environment.

382

Uh, moving around team people has a

massive effect on the redesign of certain

383

things, so when you try and do that,

you know, that has a negative impact.

384

but what I find also is you wanna

make sure that people have the

385

right balance in the problem.

386

So, you know, enough product driven,

enough, you know, best practices,

387

that they believe best practices

is the way to be quicker, but they

388

also want to deliver above, you

know, just showcasing their skills.

389

I think is where you balance it.

390

But one other interesting point,

and I hope I covered all the points,

391

is, on the length of, you know, RCs

and ADRs and how, you know, business

392

requirements go in, and, like, how

other organizational things go in.

393

In that specific, job, I

invented something else which

394

I call social decision records.

395

They have the same format of ADRs,

but I put organizational decisions.

396

So it could be your team decision.

397

It was used then at, you

know, leadership level too.

398

But let's say I had a collaboration with

another team, and we needed to land a

399

developer, or we agreed on using our test

strategy compared to their test strategy.

400

You can imagine we worked a

lot on test strategy to support

401

all of this refactoring.

402

those did not clutter, you know, our ADRs.

403

Our ADRs were for what I would ca- I mean,

architecture can be blurred, but there

404

are some things that at least I would

put more in architecture than others.

405

So decisions were important for

the delivery and significant, but

406

weren't architecturally, I would put

in exactly the same format of ADRs,

407

in SDRs, and discuss those and go

through the same process about that.

408

And that allowed me often

to have a companion.

409

So if there was a bigger project and we

collaborated between the team, two teams,

410

and we had, you know, ADRs together,

we probably had an SDR on how we would

411

make this work over a period of time.

412

So whether we, you know, shared PRs,

whether we shared developers, whatever

413

was there, there was an agreement.

414

And often that gets bled into your

project and ends up in your ADR.

415

But I want your ADR to say,

"This is what we're doing."

416

you know, it's one thing to

put it in context, it's another

417

thing to put all your, you know,

organizational decisions there.

418

Andrea Magnorsky: Uh, I, I

hadn't, I hadn't seen the

419

social decision record before.

420

That's an interesting idea.

421

I kinda think that, it might be, kind of

good to, to know a little bit about, maybe

422

as a closing thought, how, how they went.

423

Like, do you have, like, as many

social decision records as ADRs?

424

It's like, you know, like, or just

a f- a handful, but kind of the

425

general experience of, of using them.

426

And with that, maybe we can finish off.

427

Our episodes are generally about

20 minutes, and we're a little bit

428

over that, which is absolutely fine.

429

But, you know, it's like, yeah.

430

So how, how … What was the balance?

431

What was the experience, since it's

a new concept, at least for me?

432

Vanessa Formicola: we, we

had more SDRs than ADRs.

433

had more SDRs than ADRs because there

were more organizational decisions

434

to be made for the delivery than

the key architectural decisions.

435

I think the scale of the problems in

this specific context was such that

436

those architectural decisions were,

you know, things that would impact

437

in a very long period of time, but

they didn't need many different ADRs.

438

It was, you know, separate those

things, use these patterns.

439

They were meant to be

guidelines for the future.

440

They weren't meant, you know,

just … And then we had for specific

441

project, maybe an ADR and so on.

442

But the most significant one that

had impact over a long period of

443

time were there as guidelines.

444

They kind of became

principles of architecture.

445

While the SDRs were more specific to

the problem at hand in that specific

446

thing of collaboration between teams,

and you probably had a couple per,

447

say, quarter collaboration, let's say.

448

It was more like that.

449

So I would say there would be more.

450

And it's mostly because people

issues very often require more

451

attention than your actual ones.

452

And I say this as a very pure

techie, but you end up, you know,

453

solving the collaboration and making

it clear to everybody, and use

454

the same openness processes that

we try and use in architecture.

455

Bring it back to, you know,

your leadership options.

456

It's very useful.

457

I think we can all learn from

trying different roles, and

458

I've learnt things, you know, when I

was devving or doing architecture work.

459

I've learnt things when I've done pure

leadership roles, and how there were

460

challenges there, and I've tried to

cross-pollinate, you know, things that

461

work in one environment in the other.

462

And that's why I, I always

suggest to people to try different

463

roles and to approach things

from different perspectives.

464

'Cause it's very hard to understand

other people's perspective if you haven't

465

walked in their shoes for a little bit

466

Andrea Magnorsky: Yeah.

467

Yeah, absolutely.

468

What a lovely closing thought, Vanessa.

469

Thank you so much for your time

and for sharing your story.

470

Vanessa Formicola: Thanks to you.

471

It was lovely.

472

Thank you.

473

Kenny Schwegler: Thank you.

474

Bye-bye.

475

Andrea Magnorsky: you.

476

Bye-bye.