How I run delivery

The operating system — the principles, cadences and artefacts I actually use to land enterprise programmes. Earned, not borrowed.

Shield the team, not just the work#

A delivery lead's job is to control what reaches the team, not just what leaves it.

Most delivery leads focus on output — velocity, quality, dates. Fewer treat incoming organisational noise as a delivery risk. Constant context-switching, surprise announcements and political turbulence kill focus as reliably as a bad dependency.

The discipline is filtering. Not hiding — the team needs to know what affects them — but deciding what arrives on their desks, when, and in what form. Early, calm communication of relevant change lets engineers adapt. Dumping every upstream anxiety on the team does not.

The cost is visibility. You absorb pressure that might otherwise distribute across the team. That requires good relationships upward and the trust that comes from having delivered. It is not a posture a new manager can fake.

In practice

Weekly: review what is coming from leadership or programme level before it reaches the team; decide what needs communicating now, what can wait and what is irrelevant noise
When organisational change is announced, brief the team in your own words before rumour does it for you — clear, factual, without editorial drama
Maintain a running list of open escalations and dependencies you are personally carrying so engineers can see you hold them, not them
In one-to-ones, ask explicitly whether anything external is distracting people — and act on what you hear

◆ Engineers at Gamma described Matt as 'great at shielding us from unnecessary noise and keeping us up to date with changes early so we could stay focused'.

Fix the problem before you fix the blame#

A blame culture is a slow delivery risk; how you respond to the first failure sets the norm for every one that follows.

When something goes wrong in delivery, there are two choices: find out what happened so it does not happen again, or find out who caused it so someone is accountable. The second feels rigorous. It is usually destructive. Engineers who expect blame hide problems. Hidden problems compound.

The practical alternative is to make the fix the first question in any post-incident conversation. What needs to happen right now? What do we need to understand to stop this recurring? That framing is not soft — it is faster and produces more usable information than a debrief organised around culpability.

Holding this line costs something when stakeholders want a name. The delivery lead takes heat so the team does not. That is the job.

In practice

After any significant incident or missed commitment, open the retrospective with 'what do we need to fix and what do we need to learn' — not 'how did this happen and who missed it'
In stakeholder reporting, own delivery problems at the function level rather than attributing them to individuals by name
When an engineer raises a problem, respond to the problem first — not to why it was not raised sooner
Track recurring issues in a visible log so the team can see that surfacing problems leads to action, not consequences

◆ Ben Churchill, Senior Software Engineer at Gamma, noted that 'the focus was always on finding a solution rather than assigning blame, which created an environment where people felt comfortable speakin

Set direction once; do not set the method#

Telling a team what to do and how to do it are two separate decisions — only the first is yours.

The most common mistake a delivery lead makes when moving from individual contributor to manager is carrying the 'how' with them. They have solved problems in a particular way for years. It feels efficient to share that. It is not — it turns experienced engineers into executors and removes the conditions under which good work actually happens.

Ownership is not a motivational concept. It changes what someone does when a problem appears at 4pm on a Friday. A team that owns their work solves it. A team that executes instructions waits for instructions. The delivery lead's job is to make the objective unambiguous and then get out of the way.

This requires trusting people before they have proved themselves to you personally, which feels like a risk. It is. It is also how you find out what the team is actually capable of — which is usually more than a controlled environment reveals.

In practice

When assigning work, state the outcome required and the constraints — timeline, dependencies, quality bar — without specifying the approach unless asked
In sprint planning and backlog refinement, ask the engineer owning the ticket to propose the approach before offering a view
Distinguish between decisions that need your sign-off and those the team can make and report back on — default to the latter
Review whether your one-to-ones are spent problem-solving on behalf of your reports or building their capability to problem-solve independently

◆ Antonina Sztyma, Software Engineer at Gamma, described Matt as 'setting clear direction, trusting people to take ownership, and creating an environment where everyone felt supported to grow while deli