← CatZep/Engineering Guides/Management & Leadership/Cross-functional Partnerships
Getting busy, siloed teams to adopt your internal platform — by treating it as a product, not a mandate.
Student edition · understand, apply, verify
Earn useful platform adoption by solving a customer problem and making migration costs and constraints explicit.
What you should be able to do: Measure successful ongoing use rather than mandate coverage or account creation alone.
Context-dependent collaboration guidance. Examples/numbers are illustrative; first-person practice drafts are not verified personal history. Respect decision rights, safety/legal obligations, privacy, and the partners' actual capacity. No framework guarantees agreement or delivery.
Read these definitions first, or use the linked terms as you go. The examples and limitations are local to this guide; companion pages are optional.
A stakeholder is affected by or able to affect a decision. Alignment means understanding goals, constraints, tradeoffs, and the decision process; it does not require unanimous agreement.
Example. Finance values cost predictability, customers migration effort, and operations safe recovery. State these criteria before choosing.
Boundary. Consultation is not an unlimited veto. Name decision authority, required evidence, deadline, and escalation.
Outputs are produced things; outcomes are changes for users/business/team. Useful metrics state definition, denominator, population, period, and attribution limits.
Example. 'Shipped a tool' is output. 'Median onboarding fell ten to six days in this cohort' is an outcome with sample/context caveats.
Boundary. Before/after does not prove sole causation. Avoid gaming, selection bias, hidden costs, and unlike-team comparisons.
Opportunity cost is benefit forgone by choosing one investment over another. Compare expected value, effort, uncertainty, constraints, and dependencies under finite capacity.
Example. A feature can delay reliability work; compare user benefit with risk reduction and explain the choice.
Boundary. ROI/RICE/weighted scoring are aids, not exact laws. Units, uncertainty, mandatory constraints, and critical paths can dominate scores.
Ownership names who drives follow-through; accountability names who answers for outcomes. Decision rights specify who chooses/approves and who is consulted.
Example. A migration has a coordinating owner, service owners, and named release authority.
Boundary. DRI/RACI/DACI are local conventions, not guarantees. Role labels do not replace authority, capacity, and follow-through.
Change a schema in stages that allow old and new software to coexist: add a compatible representation, deploy readers/writers, backfill and reconcile, switch authority, then remove old fields only after the rollback horizon.
Example. Rename full_name by adding display_name first. Both app versions remain valid until backfill, dual-write consistency, and rollback checks are satisfied.
Boundary. Two application writes are not automatically atomic. Prefer one transaction/change-log authority and detect divergence. Dropping the old field too soon makes code rollback unsafe.
This question tests whether you can win voluntary adoption of infrastructure you build. Owning a great platform is worthless if the teams who should use it stay on their old paths. For a horizontal infra leader, adoption is the impact — and you rarely have the authority to force it. The interviewer wants to see you think like a product owner: understand the internal customer, quantify their ROI, remove every gram of migration friction, prove value with lighthouse users, then close the old door. The answer follows the CARL shape — Context, Actions, Results, Learnings — and is judged on whether you drove adoption by pull, not push.
Do you treat an internal platform as a product with customers who have a choice — earning adoption through value and low friction — or do you assume “build it and they will come” and then blame the teams when they don’t?
How to answerPractice draft: first-person narratives below are not independently verified autobiographical evidence. Use their structure, not their claimed results; replace with your genuine safe-to-share experience.
Context. My team built a new ads events ingestion client that gave exactly-once semantics and cut per-event cost, replacing a legacy logging path that a dozen product teams used. Six months after launch, adoption was stuck around 15%. The platform was technically better, but teams weren’t moving — migration looked like risky, undifferentiated work on someone else’s roadmap.
Actions. I stopped treating low adoption as a motivation problem on the teams and started treating it as a product problem on us. I embedded with two of the stalled teams for a week and watched them actually try to migrate — and found the real blocker: our “migration guide” was a 20-step wiki that assumed deep knowledge of the new schema, and the client needed hand-written config that was easy to get wrong. So I re-cut the roadmap around friction. My team built a codemod that rewrote the old call sites automatically, an adapter that let the new client read the old config so most teams changed nothing, and a shadow mode that let a team run new and old side by side to build confidence before cutting over. Next I rebuilt the ROI case in their language: instead of “exactly-once semantics,” I showed each team the specific duplicate-event bugs and on-call pages the new client would have prevented last quarter, and the dollar cost they’d each save, pulled from Scuba. Then I went for lighthouse users — I picked the most respected and the most skeptical of the twelve teams, did the migration with them so it cost them almost nothing, and had them post their before/after numbers on Workplace. That turned the narrative from “infra wants us to do work” to “the teams we trust already did this and it paid off.” Finally, with migration now a near-zero-effort path and two proof points live, I published a dated deprecation for the legacy client and worked the long tail team by team, offering to send the codemod diffs myself.
Results. Adoption went from about 15% to over 90% of event volume in one quarter, the legacy path was fully deprecated a quarter after that, and the teams that migrated saw duplicate-event on-call pages effectively go to zero. The codemod-plus-adapter approach cut the typical migration from an estimated multi-day project to a single reviewed diff.
Learnings. Technical superiority does not drive adoption — low friction and credible proof do. The highest-leverage work wasn’t on the platform itself; it was on the migration path and the social proof. And deprecation only works after the new path is genuinely easier, or it just breeds resentment.
Use the following scenario to practice making goals, uncertainty, responsibility, and evidence explicit.
| Step | Evidence, decision, and expected result |
|---|---|
| Define value for users | Team A needs schema compatibility; Team B needs simpler recovery. A common platform must meet their real workflows. |
| Measure migration effort | Include code/data changes, approvals, tests, training, rollback, and dual-run cost—not 'near zero' as an unsupported promise. |
| Pilot safely | Choose representative users, record successful operation and support burden, and repair blockers before broader rollout. |
| Deprecate deliberately | Set supported migration/rollback policy and qualified exceptions. Count meaningful successful adoption and retained users. |
No. Coverage can rise while successful use or customer outcomes worsen.
Choose a real cross-team decision. Record the shared problem, each party's constraints, options, assumptions, authority, agreed actions, owner/date, observed outcome, and reconsideration trigger. Use authorized evidence and distinguish contribution from attribution.
Use genuine, safe-to-share evidence. Example numbers here illustrate reasoning; they are not claims about your work or a guaranteed outcome.