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 of the engineer who built the feature. Developers check what they read against how the product behaves, and only that engineer can write what survives the check.
So for a head of content at a developer-facing company, the job is less about writing than about getting time with the engineers. Decide who holds the pen, build a first content map from your docs and your developers’ own questions, interview the engineer for half an hour, and send back a draft of their own words to rewrite and sign.
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, with the partner’s engineers in the loop by design: they give us interviews and checks, never blank pages.
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 shows the habit with AI answers: 76.5% of developers run a generated answer locally before they use it, and 9.6% use it as it comes. We read vendor tutorials as getting the same treatment, and if they do, only someone who knows how the product behaves can write one.
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 on the case study’s own figures. It is a PDF product for general users. What carries over is the mechanism: a guide built from how the product works sells the product.
.png)
Another Writer 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 that only executes what it is assigned writes weaker pages when it has no line to the people who built the product, however good its writers are. That is why, with a developer-facing partner, the first thing we ask for is time with the engineers, and why expert readers notice when nobody asked.
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 it was built, examples that run, honesty about limits, and an author who did the work.
Each of those comes from inside the engineering team. A writer can make the page clear, but cannot make it true without the engineer.
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 developer on the panel finds |
|---|---|---|
| A content writer from outside | None, or a review at the end | Clean prose around claims no engineer made |
| A practitioner writer from outside | An interview, if one is arranged | Steps that run, with the reasons secondhand under a stranger’s name |
| The engineer, alone | Days, so it seldom happens | The real account, on the rare day it ships |
| The engineer, in the loop | Half an hour to talk, a rewrite pass, a colleague’s check | The builder’s own account, checked, under the builder’s name |
So budget the hour, not the headcount. No writer, ours included, can write what a developer checks without the engineer’s hour, and once that hour is in, who types the first draft matters far less than whether the engineer rewrote it and signed 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:
| Question | Where it came from | Page that answers it | Who knows |
|---|---|---|---|
| Why does a webhook stop retrying after three attempts? | Top-voted GitHub Discussion | Webhooks: retries and failures | The engineer who owns event delivery |
| Will it hold above a million events a day? | Comparison searches and sales calls | The comparison page, with the benchmark’s conditions | The performance lead |
Keep the docs on the same map, because they answer the same questions for the same reader. DevTune’s 2026 benchmark covered 421 developer-tool vendors. For 155 of them, 36.8% of vendors by our count of DevTune’s table, documentation was the page of their own site that AI answers cited most, ahead of the blog.
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 yields the material for a piece and usually ideas for two or three more, which makes the interview the cheapest step in the program.
Feathery is the closest case we can show, and it is not a developer tool: it sells forms to teams in insurance and financial services. On that partnership the founders’ expertise carried almost all the content, and whenever an article’s outline needed discussing, one of them found 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. Its buyers are not developers, but the short call with the person who knows the product carries over, and 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, then send them a day ahead. Open on the easy ones. Book the call through your own calendar link so you keep the recording and the transcript, which is the raw material for everything after it.
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 Engineer Writes It Up From a Draft Made of Their Own Words
The rewrite is the step that separates this method from ghostwriting. A ghostwriter writes the post in their own words and then asks the engineer to check it. Here the draft is built from the engineer’s own words, the engineer rewrites it until it says what they would say, and their name goes on it.
We draft with models, and we say so. At Empact Partners a model writes the first draft from the interview transcript and the docs, and from nothing else. A named consultant owns the angle, the order, and the cuts. The transcript is the input, which is why the draft already sounds like the engineer.
The failed version of AI drafting differs at both ends. It starts from public material, so it knows what everyone knows, and it ends with somebody who did not build the product checking the facts. The moderators of r/programming set the bar for all of it in their rules:
“Anything clearly written mostly by an LLM. If you don’t want to write it, we don’t want to read it.” — r/programming moderators, Jan 2026
The bar is right, and a model draft clears it only one way: the engineer rewrites it until it is theirs, until they could walk a colleague through every sentence in their own words. That is the test to apply to any author, us included.
That rewrite is where a program stalls if nobody designs it, so design it:
The editor works inside that loop, on the order, the cuts, and the sentences a reader trips on, and never on the engineer’s vocabulary. Engineers who were edited the other way remember it:
“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 rewrite 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 the person who signs.
Publish the piece under the engineer’s name and link it from the docs page the map matched it to. Then let the engineer reply in the thread where the question was first asked, under their own name, saying where they work.
Then expect an argument in the comments. A long, critical thread from developers who read the whole page is a better sign than polite silence: it means the right reader spent real time on it.
The Program Costs About an Hour of an Engineer’s Time per Piece
Count the engineer’s time honestly before anyone agrees to it. Per piece, the ask is a half-hour interview, a rewrite pass of about the same length, and a short check from a second engineer. The content team carries the rest: the map, the questions, the draft, the 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. What the engineer gets back is the byline, and an engineer in the same thread describes a public technical post as the kind of visibility that gets them considered for staff roles.
What a head of content can run this week is the first half. 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 signed by the person who built the feature.
That longer half is the Content Marketing work partners hand to us. A partnership with Empact Partners opens with an audit of the docs, the community questions, and what is already published, then a roadmap. A named consultant then runs the interviews and drafts from inside the partner’s own team, and the horizon is quarters.
Watch one number in the first quarter: how many of the map’s evaluation questions have an answer an engineer signed. Those signed 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 your developers keep asking and none of them is reaching the page, book a call with me to talk through whether it is work we should do together.
