Assumptions as code: SiriusXM's approach to platform prioritization

DX · video · 2026-04-10 Reader 🖥️

Decision-Making Practices Non-Engineers Building Organizational Legibility Platform Engineering

SiriusXM's platform engineering team built a weighted, multi-factor prioritization framework (evolved from RICE) that makes trade-offs explicit through numeric weights on impact factors, and then extended it with an 'assumptions as code' system that stores organizational assumptions in a Git repository so AI can surface conflicts, staleness, and invisibility at the moment of decision-making.

practical · panel discussion / podcast episode — A DX Engineering Enablement podcast featuring Eleanor Milman (Senior Staff PM, Platform Engineering) and Mina Towadras (Associate Director, Platform Engineering) at SiriusXM, hosted by Justin Rio. The discussion covers a concrete prioritization framework evolved from RICE, an 'assumptions as code' system, and the expanding builder persona.

Structure

Part	Role
The prioritization problem in platform engineering	Problem statement: platform engineering is twice removed from revenue, so standard product metrics (ARR, revenue) do not apply, and ad-hoc prioritization does not scale across five teams and 700+ developers.
Evolution from RICE to a custom weighted framework	Solution design: adding urgency, decomposing 'impact' into seven weighted factors (developer speed, runtime reliability, cost reduction, security/compliance, data-drivenness, platform efficiency, user trust), and using leadership signals to tune weights quarterly.
The value of forcing numeric weights	Mechanism insight: requiring leaders to assign actual percentages creates a forcing function that exposes real trade-offs, unlike verbal prioritization which allows everything to be 'important'.
Assumptions as code	Extension: codifying organizational assumptions (about users, usage frequency, incident rates, etc.) into a Git repository with three faulty states -- conflicting, invisible, and stale -- so that they can be version-controlled, surfaced by AI, and validated by humans.
Three modes of AI-assisted prioritization	Operationalization: rapid (30-second auto-score), standard (conversational validation), and deep-dive (15-minute guided research) modes serve different personas and initiative sizes.
The expanding builder persona	Future context: the shift from 'software developer' to 'builder' (citing GitHub's 25% YoY user growth) creates new platform engineering challenges around security, supportability, maintainability, and onboarding for non-developer contributors.
2026 roadmap priorities	Forward look: internal discovery of existing tools, reducing contribution friction, addressing the PR review bottleneck created by higher throughput, enabling the majority (not just early adopters) of AI users, and understanding citizen developer needs.

Key terms

assumptions as code Organizational Legibility
Organizational assumptions (about users, usage patterns, incident frequency, etc.) stored in a Git repository as structured data, version-controlled and queryable by AI, so they can be validated, updated, and surfaced during planning.
faulty states (of assumptions)
Three failure modes: conflicting (two teams hold contradictory assumptions), invisible (a team does not know an assumption exists elsewhere), and stale (an assumption was once valid but is no longer).
impact factors
The decomposed dimensions of value used in the prioritization formula: developer speed, runtime reliability, cost reduction, security/compliance, data-drivenness, platform efficiency, user trust. Each is independently weighted.
weights
Numeric percentages assigned to each impact factor by leadership, reflecting quarterly strategic priorities. Changing a weight immediately re-ranks the project backlog.
builder persona Non-Engineers Building
Non-developer individuals (marketing strategists, product managers, etc.) who build software artifacts using AI tools and low-code approaches, expanding the user base of platform engineering beyond traditional software developers.
twice removed from revenue
Platform engineering builds tools for developers who build products that generate revenue -- two degrees of separation from the bottom line, making direct revenue-based prioritization impossible.

Propositions

explicitPlatform engineering cannot use revenue as a prioritization metric because it is twice removed from revenue generation.conf: high
explicitRequiring leaders to assign exact numeric weights to impact factors is a more effective forcing function than verbal prioritization or stack-ranking exercises.conf: high
explicitOrganizational assumptions can be classified into three faulty states: conflicting, invisible, and stale.conf: high
explicitThe primary value of a prioritization framework is not the numeric score it produces but the conversations it forces teams to have about trade-offs and assumptions.conf: high
explicitAI's most valuable role in prioritization is at the recall level -- surfacing existing assumptions and data -- not at the judgment level, which should remain human.conf: high
explicitData from DX surveys (quality scores, incident frequency) provides the empirical grounding needed to confidently adjust impact factor weights.conf: high
explicitestablishedThe cost of building new software is now so low that the bottleneck is shifting from creation to discovery (knowing what already exists) and review (PR throughput).conf: high
supports ←Lawyers are quietly becoming builders · p8 — Pike's plugins — feed in your playbook/preferences and correct until it remembers — are exactly 'encoding expert reasoning as reusable skills' that operationalizes and democratizes institutional (here, a lawyer's) knowledge.
supports ←Linear’s CEO just described the biggest shift in product team... · p3 — Both identify the same two-sided bottleneck shift — toward discovery/intent-formation on one side and review on the other — as code generation itself gets cheap.
supports ←How building software is changing at Anthropic · p15 — Thariq's observation that most tokens go to discovery and verification, not implementation, is a direct practitioner confirmation of the claim that cheap code generation shifts the bottleneck to discovery and review.
explicitcorroboratedPlatform engineering must expand its user definition from 'software developers' to 'builders' to remain relevant as AI democratizes software creation.conf: high
supports ←Presentation: Platform Engineering in the Age of AI · p14 — Independent practitioner corroboration of the claim that platforms must expand their user definition beyond software developers as AI enables non-developers to build.
implicitA framework that has prioritized 250-300 projects over nearly three years has demonstrated durability, validating the approach despite its initial onboarding cost.conf: medium
implicitcorroboratedThe assumptions-as-code approach is a form of organizational knowledge management that treats decision premises with the same rigor as source code (version control, review, CI).conf: medium
supports ←Presentation: Platform Engineering in the Age of AI · p17 — Independent corroboration, from a different organization, of AI forcing the rigorous externalization of organizational knowledge that was previously under-prioritized.

