Start where it matters and the risk is small.
The teams that get value quickly do not pick the most impressive task. They pick work that genuinely needs doing, that a person would otherwise do, where a mistake costs a rejected pull request rather than an incident.
Backlog and maintenance
Bugs, dependency upgrades, flaky tests, deprecation warnings. The work that genuinely needs doing and never makes it into a sprint.
Read →Code review
A reviewer on every pull request that has read the codebase, run the tests, and can point at the caller it would break.
Read →Production support
The alerts that fire, get acknowledged and never get investigated. It looks into them and writes up what it found.
Read →It is not only for code.
Everything on this page applies just as well to recurring operations work, reporting, reconciliations and research: anything with a real definition of done, consequential actions, and somebody who has to approve them.
We started with engineering because it is the hardest version of the problem. It needs a working environment, it has a genuinely dangerous action at the end, and the result is objectively checkable. The tests pass or they do not.
If your hardest approval-heavy workflow lives outside the codebase, that is a conversation worth having early. We would rather choose the next area with a customer than guess.
See Nova run on your own code.
A working session rather than a slide deck. Bring a repository and a ticket you would otherwise assign to someone, and watch it go from the ticket to a pull request you approve.