Somehow, I’ve spent a good chunk of my career working for underdogs: SoundCloud, DigitalOcean, SeatGeek—almost back to back. Streaming music in the early 2010s, simplifying cloud computing, taking on Ticketmaster… problems big enough that our competitors threw thousands of engineers at them, while we had a few hundred in the whole organization.

Customers didn’t care how many engineers we had, so a big part of my job as an engineering leader was figuring out how to take advantage of the velocity our size allowed while shipping product with the richness and stability of a company ten times bigger.

Getting there requires running a tight ship, and that’s easier when you’re in the conversations. You catch the bad assumption early, you know which two projects are about to collide, you can tell when a decision is being made by the wrong person, or when an architecture hasn’t accounted for expected growth or a shift in strategy.

Being this close obviously doesn’t scale. As I went from leading one team to leading the whole engineering organization, there were simply more projects than I could be across.

I’d be lying if I said I didn’t miss knowing about every important project and designing the most challenging systems myself. But beyond my own vanity, the real problem wasn’t that I was missing these conversations. It was that they often weren’t happening at all.

Unless I asked an engineer to write down a proposal, it usually didn’t get written. Unless I asked the right people to review it, it didn’t get reviewed. Teams weren’t making bad decisions—they were making safe ones. Often the entire research and debate was summarized as “we used the same architecture as the other projects.” That’s easy to defend when things go wrong. It’s also the opposite of the thinking that got us competitive in the first place.

I couldn’t solve this by putting myself back in every room. I needed an operating system that would make the rooms happen without me.

One of the most important tools in that operating system is what I call the Structured RFC Process, which I first wrote about publicly in 2018. It’s how we kept startup speed and technical ambition at a size where most companies trade both for committees and safe decisions.

When the Document Comes First

This ended up being some of my most widely read work; the RFC process has shown up in books, talks, and more engineering handbooks than I can track. So, unsurprisingly, I’ve been asked some version of the same question a lot lately: what do I change now that everyone is writing with an LLM?

My answer is that the most important part of a Structured RFC was never the document. It’s ultimately a change management process—a way to get an organization to commit to a decision without defaulting to slow and expensive consensus. That’s why my RFCs expire: so we can disagree, commit, and revisit instead of stalling on getting it right the first time. That’s why the author names who has the final say and who is only giving feedback. That’s why every piece of feedback gets a good-faith response even when it’s rejected. That’s why the review meeting is a milestone rather than the venue, with as many questions as possible settled before anyone sits down.

None of that changes with AI. Even in the tooling, over the years I’ve tried adaptations for more asynchronous and distributed teams, but nothing worked better, and after giving GitHub PRs, Notion, and Confluence a fair run, Google Docs is still unbeatable for this kind of collaboration.

What does change is how the document gets produced. The original process was built around a constraint that held for my entire career: people hate writing. Some of the best engineers I worked with had done the research and could hold every tradeoff in their head—they just wouldn’t put it on paper. The thinking existed; the document didn’t. Much of the template, and most of the lifecycle around it, existed to close that gap.

LLMs broke the assumption that a serious document was evidence of serious work. Now the document can arrive first: five convincing pages before anyone has had a single serious thought about the problem.

I’ve written about this a few times already: about the asymmetry between generating text and refuting it, and about how we should label our work so readers know how to engage with it. Both ended in roughly the same place: don’t spend real attention on something nobody thought through.

That works fine as personal policy. It doesn’t work as an engineering leader: nobody on my team can decide to ignore the RFC that’s blocking their next quarter. Somebody has to read it. A document that wastes their attention isn’t a nuisance, it’s a defect in how the organization makes decisions. And defects get fixed upstream.

So while the process itself works almost exactly as before, the part I had to change is the part I always said mattered least: the format.

An RFC for an AI World

As part of working this out, I did the obvious thing and wrote an RFC about it using the Structured RFC Process.

It’s a Google Doc you can copy and adapt. It builds on the original process rather than restating it, so it will make more sense if you’ve read that one first. It’s in an eternal Feedback Requested state and it has a revisit date, and I mean both seriously: if you run this and find something wrong with it, I want to hear about it!

Rather than walk through it line by line the way I did with the original, I want to use the rest of this post for commentary: why each rule is there, what it’s actually defending against, and how I use the rubric as a pre-flight check before asking humans to spend their attention on an RFC.

The author owns every word

There is a large debate happening around AI and authorship in everything from music to love letters, but irrespective of where we land as a society, within an organization you need clear accountability and ownership.

This is the most important rule, and also the simplest: I don’t care who typed the words, you own them. If the model hallucinated something and you didn’t catch it, that’s your mistake, not the model’s.

As AI becomes a normal part of producing these documents, disclosure becomes less useful to me. What matters is whether there is a human being willing and able to defend everything they put their name on.

We still follow the NABC structure

There are many formats and even variations of NABC that work just fine, so if your company has adapted to something you all like you should probably keep using it.

