There is a version of career progression that looks like success from the outside and feels like erosion from the inside: you get more senior, you sit in more meetings, you write less software, and eventually someone asks whether you'd like to become an architect. Most people in that position have already watched what happens to the ones who said yes.

Larisa Feldman joined Andrew, Andrea, and Kenny to tell a story that doesn't begin with a design problem — it begins with a decision she kept refusing to make. Over 18 years at National Australia Bank, she worked alongside integration, solution, domain, and enterprise architects, and she noticed a pattern: "they start very happy and they become quite sad." Their clear, well-reasoned visions kept getting stripped back by a mainframe that couldn't cope, an old system that wouldn't integrate, priorities that never arrived. As a senior and then principal engineer, Larisa was the one explaining how the systems actually worked before any design conversation could start — using a floppy disk as her analogy for why mobile isn't a website deployment. But she never wanted the title. As she put it, the sadness in the architects' eyes protected her.

What eventually changed her mind wasn't ambition. After leaving financial services for REA Group — no change panels, no product/tech split, everything straight to production — she was offered an architecture role on a modernisation programme. The pull was specific: "an opportunity to actually do something the way I wanted it to, rather than do it as another architect suggests." She became an architect almost by accident, but not without reason — and now measures the role by a single test: is the architecture making engineers' lives better, or harder?

This conversation explores what the architect role actually is and who it's actually for. We dig into Gregor Hohpe's "do we want architects or do we want architecture?", the case for advisor roles over architect titles, Kenny's analogy of decisions made by someone from a distant village with authority but no context, and why writing things down turns out to be an architectural act in its own right.

Key Discussion Points

• [00:01] The Reluctant Architect: Larisa frames a story that isn't about designing a system, but about years of deliberately refusing the role
• [02:00] From Steel Plants to Software: an electro-mechanical degree in a collapsing Soviet economy and an accidental route into writing code
• [05:00] "Let Me Tell You How Mobile Works": translating system constraints to architects who arrived without context — and the floppy-disk analogy that stuck
• [08:00] The Sadness That Protected Her: why the bank's architects started happy and ended demoralised, and why that kept Larisa saying no
• [10:00] Architects or Architecture?: Kenny raises Gregor Hohpe's distinction; Larisa on why an architect who still wants to code is probably in the right job
• [13:00] Advisor, Not Architect: the slightly controversial idea that some senior engineers contribute more from an advisory seat than from a room full of stakeholders
• [19:00] Self-Fulfilling Roles and the Next Village: roles that stop enabling teams and start justifying themselves — authority without context
• [22:00] Learning Not to Be Blunt: influence across stakeholder levels, writing to crystallise what only she knew, and architecture as the glue between engineers and leadership

Guest: Larisa Feldman

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

Andrew Harmel-Law: Hello again

2

Everybody.

3

and welcome back to another episode of

Stories of Facilitating Software Design

4

and Architecture with me, Andrew Hael Law,

and my co-conspirators, Andrea and Kenny.

5

And today our guest that

we've got with us is Larissa.

6

Do you wanna quickly introduce yourself?

7

Lar.

8

Larisa Feldman: Yes, sure.

9

So, my name is Larissa Feldman and I'm an

architect at company called Array Group.

10

our main software is, real Estate

Portal Marketplace, realestate.com

11

un some other businesses.

12

Andrea Magnorsky: Υπότιτλοι

13

Larisa Feldman: I've been there

for four and a half years and I've

14

been an architect for the last.

15

Two and half, almost three years.

16

Andrew Harmel-Law: That sounds exciting.

17

Andrea Magnorsky: AUTHORWAVE

18

Andrew Harmel-Law: story that

you've got for us and 'cause

19

we're really excited to hear.

20

Larisa Feldman: So, um, the

story is, a little bit unusual.

21

I'm sort of, um, unusual in a sense.

22

I'm probably not gonna talk about

how I designed anything or whatnot,

23

or maybe we'll come to that.

24

But I'm going to talk a little bit about

how I have become a reluctant architect.

25

So, yeah, that's, that's

a topic for today.

26

Andrew Harmel-Law: Just jump

into the story then, 'cause

27

that sounds really interesting.

28

So I think this happens to more than a

