Last issue was the least exciting project I've ever been part of: thirty years of spreadsheets, turned into twelve million dollars. This one is the strangest.

I used a video game to save a former employer, an insurance company, eight hundred thousand dollars.

Not gamification. Not a training simulator dressed up to look like one. An actual, unmodified consumer video game, Second Life, repurposed as the place a distributed team did real work.

The Problem Nobody Had a Tool For Yet

This was the early days of Skype, years before Teams existed or even Slack, while SharePoint was still finding its footing. "Remote collaboration" wasn't a category yet. It was whatever you could improvise or best do, given the circumstances.

The project had development teams in India and the United States, business analysts on the West Coast, and project team members on both the East Coast and in Illinois. Four time zones, minimum. The plan was follow-the-sun development: work handed from one region to the next as each day ended, picked back up the next morning further along than it was left.

Doing that well means the work never actually stops. Doing it the way most projects still try. A status email, a shared drive nobody opens until their own morning starts, a meeting half the team is asleep for — means most of what one region learned gets rediscovered by the next one instead of handed to it.

What We Built Inside a Video Game

We built an island.

Second Life let you create a persistent, shared space and just occupy it, so that's what we used it for. On the island: a workboard where questions, answers, and project documentation lived in the open, so anyone logging on at the start of their day could see exactly what the last region had asked, answered, or flagged. And a communication board, because half the team couldn't attend a live meeting at 9 a.m. Pacific if it was already 9:30 p.m. in Bangalore. Meeting notes and action items got posted in-world, so everyone knew status, ownership, and what had already shipped, whether or not they'd been in the room.

Nobody had to wait for someone else's morning to find out where things stood. The status was just there, posted where the next shift would see it whether or not anyone was awake to explain it in person.

It Wasn't Only a Workboard

The island had a second purpose, and I don't think the first one works as well without it. People could walk around, build things, decorate a space, experiment, goof around between handoffs — step out of the usual mechanics of a status meeting or a ticket queue and just be somewhere else, together, for a few minutes, while the work still moved forward underneath it.

That wasn't a private taste. Other project managers heard about it and wanted the same setup for their own teams.

What It Was Worth

The project manager estimated the approach saved roughly $800,000 (his own read) on what the project would have cost additionally without that kind of always-on visibility across four time zones, against the rework, delay, and duplicated effort follow-the-sun development produces when the handoff depends on a status deck nobody has time to read.

I want to be precise about what that number is: one experienced PM's estimate, not an audited figure. I have no reason to doubt it. At that scale and spread, the alternative is expensive in exactly the ways that are hard to see until you've fixed them. But it's his number, not mine, and I'm stating it the way he gave it to me.

This Never Made It Into a Case Study Anywhere

We ran it for two to three years. It worked well enough, and was liked well enough, that demand for it grew past the original project — other PMs wanted their teams on the island too.

Then it wasn't funded for another year and the team moved on to whatever came next.

Nobody decided it had failed. Nobody wrote up why it stopped. That's a smaller, more common ending than a dramatic one:

A thing that's working and wanted loses its budget line anyway.

Here's my honest read on why, for this one specifically: insurance is a comfort-test industry by design. The whole business runs on pricing risk precisely, which means "we've never done this before" isn't a gap to close, it's usually treated as a warning, on purpose. That instinct is right more often than it's wrong, and it's a real part of why the industry keeps standing through things that take out companies built on faster, looser judgment. But it also means something genuinely new gets judged on how familiar it feels almost as much as on how well it performs. A virtual island inside a video game never stopped feeling new, no matter how many quarters it kept working and in a shop built to price unfamiliarity as risk, "new" and "risky" get treated the same way long after the evidence says otherwise. Going with what's known instead of what might be better isn't a failure of imagination so much as the job being done exactly as designed. It's just a job that doesn't leave much room for something like this to graduate from "interesting experiment" to "line item we keep."

It's issue #11's kill-authority problem run in reverse. That issue was about projects nobody could kill even though they should have died; this one died without anyone deciding to kill it, despite working and being asked for.

I'll admit the demo probably didn't help either. A work meeting where everyone's a cartoon avatar is an easy thing to laugh at and a hard thing to put in a budget deck next to a vendor roadmap slide. But the comfort-test explanation is the one I actually believe; the demo is just the version of it that's easiest to joke about. What I know for certain is narrower: it worked, people wanted more of it, and it still didn't survive the next budget cycle. That gap, between what works and what gets renewed, is the part worth sitting with.

What Can't Be Ignored

Right now the default answer to "how do we fix collaboration or handoffs" is to buy the newest platform built for exactly that, ideally with AI in the name. Every serious pitch for one of those platforms optimizes for the same things (tell me if you heard this before): fewer clicks, faster handoffs, better search. None of them are pitched on the thing that may have mattered just as much on that island, a place where people could be somewhere else together for a few minutes, a little silly and low-stakes, and still get the work done. We've built more efficient tools since. I'm not sure we've built better places, and I don't think anyone's buying a platform to fix that, because it's not the kind of thing a business case is built to capture.

And even a good tool needs a budget line every year, not just a working version of itself. This one had both, for a while. It worked, other teams wanted in, and it still lost the argument for the next year's money, not to a better alternative but to how unfamiliar it still felt after years of working.

Working and feeling familiar turned out to be two different tests.

Worth knowing which one whatever you're running today has actually passed.

The Test

Before you fund the polished, defensible version of a collaboration fix: what's the unglamorous (maybe outright embarrassing) tool already sitting in front of you that would solve this today, if you were willing to be laughed at for using it?

And if you already have one that's working: has it passed the comfort test yet, or only the results test? Those aren't the same review, and in a lot of shops only one of them actually decides the budget.

Plant Floor to Cloud goes out every Tuesday. A monthly companion podcast comes later in the month. Same charter, more room to think out loud.

What have you repurposed that worked better than the thing you were supposed to buy instead — and is it still around? Reply, I read every one.

Reply

Avatar

or to participate