Build a cross-team kickoff doc for shared infrastructure

Shared Infrastructure Needs a Contract, Not a Wiki Page

Shared infrastructure that ships without a contract becomes a support sink — every consumer asks the same questions, and each team gets a slightly different answer. Stripe's engineering writing and GitHub's developer research both document the contract-first pattern: inputs, outputs, SLAs, versioning policy, deprecation notice period, documented before the first consumer onboards. The Pragmatic Engineer's platform writing emphasizes non-goals — explicit statements of what the platform will not do — as the highest-leverage section of the contract.

How the Build a cross-team kickoff doc for shared infrastructure Prompt Works

The prompt structures the kickoff into six sections with a contract, SLAs, onboarding steps, and change management policy, plus explicit non-goals and non-negotiables. The "top 3 assumptions consumers are most likely to violate" output is the pre-mortem — surfacing misinterpretations before they become tickets.

When to Use It

• A shared service is about to onboard multiple teams.
• A platform is growing consumers and support load is spiking.
• A rewrite is introducing breaking changes consumers need notice of.
• A new platform PM is establishing ownership hygiene.
• Consumers are asking incompatible questions that point to ambiguous contract.

Common Pitfalls

• No non-goals. Consumers assume you'll solve their edge case if you don't explicitly refuse.
• Vague SLAs. "High availability" is not an SLA. Name the number.
• No versioning policy. Consumers who can't predict breaking changes will delay integration forever.

Sources

• Stripe Blog — Stripe
• GitHub Developer Research — GitHub
• The Pragmatic Engineer Newsletter — Gergely Orosz
• The Product Engineer Role — PostHog