There is a version of career progression that looks like success from the outside and feels like a slow erosion from the inside. You get more senior, you attend more meetings, you write less software, and eventually someone asks if you'd like to become an architect. Most people in that position have already watched what happens next — they've seen the people who said yes.
Larisa Feldman joined the Virtual DDD podcast to share a story that doesn't start with a design problem or a troubled system. It starts with a decision she kept refusing to make — and what eventually changed her mind. Larisa is an architect at REA Group, the company behind realestate.com.au, and before that she spent 18 years at National Australia Bank. Her route into architecture was neither planned nor obvious, and the story of how she got there says something worth sitting with about what the role actually is, and who it's actually for.
The Architects Nobody Wanted to Become
At a large bank, you see a lot of architects. Integration architects, solution architects, domain architects, enterprise architects — each with a defined lane and a specific set of responsibilities. Larisa worked alongside many of them over nearly two decades, and she noticed a pattern.
"They start very happy and they become quite sad."
The sadness wasn't mysterious. These were people who would develop a clear, well-reasoned vision for how something should be built, and then watch it get stripped back — by a mainframe that couldn't support it, by an old system that wouldn't integrate, by competing priorities that meant it never got resourced. The gap between what they could see and what they could actually deliver was a permanent feature of the job.
Larisa was good at working with architects. She understood their proposals, pushed back when she had context they lacked, and often ended up explaining how the systems actually worked before any design conversation could begin. But she never wanted to be one of them. The sadness in their eyes, as she put it, protected her.
What Happens When Architects Don't Know the System
As Larisa moved into more senior roles — including a stint as principal engineer for mobile internet banking — she kept running into the same problem from a different angle. Architects would arrive with proposals, and she would have to spend time explaining constraints and context they didn't have. Mobile was a particularly sharp example.
"Any new solution architect or domain architect comes in and says, we are going to do this. And I'm just like, let me tell you how mobile works."
The analogy she used to explain mobile to them was a floppy disk. Once you hand it to someone and they install it, you lose visibility of everything that happens after. Mobile isn't a website deployment — the moment a user installs your app, you've given up a certain kind of control. Architects used to web systems often didn't have that mental model.
Her solution was practical: she started writing things down. Instead of having the same explanatory conversation repeatedly, she documented the constraints and historical context so that anyone walking in could read it first. This habit — of crystallising what she knew into something others could use — would turn out to matter more than she expected.
Kenny noted during the conversation that this situation is common, and the analogy he reached for was striking: it's like someone from a distant village making decisions about what you can build on your house, without ever having walked your street. The decision-maker has authority, but no context. The person with context has no authority. And often, the result is that the engineering community simply ignores the architects and does what it thinks is right anyway.
The Reluctant Yes
Larisa eventually left financial services and joined REA Group — a company that operates quite differently from a large bank. No change review panels. No separation between product and technology. Everything goes to production. The first time she heard that, it was a shock.
When she was offered the chance to apply for an architecture role on a major modernisation programme, something shifted. It wasn't enthusiasm for the title or the status. It was something more specific: the opportunity to do things the way she thought they should be done, rather than watching someone else do them differently.
"That's an opportunity to actually do something the way I wanted it to, rather than do it as another architect suggests."
That's a quiet but important motivation. It's not ambition in the conventional sense — it's more like a threshold of frustration combined with a genuine belief that you could contribute something. She became an architect almost by accident, but not without reason.
What the Role Looks Like From the Inside
Once in the role, some of the things she had found opaque started to make sense. Mapping the capabilities of systems, for instance — something she had previously dismissed as bureaucratic busywork — became useful once she could see why it was needed. The field of vision as an architect is wider than it is as a principal engineer, and that width changes what information becomes valuable.
But she was also clear about what she thinks makes the role worth doing. The measure she keeps coming back to is whether the architecture is making the lives of software engineers better or harder. If it's making things harder, it's not good architecture — regardless of how elegant it looks on a diagram.
She also described the glue function that she sees as central to the job: sitting between the development community and leadership, making sure the concerns of each are visible to the other. If that connection isn't there, she's not sure what the role is actually for.
Patterns Worth Noticing
- The context gap is a structural problem, not a personal failing. When architects don't have system context and engineers don't have organisational visibility, both groups end up making decisions in partial darkness. The question worth asking is what structures are in place to close that gap — not whether the individuals are trying hard enough.
- Writing things down is an architectural act. Larisa's habit of documenting constraints and context — started as a practical workaround — turned out to be one of the most transferable skills she brought into the architecture role. Knowledge that lives only in someone's head creates dependency and slows everyone else down.
- The unhappy architect problem is worth taking seriously as a system signal. If architects consistently start enthusiastic and end up demoralised, that's worth examining at an organisational level, not just a personal one. The pattern Larisa observed at the bank wasn't about individual resilience — it was about a structural mismatch between the scope of vision and the scope of influence.
- Not everyone who could do architecture should be pulled into it. Some senior engineers are genuinely most effective when they're deep in a problem, not in a room full of stakeholders. Larisa made the distinction between an advisor role and an architecture role, and suggested that some people would be better served — and more satisfied — in the former. That's not a consolation prize; it's a real contribution.
- The "people from the next village" problem scales. Kenny's analogy about distant decision-makers is worth holding onto. When the people making architectural decisions are too far removed from the systems they're deciding about, teams find ways to route around them. That's not necessarily a failure of the teams — it may be a sign that the architecture function is positioned too far from where decisions actually need to be made.
Closing Thought
Larisa's story isn't really about becoming an architect. It's about watching a role closely for years, understanding exactly what made it difficult, and then choosing it anyway — in a context where the conditions were different enough to make it worth trying. The question she leaves behind isn't how to encourage more people into architecture. It's something harder: whether the conditions in your organisation are ones where a thoughtful, experienced person would actually want to do the job.
Further Reading
Mentioned in this episode:
- Do we want architects or do we want architecture? — Gregor Hohpe. Referenced by Kenny during the conversation as a framing for the distinction between the role and the function. Hohpe writes extensively on this tension in his work on the software architect elevator.
Worth exploring:
- The Software Architect Elevator by Gregor Hohpe. A direct exploration of what architects actually do at different levels of an organisation, and why the distance between penthouse and engine room is a problem. Directly relevant to the gap Larisa describes between architectural vision and engineering reality.
- Team Topologies by Matthew Skelton and Manuel Pais. Offers a vocabulary for thinking about how teams and enabling functions relate to each other, relevant to the discussion of architects as enablers versus decision-makers.
- An Elegant Puzzle: Systems of Engineering Management by Will Larson. Addresses the tension between technical depth and organisational scope as engineers become more senior — directly relevant to Larisa's description of drifting away from software and back again.
- Thinking in Systems by Donella Meadows. The recurring theme in this conversation — context gaps, self-fulfilling roles, teams routing around decision-makers — is easier to reason about with a systems lens. Meadows provides one of the clearest introductions to that way of thinking.
