Senior Product & Engineering Delivery Leader

Alan Craig

I help organisations with complex product and technology environments deliver critical cross-team initiatives with greater confidence.

I work where strategy meets execution: creating portfolio visibility, strengthening planning and governance, intervening when important programs drift, and improving the operating systems around teams so delivery becomes easier to reason about and lead.

Sydney, Australia 0478 651 420 alancraig82@gmail.com LinkedIn Resume
Make reality visible

Portfolio confidence

Turn fragmented delivery signals into a view leaders can use to make decisions about focus, scope, capacity and risk.

Intervene when it matters

Program recovery

Reset alignment, governance and the delivery path when critical cross-team initiatives are drifting or losing clarity.

Improve the system

Operating effectiveness

Strengthen planning, delivery practices and organisational mechanisms so teams need less heroics and leaders get better signal.

Complexity between strategy and execution.

My best work tends to sit in the gaps between teams, functions and leadership layers: where priorities compete, delivery confidence is weak, ownership is blurred, or the organisation lacks the mechanisms to see what is really happening.

Critical programs are drifting. I create enough structure, visibility and decision discipline to recover direction without burying teams in process.
Leadership cannot see delivery reality. I connect scope, capacity, flow, investment and risk so executives can make earlier and better trade-offs.
The operating model creates friction. I improve planning, accountability, collaboration and recurring mechanisms so the organisation performs better without relying on individual heroics.

How that shows up in practice.

Five examples of the same leadership pattern: making complex product and technology environments easier to lead and more reliable at turning priorities into outcomes.

How confident are we that this initiative will actually land?

Cross-team initiatives were difficult to reason about from Jira alone. Leadership could see activity, but not whether scope movement, split focus and team throughput were changing the likely delivery outcome.

What I built

Waveline, an internal portfolio intelligence tool connecting roadmap progress, scope movement, probabilistic forecasting, team focus and a forward execution plan using Jira data.

What it changed

The conversation moved from reporting status to making explicit trade-offs about focus, scope and intervention before an initiative went off the rails.

Is the initiative genuinely tracking?
Where is split team focus slowing us down?
How much faster could we move with hard prioritisation?
What must land by when to preserve the plan?

Where is engineering capacity actually going?

Autonomous teams were making sensible local decisions, but leadership did not have a reliable portfolio view of where engineering time and money were actually being invested. Strategic initiatives told only part of the story.

What I built

A portfolio level investment view connecting engineering time and cost to initiatives, team allocation, Growth, Scale, Keep lights on and the valuable work that sat outside the core roadmap.

What it changed

Leadership could move from asking what teams were working on to having a much better conversation about whether capacity was aligned to the outcomes that mattered.

Are we investing enough in growth?
Are we carrying too much operational load?
Which teams are being pulled away from strategic priorities?
What valuable work is happening outside the roadmap?

Recovering a $1.5M initiative before it burned another ~$1M

A strategically important initiative spanning five engineering teams and multiple business functions was drifting toward a large delivery without a clear early customer learning milestone. I stepped in to rebuild the operating structure, narrow the scope and create a path to meaningful validation with schools.

Trajectory reset

The initiative was moving further from customer validation until the problem, governance and first learning milestone were reset.

Time Distance to customer-ready release February reset workshop problem, scope, governance and focus reset May school validation Target path Drift trajectory Recovered plan At the existing trajectory another ~$1M was likely to be spent before meaningful customer validation
Illustrative trajectory based on the program context and decisions made at the time. It shows direction of travel and the effect of the intervention, not a mathematically measured forecast.

Context

EP Create replaced a legacy content creation solution that could not scale, failed accessibility expectations and had become difficult to change. The platform was foundational because it unlocked future opportunities including Senior Exam Revision and Agentic Authoring.

As the follow-on work progressed, product direction was inconsistent, requirements shifted and teams lacked a coherent view of the problem they were solving. The initiative was trending toward a large solution without a clear early learning milestone.

What I changed

When the Head of Product asked me to step in, I rebuilt the operating structure from scratch: a clear problem statement, leading and lagging indicators, a RACI, decision and collaboration mechanisms, cross-team governance and a practical cadence for surfacing progress and trade-offs.

I introduced an all-in sprint review built around a steel thread. Teams worked toward enough shared foundation to reduce dependencies, then walked the end-to-end flow together so stakeholders could see exactly what existed, what was missing and what had to happen next.

The critical intervention

In February I brought together the product, engineering and design trio from each of the contributing teams, alongside key stakeholders including the Head of Engineering and Head of Design, to map the broader three-year ambition and identify the first customer learning milestone that actually mattered. Six large delivery elements were reduced to the two critical parts of the flow.

The goal was to validate whether AI-driven exam revision could produce credible, useful outcomes that teachers and students could trust, and whether those outcomes could positively influence learning growth.

Outcome

The initiative reached schools by May. Instead of continuing down a big-bang path and consuming substantial additional investment before customers could validate the solution, the teams aligned around a focused milestone with a clear reason to exist.

The recovery restored strategic clarity, reduced commercial risk and created a concrete point of learning for the next investment decision.

$1.5Minitiative budget
5 engineering teamsplus multiple business functions
6 → 2major solution elements narrowed to the first critical learning milestone
Maysolution reached schools for meaningful validation
The leadership move: turn a broad multi-year ambition into an executable learning path, then create enough governance and visibility for multiple teams to move together without adding bureaucracy.

Where does engineering leadership actually need to pay attention?

Engineering data existed across delivery, quality and operational systems, but individual metrics did not provide a coherent view of organisational health. The challenge was turning signals into something leadership could act on.

What I built

An engineering performance scorecard bringing flow, deployment, cycle time, quality, repository and team signals into one executive operating view, with drill-down detail behind the headline measures.

What it changed

Leadership could scan the organisation for meaningful exceptions, understand the evidence behind them and focus conversations on teams or systems that genuinely needed attention.

Where is engineering flow improving or deteriorating?
Which teams or repositories need attention?
Are quality signals supporting the delivery story?
What evidence sits behind the headline metric?

Build capable teams and create the conditions for them to succeed.

I have led delivery and quality capability directly, operated as a senior partner across an 80-person engineering organisation, and helped teams navigate complex change while strengthening planning, collaboration and delivery ownership.

80 people / 14 teamsOperating scope across portfolio delivery, capacity, alignment and engineering risk.
9 direct reportsLed Scrum Master and QA capability, developing people while supporting teams through organisational and operating-model change.
Capability developmentBuilt clearer expectations, stronger delivery practices and greater consistency across teams while adapting the model as the organisation evolved.
Cross-functional leadershipAligned product, engineering, finance, executives and distributed teams through planning, program recovery and organisational change.

Improve the system, not the heroics.

Make reality visible. Find the constraint. Create the mechanism that changes it. Push clarity down rather than control. Leave teams with a better operating system than the one you found.

The recurring pattern
1. Find what is actually limiting the system.
2. Instrument the problem so people can see it.
3. Create structure only where it adds leverage.
4. Build or automate when the existing mechanism is not good enough.

If something here sparks a thought, let's have a coffee.

0478 651 420 alancraig82@gmail.com LinkedIn