Clair de lune Claude Debussy
— How I work

My delivery framework.

Pragmatic. Agile-aware. Never dogmatic. Here's exactly how I run a project from kickoff to handover — the tools I use, the rituals I keep, and the trade-offs I make.

01

Discovery & Scoping

Days 0–3 · Before any code is written

Every project starts with one question: "what are we actually solving?" I sit with stakeholders, dig past the surface ask, and write a one-page brief everyone signs off on. No assumptions, no telephone game — what we're building, who it's for, what success looks like.

The deliverables

  • 1-page brief — problem, audience, success metrics, non-goals
  • Stakeholder map — who decides, who's consulted, who's informed
  • High-level scope — major chunks, MVP vs. nice-to-have
  • Initial risk list — what could go wrong, ranked by impact
02

Estimate & Plan

Week 1 · Get to a believable date

I break work into milestones with named owners. I ask the engineering team for honest estimates (not optimistic ones) and pad responsibly. The plan accounts for the work and the meetings, reviews, QA cycles, and contingency it takes to ship.

The deliverables

  • Project plan — milestones, deadlines, dependencies (ClickUp Gantt)
  • RACI — for any ambiguous decision area
  • Sprint cadence — usually 1- or 2-week sprints with demo at the end
  • Communication plan — daily standup, weekly written update, monthly stakeholder review
03

Execution

Sprint after sprint · The longest phase

Standups stay short and outcome-focused — "what did you finish, what's blocked, what's next." I unblock anything I can the same day. Anything I can't unblock becomes a written escalation with a proposed mitigation. Engineering doesn't wait on me to figure it out.

Day-to-day rituals

  • Daily standup — 15 min, outcome bullets, not activity logs
  • Async written updates — Slack/email, structured, scannable
  • Demo over deck — show working software, not slides about working software
  • Live ClickUp board — the board reflects reality; reality reflects the board
04

Risk & Issue Management

Continuous · An early-warning system

Every risk has a named owner, a likelihood × impact score, and either a concrete pre-emptive action or a documented contingency. I review the log weekly and escalate red items to stakeholders before they become full-blown issues. Bad news travels fast, in writing, with a proposed mitigation attached.

The framework

  • Identify — every kickoff ends with "what could go wrong?" brainstorm
  • Score — likelihood × impact, simple 1–5 scale
  • Own — every risk has a named owner, not "the team"
  • Mitigate — concrete action or documented contingency
  • Escalate — red items go to stakeholders before becoming issues
05

Communication & Reporting

Continuous · The 60-second-to-read rule

My status reports follow one rule: a busy CTO should grasp the situation in 60 seconds. Color-coded headline, done/planned/risks/asks structure, no walls of text. Plain language with clients, technical with engineers — I translate between the two without the broken-telephone game.

Report structure

  • Headline — 🟢🟡🔴 status + the one sentence that matters most
  • Done this week — outcome bullets, not activity
  • Planned next week — bullets with owners
  • Risks & issues — only what needs escalation, with mitigation
  • Asks — what I need from the reader
06

Quality & Handover

Last 10% · The phase most projects skip

Shipping isn't the same as delivering. I plan QA cycles into the schedule from day one, insist on a proper UAT signoff, and write handover docs the receiving team can actually use. The last 10% — training, runbooks, post-launch support windows — is where most projects fall apart. I treat it as a first-class deliverable.

The deliverables

  • QA test plan — what we test, who tests, exit criteria
  • UAT signoff — written, dated, with explicit go/no-go
  • Runbook — for the team supporting it after I leave
  • Training session — recorded; docs the team can reference later
  • Post-launch retro — what went well, what to do differently next time

Operating principles.

⏱

Async-first

Written updates over impromptu meetings whenever possible. Respect everyone's deep work time.

🎯

No surprise scope

Every change request gets a written impact assessment before any work starts.

🎬

Demo over deck

Show working software instead of slides about working software, every chance you get.

📣

Bad news fast

Surface problems in writing with proposed mitigation — never let them surprise stakeholders.

🌐

Plain language

No jargon when client-facing. Technical when engineer-facing. Translate between the two.

📚

Docs as leverage

Clean status reports, runbooks, and risk logs are leverage — not paperwork.

— Credentials

Certified, and always learning.

The Google Project Management certificates behind how I work — drag to spin through them, and tap the centred one to open the full PDF.

Want me to run your project?

Send me a brief — I'll come back with a 1-page scope and an honest estimate.

Send a Message View Resume →
Copied to clipboard
don't open it…