Bridging Business,
Technology, and Execution

Senior Solutions Engineer · Pre-Sales & Implementation · APAC

From the first client conversation to go-live, my work is about making sure what gets scoped can actually be built, and that the gap between the two stays as small as possible.

Open to the right conversation →

Profile

My work sits between the first client conversation and go-live. I've been on both sides: scoping solutions during pre-sales, then carrying them through implementation. The hard part is usually the gap between a signed scope and a working system. That's where most assumptions get tested.

I'm drawn to situations where requirements aren't fully defined, the dependencies sit with third parties, and nobody has a clean project plan. That's where making good calls with incomplete information actually matters.

My focus is practical. What needs to be true for this to work? Who owns each dependency? What can move now, and what genuinely has to wait?

I work across English, Mandarin, and Cantonese, which has been practically useful in APAC client engagements where communication style and language matter as much as the technical content. I relocated from Hong Kong to Singapore in 2022 to position myself within the core of the APAC market — being based here allows me to operate closer to the customers and opportunities I focus on.

Core Competencies

Three areas of focus

Business & Solution Alignment

Translating client requirements into scopes that hold up under scrutiny. This means identifying integration gaps at the proposal stage (not after sign-off) and being direct when a client's assumptions don't match what the system can actually do.

Technical Implementation

Working with API-based systems and fintech platforms, specifically how they behave under real integration conditions. Error handling, retry logic, third-party dependencies, and the questions that only surface once you actually start building.

Execution & Delivery

Keeping projects moving when conditions aren't fully defined. This means mapping dependencies explicitly, being clear about what can proceed versus what genuinely has to wait, and being honest with stakeholders about what's actually blocking the work.

Professional Experience

Where design meets delivery

My experience spans pre-sales solutioning and hands-on implementation, often within the same project lifecycle. The gap between a signed scope and a working system is where most of the real work happens, and it's the part I've spent the most time in.

Senior Solutions Engineer — Global CPaaS Platform, APAC · ~6 years

Clients typically came in with a clear goal (send OTPs at login, trigger transactional messages, verify users at sign-up) but hadn't worked through how that would sit inside their existing architecture. Before a scope was finalised, the work was to get specific: Where does this API call fit in the current auth flow? What happens on a timeout or error? How does the client's backend handle retries? These questions mattered because catching an integration design problem at proposal stage is cheap; catching it during build is not. A recurring part of the role was pushing back on assumptions early. Once the technical constraints were laid out, what a client thought was straightforward often needed reframing. The goal was to arrive at a scope that could actually be delivered. Over time, this approach produced consistently high close rates on competitive RFPs across the APAC region.

Implementation Success Manager — Fintech & Card Programmes · Current

Onboarding to a card programme involves more moving parts than a standard software integration: scheme approvals, BIN sponsorship, compliance reviews, and environment access, each on a separate timeline, most involving third parties who don't respond to your project plan. The challenge wasn't primarily technical; it was sequencing. Early in the project, I mapped these dependencies explicitly: which tracks could run in parallel, which were hard blockers, and what could be built or tested before production credentials were issued. That meant writing integration code against sandbox environments with clear notes on what would need updating, documenting open questions so they could be answered without derailing progress, and being direct with stakeholders when a third-party approval was the actual constraint, not anything within the team's control. Decisions had to be made continuously about what to move forward on and what to hold, without the comfort of complete information.

In both environments, the original plan needed adjusting once it met reality. What kept projects moving was being willing to make that call early rather than protecting assumptions that no longer held.

Growth

Why the breadth is the point

Each role was a deliberate expansion into an adjacent domain — not a change of direction. Operational depth informed how I scope solutions. Compliance experience shaped how I frame risk in enterprise deals. Pre-sales tenure means I understand the gap between what gets sold and what gets built. In complex technical environments, the people who can navigate across these layers tend to be the ones who can lead them.

2013

Data Centre & Ops

Telstra

2016

Risk & Advisory

Deloitte

2018

Solutions Engineering

8x8

2025

Implementation

Reap

Values reflect relative focus and depth per domain — not hours worked. Hover legend items to isolate a skill area.

Selected Case Highlights

Problems that required more than a plan

Scoping Against Real System Behaviour

Context: Pre-sales engagement at a global digital communications platform. A mid-market client was evaluating integration of OTP and transactional messaging into their existing auth flow.
Problem: The client's stated requirements didn't map to what the API could support in their specific environment. Key assumptions around retry behaviour, timeout handling, and routing had never been validated against their actual architecture.
Action: Reproduced the exact failure conditions, documented the gap between what was expected and what the system would do, and brought that back into the scoping conversation. Rather than working around the problem, the scope was revised to reflect how the system actually behaved.
Outcome: A tighter integration design with fewer assumptions. The client had a clearer picture of what they were getting, and the delivery team had a scope that didn't require revisiting the fundamentals once build began. This pattern of early technical validation — applied consistently across APAC engagements — contributed to an 80% conversion rate from evaluation to close on high-complexity deals.

Building Forward Without Complete Information

Context: Early-stage fintech onboarding involving card programme setup. Multiple third-party dependencies were in progress simultaneously: scheme approvals, BIN sponsorship, and compliance reviews.
Problem: Full API documentation was unavailable and several requirements were still being finalised. Waiting for completeness would have cost weeks, but building without visibility into the unknowns carried its own risk.
Action: Built a working baseline against what was confirmed, with gaps explicitly documented rather than assumed away. Open questions were structured so they could be answered and dropped in without requiring rework. The approach distinguished between what could move and what genuinely had to wait.
Outcome: The project stayed on track. When missing documentation and approvals arrived, integration questions had already surfaced and the team was positioned to act on them immediately rather than starting the analysis from scratch. Delivery timelines were preserved despite dependencies outside the team's control.

Approach

How I think about the work

Identify the actual problem, including constraints and dependencies that aren't immediately obvious. The right question isn't always the one being asked.

Get stakeholders to a shared understanding of what's possible and what isn't, before the build starts rather than during it.

Execute in a way that keeps making progress: surface blockers early, document what's open, and don't let uncertainty become a reason to stall.

Adapt when the situation changes. The goal isn't to protect the original plan. It's to protect the outcome. That posture holds whether the context is a client integration, a delayed approval, or any situation where the full picture isn't yet available.

Academic Background

MSc in Information Systems Management, City University of Hong Kong — completed alongside full-time professional work. Coursework covered project management, business intelligence, data analytics, and information systems strategy.

Pursuing it mid-career was deliberate. The programme sharpened how I frame ambiguous problems and evaluate trade-offs — skills that apply directly to the work.

Looking Forward

Active in the professional community

I'm a member of PMI and SCS, and I'm looking to engage more consistently with the practitioner community, particularly around delivery practices and technology implementation.

These memberships matter less for the credential and more for the ongoing exposure to how others are working through the same problems.

I'm also paying close attention to how AI and automation tooling is changing what's practical to scope, prototype, and validate within a project cycle — and what that shift means for the pre-sales and implementation workflow specifically.

PMI Member SCS Member

Outside Work

I have flown often, but I remember the roads.

Most of my trips start the same way — a rental car, a loose route, and no fixed plan beyond the first stop.

Across Southeast Asia, Northeast Asia, and parts of Europe, I have learned that the road reveals more than the destination ever does.

Structure exists. Just not in the way most people expect.

Contact

Get in touch

If you're building out a solutions engineering, pre-sales, or implementation function — or have a role that sits between technical delivery and commercial outcomes — I'd be glad to hear about it. Particularly interested in APAC-focused or cross-regional work.

歡迎以廣東話或普通話聯絡。

Bridging Business,Technology, and Execution