Short answer. Busy counts activity; shipped means a promised user flow meets agreed acceptance conditions in the agreed environment. Pick one flow your team or vendor promised, watch it through an authorized observation and record what worked, failed or remains unchecked. Until then, treat explanations from the team, vendor and founder as claims to check—not findings. This applies to in-house and outsourced teams.
A founder sees another demo and hears another explanation. Product, engineering and the vendor may each be describing a different promise. Start by making their accounts comparable: what was agreed, when it was due, where it should work and who can accept it?
The plain first step: ask each team to name the one flow they promised, then watch it run and write down what you saw. Everything below helps you record that comparison.
This guide gives founders and CEOs a milestone–blocker–owner–evidence map to complete with product and engineering.
Define one promised flow before judging progress
Write the ordered steps and acceptance condition at each one. Record the source and date of the commitment, deadline, target environment and accepting owner. If scope is disputed, preserve the differing accounts and ask the responsible people to agree it.
For an asynchronous step, record its trigger, proof that the trigger occurred and the agreed waiting window. A mailbox check alone leaves the trigger and timing questions open. Keep downstream steps unobserved until the authorized walkthrough reaches them.
Record who chose the inputs and operated the demo. A team-led test demonstration is evidence of what happened under those conditions. Verify the release and target environment separately before reporting production behavior.
Verify account ownership and your own access separately
| Dependency | Ownership evidence | Your own authorized access | Continuity question | Next check |
|---|---|---|---|---|
| Repository/history | Account or membership record, date | Open the needed material with your granted viewer role | Who else understands the affected path? | Named administrator or technical lead |
| Hosting/deployment | Account or billing record, release locator | Approved read-only role or authorized walkthrough | Who can deploy, restore and support the release? | Named operating owner |
| Vendor contract | Authorized contract owner and source | Permitted terms relevant to this question | Who can arrange a lawful handover? | Procurement or counsel as appropriate |
Use your own granted role. Keep credentials in the existing vault and ask for an appropriate role rather than a shared login. Account ownership, access, IP rights and operating knowledge are distinct facts; counsel handles legal ownership questions.
If the account holder is leaving, use your CTO is leaving: which technical decisions have no owner.
Classify explanations by the statement and its evidence
Apply the same standard to the founder, team and vendor. Split a compound explanation into exact statements and record side, date, environment and supporting locator.
| Evidence class | What it establishes | Next useful check |
|---|---|---|
| Observed | A specific event under recorded conditions | Reproduce against the agreed acceptance condition |
| Documented | What a record, setting, notice or request says | Check whether it supports this exact delivery or causal claim |
| Asserted | A person’s account awaiting corroboration | Ask for the relevant trace, artifact or permitted observation |
| Unknown/not yet checked | Evidence or a statement is missing | Name the owner and next evidence request |
A vendor notice can document a change while a causal connection remains unresolved. An acknowledged evidence-gathering assignment establishes who owns that check; completion of the implementation needs separate evidence.
Patterns to investigate—not diagnoses
These are editorial prompts, not measured frequencies or established causes:
| What you see | Ask next |
|---|---|
| Demos change but the promised flow never passes | Were acceptance conditions written down and agreed? |
| Completed work waits | Is it waiting for review, a decision or access? |
| Many tickets, none tied to the flow | Which promised step does each item serve? |
| Product, engineering and vendor explanations differ | Which statement is observed, documented or only asserted? |
Invented example: the email condition is unmet, the cause is open
All roles, times and records here are fictional. The agreed production flow is account creation, email receipt within ten minutes, terms/plan, authorized payment and order confirmation. The waiting window is an illustrative agreement.
An authorized run shows account creation at 10:00. At 10:11 the agreed test mailbox and spam folder still lack the email. A vendor notice describes an API change; a ticket alleges that change caused the missing email. The in-house developer acknowledges the trace investigation. A founder-side terms request is unanswered, while the vendor backend lead says payment is complete and agrees to gather QA evidence. Later steps remain unobserved.
| Step | What was promised vs seen | Status of the explanation | Who checks next | What to ask for |
|---|---|---|---|---|
| B01: email | Trigger evidenced; receipt condition unmet at the cutoff | API notice documented; cause asserted | In-house developer | Event-linked dispatch/receipt trace and an authorized rerun |
| B02: terms/plan | Downstream step unobserved | Unanswered request documented; dependency on shipment unresolved | Assignment pending | Sponsor names the approver and checks the dependency |
| B03: payment | Downstream step unobserved; live charge excluded | Completion asserted; QA evidence pending | Vendor backend lead owns evidence gathering | Release/QA artifacts and an approved test route |
| B04: order confirmation | Downstream step unobserved | Completion statement not yet checked | Assignment pending | Team lead names the check owner and safe route |
The observed email mismatch stays valid while its mechanism is open. B02–B04 stay unknown rather than inheriting the email’s failure. Keep account-access and continuity findings attached to the same map. The first request is the B01 trace and authorized rerun; evidence on the other rows remains visible.
If the technical decision remains uncovered, talk with the Grand Rounds curator about relevant CTO experience.
Copy a milestone–blocker–owner–evidence record
| Field | What to record |
|---|---|
| Promise | Source/date, deadline, ordered user steps, target environment, acceptance owner |
| Observation | Trigger/window, input, observer, mode, release/environment evidence and cutoff |
| Step/dependency | Stable row ID, observed mismatch or unresolved condition, current status |
| Explanation | Exact statement, who said it, source/date, class and evidence limit |
| Access and control | Account owner, your own role, continuity dependency, evidence locator |
| Next check | Accepted responsible person, inspectable artifact, safe route, due/review date |
Choose a bounded request that could change the next decision. Ask the sponsor to assign an owner where one is missing. A generic recovery budget or rewrite proposal comes after evidence about the actual constraint.
Is the evidence enough to compare routes?
As an editorial planning heuristic, compare routes once the promised flow has a dated source, each step is observed, failed or explicitly unchecked, repository/hosting ownership and your authorized access are established for the relevant scope, and each failing row has a next-check owner. If a gap remains, investigate it rather than treating a preferred solution as a finding. If access is unavailable, compare a bounded investigation or lawful handover as options; this checklist is not a ban on considering alternatives.
The invented example still has unassigned checks on B02 and B04. By contrast, one observed fault with agreed acceptance, relevant access and a named check owner may be enough for a narrow repair decision. Once the evidence supports the comparison, compare repair, refactor and rewrite against one next-release outcome.
CTO experience in the Grand Rounds network
These checks are editorial working aids. Two network CTOs describe delivery-recovery experience in their profiles:
- Jerome MacGillivray: his profile titles his role “Fractional CTO — technology strategy, delivery recovery and engineering leadership” and lists platform recovery and vendor and technical due diligence.
- Neil Catton: his profile describes a “Get to Green” recovery of multiple SLA failures for a government client at Fujitsu.
Meet the network on the CTOs page; discuss relevant experience with the curator.
What changes the scope of outside help?
Start with your team if it can agree the promise and supply evidence. Cross-system flows, unclear vendor access and unsupported explanations may warrant senior input. The curator discusses your decision and relevant CTO experience; availability and any later working arrangement are confirmed separately. Implementation retains its own scope.
Boundaries
The map is an editorial checklist, not a validated diagnosis or legal view on ownership. The worked example is invented. Use authorized observations and permitted records; avoid live charges, destructive tests and uncontrolled customer exposure. Specialist decisions stay with their qualified owners.
Grand Rounds is an initiative of Dinarys, and a conversation may lead to cooperation with Dinarys.