Case study. I designed the platform and set the standard; the tech leads made it stick and the teams wrote the tests.
The situation
The signals about how work was moving existed, but they were spread across Azure DevOps and GitHub. Answering a basic question about delivery health meant assembling it by hand, so decisions leaned on whoever sounded most confident.
What I did
I designed and built an internal engineering intelligence platform. It combines Azure DevOps and GitHub signals to show sprint delivery, release quality, pull-request movement, blocked work, feature progress, QA automation coverage and code promotion status. Teams use it routinely.
The first finding that mattered was uneven quality at handoff: some teams passed QA and user acceptance testing cleanly, and others did not. So I set one specific standard. Before work goes to QA, developers provide proof of validation suited to the change: new unit tests with a passing report, a new Playwright test that passes, or a short demonstration.
A rule only lasts if someone owns it. I announced it myself at an all-hands meeting, made each tech lead accountable for adoption in their team, and followed up to ensure progress was being made.
What changed
The product teams in my organization adopted the standard, and fewer tickets are failing QA and acceptance testing.
What I would carry forward
Build the instrument before you mandate anything. Let the evidence show where the problem is, make one specific ask, and follow it until it sticks.
Related: DORA metrics · Goodhart’s Law