Most developer-facing SaaS companies try to fix their technical content by hiring someone to write it. Whether that works depends on whether the content team can buy an hour with the engineer who built the product. Developers check what they read against how the product behaves, and what survives the check comes from that engineer.
So for a head of content at a developer-facing company, the job is less about writing than about getting time with the engineers. Build a first content map from your docs and the questions developers ask about your product, interview the engineer for half an hour, then write the draft from what they said and have them review it.
Empact Partners has worked from inside B2B software companies’ marketing teams as a go-to-market consultancy since 2020. With developer-facing partners we run Content Marketing this way: the partner’s engineers give us interviews and reviews, and we never hand them a blank page.
Developers Decide by Checking the Product Against the Page
A developer reads a vendor’s tutorial the way they read a pull request. They run the steps, compare each claim with what the product does, and stop trusting the page at the first thing that does not hold.
Stack Overflow’s 2026 Developer Survey asked developers what they do before they use an AI-generated answer for a development task. 76.5% of them run the answer locally first, and 9.6% use the answer unchanged. We expect a vendor’s tutorial to get the same test.
That reader meets your content on one of two routes, and either one can decide the deal.
For a product bought this way, Empact Partners treats the technical content as the go-to-market itself. The developer meets the docs, the tutorials, and the engineering posts before anyone from sales, and often instead of them.
At PDF Reader Pro, the product guides we wrote, each walking a user through one job in the app, account for 15 to 20% of monthly sales, by the case study’s figures. PDF Reader Pro serves general users, so what carries over is the mechanism: a guide built from how the product works sells the product.
.png)
A Writer Without the Engineer Cannot Write What a Developer Checks
The usual fixes all add a writer: more posts, a better writer, or a model drafting from public material with somebody checking the facts. Each produces a page that is accurate enough and still reads as written from outside.
The parts a developer probes hardest are the ones nobody outside the engineering team knows: why the product is built this way, where it breaks, and what the team chose not to build.
.png)
A content team with no line to the people who built the product writes weaker pages, however good its writers are, and expert readers notice when nobody asked the engineer. That is why, with a developer-facing partner, the first thing we ask for is time with the engineers.
What developers on Reddit say about vendor content
The developers on the other side of the page say it more bluntly.
“Every corporate ‘engineering blog’ I’ve ever seen is heavy on propaganda and light on technical detail.” — r/ExperiencedDevs, Aug 2022
“But some companies will outsource their blog as part of a content marketing strategy. Then the actual authors of the blog posts end up being people like me with no actual connection to the company.” — r/ExperiencedDevs, Aug 2022
“I’m quite happy for high quality engineering posts from vendors to be in my feed, I have learnt a lot from them throughout the years.” — r/dataengineering, Oct 2025
We read 32 threads across seven developer communities, dated 2020 to October 2026. When developers said why they trusted a company’s technical content, they gave the same reasons: depth about how the product was built, examples that run, honesty about limits, and an author who did the work.
Each of those four comes from inside the engineering team.
Set the ways of staffing technical content side by side and judge each one by what the developer on the panel finds when they check.
| Who writes | Engineer time per piece | What the panel finds |
|---|---|---|
| A content writer from outside | None, or a review at the end | Clean prose around claims no engineer made |
| A writer who codes, from outside | A call, if one is arranged | Steps that run, with the reasons at second hand |
| The engineer, alone | Days, so pieces seldom ship | The real account, on the rare day one ships |
| The content team, with the engineer | Half an hour to talk, then two reviews | The builder’s own account, checked by the builder |
So budget the hour, not the headcount. No writer, ours included, can write what a developer checks without the engineer’s hour. Once that hour is in, it matters far less who types the first draft than whether the engineer who gave the interview reviewed it.
The First Content Map Comes From Your Docs and Your Most-Voted Questions
The engineer’s hour is only worth buying once you know what to ask, and the best map of that is already public. When Empact Partners starts work with a developer-facing partner, the first content map comes from material the company already owns, before anyone opens a keyword tool:
Two rows of a first map, invented to show the shape rather than taken from a partner. The first question comes from a top-voted GitHub Discussion, and the second from comparison searches and sales calls:
| Question | Page that answers it | Who knows |
|---|---|---|
| Why does a webhook give up after three retries? | Webhooks: retries and failures | The engineer who owns event delivery |
| Will it hold above a million events a day? | Scale limits, with how they were tested | The engineer who ran the load test |
Keep the docs on the same map, because AI answers often cite them ahead of the blog. DevTune’s 2026 benchmark covered 421 developer-tool vendors, and by our count of DevTune’s table, the page of their own site that AI answers cited most was the documentation for 155 of them (36.8%) and a blog post for 122.
Half an Hour With the Engineer Who Built It Carries a Piece
Engineers say no to writing and yes to talking, so the method runs on talking. One focused call of fifteen to thirty minutes with the person who built the thing gives you the material for a piece and usually ideas for two or three more, which makes the interview the cheapest step in the program.
We ran the same process with Feathery, whose no-code forms sell mainly to insurance and financial-services teams rather than to developers. The expertise we got from interviewing its founders gave us almost all the content, and whenever an article’s outline needed discussing, one of them made time for a quick call.
The case study puts organic traffic up more than 300% in 16 months, with more than 5.5 million impressions, and almost every post carried an interactive demo. With an engineer on a developer product, these questions make the half hour pay:
Decide the angle before you write the questions, because a vague topic gets vague answers. Send the questions a day ahead, and open the call on the easy ones. Book the call through your own calendar link so you keep the recording and the transcript.
Say plainly when you do not follow. An engineer explains more patiently to someone who admits a gap than to someone performing expertise, and if the answers keep coming back short, the questions are wrong, not the engineer.
The Content Team Writes the Draft, and the Engineer Reviews It
At Empact Partners the content team drafts with a model, and we say so. The model works from the interview transcript and the docs, and from nothing else. A named consultant runs the interview, owns the angle and the cuts, and decides when the piece ships.
A model cannot draft the engineer’s knowledge of how the product behaves. The interview supplies that knowledge, and the engineer’s review checks the draft against the product. A model drafting from public material skips both, which is why that fix fails. Every piece goes through the same five steps:
In the final edit, keep the engineer’s own terms, including the ones the editor would not choose. Engineers who have written for their company’s engineering blog remember the other kind of edit:
“The editor didn’t feel like he’d done his job until he had tightened up my writing, but the problem was he didn’t just fix typos and a couple big words I snuck in, he touched some turns of phrase that I liked and rephrased some jargon that he clearly didn’t understand and he kept making me sound stupid.” — r/ExperiencedDevs, Aug 2024
What the engineer’s review adds is usually small and decisive. One sentence, invented to show the kind of change rather than taken from a partner’s draft:
The second version is the one a developer on the panel can check, and the one a champion can repeat to whoever approves the budget.
Link the finished piece from the docs page the map paired with its question. Then answer that question where developers first asked it, with the link and a line saying who you are and where you work.
Expect an argument in the comments. A long, critical thread from developers who read the whole page is a better sign than polite silence, because the right reader spent real time on the page.
The Program Costs About an Hour of an Engineer’s Time per Piece
Count the engineer’s time honestly before you ask for it. Per piece, the ask is a half-hour interview, a review pass of about the same length, and a short second review from another engineer. The content team carries the rest: the map, the questions, the draft, the final edit, the publishing, and the upkeep queue.
Take that ask to the head of engineering, and expect the objection engineers post themselves:
“It’s almost always a bad idea to have a developer do this. Unless they specifically enjoy doing it, it is going to be a drain on their morale and energy to spend time on it.” — r/ExperiencedDevs, Aug 2024
Engineers are right about blank pages, which is why the method never hands them one. The engineer talks for half an hour and reviews what comes back, and the writing stays with the content team.
The head of content can run the first half this week. Export the docs map, pull the most-voted questions, add the evaluation column, and book one engineer for half an hour on the question at the top.
The rest takes quarters: a review rhythm the engineers trust, and a library deep enough that a developer on the panel finds their question answered and reviewed by the person who built the feature.
The library and the review rhythm are the Content Marketing work partners hand to us. A partnership with Empact Partners opens with an audit of the docs, the community questions, and the published pages, then a roadmap. From there a named consultant runs the interviews and takes every piece through both reviews, quarter after quarter.
Watch one number in the first quarter: how many of the map’s evaluation questions have an answer an engineer has reviewed. Those answers are the pages a developer on the panel opens first, and until they exist, the shortlist gets decided on somebody else’s content.
If your engineers know the answers developers keep asking about your product and those answers never reach the page, book a call with me to talk through whether it is work we should do together.
