The Document Nobody Asked For
The RFC that’s technically right and organizationally invisible — and what’s missing from it.
You spent three weeks on it. The RFC that explains, with precision, why the current data pipeline architecture will fail at 10x load — not theoretically, but based on the production metrics you’ve been tracking since November. You included the failure scenarios, the latency projections, and the cost modeling. You proposed a migration path that doesn’t require a rewrite. You even wrote a FAQ section anticipating the objections you knew would come from the payments team.
You posted it in the #architecture channel on a Tuesday morning. Raj, another senior engineer, reacted with an emoji. Your engineering manager said, “Great write-up, let me find time to review.” A product manager you’d never met asked if this would affect the Q3 roadmap.
Then nothing.
Two weeks later, the document has four comments — two from Raj, one from your EM asking a clarifying question he could have answered himself, and one from an engineer on another team who used the thread to raise an unrelated question about the build system. The VP of Engineering hasn’t opened it. The payments team lead, whose system is the primary risk, hasn’t acknowledged it exists.
You sit in your next 1:1 with a familiar frustration. The document is right. You know it’s right. Raj knows it’s right. And it doesn’t matter, because being right is not the same as being heard.
This is the defining frustration of staff-level engineering. You’ve reached the point in your career where you can see architectural problems before they become incidents, where you can trace the second and third-order consequences of a technical decision across three teams. Your technical judgment is, in the ways that matter, the thing the organization promoted you for.
And the organization keeps not acting on it.
The engineer’s instinct — and it’s a good instinct, in a technical context — is to make the document better. Add more data. Sharpen the projections. Include a proof-of-concept. If the argument is rigorous enough, the reasoning clear enough, the evidence overwhelming enough, surely the organization will respond.
It won’t. Not because the argument is flawed, but because organizational decision-making doesn’t run on the same protocol as technical decision-making. A well-structured RFC answers the question “Is this technically correct?” The question the organization is actually asking is different: “Is this safe to act on right now, given everything else we’re navigating?”
Those are different questions with different inputs.
The technical inputs are the ones staff engineers know how to produce: data, analysis, risk modeling, and proposed solutions. The organizational inputs are the ones they tend to underinvest in, and those inputs are rarely in the document itself.
Consider what “safe to act on” means for the people who need to say yes. The payments team lead isn’t evaluating your latency projections in isolation. She’s in the middle of a PCI compliance audit. Any suggestion of architectural change triggers a fear response that has nothing to do with your technical merits — it’s about the audit timeline her VP is tracking. Your document doesn’t address this. It doesn’t even acknowledge it exists. From her perspective, your RFC is a well-reasoned argument for adding risk to a quarter when her primary objective is to reduce it.
The VP of Engineering isn’t ignoring your document because he disagrees. He’s ignoring it because he has fourteen documents competing for his attention and no organizational signal telling him yours is the one that needs action this week. Your RFC arrived in the same channel as feature proposals, post-incident reviews, and dependency upgrade requests. Without someone — you, your EM, Raj, anyone — creating the context that elevates this document from “interesting analysis” to “thing we need to decide on,” it sits in the queue.
Your engineering manager said, “Let me find time to review.” That phrase is a specific kind of organizational statement. It means: I see this exists, I acknowledge it seems important, and I have no mechanism for prioritizing it against the twelve other things I need to do this sprint. If you take that statement at face value and wait, you’ve delegated the urgency of your own work to someone who doesn’t feel the urgency the way you do.
The staff engineers who get their proposals adopted — consistently, not as one-off exceptions — do something the technically-focused ones don’t. They treat the document as the artifact of a campaign, not the campaign itself.
Before the RFC lands in #architecture, they’ve already had a conversation with the payments team lead — not to present the proposal, but to understand what she’s worried about this quarter. They know about the PCI audit. So the RFC explicitly addresses migration timing in a way that prioritizes compliance work. Not because compliance is more important architecturally, but because the person who needs to say yes needs to know her priorities aren’t being overridden.
They’ve had coffee with the VP of Engineering and mentioned the production metrics informally — not the proposal, just the data. When the RFC arrives, the VP has already been thinking about the problem for a week. The document doesn’t introduce a concern. It gives structure to a concern that’s already active in his mind.
They’ve talked to Raj — not just as a technical reviewer but as an ally who can bring it up in the staff engineering sync. When the RFC appears, it doesn’t come from a single person with an analysis. It arrives with context that multiple people in the organization are already holding.
None of this is in the document. None of it shows up in the technical review process. But all of it determines whether the document leads to action or sits in a channel with four comments.
This is uncomfortable for engineers who believe technical merit should determine technical decisions. And they’re not wrong to believe it — the instinct toward rigor is what makes the analysis valuable in the first place. The discomfort comes from a gap between how decisions should work and how they do work. Staff-level leadership lives in that gap.
The engineer who refuses to engage with the organizational dimension — who writes the strongest possible technical argument, posts it in the channel, and waits for the organization to recognize its merit — isn’t taking a principled stand. They’re opting out of the process where influence actually happens. And opting out doesn’t change the process. It just means the decision gets made without their input.
The organizational work isn’t politics in the pejorative sense. It’s the operational reality of how groups of intelligent people with competing priorities converge on a shared technical direction. Participating in that convergence isn’t a compromise of your engineering values. It’s the expansion of your engineering practice to include the systems that are made of people.
And here’s the part that connects back to the document itself: when you’ve done the organizational work, the document changes. The RFC that accounts for the payments team’s constraints, that names the VP’s priorities and shows how the migration serves them, that builds on conversations Raj has already seeded — that document reads differently than the one that’s merely technically correct. It’s still technically rigorous. But it’s written for the humans who need to act on it, not just for the codebase it describes.
The same technical substance. A different document. A radically different outcome.
This is the skill that Prism Signal’s IC scenarios put you inside. In The Platform Proposal, you’re a staff engineer writing the document that makes the case for a platform investment. The technical merits are real. The organizational resistance is real, too — a VP with a different vision, a team lead protecting his roadmap, a principal engineer who’s seen proposals like yours fail before.
The scenario doesn’t test whether you can write a technically sound proposal. It tests whether you can write the emails that navigate the organizational terrain around it — and you practice by actually composing them. No multiple-choice options. No suggested responses. Just the compose window and the weight of choosing words that are technically honest and organizationally aware at the same time.
Your first scenario is free. No credit card, no commitment — just the document the organization has been waiting for, and the practice of making it land.