Roll out a dependency policy to an acquired team by explaining why each rule exists, showing exactly what changes in their daily work first, running rules in warn mode before enforcing, and giving them a named person and a clear path for questions and exceptions. Treat it as a conversation, not a memo.
Start with what changes for them
An acquired team has working habits, often good ones. The first message should not be the full policy document. It should be a short list: the three or four things that will change in the next month, what each looks like in their pipeline, and when.
If the list is long, you have not prioritized. Cut it down to rules that prevent serious harm and can be met quickly.
Explain the reason behind each rule
A rule with a reason gets followed. A rule without one gets bypassed. For each item, give one sentence on what it prevents. "Packages must come from the internal mirror, so a poisoned public package cannot reach a build unreviewed" is better than "use the mirror".
Show it, do not just tell it
Walk the team through a real pull request where the gate runs. Show a pass, a warning, and a block, and show how to read the message. Most friction comes from unclear failures, not from the rules.
A rollout in four moves
- Meet. A short session with the team leads. Ask what their current practice is, and learn what they already do well. Write down anything that is stricter than your policy.
- Warn. Switch rules on in warn mode. Share a weekly list of what would have failed.
- Support. Offer pairing time for the first fixes, and templates for common cases such as pinning and lockfiles.
- Enforce. Move rules to enforce on dates the team was told about.
Make asking for help easy
Name a person, not a mailbox. State how fast you will respond. Keep a public log of exception decisions, so the team can see that requests are handled fairly. See who approves a new dependency, a lightweight intake policy.
Listen for signals
Track how often the team asks for exceptions, which rules they ask about, and how long fixes take. A cluster of requests on one rule means the rule, the tooling, or the explanation needs work. Adjust and say that you did.
Avoid common mistakes
- Sending the entire policy on day one
- Enforcing before a dry run
- Replacing the team's tools without a reason they can see
- Ignoring practices the team already follows that are stricter than yours
- Going quiet after the announcement
Try it yourself
Click through it at your own pace, or open it full screen. Follow the pull request to see how a failed check is explained to the developer.
Safeguard's policies and gates show results where developers work, in the pull request, and run in warn mode before you switch to enforcement.
Quick check
Should we replace the acquired team's tools right away?
Not usually. Settle policy outcomes first, then consolidate tools on a plan the team can see.
How do we handle rules the acquired team already beats?
Adopt them. If their practice is stricter, it may be the right merged rule.
Last reviewed: 19 October 2026.
