Skip to content
, Home

Quality & Engineering Leadership

CI/CD
that tells your team quickly whether a change is safe to ship.

CI/CD covers the pipelines and feedback loops that tell your team quickly whether a change is safe to ship. It matters when slow pipelines or red builds nobody trusts make changes harder to release.

Discuss quality and deliverySee the full offer

The real question

How much is caught before it is written, not after it is merged.

From the Quality Maturity AssessmentDevelopment & Delivery Practices

01Questions

The questions
it answers.

  • How long does a change wait for an answer?

    You can see where the time goes between a commit and its result, and which wait to remove first.

  • Is a red build information or noise?

    A failed run is trusted to mean the change is wrong, not re-run until it passes.

  • How far is what you tested from what you ship?

    The pipeline tests the thing it releases, in environments consistent enough to trust.

  • Which gates earn their place?

    Each pipeline gate and manual step has a reason to stay; the others move earlier or are removed.

02Approach

How I work
on it.

  1. Map the path from commit to release

    I follow a change through the pipeline with your team and note where it waits, where it fails and what is still checked by hand.

  2. Order the fixes by impact and effort

    I rank the fixes by how much waiting and noise each one removes against the effort it takes, and agree the order with your team.

  3. Change the pipeline in visible steps

    I work with your engineers on the agreed changes in small steps, measuring feedback speed and test reliability as each one lands.

What you leave with

  • A map of the pipeline showing where changes wait, where they fail and what is still checked by hand.
  • A list of pipeline improvements, ordered by impact and effort.
  • Agreed changes to the pipeline and its feedback loops, made with your engineers.
  • Measures of feedback speed and test reliability that your team keeps.

03Evidence

The topic,
in practice.

From my employment: a case study that measured where each change’s time went between commit and release, and QA’s work so far on the tests a green build depends on. It keeps what changed apart from what is still planned.

Case studies

  • Clearing the way for a release train at an AI-native language-technology platform.

    Every hour from first commit to production was classified by whether anyone was working on the change, and most of it was waiting. The first results are in the tests a green build depends on: Playwright runs are now measured on whether they pass without a retry; the share that does has roughly doubled, though changes to the shared test environment likely did much of the work.

Where it sits in the assessment.

The Quality Maturity Assessment scores nine dimensions. These are the ones this work moves.

Open the assessment

The other topics.

  • Quality strategyWhat quality means for your product, who owns it, and how “good enough to ship” gets decided.
  • Organisational maturityWhere the organisation stands across nine dimensions, and which one is setting the ceiling.
  • Test architectureTesting designed around your product’s risks and system boundaries, so a green build says what is safe to release.
  • Release confidenceA release decision that can point to what was verified and what was not.
  • Fractional leadershipSustained direction across quality and delivery, without a full-time hire.

Want to improve reliability
and delivery?

Describe the team, the pipeline and what is getting in the way.

Discuss quality and delivery