Align ‘Done’ Across Teams to Prevent Last‑Minute Surprises on Shared Goals

When we routed perpetuals through Hyperliquid via builder codes, the single artifact that prevented late surprises was a pass/fail integration acceptance checklist written before the first API call ever happened. Not documentation. Not meetings. A checklist with binary outcomes.

We built Nika as a consumer application that routes specialized infrastructure to partners rather than building everything in-house. Hyperliquid ships the matching engine for perpetuals. Polymarket ships prediction market inventory and resolution. We ship the interface, the wallet, the cross-chain plumbing, and the AI layer that ties it all together. This model works only if handoffs are clean.

The checklist had three columns: integration point, acceptance criteria, pass/fail. Each line was a specific user action or system state, defined before the integration work began. “User opens a long position on ETH-PERP using NikaAI natural language input” is not an acceptance criterion. “User opens a long position on ETH-PERP using NikaAI natural language input, position reflects on Hyperliquid’s order book within 200ms, user receives confirmation in-app with position ID matching Hyperliquid’s ID” is an acceptance criterion. The difference is testability.

The rule we followed: if the person receiving the handoff cannot run the test without asking a question, the criterion is not specific enough. Questions during testing mean the agreement was written at the wrong altitude. We caught this early because our team is three people. When the person who wrote the integration spec is also the person testing it, vague criteria fail immediately.

What saved us multiple times was treating partial passes as fails. If nine out of ten criteria passed, we did not ship. Partial delivery compounds. The integration partner thinks they are done. You think you are almost done. Two weeks later, the tenth item is blocking mobile launch and both teams have moved on. Binary outcomes prevent drift.

The late surprises we avoided: wallet state mismatches after failed transactions, position size rounding errors at the API boundary, biometric re-authentication breaking mid-session when the app backgrounded. Every one of those would have surfaced in production if we had treated “mostly works” as sufficient during handoff.

TKEG Expat is a corporate-services firm that manages 112 companies across 20 jurisdictions as of May 2026, and the definition of “done” is never written by the team doing the work. It is written by whichever outside authority has to accept the output.

Our compliance stage cannot be called done just because the file looks complete internally. Article 14(1) of Directive (EU) 2015/849 stays operative until 10 July 2027, when Article 77 of Directive (EU) 2024/1640 repeals it. And from that same date, Article 23(1) of Regulation (EU) 2024/1624 restates the same timing rule: verification of the customer and the beneficial owner takes place before the business relationship is established, lower-risk postponement aside. Therefore, the gate is a date fixed in a statute, instead of a date agreed in a meeting.

The single agreement is one line, and I believe it is the only one worth having: each handoff must produce the artifact the receiving authority accepts, in the version in force on the day it is filed. Our compliance stage hands its file to the incorporation stage, which checks the form version before it accepts the file. For example, Ireland’s Form A1 currently is the version substituted by the Companies Act 2014 (Forms) Regulations 2023, in operation since 11 June 2023.

Most of the time, a late surprise is a team that marked its part complete against a form or a standard that was already superseded, and the version-in-force line catches that at the handoff instead of the filing counter.

One agreement that consistently prevented late surprises was a shared failure forecast completed before the first handoff. Most teams align on what success should look like, but few align on how failure is likely to appear in the next department. That gap creates avoidable friction. The forecast forced every team to list the three most probable breakdowns their work could cause downstream and how those risks would be detected early.

I have seen this create a very different level of ownership. Instead of protecting departmental speed, teams begin protecting the full chain of delivery. The practical checklist included warning signs, validation steps, fallback actions, and named owners. That made done far more honest because it included not only readiness, but operational consequences.

We have found that teams align faster when done means decision readiness rather than task completion. In cross-functional work, a handoff is successful only when the next team can make a confident decision soon after receiving it. This means the work should answer the obvious questions before they are asked. When teams understand this standard, they stop sending half-finished thinking that only looks complete.