Arguments

Platform engineering needs a custom prioritization framework, not off-the-shelf RICE. strength: high

Explicit premises:

RICE lacks urgency, which platform teams need for hard deadlines (vendor contracts, company launches).
RICE's single 'impact' dimension is too coarse for platform engineering's multi-stakeholder value.
Platform engineering is twice removed from revenue, so standard product metrics fail.

Implicit premises:

A prioritization framework must reflect the actual dimensions along which a team creates value.
Internal platform teams face fundamentally different constraints than customer-facing product teams.

Inferences:

Therefore, impact must be decomposed into multiple independently weighted factors.
Therefore, urgency must be an explicit input, not smuggled in through override mechanisms.

Codifying assumptions in a repository and surfacing them via AI improves decision quality at scale. strength: high

Explicit premises:

Assumptions can be conflicting, invisible, or stale -- all leading to poor decisions.
Manual research of assumptions is too expensive for smaller initiatives.
AI can cheaply surface relevant prior assumptions at the moment of planning.

Implicit premises:

Most organizations have no systematic way to track the assumptions behind past decisions.
The cost of a wrong assumption increases with organizational scale.
Assumptions degrade over time without active maintenance.

Inferences:

Therefore, storing assumptions as structured, version-controlled data enables AI-assisted recall.
Therefore, the human-AI split should be: AI handles recall, humans handle judgment and validation.

Platform engineering must prepare for the 'builder' persona as a first-class user. strength: medium

Explicit premises:

GitHub saw 25% YoY user growth, which is unlikely to be entirely new professional developers.
Non-developers are already building software using AI tools (e.g., ChatGPT-assisted Python apps).
These builders will proceed regardless of whether platform engineering supports them.

Implicit premises:

Unsupported builders create security, maintainability, and supportability risks.
It is better to provide guardrails than to try to prevent non-developers from building.

Inferences:

Therefore, platform teams need to understand builder needs (scale, data access, security) and provide appropriate golden paths.
Therefore, documentation and AI-readable skills become critical infrastructure.

Narratives

