Meet Phil: Principal Architect
Learn how Phil builds robust tech by understanding the entire system and anticipating every challenge.

Beyond The Happy Path: Meet Phil Mork, the Architect Building Resilient Systems
What sets a truly great systems architect apart? For Phil Mork, a Principal Architect at Endava, it’s the relentless pursuit of what lies “beyond the Happy Path”. Though his first love was electrical engineering, Phil’s journey from Minnesota to Charlotte, North Carolina, has been defined by a commitment to building robust, resilient systems. Since joining Endava through the Levvel merger in 2018, Phil has been instrumental in helping clients launch modern payment systems and digital banks. His secret? A singular principle: think beyond the Happy Path.
Let’s start at the beginning. What first sparked your interest in technology?
My dad was an electronics technician at Honeywell [an automotive and aerospace manufacturer]. Growing up in Minneapolis, I was immersed in the world of fixing electronics. While electrical engineering at the University of Minnesota was my initial focus, computer science classes soon ignited my passion for software.
How did you first approach the IT industry?
My first foray into the IT industry was at a company specialising in embedded systems software and hardware. Here, electrical engineering graduates like me were uniquely positioned to write software, leveraging our deep understanding of hardware. Imagine the challenge: developing a real-time, multitasking, preemptive operating system in assembly language, all under severe system storage limitations. We had to write everything efficiently, which is why we used assembly. I moved from assembly to C, then C++, then Java. I got into object-oriented programming, which I found fascinating.

What other roles or experiences have paved the way to where you are now?
My path then led me to a medical device company, where we built implantable defibrillators and pacemakers. This wasn't just about code; it involved intensive training on the intricacies of how the heart works, understanding how these devices monitored for issues and delivered life-saving shocks to restore rhythm if needed. I enjoy learning, especially outside of software, so that role had a big impact on me.
Why did you leave that line of work?
Despite the profound impact, the regulatory environment limited creativity. I spent more time dealing with red tape than coding. Also, working on software that can have direct life-and-death impacts is intense; I didn’t want that level of pressure long-term. This led me to IT, healthcare insurance, and then financial services coinciding with a personal move to North Carolina with my wife, drawn by the climate and access to nature. Charlotte also happens to be the second-largest banking hub in the US. I had a stint at a financial services organisation, drawn by its mission to support educators. It was there, while leading development teams, that a crucial realisation struck me: the vital importance of understanding full system architecture. This "aha!" moment propelled me to focus on optimising the entire architecture, not just isolated applications. After that, I landed at a renowned national bank.
What drew you to Endava?
At the bank, I worked on Apple Pay and other projects that needed to handle large spikes in volumes. I saw the importance of cloud computing in providing elasticity without having to own all that infrastructure. But we couldn’t use cloud computing due to conservative policies. I joined Levvel and later Endava to embrace cloud-native tech.
It’s not just about building one brilliant app; it’s about understanding how everything fits together – how different parts of a system interact and impact each other."
Can you share what your first project at Endava was?
My first project was helping a super-regional bank integrate with Real-time Payments (RTP) and that was on day one. That was the first assignment I started when I joined Levvel/Endava in 2018.
This was no small feat; RTP was the first new payment rail in the US in approximately 40 years, spearheaded by The Clearing House. At the time, there was a very small number of banks that had joined it, so it was fun to be part of something that was so brand new.
We helped that bank get live on that new rail, and it was exciting to figure out all the challenges that came with building something new and mission-critical. You can build the best application, but if the overall architecture is flawed, it won’t scale.
Another project I'm particularly proud of involved assisting a bank launch a full digital platform in a mere 90 working days. We built it from scratch using AWS and cloud-native vendors, working with a great team to create an entirely new system. This project wasn't just a success; it was a testament to how rapid innovation and modern technology can truly transform an industry often held back by legacy systems.
Beyond the projects, what defines the culture at Endava for you?
Endava has smart, collaborative people focused on delivering excellence. This collaborative spirit extends to my personal passion for mentoring. I'm not a formal career coach, but I've mentored colleagues informally for years, highlighting my commitment to nurturing talent.

What do you enjoy outside of work since you mentioned moving to North Carolina for the weather?
I enjoy hiking and exploring state and national parks. I picked up swimming during the pandemic, enjoy reading and podcasts, and engage in friendly table tennis matches with colleagues. When with my wife and three adult children, my family dives into various board games, with 'Terraforming Mars' being a current favourite.
What motivates you as an engineer today?
My philosophy, which I passionately champion, is to 'think of the system as a whole – not silos'. It’s not just about building one brilliant app; it’s about understanding how everything fits together – how different parts of a system interact and impact each other. That's a key responsibility of an architect. This can often involve tradeoffs that, if viewed from the siloed lens of one particular application, seem suboptimal. But when viewed at a system level, they provide great benefits.
This holistic view is also crucial for my other driving principle: to 'design beyond the happy path to prevent failures'. If you rush through software engineering projects, it can be easy to focus on what software engineers call the happy path, which is when everything works out well. But over time I’ve definitely come to see and appreciate that if you don’t give enough consideration for what they call the sad path or the edge cases, one of those can occur and bring down an entire system or cause really negative events. For me, ignoring edge cases is a critical oversight: if you don’t consider the edge cases, one small issue can bring the whole system down.
What advice would you give aspiring engineers?
Keep learning. Strive to understand the full architecture, not just your application. You can design your own application really well in isolation and still have an architecture with a lot of problems. Ultimately, that has the great overall impact.
From embedded systems to enterprise architecture, Phil’s story is about learning, building with purpose, and always designing beyond the Happy Path.