Most pitching advice tells you to lead with the story. For Ars Technica that advice is actively wrong. Lead with the mechanism, and let the editor decide whether there is a story in it.
This is the publication where a 3,000-word explainer on memory allocation outperforms a product launch, where the comment section contains people who built the thing being discussed, and where a press release written in the usual register reads as noise within about four seconds. Founded in 1998 by Ken Fisher and Jon Stokes, named for the art of technology, owned by Condé Nast since 2008, Ars has kept an unusually stable editorial identity across nearly three decades of tech media churn. That stability is the single most useful fact for anyone pitching it, because it means the filter has not moved and you can learn it.
So the question of how to pitch Ars Technica is really a question about one thing: can you describe what your thing does at the level of mechanism, and does that description hold up under scrutiny from someone who knows the field better than you do.
The Audience Is the Editor’s Real Constraint
Every outlet has an audience. At Ars, the audience is a veto.
The readership skews toward working engineers, sysadmins, researchers and the technically self-taught, and it is vocal. A story that overstates a claim does not quietly underperform; it gets dismantled in the comments within the hour, with sources. Editors know this, so the question running behind every pitch they read is not “is this interesting” but “will this survive my readers.”
That reframes your job. You are not persuading an editor that your news matters. You are handing an editor enough verifiable technical substance that they can defend the piece. A pitch that does this well feels less like marketing and more like a well-organised handover: here is the claim, here is the measurement, here is the method, here is who can confirm it, here is what we do not yet know.
The last item in that list is the one almost nobody includes, and it does more for credibility than anything else you can write. Stating a limitation before the editor finds it signals that you have already run the adversarial pass yourself.
The Three Mechanism Tests
Here is the framework I use before sending anything to a technical publication. Call it the Three Mechanism Tests. A pitch has to pass all three, and the order matters because each one is cheaper to run than the next.
The first is the Mechanism Test. Can you explain how the thing works in three sentences, without a single abstraction that could apply to a competitor? “Our platform uses AI to improve throughput” fails. “We moved the deduplication step from the write path to a background compaction pass, which cut p99 write latency from 340ms to 51ms on the same hardware” passes. The test is specificity that forecloses alternatives. If a rival could paste your sentence into their own materials unchanged, you have written positioning, not mechanism.
The second is the Falsifiability Test. Does your central claim name a condition under which it would be false? A claim that cannot fail cannot be reported, because there is nothing for the journalist to check. “Significantly faster” is unfalsifiable. “Faster on sequential reads above 1MB, slower below 64KB, measured on the following hardware” is falsifiable, and therefore publishable. Volunteering the regime where you lose is not weakness; it is the thing that makes the rest of your numbers believable.
The third is the Comment Survival Test. Imagine the most knowledgeable hostile reader in your field reads the published piece. What is their first objection? Write it down. If you cannot answer it in the pitch, you are asking an editor to absorb a risk you would not absorb yourself. This test kills more pitches than the other two combined, and it kills them before an editor has to.
Run it properly and it is uncomfortable. The useful version is not imagining a vague sceptic; it is naming an actual person in your field whose judgement you respect and who has no reason to be kind, then writing their objection in their voice. People who do this consistently report the same thing: roughly half the time the exercise sends them back to the engineering rather than to the editor, because the objection is correct and the claim was softer than they wanted to believe. That is the test working. A pitch withdrawn on your own initiative costs you nothing, while a published claim that collapses under a knowledgeable reader costs you the outlet.
What to Actually Send
Keep the email short and put the mechanism in the first two sentences. Subject lines that state a technical fact outperform subject lines that promise a story.
A structure that works: one sentence on what changed at the mechanism level, one sentence on the measurement that supports it, one sentence on why it matters to a practitioner, then the offer of access. Access means something concrete: the engineer who built it available for a technical call, benchmark methodology you will share in full including the unfavourable runs, hardware and version details, and reproduction instructions if the thing can be reproduced.
Attach nothing. Link to a page that holds the detail. Do not send a PDF press release and do not send a video. If your supporting material requires a download before it can be assessed, it will not be assessed.
On who to send it to: find the writer who has covered your specific subsystem, not your industry. Ars writers hold deep and narrow beats, and the difference between the person who covers storage and the person who covers networking is not a nuance you can paper over with a general pitch. Read their last five pieces, note the questions they kept asking that their sources did not answer well, and answer one of those questions in your opening line. Mastheads move, so check the current one on the site rather than trusting any list in a blog post, including this one.
On timing, how to pitch Ars Technica differs from the daily news outlets. Timing matters less here than at a news-cycle outlet, because Ars publishes explanatory work that does not expire in a day. That cuts both ways: your embargo counts for less, and your story has a longer shelf life. A piece that is genuinely interesting at the mechanism level can be pitched successfully weeks after the news has passed, which is almost never true elsewhere.
The Benchmark Appendix Nobody Asks For
There is one attachment to your linked page that changes outcomes more than anything else in this piece, and it is the part teams resist most: publish the runs that went badly.
A benchmark page that shows only favourable results is read by a technical audience as a selection effect, and the reader does the correction themselves by discounting everything on the page. A benchmark page that shows the workloads where you lose, with the same rigour as the ones where you win, gets read at face value. The asymmetry is large and it is counterintuitive to anyone trained in conventional marketing, where you do not volunteer weaknesses.
What belongs on that page: exact hardware, including firmware versions where they matter. Exact software versions on both sides of the comparison. The workload generator and its configuration, ideally as a file people can run. Number of runs and the spread, not just the median. The regimes where the result reverses. And a short paragraph on what you tried that did not work, which is the single most persuasive thing an engineering team can publish about itself.
This does double duty. It gives the writer material they can cite and check, which lowers the cost of covering you. And it gives the hostile commenter less to do, because the obvious objection has already been addressed in print by you rather than discovered by them in public. Several technical outlets will link directly to a methodology page of this quality, which means the page keeps earning long after the article’s traffic has decayed.
After You Send: The Part That Needs Discipline
Follow up once, after five working days, in three sentences, in the same thread. Add one new fact rather than repeating the pitch. If there is no reply to that, stop.
The reason to stop is not etiquette. Technical editors keep long memories and small beats, and a sender who pushes after two silences gets filtered permanently, which costs you every future story rather than this one. A sender who pitches twice a year with real mechanism and accepts silence gracefully becomes, over a few cycles, someone whose subject line gets opened. That is the actual asset, and it compounds.
When you do get a reply, it is frequently a question rather than a yes, and the question is usually the hardest one in the subject area. Answer it the same day if you can, answer it precisely, and say plainly when you do not know. An honest “we have not measured that, here is what we would expect and why, and we can test it this week” is a strong answer. A confident guess that later turns out wrong ends the relationship, because you have handed an editor a correction to publish with their name on it.
One more thing worth saying about failed pitches. A no from a technical publication is often a no about timing or framing, not about substance, and the editor will sometimes tell you which. Read that reply carefully instead of filing it. The sentence that explains why a story is not ready is a specification for the story that would be, written for free by the person who decides.
Why Most Pitches Fail Here Specifically
Pitches fail here for a small number of repeated reasons, and all of them are visible before you hit send. Each one is a specific way of forgetting who reads the publication.
The claim is at the wrong altitude. Describing a category (“we are building the future of observability”) instead of a mechanism gives the editor nothing to verify, and verification is the whole job.
The numbers have no method. A 40% improvement with no baseline, no hardware, no workload and no variance is not a number, it is an adjective wearing a number costume. Technical readers treat an unmethodical benchmark as evidence against you.
The pitch sells rather than informs. Register matters more at Ars than almost anywhere. Words like transformative and next-generation signal that the sender has not read the publication, which answers the editor’s real question before they finish the first paragraph.
And the most common failure: there is no story, only an announcement. A funding round is not a mechanism. A partnership is not a mechanism. A rebrand is certainly not. If the only new fact is that something commercial happened, the honest move is to not pitch Ars Technica and to place that news where it fits, then come back when there is engineering to talk about.
Learning how to pitch Ars Technica well is mostly learning to tell those two situations apart, and to wait for the second one. The publication rewards patience in a way that the daily news outlets do not, because a good technical story there keeps earning attention for years. It is worth the wait, and worth the discipline of running the three tests on your own claim before an editor has the chance to.