Cross-Team Deployment Governance
Designed and introduced a structured deployment review process at Pushpay to prevent breaking changes from reaching dependent teams — a recurring cross-team meeting with a pre-deploy checklist and documented approval criteria.
In a large enterprise Salesforce org with multiple dependent teams, an uncoordinated deployment is a shared problem. At Pushpay, changes were reaching production without any structured review of downstream impact — a change that looked safe in isolation could quietly break an automation or report that another team owned and depended on.
The Problem
The risk compounded with org size. The more teams using the same org, the more likely any given change was to touch something someone else depended on. Without a coordination mechanism, catching conflicts fell entirely on individuals — which meant it wasn't caught until something broke in production.
What I Designed
A recurring cross-team deployment coordination meeting with a defined agenda and pre-deploy checklist. The format made upstream and downstream dependencies visible before changes moved to production: each team with pending changes presented what was going in, and other teams could surface dependencies or concerns before the deployment window closed.
Documented criteria defined what required full cross-team review versus what could move on an expedited track — adding oversight without slowing down routine changes that carried low dependency risk.
Outcome
Breaking changes to dependent teams were caught before production rather than after. The review process created a lightweight institutional memory around deployment history and dependencies that hadn't existed before. The process was still in use after my tenure — the clearest signal that it solved a real problem rather than just creating process for its own sake.