TokoFood Integration

The hardest problems were not technical. When a defect crossed both organizations, who owned resolution was rarely obvious. The work was less about finding answers than making the cost of not finding them visible.

Reporting lines created a secondary complication. Teams working on the same integration reported into different organizations, which meant there was no single decision-maker who could resolve cross-team disagreements unilaterally. Escalations needed to be constructed carefully: presenting a clear picture of the situation, the options, and the tradeoffs, rather than simply surfacing a problem and waiting for a directive. Escalating well is its own skill.

One dynamic I hadn't fully anticipated: different functions needed to hear different things. Engineers needed precise defect descriptions and reproduction steps. Senior stakeholders needed risk assessments and confidence signals. PMs needed clarity on what was blocking their milestone. Writing the same status update for all audiences (which is what happens when you rely on a single shared tracker) serves none of them well.

Communicating upward required its own adjustment. As an associate-level contributor making regular direct contact with VP-level stakeholders, the most important thing I learned was that at that level, leaders are not looking for exhaustive detail. They are looking for three things: what is the situation, what is at risk, and what needs their decision or attention. Everything else is noise. Structuring communication that way (and resisting the instinct to over-explain) made those interactions substantially more effective.

The broader pattern: in complex cross-organizational initiatives, the coordination work is often harder than the technical work. Technical problems have a ground truth: you can run a test and get an answer. People problems are ambiguous, involve competing interests, and rarely have clean resolutions. The most useful thing to develop is the ability to hold that ambiguity without either forcing premature resolution or letting it drift.

The two organizations had evolved independently, which meant they had also evolved independently in how they thought about the same concepts. "Order" meant different things on each side of the integration. "Logistics" referred to different operational realities. These weren't naming conventions that could be resolved with a glossary. They reflected genuinely different domain models: different assumptions about how food delivery and marketplace commerce worked, encoded into years of independent development.

Before any defect could be triaged, before any ownership question could be resolved, the teams involved had to agree on what they were talking about. The work of establishing shared language was not a preliminary step that preceded the real work. It was the real work: or at least as important as it.

The clearest lesson from working across this boundary: in a cross-organizational integration, organizational and conceptual problems tend to arrive first in technical costume. Debugging the technical symptom without addressing the underlying model mismatch only moves the problem downstream.

The integration launched on schedule with no critical post-launch incidents. For a project of this complexity, that result was not guaranteed. It required sustained coordination across teams that had no prior working relationship and no shared process.

Rollout was intentionally gradual: Jakarta first, then expansion to major cities, then nationwide. The gateway scope held through each phase. No substantial feature iteration was required before expansion, which suggests the decision to constrain initial scope rather than attempt full feature parity was directionally correct. The order flow functioned as intended after launch. Users could discover and place food orders through the Tokopedia app, and no critical failures surfaced during rollout that would have required pulling back the feature or halting expansion.

I don't have post-launch metrics I can cite from this project. My role ended at launch, and I didn't have visibility into the product analytics that followed.

If I had been defining success criteria, I would have tracked three things: total orders placed through the integrated experience, as the primary adoption signal; order completion rate, as the clearest proxy for reliability and user trust; and complaint ticket volume related to the food ordering flow, as an early warning signal for experience failures the team hadn't anticipated. Together, these answer the question that actually matters: are users successfully ordering food through our app, and are they running into problems when they do? The first two measure whether the integration worked. The third measures how well it worked at the edges.

The absence of metrics here is a real limitation of this case study, and I'd rather acknowledge it directly than work around it. What I can say is that the gradual rollout proceeded without reversal, and the initial scope proved sufficient to support nationwide expansion. For a first integration across two post-merger organizations, that is a meaningful signal: even without numbers attached to it.