How do you prioritise CI/CD test infrastructure work against feature delivery requests from product and engineering?

Test infrastructure work is invisible until it becomes painful. The failure mode is teams tolerating a 45-minute CI pipeline or a 30% flaky test rate because the pain accumulates slowly and no single incident justifies stopping feature work.

To build the prioritisation argument, instrument your pipeline first. Measure average pipeline duration per week, flaky test failure rate, and engineer-hours spent re-running pipelines or debugging environment issues. Convert to a cost: "our pipeline takes 38 minutes — 30 engineers trigger it 3 times a day — that is 57 engineer-hours of waiting per day."

Frame improvements as deliverables with measurable outcomes: "reducing CI to under 10 minutes will save 40 engineer-hours per week and cut our cycle time from 3 days to 1.5." This language works in quarterly planning conversations.

In practice, treat CI/CD infrastructure as a first-class workstream with a dedicated capacity allocation (10–15% of QA engineering time) negotiated at the start of each planning cycle — not as reactive work done when bandwidth allows.