To make this practical, we use a pre-handoff review with one simple rule. The receiving team must explain the work back in their own words. If they cannot explain it clearly, the work is not ready yet. This simple step reveals missing context, unclear language, and hidden assumptions early and has been more useful than long status meetings.

Our version of a handoff is a clinical handover, and the agreement that worked is that done gets defined by whoever picks the work up, not by whoever puts it down.

Left to the person finishing, done means I have written my note. To the person receiving, done means I can act on this without having to come and find you. Those are different amounts of work, and the gap between them is where things get dropped.

So the handover checklist is written by the receiving side. It is short, because a long one gets skimmed and turns into a ritual: what was found, what is outstanding, who is chasing it, and by when. If any line is blank, it has not been handed over yet.

Callbacks caused by unclear handovers fell 46% in the year after we did that, and the share of those reaching me personally fell further.

The part that took getting used to is that this lets a more junior person say not yet to somebody senior. That is the point of agreeing it in advance. Saying not yet becomes a reference to a shared document rather than a challenge to a person.

We once had a handover where outstanding meant awaiting a result to one clinician and awaiting a phone call to another. Both readings were reasonable. Only one had anybody doing anything.

Done means a checklist, not a feeling. Our crews follow a written, room-by-room list for every turnover, and the published version runs 113 tasks for a standard clean, more for bigger units. Each room needs a before-and-after photo before it counts as finished. That checklist is the agreement, not a meeting where everyone nods at ‘guest ready’ and pictures something different for the bathroom than for the kitchen. The photo either exists for that room or it doesn’t, so nothing gets argued about after the fact. Rooms get worked in a fixed order too. The next room doesn’t start until the current one is checked off and photographed. That’s what stops the surprise everyone dreads: two people each assuming the other covered something, and it only shows up at the final walkthrough. The setup I keep running into without this is teams agreeing on the big goal in a meeting and skipping the room-level detail completely. A single page with a task count and a photo requirement per room does more for alignment than another status call.

We use a Closing-Ready Deal File checklist so there is no question about what done means. It holds the contracts, disclosures, payoffs, and title work. I’ve found this stops those annoying surprises that pop up after handoff, especially when working remotely. You catch the missing stuff before it turns into a delay. Honestly, if you want this to run well, just build the checklist into your workflow tool so everyone can see where things stand.

“Done” means something different to every team, and no checklist fixes that until each team says it out loud.

We all saw the typical case where everyone said the checklist was fine, yet nobody had actually agreed on what the word “done” meant. That was the discovery that changed how I run this now. Design calls something done when it’s approved. Engineering calls it done when it’s merged. The team building on top of it calls it done when it meets a target nobody had shared with the other two.

The single practice I rely on isn’t a checklist. It’s a one-sentence rule. Before any shared goal starts, every team says out loud, together, what “done” means to them, and who owns getting there. If two definitions clash, we fix it in five minutes, not during delivery. Left unaddressed, that same mismatch becomes rework and a missed date, because on paper, every team had technically finished their part, and nobody was actually responsible for the gap between them.

We used a shared doc in the last days at Acquire.com – a “done” spec. It contained the owners, listed who needed to sign off and had a draft e-mail to the customer. It allowed us to see the things missing almost two weeks in advance, but it wasn’t till after several failed attempts that we had the thing that stopped us running around in panic.

At Truly Tough Contractors we used a Build-Ready Package checklist before handing off projects. Requiring a signed scope, permit updates, and CRM notes stopped the usual chaos. The teams knew the job inside out. Whenever a surprise popped up we just added it to the list. It made the handoffs much smoother because everyone finally agreed on what finished actually looked like.

In international manufacturing, I’ve seen shipments get held up for weeks because of a missing certificate or wrong label. It’s incredibly frustrating. So now at Haizol, we have a simple rule: before anything leaves the factory, we get the packing list, all certifications, and photos of the labeled boxes. It doesn’t solve every problem, but it stops the preventable disasters at the border.