few people, I think, in our industry.

29

So.

30

Larisa Feldman: Yeah, I think so.

31

so, I was born in, in Ukraine,

which was a former Soviet Union.

32

And, the end of my education just

happened to be in the nineties where

33

Soviet Union kind of all started collapse

and the industry started to collapse.

34

And, as I was always very curious about

how things work, my education that I

35

got was electro mechanical engineering.

36

So.

37

I spent five and a half years, you

know, learning about, big machines,

38

you know, the, steel making plans,

things like those ones, and then

39

suddenly there is no industry.

40

So, so I found a job in a small accounting

companies and, that company had.

41

A piece of software that

supported some scripting and

42

then needed some customization.

43

So that's how I started

getting into writing code.

44

and couple of years later, my family

migrated to, to Australia and I sort

45

of thought, okay, that's a new start.

46

How about, Going into something different.

47

And with my job experience, I decided

to do post-grad in software engineering.

48

that was in 99, so that

was a advent of Java.

49

So the first Java I tried

was like version 1.0,

50

0.3,

51

I think.

52

and then my software

development career started.

53

and, I, I was, doing, sort of

after, after that, that one year

54

of postgrad I worked for some small

55

Boom happened and there was a

lot of very interesting things

56

happening in an industry.

57

And then I spent a couple of years in

superannuation companies, so that's

58

where all, you know, the pensions are

stored and calculated in Australia.

59

And, my next big chunk of my career

I spend in National Australia Bank.

60

so if you're not familiar with

it, in Australia, we've got

61

what's called Big four banks.

62

So those are like, you know, larger,

larger banks amongst the smaller ones.

63

And I spent there whooping 18 years.

64

And the, the large part of that,

career I spent trying not to become an

65

architect, which was quite interesting.

66

So, I spent, spent a lot of time with.

67

Area, which is called digital.

68

Like I, I really don't buy into

the term because like everything's

69

digital nowadays, but that's how big

banks and big organizations, like

70

all the organizations call those

areas digital, whatever that means.

71

and I spend time in like internet

banking that's like, you know,

72

start of internet banking.

73

And we started with,

2,400 concurrent users.

74

And by the time I left the team,

four or five years later, that was

75

like over 40,000 concurrent users.

76

And we are talking about, you know, just,

just Australia, which is population wise.

77

Not huge, right?

78

So that's like a big, big change

where, four years before we could

79

find a quiet time in the middle

of the night to do change and

80

suddenly there is no quiet time.

81

You can't do change in a quiet time.

82

You can't shut it down.

83

So that was very, very interesting.

84

and then I turned the, corporate internet

banking that's like quite different.

85

That was, that was cool.

86

And then, some smaller.

87

Roles here and there, and over

time kind of been shifting into the

88

role from the, software engineer

to senior software engineer.

89

And, one of my last roles in there

I did, I was principal engineer

90

for mobile internet banking.

91

and that was one of the, another

reluctant things I did, in a career.

92

I.

93

I was never really

passionate about mobile.

94

So when somebody tapped me on a shoulder

and said like, we need a, like, you

95

know, really good principal engineer

to set up standards and delivery

96

pipelines and all of those things

for mobile, I'm just like, mobile.

97

I'm not spending a lot

of time on my mobile.

98

I'm not like, very curious about that.

99

But, um, but yeah, I took it on

and that was very interesting

100

and, and very, very different.

101

Um, but.

102

How it relates to the talk is that as, as

you become more senior engineer in large

103

organizations, You deal with a lot of

architects coming to your digital channels

104

and saying, we want to, to do this thing,

or we want to implement that feature.

105

And the architects, especially solution

architects, they, they don't have the

106

context of the system or of how things

work or, some historical context, right.

107

That, that you might have as, as a senior

engineer or as a principal engineer.

108

And I found myself.

109

Self, explaining a lot of, a lot of

things about a lot of different systems.

110

mobile probably was one of those,

unusual ones where any new solution

111

architect or domain architect comes in

and there's like, we are gonna do this.

112

And I'm just like, Let me

tell you how mobile works.

113

because it's so very different.

114

It's not like you, deploy something and

it just appears on a website, right?

115

it's a little bit like in desktop times.

116

Like you, like given a floppy disk

