About
I'm a Technical Project Manager. Seven years at AccelByte, from technical documentation to Senior Technical Project Manager — most recently owning release and launch governance across teams that each owned their own scope. I work through cadence, evidence, and explicit trade-offs rather than formal authority, and I stay accountable for the coordination, accepted risk, and delivery result that connect the specialists' work.
My CV carries the chronology and scope; this page is about the judgment behind the work.
I am based in Indonesia (UTC+7) and available immediately for international remote opportunities or employer-supported relocation.
After leaving AccelByte in July 2026, I extended my platform experience hands-on: running live infrastructure across providers, integrating Meta, Google and marketplace advertising and search-analytics platforms, and learning how LLMs and AI operating models behave in production. I learned by building six systems, from a live AI assistant that helps small merchants turn their own connected data into decisions, through commerce and payments systems, to an internal company OS. I also went outside software — learning 3D design and CNC machining end to end, from a model to toolpaths to G-code and a cut part, and exploring where AI genuinely helps that process. I learn fastest when I cross into unfamiliar ground, and I would rather keep learning than stand still. Most of my delivery experience predates the current AI wave — which is the point: I bring the process to it.
What shaped how I work
My operating approach was earned, not issued. It comes from years of real delivery — including mistakes and misjudgments I stayed accountable for. When a release stopped behaving like the plan, I examined which evidence, assumption, or coordination gap I had missed, then changed how I ran the next one.
That maturity did not arrive all at once or through a frictionless path; it was built by carrying delivery through ambiguity, live incidents, recovery, and follow-through, and by owning the consequences along the way. What you can see in this portfolio is only a part of that — a few situations chosen so they can be shown safely and without breaching confidentiality. The fuller picture is the accumulated judgment behind them, which I'm glad to talk through directly.
How I run delivery
The work is a recurring rhythm rather than a plan document. A request arrives as intent, so the first job is to establish what it is actually for and how it ranks against work already committed. Then it gets broken down until every piece belongs to exactly one team — on a microservices platform a single feature routinely crosses more than five service teams, and that mapping is where most of the real difficulty lives.
Estimates come from the engineers who will do the work, not from a date handed down and defended. Each piece is then committed with a named owner and an expected date, and run through two-week sprints with daily standups, backlog refinement, and milestone tracking — with dependencies between teams named and followed, and a re-estimate the moment reality changes. Capacity is watched continuously so an overcommitted team surfaces during planning rather than at the end of a sprint, and status means the work was actually validated, not that development finished.
That rhythm has to hold under load: a major service release every month, near-daily hotfixes and updates, and one or two customer game launches a month each landing on its own release date. The same rhythm covers the whole range of work — a one-service change and a worldwide launch for a AAA live-service title, including its storefront, account, and entitlement surfaces — because the mechanics do not change with the size, only the ceremony does. When something slips, the evidence comes out of the standup and the sprint — what is blocked and what it would take to clear it — and that is what goes to the customer or to leadership: an honest renegotiation with a stated reason, not an apology after a date has already passed.
I have also mentored developing program and project managers — reviewing their plans, scoping, and stakeholder communication, and coaching them on running delivery rather than only reporting it. The same principle runs through all of it: I do not carry technical authority over the teams whose estimates I coordinate, so a commitment holds because the people doing the work made it and someone kept verifying it, not because anyone could compel it.