Your Engineering Expertise Deserves To Be Understood

I help you translate complex ideas into clear thought leadership that strengthens your reputation and helps others understand the value of your work.

If you work in engineering, you already know something most people outside the field don’t.

The best ideas usually come from the people closest to the work.

The ones designing the systems.
Running the models.
Solving the problems nobody else can.

In other words, people like you.

But when it comes to shaping industry conversations — articles, conference panels, media commentary, even LinkedIn discussions — those voices are often missing.

Not because the expertise isn’t there.

Because translating complex technical thinking into clear writing is a completely different skill.

And realistically, you probably don’t have the time to do it properly.

Meanwhile, the people shaping industry conversations aren’t always the ones with the deepest technical understanding.

Often they’re simply the ones publishing their ideas.

While you’re buried in project work — designing systems, solving problems, delivering real outcomes — the insights behind that work often stay inside internal reports, project documentation, or technical meetings.

Over time, that creates a strange dynamic.

The people doing the most important work often have the least visibility.

And the people influencing industry conversations — the ones speaking at conferences, shaping policy discussions, or attracting new opportunities — are often the ones who have simply learned how to articulate their thinking clearly.

Not louder.

Just clearer.

That’s where I come in.

I work with engineers and technical leaders to turn real-world expertise into clear, credible thought leadership — without hype, marketing jargon, or forcing you to spend hours trying to write it yourself.

The Engineering Communication Gap

The challenge you’re running into probably isn’t really about writing.

It’s something deeper.

Engineering and communication operate in two very different modes of thinking.

You’ve spent years learning to think in systems — constraints, trade-offs, assumptions, failure modes — the layers of reasoning required to make something actually work in the real world.

But communicating that thinking clearly requires a different skill entirely.

It requires structure. Narrative. Context. Knowing which part of the story actually matters to the person reading it.

And that’s usually where things break down.

You might have tried writing things yourself. Which makes sense — you understand the work better than anyone.

The problem is that engineers naturally optimise for precision, not readability. So the writing ends up accurate, but dense.

The real insight often sits buried deep inside technical explanation. And with project work already filling your schedule, writing properly rarely becomes the priority.

Maybe you’ve handed things off to a marketing team or agency.

That can improve readability, but it often introduces a different problem. If the person writing the material doesn’t really understand the engineering, they tend to default to broad, generic language.

You’ve probably seen it before…phrases like “innovative solutions” or “cutting-edge technology.”

It sounds polished, but it rarely explains anything meaningful about the work. And technical audiences can spot that immediately.

And then there’s AI, which you may have experimented with already.

AI is good at producing something that looks like a well-written article pretty quickly. But it’s also good at sounding plausible while getting subtle details wrong.

In technical fields, those errors matter.

If someone reads something with your name attached to it that misses the mark, it doesn’t just weaken the piece — it can quietly hurt your credibility too.

So while none of these approaches are inherently bad…

They only solve part of the problem.

You understand the engineering.

Writers understand communication.

But without someone translating between those two worlds, the real insight behind your work often never gets communicated clearly.

That’s the gap I focus on closing.

Translating Engineering Expertise Into Clear Insights Requires A Different Skillset

My background is a little unusual.

Before studying engineering, I spent years working in professional copywriting. Much of that work was in financial publishing — the kind of environment where you can’t just throw words around loosely.

It’s heavily regulated.

Every claim has to be defensible.
Every argument needs evidence behind it.
And every piece of communication has to balance clarity with precision.

You get used to operating in a space where accuracy really matters.

At the time, I didn’t realise how relevant that would become later.

But once I started spending more time around engineers — studying, working alongside technical teams, and speaking with people across the energy and power sector — I began noticing something familiar.

The communication challenges engineers face are very similar to the ones that exist in regulated financial publishing.

In both worlds, the ideas are complex. The details matter. And if something is simplified too aggressively, credibility disappears very quickly.

