Tokyo to Saigon — The Only Way Out of a Death March

Stories about starting a company in Vietnam are usually told with the excitement of the beginning. One message that crossed the sea, meeting a team of six science-major guys, feeling our way through days with no work yet — I wrote all of that in “It Started with One Message.”

But the thing I learned most from those days in Vietnam wasn’t how to begin. It was how to decide where to stop, and what to end. What pressed that on me was the local project I’m about to describe.

The third local project

The company had tripled in size, but three times the work hadn’t followed. In both Japan and Vietnam, I spent my days chasing new projects where we could show what we were capable of.

In that stretch, an inquiry came to the Vietnam side through a friend of one of our members. We’d actually had two local inquiries before: one where our estimate didn’t fit and the thread went quiet, and one where, during the discovery calls, we agreed it made more sense to test Product Market Fit some other way before building a system — so it never became a contract. Would the third time be the charm?

The client was a retailer with stores all across Vietnam. Hector’s first meeting went well, and from there the exchange moved to a Zalo group. They let me into it, but the Vietnamese messages flew by too fast to follow. Seeing “Cảm ơn anh” (thank you) and heart marks fly around, I figured things were heading in a good direction, and I watched from the side.

And that is exactly where the trap was set.

At first, Hector’s team had proposed starting small — building only the piece that solved the client’s single biggest pain. But somewhere in the Zalo back-and-forth, it was the client who got excited. The scope kept swelling. By the time requirements settled after three or four weeks of meetings, that first “one small feature” had become a year-long, build-everything-from-scratch system — front end, back end, and infrastructure all included.

The orange quote

The hard part of the estimate was the price. Neither Hector nor I had any feel for the going rate in Vietnam. I’d worked with overseas clients before, but never taken on a Vietnamese client. I calculated the fee carefully, feeling my way, printed it, stamped the company seal, scanned it, and sent it to Hector.

“It’s a bit dark,” he replied. Thinking the scan was underexposed, I asked, “If I lighten it more, the table headers get hard to read — is that okay?” He came back with: “Can you use orange?” …The color was dark?

It turned out he didn’t mean the scan quality — he meant the gray header row of the quote looked drab. Vietnam’s formal invoices (the “red invoice”) carry patterns and yellows, with the flourish of a Japanese certificate of merit. Next to that, my quote really was too plain. I hurriedly changed the header background to orange and resent it. “Much better.” Cultural difference lives in details like these.

When the estimate was approved, the Japan team — half-expecting it wouldn’t convert this time either — was surprised. For the contract, we started from the bilingual Japanese–Vietnamese development agreement Hector and I had once labored to create. Vietnamese people really do read contracts closely. The haggling over post-release support terms went on and on.

Then, at the signing stage, another piece of “Vietnam” appeared. The commission. There’s a custom of paying 1% of the deal to whoever introduced the client — and naturally, that person expects it. It reminded me: a friend who now runs a 1,500-person development company used to say, in his early days, every time we met, “If you introduce me to a good client, I’ll pay you a share of the revenue.” That wasn’t an exaggeration or mere politeness — it was Vietnamese business custom itself.

My aim in taking this project was less about revenue than about building connections in Vietnam. Paying the commission might bring another introduction, another thread. We decided to pay, in keeping with the custom.

Double

But the project, once it started, simply would not go well.

Even pouring in far more people than planned, we couldn’t hit the monthly milestones. When I dug in, I found the work was going to take more than double the original estimate.

Fifteen years in, I still misjudge estimates sometimes. But I’d never seen the real effort come in at more than double. A single iPhone app, you can somehow finish even at double. But a year-long system — front end, back end, infrastructure all from scratch — at double the effort, covering the gap out of our own pocket is nearly impossible.

Let me be honest: the fault was partly mine. The client only spoke Vietnamese, so I’d left the whole exchange to the team on the ground. That was the mistake. Had I been in the middle, I might have put a brake on while the scope was still ballooning.

“The only way out is to cut features to the bone”

At that moment, a line from a university professor came back to me.

