About
I'm a Release & Launch Manager for games and live-service platforms. What I own is the
delivery system around a launch — planning, cross-team coordination, evidence, accepted risk,
ownership, and recovery options — not the engineering my teams do. The heart of the work is
turning incomplete technical and operational signals into an accountable decision: what ships,
under what conditions, and who owns what if it has to move.
My CV carries the chronology and scope; this page is about the part a résumé can't — the
judgment behind the work, and how it was earned.
I am based in Indonesia (UTC+7), available for international remote opportunities, and open
to employer-supported relocation.
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.
Evidence and ownership
How this portfolio was made
- What kind of evidence are these cases?
- Professional experience — anonymized cases are real work, generalized
to protect confidentiality and NDA obligations. Representative capability case
entries are built from recurring real patterns and demonstrate a repeatable operating
pattern.
The provenance label on every case tells you which kind you are reading.
- How do you actually use AI?
-
I adopted AI tools recently and deliberately — most of my delivery experience predates
them, so this is a speed tool, not something I depend on. I use it to organize operating
data and prepare a structured first pass, then manually cross-check the result against
source evidence. I have caught an AI-assisted step returning wrong data even after a
strong prompt. AI accelerates the work; it does not make the decision, relax the
validation standard, or own the call.
- Did AI build this site for you?
-
The concept and the standards are mine — capability selection, evidence model, scenario
logic, information architecture, confidentiality boundaries, and acceptance criteria. I
then used AI deliberately to build it: research, drafting, design iteration, and
implementation, directed and reviewed by me throughout. AI did much of the construction;
the idea, the direction, and the accountable review did not. This site is itself an
example of how I direct AI, validate the output, and own the result.
- What do the cases prove?
-
They show how I structure delivery ownership, release judgment, evidence, communication,
and recovery choices. They do not claim invented metrics, customer endorsement, or
hands-on engineering work that belongs to the teams I coordinated.
- How do you stay accountable for what ships?
-
I stay with the work through delivery: make the decision boundary clear, validate the
evidence behind it, keep owners and recovery conditions visible, and follow the outcome
after release. Specialists own their technical work; I remain accountable for the
coordination, accepted risk, communication, and delivery result that connect it.