So the real challenge isn’t just writing clearly.

It’s holding two things in balance at the same time.

Clear enough that someone outside the immediate technical domain can understand what’s happening.

But precise enough that another engineer reading it doesn’t immediately think, “that’s not quite right.”

Spending time on both sides of that divide — professional communication and engineering thinking — made the underlying issue obvious.

You don’t lack expertise.

What’s usually missing is translation.

How I Help Engineers Translate Technical Work Into Industry Insight

The way I work with engineering teams is pretty straightforward.

Instead of asking you to suddenly become a content creator, I focus on extracting the thinking that’s already there.

Every engineering project contains interesting decisions — trade-offs, design choices, lessons learned, insights about how systems behave in the real world. But those insights usually stay inside project documentation or internal discussions.

My job is to surface those ideas and translate them into communication that other people can actually follow.

That usually starts with a conversation.

We talk through the work, the context around it, and what made the project interesting from an engineering perspective. From there, I turn that thinking into clear, structured pieces that can live outside the project — things that help clients, peers, and the wider industry understand what your team actually does.

Depending on the firm and the type of work you’re doing, that could take a few different forms…

Thought leadership

Articles or commentary that explain technical ideas in a way that positions you as a thoughtful voice in your field. The kind of pieces that spark conversations among engineers rather than sounding like marketing.

Engineering case studies

Turning complex projects into narratives that clearly show the problem, the engineering approach, and the outcome. These are useful for websites, proposals, and explaining the real value behind your work.

LinkedIn ghostwriting

Helping technical leaders like you share insights regularly without having to sit down and write everything yourself. Usually built from short conversations that get turned into structured posts.

Technical website content

Clear explanations of what your firm actually does and how your expertise fits into the problems clients are trying to solve. Less jargon, more clarity.

The goal across all of it is the same.

Not marketing hype.

Just clear, credible explanations of real engineering work.

How The Process Works

The process itself is pretty simple, and it’s designed around one main constraint: engineers are busy.

The last thing I want to do is create more work for you. So the whole system is built to capture your thinking efficiently and turn it into something useful without asking you to spend hours writing.

Usually it starts with a conversation.

We sit down and talk through a project, a technical idea, or something interesting your team has been working on. I’ll ask questions, dig into the decisions behind the work, and try to understand what actually made the engineering interesting — not just what was built, but how and why it came together the way it did.

That’s where most of the real insight lives.

Once I’ve got a clear picture of the thinking behind it, I translate that into a piece of writing that captures the story properly — structured, clear, and still technically credible. The goal isn’t to simplify the engineering so much that it loses meaning. It’s to present it in a way that someone outside the immediate project can follow.

Then you’ll get a draft to review. This is where we make sure the nuance is right, the details are accurate, and the piece actually reflects how you’d want the work represented.

Once that’s locked in, it’s ready to go.

That could mean publishing it as an article, turning it into an engineering case study for your website, adapting it into LinkedIn posts, or using it as supporting material in proposals and industry discussions.

From your side, it usually just means one conversation and a quick review.

The rest of the work happens on my end.

Who This Work Is Designed For

This kind of work tends to resonate with a fairly specific group of engineers.

Usually it’s people who are working close to complex systems — the ones designing infrastructure, analysing networks, modelling behaviour, or solving the kinds of technical problems that only really make sense once you’ve spent years in the field.

Consulting engineers, technical leads, principal engineers, or founders of smaller engineering firms who are deeply involved in the technical side of their work but are also starting to think more about how their ideas show up outside the project team.

You may work in sectors where the systems themselves are complicated and the broader industry conversation is moving quickly — things like power systems, renewable energy, grid infrastructure, and the wider energy transition. In those spaces, there’s often a huge amount of expertise inside engineering teams, but very little of it gets communicated clearly to the outside world.

That’s where this tends to be useful.