to someone, they've installed it,

117

and then you have no visibility to

anything that happens after, right?

118

So that's the analogy I use.

119

I've started documenting all of that.

120

So instead of having those conversations,

I will say, this is pretty for you once

121

you've done, come back and talk to me.

122

And the more I became like a

principal engineer and working

123

more with architects, I found that.

124

I do less and less code and I

delegate more and more to, to

125

senior engineers and that was tough.

126

So, just before I joined mobile team,

I kind of decided that like really

127

want to go back to coding and I did,

for about two and a half years and.

128

Then it became sad.

129

I kind of like, okay, so I'll

code yet another feature, I'll try

130

another framework, kind of miss that,

larger picture, you know, things.

131

And and when I went to be the principal

engineer in mobile, that's kind of

132

opened up again, those opportunities

to work across different, different

133

lines of business, different, you know,

134

Different architects, there's like

payments, accounts, loans, like,

135

you know, as an internet banking

app, you've got all of it, right?

136

And it's so, but then again, it's one

of the reasons I never even entertained

137

applying for the architectural role in at.

138

National Australia Bank is

as a very large organization.

139

I kind of observe the architects

who are never quite, quite happy

140

bunch, because they can come up with

this brilliant idea, like how to

141

implement a product and all of that.

142

get stripped away by, you know, there

is this mainframe and it can't do this.

143

Or there is this old

system, it can't do this.

144

Or, you know, we don't

have priority to do that.

145

And they kind of like, they start

very happy and they become quite sad.

146

So, and I was, I was never tempted

to be honest, although I was

147

prompted and prodded couple of times.

148

But, the sadness in their eyes,

that eventual sadness kind

149

of protected me from that.

150

I loved working with them.

151

They were all great, great guys and

girls, like, you know, I always had

152

a really good relationship with them,

but I was never tempted to apply.

153

four and a half years ago, I decided

to leave financial services behind

154

and do something very different.

155

Enjoyed the advertisement company, which

is, very different and very exciting.

156

And although you can't say it's

like, a startup company or whatnot,

157

it's a very, modern, like it's

30 old company, but it's set up.

158

Quite modern way, of adopting Agile,

not having separate product and

159

technology like we all work together.

160

everything goes directly into production.

161

it's very different.

162

And there were quite a

few shocks there for me.

163

like what do you mean, everything

deployed into production straight away?

164

So there is no like change

panels and change reviews

165

and all of those things, but.

166

That was, that was really cool.

167

And I joined as a role that was quite

similar to principal engineer role.

168

And in, in first, year and a

half, I helped to, stand up.

169

Big modernization program that, you

know, looks in transforming one of

170

the oldest software in, onto the

new platform and new technology.

171

And and I was offered

like, do you want to apply?

172

As an architect for the

role for that program.

173

And I thought, well, that's an opportunity

to actually do something the way I wanted

174

it to, rather than do it as another

architect, you know, suggest, to do it.

175

And, so yeah, that's, that's how I become

an architect a little bit accidentally.

176

Kenny Schwegler: So a lot of

things hit, hit home for me.

177

Architects not being happy because,

you know, don't know enough context.

178

But one thing I want to focus on, and I

think that's an interesting observation,

179

I always see only with the role architect,

but also business analysts or other

180

roles, they're so rigidly defined.

181

That, it becomes very binary, right?

182

If, if you become an architect, you can

only do this, you cannot code anymore.

183

And, it's what Gregor Hopi

says, do we want architects

184

or do we want architecture?

185

what happened with you

a little bit, right?

186

Because I think having

you doing architecture is

187

like the best

188

thing you can ever imagine, right?

189

We have a senior principal.

190

In a team doing coding, knowing so much

191

so much.

192

about it, do letting that person do

architecture, great, but also make sure

193

that they're not being overwhelmed.

194

This is what I usually often

see in teams happening, and

195

you had the same thing, right?

196

You're we're organizing things in a team

and doing less and less coding, right?

197

Larisa Feldman: Yeah.

198

Yeah, I think so.

199

You just sort of don't have

that, that much bandwidth.

200

Um, but I, I found myself doing bits

and pieces of code in anyway, like,

201

I think, you get drawn to it anyway.