If anything—and this has nothing to do with AI—the only part of NABC I’m really married to is always including Do Nothing as an alternative. I can’t tell you how many times over the last ten years I’ve started an RFC convinced something was a great idea, only to discover that I couldn’t make a convincing case for doing it instead of simply letting things continue as they were.

The argument is narrative prose, not bullet points

Something interesting happened as we went remote-first and then remote-friendly: we lost a lot of our shared surfaces for thinking together. Nobody ever really built a distributed whiteboard that felt like a whiteboard, so we fell back to the next best thing: a shared Google Doc everyone stares at during a video call.

Add Slack replacing much of email and, somewhere along the way, we started replacing prose with bullet points. Just before AI-generated content became common enough to warrant changing the RFC process, I was already seeing an epidemic of RFCs that were little more than lists of bullets.

AI makes this worse because it can turn those bullets into plausible prose without filling in the missing reasoning. The output looks like the writing problem has been solved, while the argument underneath can still be exactly the same list.

Implementation detail stays out

One trick I’ve found useful when writing an RFC with AI is to use a developer tool such as Pi or Claude Code instead of a chatbot, giving it access to the affected codebases while producing the document. This is an incredible way to give the model the right context and quickly falsify assumptions.

The problem is that this exacerbates the already existing tendency of LLMs to jump from an abstract requirement to lines of code. Give an agent access to the repository and suddenly your architectural proposal comes back with class names, schemas, method signatures, migration sequences, and a list of files to modify. It feels impressively concrete, but most of that information is irrelevant to the decision the RFC is asking people to review.

I still want enough technical detail to understand the shape of the proposal. A small interface, some pseudocode, or a toy example can be the clearest way to communicate an idea. But once we’re debating filenames, method signatures, migration sequencing, or the exact DDL, we’ve probably crossed into a different document.

Diagrams are first-class content

I would have added this even without AI. Diagrams are fundamental to communicating software architecture, and a good bird’s-eye view gives a reviewer a chance to spot a problem before reading two thousand words.

There’s also a temporary hack here. At least as I write this, LLMs are still noticeably worse at producing a good architectural diagram than they are at producing convincing architectural prose. Asking for a diagram therefore often forces the author back into the loop: you have to decide what the important boxes actually are and how they relate.

I don’t expect that advantage to last, but I’ll take it while it does.

Claims should be traceable

Hallucination is a societal problem at this point, so I don’t think I need to spend much time explaining why invented facts and references are bad.

What I find more interesting is that references make AI useful on the review side too. A reviewer can give the RFC and its sources to an LLM and ask it to check whether the sources actually support the claims being made. The author gets to use cheap machine research, but also has to leave enough of an evidence trail for cheap machine verification.

The core proposal fits in a budget

This is the silliest rule, but somehow the most practical. The exact number is irrelevant. It’s just as easy to hide a poorly researched argument behind six bullet points as it is under six thousand words, so the goal isn’t “shorter is smarter.”

The point is to put a price on asking for attention. Pick a number appropriate for your organization and force authors to decide what actually belongs in the shared argument and what can live in an appendix. Mine is 2,500 words, with 1,500–2,000 as the target. I’m not religious about those numbers; I’m religious about having a budget.

The rubric

The rubric might be my favorite addition, because it’s the part that uses AI to improve the process rather than just the writing.

Machine attention is cheap. The whole problem I’ve been describing is that human attention isn’t. So before I ask anyone to read an RFC, I hand the document and the rubric to an LLM and tell it to be annoying: find claims with no evidence, find alternatives that are obviously straw men, find bullets pretending to be reasoning, tell me where I’m explaining implementation instead of the proposal, check the word count.

It clears out the mechanical objections so a reviewer’s time goes to the argument instead of the document.

There’s a second effect I didn’t anticipate, and I’ve come to think it matters more. A big part of the original process was making it safer to put forward an incomplete or even crazy idea and iterate on it with other people. The rubric turns out to help with that directly: it’s a test authors run on their own work, in private, before anyone else sees it. You get to find the obvious hole yourself rather than having it found for you in a comment thread.

Which is why the rubric is not a grading system. Passing it doesn’t mean the proposal is good. It means the document is ready for humans to have the argument the process was built to create.

–

It’s strange that a process designed over ten years ago held up this well, and even stranger that what finally disrupted it did so in a matter of months. We’re in a hybrid moment: we use AI for most of the work and still operate at roughly the same level of abstraction as before. Until that changes, I expect to keep patching this thing as the tools move, and I expect we’ll be back here doing it again.

What won’t change is the reason it exists. If you’re a few hundred people going up against a few thousand, you don’t win by working harder, you win by not wasting decisions. Somebody has to make the case, the right people have to argue with it, and someone has to decide. That was expensive to make happen in 2018 because nobody wanted to write. It’s expensive now for the opposite reason. The job is the same either way: keep the rooms worth showing up to.