Tidra | Maintenance, Tech Debt, and Other Cross-Cutting Work at Scale Product Use Cases Code Migrations Config Standardization CI/CD Migrations Security & Compliance<br>Initiative Library Docs Blog<br>Start free trial
Book a demo
Sign In
[ PLATFORM ENGINEERING ]
[ MAINTENANCE ]
[ TECH DEBT ]
Maintenance, Tech Debt, and Other Cross-Cutting Work at Scale
Kenneth Rose<br>May 21, 2026 · // 11 min read
We spoke with 100+ teams about what works when you’re trying to push a code change across 50 repos, or 500, or nearly 2000. These are our findings.
TL;DR<br>The hard part of cross-cutting work isn’t writing the code, it’s getting other teams to merge.<br>What works: calibrate on a small batch first, centralize PR creation for low and medium complexity, treat merge (not “PR opened”) as the only completion metric, and give leadership visibility into per-team progress.<br>What doesn’t: filing tickets, letting Renovate run unattended, auto-merge without review, reaching for IDE coding tools at multi-repo scale, and counting “PRs opened” as progress.
Read the playbook · Skip to the anti-patterns
The Gist
For most cross-cutting initiatives, writing the change is the easy part. What’s hard is everything after the PR opens: getting other teams to look, getting them to prioritize over their own roadmap, knowing whether the PR ever actually merged.
Most AI tooling focuses on the “inner loop” of software development and makes the actual writing part faster. This guide is about the rest of all the “outer loop” work that has to happen as well.
About Tidra<br>Tidra is the AI maintenance agent for platform teams shipping the same code change across hundreds of repos: dependency upgrades, framework migrations, security patches, config rollouts. Define an initiative once, generate every diff, and track each PR to merge from a single dashboard. Try free →
Where the Work Breaks Down
Over the last year, we’ve spoken with 100+ teams across platform, infra, DevEx, and AppSec roles. Some of them manage tens of repos, others manage thousands. The size of the org changes the volume of the work, but the shape of the problem stays roughly the same.
A platform engineer at a fintech walked us through his typical week. He’d personally raised PRs across a dozen services his team didn’t own. The code was fine. He spent the next several weeks in Slack channels asking people to please look at the PR, please review it, please merge. His one-line summary:
“Even with the PR there, it becomes a human coordination getting-the-work-done problem.”
That’s roughly what we heard, in various forms, from most of the teams we talked to. The reasons tend to cluster.
Centralized teams own implementation, even when they didn’t pick the work. Sometimes the platform group is the one deciding everything needs to move to Python 3.12. Sometimes it’s a security mandate, a compliance deadline, or a business requirement that lands on their desk. Either way, they’re the team accountable for making it happen across services owned by other teams. So every initiative starts with a round of negotiation: explaining the change to each owning team, convincing them it should jump their queue, then waiting.
And that queue is long. Most of the teams we talked to said their service owners typically have 30 to 50 PRs sitting open before yours shows up. A fintech engineer described what that looks like from the receiving end: “You’re on queue 64 of whatever, come back in a week.” The PR being there doesn’t change anyone’s behavior. Ownership of the service isn’t ownership of the initiative. Without somebody accountable for the whole thing landing, the work falls through the cracks at the merge step.
Tech debt loses to product work every quarter. Unless something forces the issue (a CVE, an end-of-life deadline, a recent incident), the work slides. A platform lead at a marketplace company put it bluntly: “Realistically, very few companies have the capacity for handling tech debt constantly.” The implication is that initiatives have to be run as deliberate campaigns, not as ambient background work.
Plenty of teams have tried writing bulk-PR scripts to get around this. They work on a handful of repos and break on the next batch because of variation no one anticipated. And even when they work, they don’t show you anything about what happens after the PR is open.
What We Saw Working
The teams that ran these initiatives well had a few habits in common. We’ve grouped them under scoping, making the change, and getting it merged, though in practice the pieces blur together.
Scoping the Change
Whether you’re using an AI agent, a script, or doing the work by hand, the teams that scoped well had a habit in common: they didn’t define the change once and ship it. They calibrated the change on a small batch of repos first, refined the definition based on what broke, and only then scaled.
One pattern we heard from a platform engineer at a smart-home company: pick a “simple” repo, a...