202

So even as an architect, if you need

to do some reporting on something, and

203

I need to look at GitHub, my, my first

thought is like, how about I'll just

204

write something that do it for me, right?

205

Rather than, you know, exporting

it into spreadsheet or whatnot.

206

And,

207

Kenny Schwegler: Yeah.

208

Larisa Feldman: I think it's quite

powerful now with having all the AI tools,

209

you know, to actually not letting that go.

210

And for me, software engineering is

something that I hold really dear.

211

So for me, any architecture that makes

life for software engineers really

212

hard, is not a really good architecture.

213

To be honest, because they experience

and how well they can work is

214

quite important for me as well.

215

So I think you get less coding because

you just don't have less bandwidth.

216

but I think if an architect

still have that, desire to code,

217

it's probably, they're probably

in the right job, I think.

218

Kenny Schwegler: I see that this

struggles a lot with engineers

219

that, don't want to become that

full-time architect want to still, but

220

they're the main person in the team.

221

And then get overwhelmed by

all the meetings they're in.

222

And it's sort of like, at some points

I feel that myself as now an architect

223

enabler, if the knowledge is not

shared in a way, the person in the

224

team gets overwhelmed with meetings.

225

and, that's a struggle I see

a lot of engineers, struggling

226

with because they want to do more

architecture, but they don't want

227

to get overwhelmed with meetings.

228

Larisa Feldman: maybe a bit controversial.

229

I think, um, I think some senior

developers, that gets drawn into that

230

sort of architecture discussions and

whatnot, they probably would be more

231

useful and more happy, happier if, if

they are as a advisor role rather than

232

being, you know, drawn into actually

doing an architecture and, you know,

233

being drawn into those meetings.

234

I think there is a lot of, well, once

you get into some of those, you know,

235

really strong, Software engineers at

the staff level, you can find that

236

they're really their happy places.

237

Like just, just them and a computer

and maybe pair programming with

238

someone, but in a larger audience.

239

And like, you know, in the meetings,

it's not their happy place.

240

So I think, I think it's okay.

241

We need these people too.

242

they excel at what they do.

243

I think somebody may be less experienced

but more curious and could be a better.

244

candidate to grow as an

architect, sometimes that sets

245

my, I don't know, my 2 cents.

246

Kenny Schwegler: I

tried to do that, right?

247

I tried to facilitate these

people in teams and remove some

248

of the burden the role gives.

249

But then the danger I always see is

that a lot of knowledge towards me.

250

So, you want to make sure that the

knowledge of this whole system.

251

It's available for the teams to move on.

252

Right?

253

It's sort of like a, a, a symbiotic

relationship if you're not careful

254

and you want to step out of it.

255

But I think that's a good one, right?

256

How can we make sure that these

people start advising instead of

257

taking on the burden of, of with

all the politics or dealing with

258

all the other things around them?

259

Yeah.

260

Andrea Magnorsky: If only

there was a thing about a bias

261

and decision, "kuch" Andrew

262

Andrew Harmel-Law: I know, I know.

263

I completely relate to

that Larissa, right?

264

'cause like.

265

As soon as someone gets the word

architect in their job title,

266

they end up being, they get, like

267

like you said they have to go to meetings.

268

They become blockers and, and that's, so

they can't, they don't get enough time to

269

do any of the things that they need to do.

270

But like Kenny said, advice is more

like, you can even do async, right?

271

Like I.

272

Lots of stuff I coach people on these

days is like, maybe you're not like, you

273

don't like standing up in meetings and

having an opinion and then having your

274

opinions challenged because that's not,

you need time to think, but if you can

275

write stuff down, which might not be

one of your skills, but you can learn

276

to write stuff down and then provide

like written advice and input and stuff.

277

Larisa Feldman: Yeah.

278

Andrew Harmel-Law: It's a big deal and

it can really transform things, right?

279

Like then you can get these people

who might be more happy sitting

280

down on their own or in a pair.

281

can still have an impact, but they don't

have to turn up at meetings and stand in

282

front of whiteboards and point at things

and yeah, I think it's super powerful.

283

Andrew, you were gonna say

something though, I think, or, yeah.

284

Andrea Magnorsky: It may or may not be

opportunistic, you upload something.

