How I run delivery

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

Written from my own programmes — each one earned somewhere, most of them the hard way.

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

Ownership transfers motivation; tasks do not#

Giving engineers genuine ownership — not assigned tasks — is what separates a high-performing squad from a compliant one.

Most delivery leads confuse delegating work with giving ownership. Delegating a task leaves the person executing it; giving ownership leaves them accountable, invested, and motivated to find a better way. The distinction sounds philosophical but it shows up immediately in output quality and problem-solving behaviour.

The weaker approach is to hand down tickets and check they are completed. The stronger approach is to be clear on the outcome, back the individual publicly, and then get out of the way. Engineers who feel trusted do not wait to be told what to do next — they anticipate, they flag early, they care.

This costs the delivery lead something real: the comfort of control. You will not always know the detail of how work is progressing. That discomfort is the point. It is the price of a team that delivers without being pushed.

In practice

In sprint planning, assign outcomes to individuals, not just tickets — make clear what done looks like and why it matters
When an engineer raises a blocker, ask what they think the solution is before offering your own
In 1-to-1s, ask explicitly what decisions they want to make themselves this week and confirm you will back them
When something goes well, name the individual in stakeholder updates — make their ownership visible upward

Engineers at Gamma described feeling 'always backing your corner' and that Matt 'gave us ownership over our work instead of micromanaging, which made a big difference.'

Ways of working must outlast your presence#

If the team's processes depend on you being in the room, you have built a dependency, not a foundation.

A delivery manager who is indispensable has failed at one of the most important parts of the job. The test of good ways of working is not whether they function while you are there — it is whether they hold after you leave. That requires building structures and culture that belong to the team, not to you personally.

This means introducing process without being prescriptive about it. The team needs to understand why a ritual or standard exists, not just comply because you said so. When people understand the purpose, they maintain and evolve the practice themselves. When they do not, it collapses the moment you stop enforcing it.

The practical cost is that you have to resist the urge to be the answer to everything. Let the team resolve their own conflicts. Let them iterate the retrospective format. Let them own the definition of done. Your job is to create the conditions, not to be the conditions.

In practice

Document ways of working in a team-owned space from day one — not your personal notes, their shared wiki
Run retrospectives in a way that generates team-owned actions, not actions for you to carry
When you introduce a new process, explain the reasoning explicitly so the team can evolve it without you
Periodically step back from facilitating a ceremony and let a team member run it

At CAVU, 'the processes, team culture, and ways of working that he helped put in place have had a lasting impact, and many of them remain in use today' — after his tenure ended.

Communicate change early; silence is not protection#

Withholding organisational changes from your team to protect their focus is a mistake — early, honest communication is what keeps them steady.

Many delivery leads believe that keeping the team insulated from uncertainty means not telling them about it. This is wrong. People sense when something is being held back. The rumour that fills the information gap is almost always worse than the reality, and the trust lost when they find out you knew is very hard to rebuild.

The correct version of shielding the team is selective, not total. Irrelevant noise — politics, reorganisations that do not affect them, senior posturing — does not need to reach the team. But changes that could affect their work, their priorities, or their environment should arrive from you first, with context, before they hear it elsewhere.

Telling people early, even when the news is incomplete, gives them time to process and adapt. It also signals that you respect their ability to handle reality. That signal builds the kind of trust that makes a team functional under pressure.

In practice

In the weekly team update, include a short 'on the radar' section — things you are watching that may affect them, shared early
When a stakeholder decision is pending that could shift priorities, brief the team before the outcome is confirmed — not after
Be explicit about what you are actively filtering out and why — transparency about the filter itself builds trust
After any significant organisational announcement, hold a short open session for questions before assumptions calcify

Ben Churchill noted Matt was 'great at shielding us from unnecessary noise and keeping us up to date with changes early so we could stay focused.'

Psychological safety is a delivery mechanism, not a nicety#

Teams that do not feel safe to speak up surface problems late; late problems cost more than early ones, always.

Psychological safety is often framed as a wellbeing concern. That framing undersells it and means it gets deprioritised when delivery pressure rises — exactly when it matters most. The delivery case is simple: if engineers are reluctant to flag a problem, you find out about it in a sprint review or a production incident rather than a stand-up. The cost of late discovery is almost always higher.

Creating safety requires consistent, visible behaviour from the delivery lead. A blame-free response to one incident is not enough — the team watches what happens the next time, and the time after that. The pattern has to hold under pressure, because that is when the temptation to look for someone to blame is strongest.

The practical upside is that teams with genuine psychological safety are faster. Issues surface in hours rather than days. People ask for help before they are blocked rather than after. Decisions get made with better information because no one is filtering what they say.

In practice

When a problem is raised in stand-up, respond with 'what do we need to resolve this?' before anything else — model the behaviour publicly
After a production issue or missed commitment, run a blameless retrospective and document it — make the artefact visible
In 1-to-1s, ask explicitly 'is there anything you have been hesitant to raise?' on a regular cadence
When someone flags a risk early, thank them in front of the team — reinforce the behaviour you want to see more of

Ben Churchill noted that the blame-free approach 'created an environment where people felt comfortable speaking up and working together to fix things.'

Stakeholder credibility is built by communication, not delivery alone#

Delivering the work is not enough — stakeholders at every level need a communication style matched to what they actually care about.

A common mistake among technically strong delivery leads is assuming that good outcomes speak for themselves. They do not. Stakeholders who are not kept appropriately informed lose confidence even when delivery is on track. Credibility is built through consistent, well-calibrated communication — not through the work alone.

The calibration is the hard part. A senior executive needs a different conversation to a product owner or an engineering lead. The failure mode is applying one mode to everyone: either over-explaining to people who want the headline, or under-explaining to people who need the context. Both damage the relationship.

This also means being equally visible when things are difficult. Stakeholders who only hear from you when things are good stop trusting your updates. The delivery lead who brings bad news clearly and with a plan is far more credible than one who goes quiet or softens problems until they cannot be ignored.

In practice

Prepare a one-paragraph stakeholder summary each week — written for a reader with no context, covering status, risk and next decision required
Know explicitly which stakeholders want data, which want narrative, and which want the single bottom line — and write to that
When a commitment is at risk, communicate it before it is missed, not after — include what you are doing about it
After major milestones, share a short written update proactively rather than waiting to be asked

Colleagues consistently noted the ability to 'deal well with stakeholders at all levels' and to 'bring stakeholders together,' with this cited independently across multiple organisations and roles.