How I run cross-team delivery.

Fourteen situations from live-service and platform work, plus my own builds. Names are removed. Solid squares mark real projects; hollow squares are composites built from patterns I've seen many times. Why

Running Cross-Team Delivery Without Technical Authority Negotiating Scope When the Date Can't Move Owning a AAA Live-Service Delivery, End to End Keeping an Incident Moving Before the Diagnosis Is Settled Reading a Report by the Numbers — AI-Assisted, Human-Validated A Release That Went Wrong — and What I Owned

Pick a question on the left. Open the matching case →

Delivery across teams

■ Owning Platform Delivery Across Concurrent Customer Accounts Owning platform delivery across a standing portfolio of concurrent customer studio accounts, as the assigned technical producer for each account. ■ Running Cross-Team Delivery Without Technical Authority The monthly cadence that turned customer feature requests into broken-down, estimated, and timeline-committed engineering work in Jira, backed by a change-request tracking tool I built to verify each item was truly ready — reviewed, QA'd, and accounted for — before it shipped. □ Holding a Commitment Accountable Without Owning the Work A committed task starts slipping against its tracked date. The response is not a reminder or a status chase — it's finding the actual blocker, then routing the fix to whoever can move it, engineer, lead, or another team, while keeping the commitment itself visible the whole time. ■ Running Three Concurrent Projects for One Customer One customer relationship, three separate active projects running in parallel internally, each with its own scope, team, and timeline — the skill is fast, accurate context switching, not just tracking three lists.

How I run delivery

■ How I Run Delivery, From Request to Done The day-to-day operating rhythm behind cross-team delivery: how an incoming request is prioritised against what is already committed, then becomes team-level work with a real estimate, how those commitments stay visible through two-week sprints and daily standups in Jira, and how capacity conflicts and slipping dates surface early instead of at the deadline.

Dates, scope and accountability

■ Negotiating Scope When the Date Can't Move A customer needs a feature by a fixed date; engineering's honest estimate says the full feature can't get there. The product decision — which slice ships now, which waits — made openly with the customer, with the rest re-estimated rather than letting the date or the scope quietly slip. ■ Wiring a Marketplace Ad Platform into a Live Storefront A live storefront needed more than a catalog: it needed to read its own ad performance, promote products, and diagnose what was underperforming — without handing spend control to an automated system.

Releases and incidents

■ Owning a AAA Live-Service Delivery, End to End Owning delivery and integration for a AAA live-service launch, including coordinating mitigation and communication during a live issue. □ When the Launch Information Isn't Handed to You A representative launch spans hectic teams with different dependencies and timelines. When the full picture does not arrive, the release owner actively chases it before the gap can become operational risk. □ A Release That Went Wrong — and What I Owned A representative release passes every checklist, then PC players hit a live issue because a service configuration was validated only through the console path. □ Making a Platform Release Visible from Scope to Recovery A representative platform release combines local test evidence with customer usage patterns so global readiness reflects how the service is actually used—not only how teams assumed it would be used. □ Keeping an Incident Moving Before the Diagnosis Is Settled A launch-window segment degrades while diagnosis remains unsettled. The capability is maintaining decision cadence, ownership, and reversible action without allowing a hypothesis to become a fact.

Applied AI

■ Reading a Report by the Numbers — AI-Assisted, Human-Validated Using AI assistance to make operating reports — release, launch, or a customer usage read — faster and more repeatable while keeping every conclusion under human validation. ■ Turning a Small Merchant's Own Data into Decisions Small merchants already have the data they need to price and advertise better — in the platform or in third-party analytics they never opened. I designed a live assistant that reads the accounts a merchant has already connected and turns them into decisions, with the owner in control of any action. ◆ Running AI Systems With the Discipline of a Release Six AI systems built and run since July 2026, four of them live at real traffic. The interesting part is not that they use models. It is that each one needed the same things a release needs: a cost ceiling, a validation layer, an approval boundary, and an answer to what happens when the model is wrong.