If you’re working in an area like energy, infrastructure, or engineering consulting, and you’ve ever noticed that the most interesting insights from your projects rarely make it beyond internal reports or technical meetings, then this approach usually resonates pretty strongly.

It’s not really for firms looking for traditional marketing.

It’s for engineers who want their thinking — the real technical reasoning behind their work — to be understood a little more clearly by the industry around them.

What Tends to Happen When This Is Done Well

When engineering expertise starts getting communicated clearly, the changes are usually pretty subtle at first.

Conversations with clients become easier. Instead of spending half the meeting trying to explain the context behind a project, people already have a rough understanding of how you think about the problem.

The work speaks for itself a bit more.

Over time, something else starts to happen as well. The ideas behind your projects — the reasoning, the trade-offs, the lessons learned — begin to circulate outside the project team. Other engineers reference them. Industry peers start to recognise your perspective on certain problems.

Your firm becomes associated with particular kinds of expertise.

Not because you’re trying to promote it aggressively, but because the thinking behind the work is now visible in a way it wasn’t before.

And that tends to open doors in fairly practical ways. Clients have a clearer sense of what you’re good at. Invitations to contribute to industry discussions or panels become more common. People who are trying to solve similar problems already understand how you approach the work.

None of that happens through marketing hype.

It happens through something much simpler.

Clarity.

When the reasoning behind good engineering becomes easier to understand, the credibility that was already there just becomes more visible.

What Clients Have Said About Working With Me

“Josh is friendly and professional to work with. He pinpointed all my requirements in our meeting and delivered professional work that I can be proud to show my clients. I’ve already recommended him to others.”

Liam Kelly, Protest CMT

“I have had the pleasure of using Josh’s copywriting skills for not only my own company website but also a major project I am building out at the moment. Josh’s professional and friendly nature make him an absolute pleasure to deal with and his copywriting skills are exceptional.”

Darren Boal, Stang Digital

“I’ve hired Josh for several projects because he is a talented and dedicated writer.”

Daniel Neale, Motionstory

Start With a Conversation

If you’re interested in exploring whether this approach could be useful for your team, the first step is simply a short conversation.

There’s no obligation — we’re just seeing whether it’s a good fit.

We’ll talk through the kind of work you’re doing, where communication tends to get difficult, and whether translating some of those insights into industry content would actually be valuable.

Because this work involves deep conversations and careful translation of technical thinking, I only take on a small number of clients at any given time.

If it looks like a good fit, we can discuss availability and what next steps might look like.

Book a conversation below.

Common Questions

Usually not very much.

Most projects start with a structured conversation where we talk through the work, the context around it, and what makes the engineering interesting. From there, I handle the writing and structure.

You’ll receive a draft to review to ensure the technical details and nuance are correct, but the goal is to minimise the amount of time you need to spend on the process.

Accuracy is a core part of the process.

Every piece is built around conversations with you or your team, so the writing reflects the actual thinking behind the work rather than assumptions from the outside.

Drafts are also reviewed with you before publication to make sure the technical reasoning, terminology, and nuance are correct.

No.

The goal is not promotional copy or marketing slogans.

The focus is on explaining the real engineering thinking behind your work — the decisions, trade-offs, and insights that make projects interesting from a technical perspective.

When that thinking is communicated clearly, credibility tends to follow naturally.

The initial conversation is simply an opportunity to understand the type of work you’re doing and where communication tends to be challenging.

If it looks like translating some of those insights into industry content would be useful, we can talk through what a small initial project might look like.

If it doesn’t seem like a good fit, that’s completely fine — the conversation is simply about exploring the possibility.

That usually becomes clear quite quickly in conversation.

If your work involves complex technical thinking, interesting project decisions, or insights about how systems behave in the real world, there is often material worth translating into clear communication.

The goal is simply to make the thinking behind that work easier for others to understand — whether that’s clients, peers, or the wider industry.

If those kinds of conversations already happen inside your team, there’s usually something valuable there.