285

As in the case of Larissa.

286

It's like, I didn't really want to

be an architect, because they look

287

tough and I didn't want to be tough.

288

I think the question is about the general

scene, or the generalization of it.

289

What does it mean…

290

About the career How can you see in

the future, for example, we're here

291

now, we all have the same careers now.

292

What exists in our future and we

don't hope for, because we don't

293

think we want to, but it's also hard

to know until you're on the road.

294

For example, from Larissa, I know your

story that you really enjoy now, even if

295

you didn't want to be an architect for

many years and that's because you're…

296

Not just an architect, not the right role,

but the right role in the right place.

297

And I think as we move our careers,

the roles become less clear, and we

298

need to have that internal process

to see what we're going to do in the

299

next one and try to figure it out,

rather than choosing it for ourselves.

300

I don't know, that's how I was when

you made me in the positive photos.

301

Larisa Feldman: Yeah, I think,

I think you, you nailed it.

302

It's probably depends where as well.

303

You know, it's not just, like

the role of architect is so

304

different depending on the company.

305

And, sometimes it's very rigid.

306

You do just this, right?

307

Like in a big bank you'll have your

integration architects or solution

308

architects, domain architects,

enterprise architects, you know,

309

and each role has got very specific

things where if you look at, like, we.

310

We are just the group of architects

and whatever within architecture we do.

311

Right?

312

And uh, um, I find, some aspects

of the architect role very

313

appealing and I like it very much.

314

Some less so, but I think, A lot

of things that architects did,

315

which I didn't see a value of,

started to became apparent, right?

316

Because you get dragged into things

that you haven't been, you know,

317

um, in some of the discussions

or in some of the, you know, um.

318

In, in some of the initiatives

at a different level when they

319

just start up or, you know,

like, it, it's very different,

320

different way of looking at things.

321

You look at, across organization,

you look at different initiatives,

322

you're trying to draw the line.

323

So your field of vision is quite wide.

324

It's not, not very narrow.

325

So certain activities that architects

do and I'm just like, oh, why would they

326

do it, like mapping the capabilities

of systems or something like that.

327

It's now kind of quite apparent why,

so I can, I might be enjoying it a bit

328

more because now I see a reason why

or, you know, which is which is good.

329

so yeah, I'm definitely enjoying it.

330

sure.

331

Kenny Schwegler: yeah, I often

see architects in that role, and

332

not even architects, but everyone

in, in this leadership role.

333

It starts well, right?

334

You want to have engineers and

teams do engineering, and you

335

say, oh, okay, there's all these

stuff that we need to think about

336

holistically, so let's pull that out.

337

Which is a good, maybe

a good thing, right?

338

Let's pull that out to a role.

339

I often see that role not reflecting.

340

Are we still enabling the teams

to do their work better or

341

are we just self-fulfilling?

342

I see it with managers as well.

343

Yeah.

344

They, they're really looking

for us to make decisions.

345

Right.

346

And, and, and because

347

Today he have the capacity to do it

or the cognitive load load to do it.

348

That's usually along along

the lines, what I usually do.

349

And the the architecture well,

teams know ity sure, correct.

350

But.

351

If you then say.

352

That's why we are here.

353

That's like a self prophecy.

354

And and then you stop looking at

what do the teams actually need?

355

the teams

356

might need we guide them

understanding about, then they

357

can make decisions themselves.

358

that's the thing that I you

say with the story, right?

359

The solution architect came, but they

don't know, understand the context of it.

360

It reminds me me a little bit

of, of, actually in our village.

361

We, want to get something done on your

house and someone from another village

362

somewhere far away, will make a decision

if you are allowed to do that or not.

363

If it's you are not not not allowed.

364

to this and this rules.

365

And I'm like, well, have

you seen my neighborhood?

366

Other people do it right?

367

And because they're not living

in the village, don't know

368

the context of the village.

369

So they make vary.

370

mis weird decisions in a way.

371

And then they have all this

form of control over it.

372

I think that's what I hear you.

373

And that's that's off-putting

to a lot of engineers, I guess.

374

Right?

375

You don't want to be in that role,

without context trying to make

376

decisions that cannot be done anyway.

377

Is that something that didn't

want to make you architect in that