Eleanor was the first product manager hired into platform engineering by Jared Winsky. Engineering counterparts were doing great prioritization at the team level, but it did not scale across five teams and 700+ developers. They tried RICE, it felt wrong immediately, and they iterated over three years to the current framework.
→ Origin story establishing why a novel framework was necessary and how it evolved organically rather than being designed top-down.
Eleanor and another PM attempted to prioritize a delivery team's full backlog of smaller tasks but abandoned the effort because it was too laborious to research assumptions for each item. This failure motivated the AI-assisted assumptions-as-code approach.
→ Demonstrates the scaling problem that assumptions-as-code solves -- manual assumption research does not scale to smaller work items.
Mina and Eleanor met at Pivotal Labs, whose values were 'do the right thing, do what works, and be kind.' This informs the three-mode design: deep-dive (do the right thing), standard (balanced), and rapid (do what works).
→ Cultural anchor connecting the pragmatic design philosophy to shared professional history.
A non-developer who was one of the highest users of their chatbot was discovered to be building a Python app by asking ChatGPT questions, with no coding background.
→ Concrete example illustrating the emergence of the builder persona and why platform engineering must adapt.

Questions addressed

✅ How should platform engineering prioritize when it cannot use revenue as a metric?
Decompose impact into multiple weighted factors (developer speed, runtime reliability, cost reduction, security/compliance, data-drivenness, efficiency, user trust) and let leadership tune weights quarterly based on strategic signals.
✅ How do you maintain alignment with leadership while preserving team autonomy?
The framework serves as a shared contract: leadership sets weights (strategic direction), teams rate projects within those weights (tactical autonomy). Data (e.g., high quality scores) provides empirical backing for decisions.
✅ How can AI improve platform engineering prioritization?
AI handles recall (surfacing existing assumptions from a Git-backed repository) while humans retain judgment (validating assumptions and making final decisions). Three modes (rapid, standard, deep-dive) serve different time/depth trade-offs.
⭕ How should platform engineering adapt to non-developer builders?
Partially addressed: the team is doing user research to understand builder needs (scale, data access, security requirements) and plans to provide golden paths and AI-readable documentation. Specific solutions are still being developed.
⭕ What is the actual formula or algorithm used in the prioritization framework?
The formula is referenced but never fully specified. We know it includes weighted impact factors, urgency, confidence, and effort, but the exact mathematical relationship is not disclosed.

Gaps

missing evidenceThe exact prioritization formula is never disclosed. We learn the inputs (seven impact factors, urgency, confidence, effort) and that weights are tunable, but the mathematical relationship between these variables is not shared.
Read next: Look for SiriusXM conference talks or blog posts that may publish the formula; also consider whether the formula matters less than the conversation process it enables.
unexamined assumptionThe framework assumes that leadership can meaningfully assign numeric weights to impact factors. Whether leaders actually have the information and cognitive capacity to set accurate weights -- or whether the weights merely formalize existing biases -- is not examined.
Read next: Research on calibration in expert judgment (e.g., Tetlock's superforecasting work) and whether structured elicitation improves or merely formalizes biases.
missing evidenceThe assumptions-as-code system is described conceptually and architecturally (Git backend, AI surfacing, three modes) but no concrete examples of stored assumptions, their schema, or real validation outcomes are shown.
Read next: Look for open-source implementations or detailed case studies of the assumptions repository; consider building a prototype to test the concept.
scope limitationThe discussion focuses on prioritization within platform engineering but does not address how this framework interacts with prioritization in the product engineering teams that platform engineering serves. Cross-org priority conflicts are mentioned but not deeply explored.
Read next: Explore how platform engineering priorities can be formally linked to product engineering priorities, possibly through shared impact factors or dependency mapping.
unexamined assumptionThe 'builder persona' argument relies heavily on GitHub's 25% YoY user growth as evidence of non-developer adoption. This statistic could have many explanations (more professional developers, more student accounts, more bot accounts) and is not validated.
Read next: Examine GitHub's actual user demographics data; look for stronger evidence of non-developer builder growth in enterprise settings.

Assumptions as code: SiriusXM's approach to platform prioritization

Structure

Key terms

Propositions

Arguments

Narratives

Questions addressed

Gaps

Related documents