Interview with Patrick Kua
What does it mean to be an architect in today’s fast-paced tech world? For Pat Kua, it’s less about the title and more about fostering a culture where everyone cares about architecture. Shaped by the early days of agile and XP, Pat believes in moving beyond strict role boundaries toward team empowerment and shared ownership. As he puts it, “you might label me as an architect but it’s just one of many hats I think senior technical leaders play these days.”
Pat’s reflections offer practical inspiration for anyone passionate about building better systems together.
Where to find Patrick:
What inspired you to become an architect?
I don’t think of myself as an architect first and foremost. Rather a senior technical leader and I believe that technical leaders need to understand the value of architecture and cultivate a culture where others care about architecture. Therefore, you might label me as an architect but it’s just one of many hats I think senior technical leaders play these days.
Was there a defining moment or project early in your career that shaped your approach?
There wasn’t a specific defining moment, but as I grew up in the early days of agile (specifically XP), there was a sense of moving away from centralised, strict role boundaries, to a more self-empowered and team ownership approach that definitely influenced my style to leadership and how I approach cultivating architecture in teams and organisaitons. You can probably see these influences in the Building Evolutionary Architecture book.
How would you describe your architectural philosophy in a sentence?
Guided, iterative chaos 🙂
Can you walk us through how you approach a new design project, from concept to completion?
If it’s a completely new thing, it makes sense to do a Discovery/Inception/Kick Off to quickly get a sense of what the business scope is, what makes this system unique compared to others, and to quickly establish assumptions and key decisions. The length of this phase is often relative to the overall complexity of the system, but could go from 1-3 days up to 2 weeks. A good outcome of this initial phase is that we have a good rough understanding of what business goals we’re trying to reach, and an agreed initial approach about how we will reach them from a technical solution perspective.
After the discovery/inception/kick off, comes the “delivery” phase, but the first few weeks are front-loading all the risky elements. Some of this might involve technical spikes to validate solutions or the “first-time” activities where we integrate a vendor, external framework/library and establish the patterns we’re going to use throughout the codebase. A good outcome of this these early weeks is what is often called a “Walking Skeleton”, which proves the architectural approach is possible, useful and meets the architectural characteristics we care about. If you’re familiar with story mapping, this would be the first end-to-end slice across the map.
The rest of the delivery (assuming there are no other significant changes) would be approach in an agile (iterative and incremental fashion), building on the assumptions and architectural decisions we’ve proven out with richer fidelity features or more complex scenarios
What’s the biggest challenge you’ve faced in a project, and how did you overcome it?
As a former consultant, I faced many big challenges, but an early one I remember was being forced to use a Proof of Concept (PoC) codebase another architect had generated through a drag and drop editor as the “foundation” of our application. Although it provided a great basis to understand what the UI and application flow was, the code was extremely complex, coupled and very hard to test. Since there wasn’t that much code in the PoC, we said that we would use the design patterns, but it’d be easier to start incrementally from scratch and TDD the entire architecture.
Since I suspected they felt “it’d be faster” if we used their code, we doubled down on trying to show visible progress as quickly as possible with the application that also had a good set of tests (unit, integration and acceptance tests). Since we made a lot of progress after a week replicating all the PoC’s functionality with an automated test suite, the architect didn’t end up worrying that we didn’t use the code they wrote. We finished this project early (8 out of 12 weeks) and I also found out later that this system stayed in use (in production) for five years and only had one bug ever reported! I also discovered that the bug was a story intentionally deprioritised during the system development as a “that’ll never happen” situation.
How do you balance creativity with practicality in large-scale projects?
The trick to finding balance between these two traits is not to see them in opposition. Instead, challenge people to find creative solutions that are also pragmatic and easy for others to use. When I learned functional programming, you’re often thinking of three cases: 0, 1 or many. If it’s the first time you’re doing something, there should be a lot of creativity and you can harness your entire team to experiment, prototype and find a creative solution. If it's many (more of the same situation), there should be a very good reason to diverge.
What inspires you most in your work as an architect?
One thing that keeps me excited about technology, software and architecture is how there are some fundamentals that don’t really change, but we also learn about new ways and approaches as well. I’m especially inspired by the generous nature of our industry sharing our experiences as a way of learning from each other and I’ve seen this through mailing lists and books, then blogs and open source, and of course, conferences, papers and other communities.
Who or what has had the biggest influence on your thinking and approach to architecture?
I spent a significant time at ThoughtWorks, so I’d have to say Martin Fowler and Gregor Hohpe. I was particularly fortunate enough to hang out with Gregor in my first Australian Away Day (an internal ThoughtWorks event), who was so humble and generous with his knowledge. I still remember his talk, where he shared his lessons learned from writing his book, “Enterprise Integration Patterns”.
What trends do you think will define the next decade in architecture?
I’m not very good at predicting the future, but definitely how AI (specifically LLM) changing the tasks and activities people spend time on. Just like compilers moved programmers away from assembly code, I’m curious to see how this will take shape.
How AI is shaping modern architectural design?
Since AI makes generating code easier, engineers should focus even more on the architectural design elements. This means focusing more on identifying (and testing) if the generated code meets the architectural fit (we describe as Fitness Functions in Building Evolutionary Architectures). Faster doesn’t always mean better as well, so I’m interested to see what new approaches to managing tech debt will emerge.
What advice would you give to young architects just starting their careers?
Many architectural ideas are relatively constant, so I would say focus less on the “flavour of the week” and focus on architectural principles. This means going back and reading older books and resources. I’m constantly surprised at how many people have not.
If you could go back and give your younger self one piece of advice, what would it be?
Identify and lean into your strengths.
What do you think about Dear Architects?
It’s nice to see a place that is focused on architecture
Patrick Kua is a seasoned technology leader with 20+ years of experience. His current mission is accelerating the growth of technical leaders through coaching, mentoring and training. He has had many years of hands-on experience, leading, managing and improving complex organisations and software systems as the CTO and Chief Scientist of N26 (Berlin, Germany) and as a Technical Principal Consultant at ThoughtWorks.