378

Larisa Feldman: Yeah,

379

Kenny Schwegler: previous moment?

380

Larisa Feldman: I think

that's one of the aspect.

381

And another one is that,

like vision really, you know,

382

transformed into what the.

383

What they saw it to be because

of gazillions of different

384

limitations and inability to make

decisions quickly, as in any large

385

organization, an old organization.

386

but like I think you are

quite right about like.

387

Engineering community overall.

388

in, in some organizations just

trying to ignore the architects and

389

the, the function of architecture.

390

Kind of like, like, like those

people in, like in the next village.

391

So they just ignore what they say

and just do what I want in my house,

392

you know, and my, as my neighbor did.

393

I think at area we are a bit better

at, at least we do try, we try to

394

listen to the community and there are

channels they can, you know, tell us

395

Andrea Magnorsky: if

you are doing a good job

396

Larisa Feldman: or need

to look at, at something.

397

And we try to, to measure how well we

doing our job for, for the development

398

community as well as for our stakeholders.

399

So I think that's, That

is quite important.

400

At least it's very important for me.

401

because I think if you are not

there as a, as that glue between

402

the development community and you

know, and leadership, then it's

403

not quite clear why we are needed.

404

Andrea Magnorsky: One of the

405

last questions, did you find that

406

You spend more time thinking

about influence Let's

407

say, you are more opportunistic

in your cooperation and you happen

408

to use more time than the previous

one and if this is the case, then

409

how did you learn these plans Um,

410

Larisa Feldman: definitely I, I do.

411

And, um, at a different level

of, you know, stakeholders.

412

So, uh, the,

413

Andrea Magnorsky: the context

414

Larisa Feldman: and tone of voice

and the right, you know, level

415

of details is quite important.

416

Started as being a really

blunt person, to be honest.

417

And, I had to learn along the way to,

you know, to pick the words and, put

418

things in the context and, you know,

I'm one of those unfortunate people

419

that can have everything clear in my

mind, but sometimes struggle to explain.

420

And because sometimes it's just based

on experience and you have a gut feel

421

that this thing won't work or won't

work as well as you think it will,

422

but it's very hard to articulate.

423

So over the years I tried to learn

how to kind of extract it from

424

my brain on, on paper or digital

media to kind of crystallize it.

425

You kind of like learn it

through the, through your career.

426

And I think if somebody has, has

an ambition to become an architect

427

or principal engineer, they just

need to look for opportunities.

428

And opportunities and in

my view, are always there.

429

You know, like if you know something that

only you know, or have some historical

430

context, you can always, you know, put it

on paper and share it as a blockbuster.

431

Just something on, you know,

confluence so people would know.

432

so I kind of did it through the

last, I dunno, maybe 15 years.

433

So I found it relatively

easy join, like joining the

434

architecture team from that aspect.

435

One thing I found a little bit

challenging, easy kind of deal, visa,

436

with executives and general managers

more, and that's like a different

437

level of thinking about the business.

438

As you are, like even

like head of product.

439

So that kind of level of vision, even

though I kind of thought, okay, I have

440

got that, that level of vision and for

the architecture and the systems, I had

441

a very little understanding how business

and product people do it at that level.

442

So that's quite fascinating

to even look at that as well.

443

So that's an interesting, and

how they communicate is, is

444

very, Very, very high standards.

445

Let's put it this way.

446

Andrew Harmel-Law: Yeah.

447

Super interesting.

448

Thanks Larissa.

449

For, for that all the other stuff.

450

There's a few things that you

said I'm gonna be thinking about.

451

Like one, the thing that hit me most

was, It needs to make like the, the

452

things you do as an architect need

to be, make the developer's lives

453

better or need to, you know, be, and,

and beneficial to the developers.

454

'cause otherwise it won't have any impact.

455

And I think that's, a big deal.

456

But I think we're out of time.

457

So, thanks very much for sharing

your story and it was very different

458

from lots of the other ones we hear.

459

So thank you very much

for taking the time and,

460

Larisa Feldman: Thank you.

461

Andrew Harmel-Law: sharing

everything with us.

462

Cheers everybody.

463

Andrea Magnorsky: bye

464

Larisa Feldman: Thank you.

465

Bye.