Architecting Change: What I Learned from Building Trust to Drive Transformation

By: Tuan Anh D. (Dennis Dao)

When I stepped into the role of Principal Architect for FinTech solutions at Southeast Asia’s leading travel platform, I thought my biggest challenges would be technical. I was brooding over restructuring systems, fixing bugs, and aligning platforms.

But, I quickly learned that the real challenge and opportunity was in the human element.

This is a reflection on the five lessons I learned while trying to drive change in a deeply technical and distributed organization.

At its core, this is a story about building trust.

Lesson 1: Bring People With You

When I first joined FinTech Solutions, I came in with a clear architectural vision. I analyzed the systems, identified redundancies, and saw a path toward a more cohesive and scalable platform. I thought, “If I present a reasonable solution, the teams will get on board.”

I was wrong.

While I thought I was leading a meaningful transformation, my co-workers felt I was challenging the status quo. Instead of enthusiastic agreement, they politely nodded along to my ideas without taking any action.

That was the first real lesson: a sound vision is not enough. No one cares how elegant the architecture is if they don’t feel heard, seen, or involved.

So I changed my approach. I started by asking better questions. What were the pain points they saw every day? What was working well enough that it warranted no change at all? And what could we improve together?

Instead of pitching a complete design, I began co-authoring the journey with them. It was a powerful shift from “Here’s what we should do” to “Let’s figure it out together”.

The lesson helped me earn buy-in from engineering managers. They already knew of my expertise, but what really convinced them to support my vision was my willingness to listen.

Lesson 2: Lead With Transparency and Shared Reasoning

My conversations with the engineering managers helped me understand the value of clear communication. Trust comes from demystifying the process, and removing complexity where possible.

I spent hours walking key stakeholders through my decision-making process. I didn’t want to show PowerPoint slides and just be done with it. I wanted to invite them into my thinking and allow them to probe until they had the answers.

It took time, but eventually, the managers began to see not just the what, but the why.

And when people understand the “why,” they begin to care about the outcome.

It also helps to provide transparency into the end user’s thought process. My advice here would be to encourage tight feedback loops between your teams and users.

At MISSION+, we embrace the Uncomfortably Simple approach to product building because it provides user insights at each stage of development. Regular releases, even in basic form, ensure you get immediate feedback on what works and what doesn’t.

This information supports more nuanced conversations with your team members and enables the kind of shared reasoning that builds trust.

Lesson 3: Crisis Is an Opportunity to Lead by Example

A defining moment for me arrived during a critical incident with our Payments system.

A coupon campaign had gone live, and we soon discovered users were finding loopholes to exploit it. It was late, tensions were high, and the team was scrambling to patch holes in a sinking boat.

This stressful situation was a golden opportunity to build trust. I joined the war room with the intention of contributing instead of just overseeing things. I rolled up my sleeves, reviewed logs, asked questions, and stayed with the team through the night until the issue was resolved.

Similarly, when the Rewards system suffered a duplicate points injection issue, I was in the trenches again. By this point, I understood that real leadership is about showing up when it matters most.

These high-stress environments helped me see my team in its most raw form. People opened up, with even previously guarded engineers proposing ideas. They found it easy to think of me as “one of them” instead of as a cold and distant administrator.

Lesson 4: Mentorship Is a Trust Multiplier

As I built trust, I noticed that junior engineers started leaning in more frequently to ask questions and offer ideas. Their willingness to learn helped me take another step forward in my leadership journey.

I shifted my focus toward mentorship, hoping to amplify my team’s trust in me. From encouraging junior voices in discussions to enabling experimentation, I broke down barriers to ensure my team felt safe expressing themselves.

In fact, “What if we tried this?” became a common refrain during our brainstorming sessions. Each member felt comfortable pitching their ideas, knowing that they would be seen and heard.

My greatest takeaway here was that your team members will show up every day if you acknowledge their potential. The best kind of mentorship allows confidence to ripple outward and create a distributed sense of leadership.

Ultimately, trust doesn’t scale through processes. It scales through people, and mentorship plays a key role in building that trust.

Lesson 5: Culture Is the Ultimate Architecture

As a technologist, I used to think of software and systems when I saw the term “architecture”. However, my experience as a leader taught me that the most enduring architecture is in how your people work together.

A great engineering culture is one where people are trusted to make good decisions. Leaders don’t feel the need to micromanage, knowing that innovation comes from unhindered brilliance. Silos start to dissolve as people feel psychologically safe enough to pitch in and collaborate.

When I think about my time as a Principle Software Architect, I realize that the systems I built with my team were the result of people feeling empowered and connected.

Yes, we restructured services, improved scalability, and modernized our stack. But those changes only stuck because the cultural foundation was there: shared ownership, openness to feedback, and a willingness to learn together.

Final Thoughts

Looking back, my proudest achievement wasn’t any specific design pattern or performance gain. It was the trust we built together. Because trust is what made the transformation possible and what it enables it to endure.

If you’re trying to drive change in your organization, start there. Architect the trust first. The systems will follow.

Who is Dennis?

Dennis is a Fractional CTO and Distinguished Software Architect at MISSION+. With a proven track record of building high-performance financial systems at scale, he demonstrates a passion for tackling complex problems with innovative solutions. As a technology leader, he is an effective communicator who works with both product and engineering teams to achieve meaningful outcomes. Connect with Dennis to talk architecture and tech culture by reaching out at hello@mission.plus.