Your engineers have the substance your content needs, and almost none of them have the time or the desire to sit down and write it. So stop asking them to. The move that unlocks a steady stream of genuinely technical content is to interview the expert and do the writing yourself, which turns a task they dread into a thirty-minute conversation they can do between meetings.
I have run this inside more than 30 companies, and it is the single biggest reason some devtools blogs are full of real, credible content while others sit empty with three half-finished drafts in a folder. The empty ones are usually waiting on an engineer to find a free afternoon to write, which never comes. Here is the version that works.
Why founders and engineers stall on content
It is almost never that they have nothing to say. The person who built your query planner can talk for an hour about why they made the tradeoffs they did. Put a blank document in front of that same person and ask for 1,200 words by Friday, and it sits untouched for a month.
Writing is a separate, slow skill from knowing the material, and it competes directly with shipping the product. Asking a senior engineer to produce finished prose on a deadline is asking them to do the thing they are worst at and least want to do, in time they do not have. No wonder it stalls. The thing blocking your content was never a shortage of knowledge, it was the expectation that the person with the knowledge also be the one to write it all up.
Interview them, do not assign them
The approach rests on one swap: instead of asking the expert to write, you ask them to talk, and you handle everything after that.
A focused conversation gets you the same substance with none of the friction. The engineer explains how the thing works, you ask questions, you record it. Then you take that recording and turn it into the post: the structure, the search work, the clear writing for someone reading it cold. They never see a blank page. Their only remaining job is to read the draft and tell you where you got the facts wrong, which is quick and which they are actually good at.
This is how I produced content across three distinct executive voices at once at Zerve, as part of a program that shipped more than 50 posts in a year. Three busy people, none of whom wrote a draft, all of whom sounded like themselves on the page. The same principle is what makes ghostwriting for a technical founder work at any volume.
How to run a good interview
Keep it to about thirty minutes and come prepared. Before the call, you should already know the topic and roughly what question it answers, ideally pulled from a real search query or a repeated support ticket. The interview is for the substance only, not for figuring out what to write.
Ask how the thing actually works, then keep asking why. Why that approach and not the obvious one. What breaks if you do it the naive way. What would a smart engineer get wrong on their first try. The gold is almost always in the why, because that is the part that cannot be looked up and the part that proves a real practitioner is behind the page. Record everything, with their okay, so you are listening and following up instead of scribbling notes and missing the good tangents.
When they say something sharp and specific, slow down and get the detail. Those exact phrases, the real numbers, the named edge cases, are what will make the finished post survive a skeptical read.
You write, they check, and the check stays narrow
Once you have the interview, the writing is yours. So is the structure, the headline, the internal links, and getting it to rank. When the draft is ready, it goes back to the engineer for one thing only: is this correct.
Keep that review ruthlessly narrow. You are asking whether the code runs, the claim is true, and nothing misrepresents how the product behaves. You are not asking them to copyedit, restructure, or weigh in on the title. A senior engineer will turn around a tight accuracy check fast. Hand them a line-editing job and the draft disappears for three weeks. This split is also what keeps a weekly cadence alive, which I get into in building a content engine that actually ships.
Protect their time like it is the scarce resource it is
The reason this keeps working is that it stays cheap for the expert. Thirty minutes of talking plus a short review, versus a lost afternoon of writing they resent. If you respect that trade, engineers will keep saying yes.
Batch the interviews when you can, so one sitting feeds several posts. Offer an async option for the review, a quick set of inline comments rather than a meeting. And never send back a draft riddled with obvious misunderstandings, because nothing burns an engineer’s goodwill faster than feeling like they have to rewrite your work. Do the interview well enough that the review is genuinely just a check, and they will treat the next request as easy.
When the expert is the founder
Early on, the subject matter expert is usually the founder, and the same method applies. They have the sharpest view of why the product exists and who it is for, and they have the least time of anyone. Interview them, write it, let them check it. Done right, they get thought leadership in their real voice without ever opening a blank document, which is the only version of founder content that survives contact with a busy quarter. If you want someone to run those interviews and turn them into a steady stream of content your buyers trust, that is the work I do, and you can tell me who holds the knowledge on your team.