As an undergraduate, I was in a software engineering lab. Software engineering isn’t the craft of building itself, like programming — it’s the discipline one level up: requirements, effort estimation, quality management, the meta-view of how software gets built.

The professor whose lab I chose was the only one in the department without a doctorate or even a master’s — someone who had come up through the field. He’d been through many enormous projects at NEC, where the very best computer engineers in Japan gathered at the time, and he had wisdom no one else did. Back then I only wanted to learn the craft of building, so I didn’t really listen. I don’t remember much.

But one thing has stayed in my head ever since:

When a software development project turns into a death march, the only way out is to cut features to the absolute bone.

Adding people, adding budget, pushing back the schedule — none of it gets you out. The only road out is to cut. The local project in Vietnam was exactly the situation he’d described.

Can’t cut

I told the Vietnam team: tell the client the problem openly. Talk it through, thoroughly, to find anything we could cut from the spec. And I passed along the professor’s theory, too.

A week later, nothing had improved. The answer came back: “There’s nothing more we can cut.”

Cutting a spec is, surprisingly, a creative act. With imagination you find unexpected alternatives that slash implementation cost to a fraction. But it needs the client’s help. Among the things the maker is convinced are “absolutely necessary,” there is often a “this would actually be fine too” — and that alternative frequently comes from the client’s side. If trust is there, and you can borrow the client’s imagination, you can reach it. This time, that wasn’t the situation.

Next, I asked them to keep discussing cuts while negotiating a higher fee. A while later, a report came back: “We proposed doubling the fee and doubling the schedule.”

Doubling the schedule is a bad move. It’s exactly what the professor meant by “extending the timeline won’t get you out.” I advised keeping the schedule as is, but the reply was, “The engineers are tired, so it’s better to have twice the time.” I had a bad feeling.

Then the client’s answer arrived: “The schedule can double, but keep the budget the same.” It got worse.

The decision

Two years of a death march would sink the company.

So I decided. Negotiate to have the project canceled.

It was only two and a half months in. If it has to end anyway, sooner means less damage to both sides. Charging on doesn’t only hurt the maker. Being forced to build double the scope for the original budget may look like a bargain for the client, but in reality the schedule, the quality, the maintainability and extensibility all collapse. Their requirements and acceptance work double, too. It’s a loss for everyone.

Deciding to stop isn’t running away. It’s the judgment that tears both parties free of a death march — a future in which no one is happy.

The reckoning

Some days later, at my regular craft beer spot in Ho Chi Minh City, I ran into the man who’d introduced the project — TH. At a dinner the night before, the talk had turned to the canceled project, and when I said out loud that I felt bad toward him, one of our members invited him along.

We ordered beers first, and after a toast I brought it up: “I’m sorry we couldn’t pull it off.”

TH, with a slightly sad, frustrated look, began slowly. “What those people originally wanted was a very small system. I can’t understand how it grew so big.”

He was right. What I’d first heard from Hector was less a system than “one feature of a system.” After that first face-to-face meeting, it had swelled and swelled in the heat of Zalo. TH said: all they’d needed was that small thing; the rest was already fine as it was. Couldn’t we have held the requirements down to that?

Hearing it, I regretted it even more. If only I had been right there in the middle from the very start. Leaving it all to the local side, on the excuse of the language barrier — that was the real reason the runaway scope was never stopped.

To finish is to know where to end

Stories about new ventures overflow with how to begin. But after a long time building products, the part I find genuinely hard isn’t starting. It’s deciding where to cut, what to end, and what to keep.

The power to carry an idea through to completion is inseparable from the power to decide what not to build. When scope threatens to swell, get in the middle and put on the brake. When a death march looms, cut the spec before it starts. If it still can’t be cut, don’t take it — or take only the prototype and step away. And even once it’s running: end it before it collapses.

We can be “a company that finishes” not because we grind our way through to the end on sheer willpower. It’s because we know where to stop. Our days in Vietnam pressed that truth on me all over again.

— This local-project story actually has more to it. Some time after the reckoning, that man TH comes back with another proposal. I intend to write how it all turned out before long.