80 Articles Across 6 Technical Verticals: What Writing for Defence, Aerospace, and Healthcare Taught Me About Expertise

Over two and a half years at Critical Software, a company that builds safety-critical software for industries where mistakes have consequences, I wrote more than 80 blog articles and web pages for some of the most demanding audiences in B2B: defence, aerospace, transport, healthcare, energy, and financial services. The readers were engineers and specialists who understood their field far better than I ever would. Time on site went up 30% and organic traffic grew 28% year on year, which tends to surprise people, because the instinctive assumption is that writing for technical audiences requires being a technical expert yourself. It doesn’t, it requires something else, and it took me a good chunk of those 80 articles to work out exactly what.

How do you write credibly about something you’re not an expert in?

Writing for technical audiences starts with being honest about your job: you’re not the source of the knowledge. You’re the person who finds it, understands it well enough to explain it, checks it with someone who actually knows, and turns it into something a reader will trust and act on. The moment you forget that and start performing expertise you don’t have, a technical reader catches you, because the people in these fields can smell a bluff in a sentence.

This is also roughly what Google’s own quality guidelines have settled on. The E-E-A-T framework, which stands for experience, expertise, authoritativeness, and trustworthiness, leans heavily on demonstrable knowledge, and the standing advice for content in specialised fields is blunt: when you lack the formal credentials yourself, you collaborate with verified experts to write or review the work. That’s the actual method, with the credibility coming from the rigour of the process rather than from a job title you don’t have. I made the fuller version of this argument in you don’t need to be technical to write for technical buyers, you need to be rigorous, and Critical Software was where I learned it the hard way, across six fields at once.

How do you get knowledge out of a subject-matter expert without wasting their time?

This is the skill nobody teaches, and for technical audiences it’s the one that matters most: the engineers and specialists I needed were busy, senior, and allergic to fluff, and their time was the most expensive input in the whole process; wasting it was the fastest way to never get a second meeting.

So I never walked in empty. Before talking to an expert I’d already done the reading, the public documentation, the existing material, the competitor content, whatever I could find, so I arrived understanding maybe 70% of the topic and knowing exactly where my 30% of confusion was. That meant I wasn’t asking them to teach me the basics, which they resent, but to fill specific gaps and correct specific misunderstandings, which they’re usually happy to do because it’s fast and it’s interesting to them.

I asked sharp, narrow questions instead of “so tell me about radar systems.” I’d say what I thought was true and ask them to correct it, because experts find it much easier to fix a wrong statement than to summarise a whole field from scratch. A good prompt was “my understanding is that X causes Y, is that right or am I missing something,” and the correction that came back was usually worth more than an hour of open-ended explanation.

And when I sent drafts back, I was explicit that I wanted an accuracy check rather than a writing critique. Engineers will happily rewrite your prose into something unreadable if you let them, so I’d flag the specific technical claims and ask only “is this correct, and is anything overstated.” That kept the review fast for them and protected the readability for me. Respecting their time that precisely is what turned one-off favours into people who’d actually pick up when I called again.

Why is getting it wrong not an option in defence or healthcare?

In most content marketing an error is embarrassing; for technical audiences it’s a credibility event that can lose you the reader permanently, and in the safety-critical and regulated corners of them, it can be a genuine liability. A defence or aerospace audience that catches one wrong technical claim will assume the entire piece is amateur and stop reading your company’s content for good.

So accuracy wasn’t a final polish, it was built into the process from the start. Every technical claim in a piece traced back to a specific source: official documentation, a standard, a published study, or a named expert’s confirmation. I kept the equivalent of a source log so that if anyone ever challenged a statement, I could show exactly where it came from; anything I couldn’t verify didn’t go in, no matter how good it sounded, because a confident sentence I couldn’t back up was a risk, not an asset.

Does the vertical change how you write?

Completely, and underestimating that is how generic content for technical audiences dies. The six fields I wrote for had genuinely different expectations, and the same article structure that worked for one would quietly fail in another.

Healthcare and financial services sit in what Google formally classifies as Your Money or Your Life territory, where the accuracy bar is explicitly higher because a wrong claim can affect someone’s health or finances directly. Writing for those readers meant heavier sourcing, more caution around anything that resembled advice, and a tone that earned trust through precision rather than enthusiasm.

Defence, aerospace, and transport brought a different pressure: these are safety-critical and often security-sensitive worlds, so the writing had to be exact about capabilities without ever drifting into claims the company couldn’t stand behind, and careful about anything that touched confidential or regulated territory. The tone there was measured and evidence-led, because the audience respects restraint and distrusts hype.

Energy and the broader engineering topics gave a little more room to be expansive and educational, but even there the technical precision had to hold. The throughline was that each field had its own definition of what credible sounded like, and learning to hear that difference was most of the job.

What does writing 80 articles in two and a half years actually look like?

Less glamorous than it sounds, and more systematic. That pace, roughly 30 to 35 substantial pieces a year, ran alongside the rest of the job, which included segmented email campaigns, internal communications to over 700 employees across four countries, and content for a company-wide rebrand. The volume was only possible because the process for serving those technical audiences was repeatable: research to a point, identify the gaps, get expert input efficiently, draft, verify against sources, publish.

The myth is that high output means cutting corners on quality, but the reality is closer to the opposite, because a sloppy process is slow: chasing experts for the same answer twice, fixing accuracy problems after publication, rewriting pieces that missed the field’s tone, all of that costs far more time than getting the system right once. I wrote about running this kind of solo content operation at volume in 60+ marketing pieces in 18 months, and the lesson held at Critical Software too: speed comes from the system, never from skipping the rigour.

Why did credible technical content grow organic traffic 28%?

Because credibility is what earns both the reader and the links; when a piece is genuinely accurate and useful to technical audiences, those readers stay longer, which is most of why time on site rose 30%, and the content gets referenced and linked to by other credible sources in the field, which is a large part of why organic traffic grew. Authority in search is built substantially on other authoritative pages pointing to yours, and nobody in a technical field links to content that gets the basics wrong.

This is the commercial case for quality that I’ve made before in good writing isn’t a nice-to-have in B2B, it’s your competitive moat. In technical verticals it’s even starker, because the audience is more discerning and the cost of looking amateur is higher.

What would you tell someone writing their first piece for technical audiences?

Drop the pressure to sound like an expert, because you’ll fail and they’ll notice; aim instead to be the most rigorous non-expert in the room, the person who did the reading, asked the precise questions, checked every claim, and respected the reader’s intelligence enough not to dress thin understanding up as authority.

Find your experts early and treat their time as the scarce resource it is, do your homework before you reach out, ask narrow questions, and send drafts back for accuracy rather than applause, learn the specific field’s idea of what credible sounds like before you write a word in its voice, because the tone that lands in energy will misfire in healthcare, and when you’re not certain a claim is right, leave it out. A shorter, accurate piece beats a thorough one with a hole in it every single time.

The expertise was never the point; the willingness to do the work that earns the trust of technical audiences was, and that part is available to anyone prepared to be honest about what they don’t know.