Why Technical Companies Struggle to Explain What They Do

Sharing is caring!

Reading Time: 8 minutes

I have sat in a lot of first meetings with technical businesses. There is a moment in almost all of them that I have come to expect.

Someone starts explaining what the company actually does. Not the version from the brochure, the real version, usually because I have asked a question that annoyed them slightly. And it is brilliant. Clear, specific, occasionally funny. Twenty minutes in I understand exactly what they do, why it is difficult, and why they are better at it than the firm down the road.

Then I go home and read their website. And I cannot find a single trace of that conversation anywhere on it.

This happens so consistently that I stopped thinking of it as a writing problem. It is not that technical people cannot communicate. Most of them communicate beautifully, right up until the moment they are asked to write something down for strangers. Then something goes wrong.

Here is what I think is actually going on.

You cannot unknow the thing you know

In 1990, a psychology student at Stanford called Elizabeth Newton ran an experiment that has stuck with me ever since I first read about it.

She split people into two groups. Tappers and listeners. The tappers got a list of twenty-five very well known songs, picked one, and tapped out the rhythm on a table. The listeners had to guess the song.

Before they started, Newton asked the tappers how often they thought the listeners would get it right. They said about half the time.

Across 120 songs, the listeners guessed three. Two and a half percent.

The reason is simple once you see it. When you tap out a song, you can hear the whole thing in your head. The melody, the words, the instruments. It is playing in there while your finger moves, and it feels obvious. The listener hears knocking on a table.

This is called the curse of knowledge, and it is not a failure of intelligence or effort. It is that once you know something, you genuinely cannot reconstruct what it was like not to know it. The knowledge sits between you and the person you are talking to, and you cannot see round it.

Now think about someone who has spent twenty years in subsea inspection. When they write a sentence about their work, the entire context is playing in their head. The vessel. The client. The thing that went wrong in 2011 that taught them to do it this way. Every word carries all of that, for them.

The reader gets knocking on a table.

You were trained to write like this

The second thing is that technical people are not bad writers. They are very good writers, at something else.

I trained as a design engineer before I did this, and the writing I did then had rules. Be precise. Be complete. Remove ambiguity, because ambiguity in a specification is how things get built wrong. Never claim more than you can evidence. Assume the reader is a peer who will check your work and enjoy finding an error in it.

That training produces excellent specifications, reports and tender responses. It is exactly right for those documents.

It is close to the worst possible training for a website.

Because a website is read by someone who is not a peer, who is not checking your work, who will not read to the end, and who is trying to answer one question: are these the right people to talk to? Precision does not answer that. Completeness actively works against it, because completeness means length and length means they leave.

So you get websites written with all the discipline of a technical document and none of the purpose of one. Accurate, thorough, defensible, and completely unpersuasive.

The person reading is not who you are picturing

When technical firms write their website, they tend to imagine another technical person reading it. Someone who will appreciate the detail and recognise the significance of the accreditations.

Sometimes that is who reads it. Often it is not.

It might be someone in procurement building a shortlist of six. It might be a commercial manager who has been told to find options by Thursday. It might be an operations lead who knows the discipline but not your corner of it. It might be a founder’s assistant.

None of those people are unqualified to judge you. They are just judging you on different criteria than you expect. They want to know whether you do the thing they need, whether you have done it before at their scale, and whether you seem like a business that returns calls.

A page that opens with your quality accreditations answers none of that.

Everyone adds. Nobody removes.

There is a structural reason too, and it is the one nobody wants to name because it involves colleagues.

Technical company websites are usually written by committee. A draft goes round. The technical director adds a paragraph on methodology because it was missing. The commercial lead adds the sectors, because a client asked about one last month. Someone from HSE adds the safety record. Someone adds the parent company. Someone adds a line about being at the forefront.

Every one of those additions is reasonable on its own. And nobody, at any point, deletes anything, because deleting someone’s paragraph is a conversation and adding your own is not.

What comes out the other end is not a piece of writing. It is a settlement. It reads like a list because it is a list, of everything nobody was willing to argue about.

The version that worked was the one that person gave me out loud in the meeting, before the committee got hold of it.

The fear that sits under all of it

This is the one that comes up in the room rather than in the brief, and it is worth saying plainly, because it is the real blocker.

Technical people are frightened of sounding unserious.

If you simplify your work, you worry that a peer will read it and think you have gone soft, or that you are overselling, or that you do not really understand the depth you are glossing over. In an industry where your reputation travels by word of mouth through a small network, that is not a silly fear. It is a rational one.

So the writing hedges. It stays technical as a form of insurance. It would rather be impenetrable than embarrassing.

I understand it. But it is costing you work from people who never got far enough into the page to judge you either way.

What actually works instead

None of this is fixed by hiring someone to make your website friendlier. It is fixed by changing what the words are trying to do. Five things help.

Say it out loud first

The version you give in a meeting is almost always better than the version you type. It is shorter, it starts with the point, and it does not contain the phrase “solutions provider”.

So record yourself explaining it to someone. Transcribe that. Start there. You will find you naturally led with the problem, used a real example, and skipped the accreditations entirely, because out loud you can feel the other person losing interest and you correct for it in real time. Writing gives you no such feedback.

Ask so what until it stops being interesting

This is the most useful habit I know for technical copy. Take any sentence about your capability and ask what it lets the client do. Then ask again.

Start:  “We provide advanced non-destructive testing using phased array ultrasonic inspection.”

So what?  It finds flaws inside a weld without cutting anything open.

So what?  You can tell whether a weld is failing without taking the asset apart.

So what?  You find out before it fails, not after, and you do not lose production to an inspection.

Landing:  “We find failing welds before they fail, without shutting you down.”

That final sentence contains no jargon and loses nothing. The phased array detail still belongs on the page, further down, for the reader who wants it. But it is no longer the door.

Most technical websites are made entirely of the first line. The client is looking for the last one.

Lead with the problem, not the capability

A capability is what you have. A problem is what they have. Only one of those is why they are on your website.

This is a reordering rather than a rewrite, which is what makes it the cheapest fix available. The same page, with the client’s problem in the first paragraph and your methodology in the fourth, performs enormously better than the reverse. Nothing is lost. Everything is still there.

Write for the person who has to defend choosing you

This one gets overlooked and it matters more than almost anything else.

In most technical purchases, the person who finds you is not the person who signs off. They have to go and make the case internally, often to someone more senior and more sceptical, sometimes to a committee.

Your website is the ammunition they take into that meeting. If it gives them a clear sentence about what you do, one specific piece of evidence, and a reason you are the sensible choice, you have made their job easy and they will fight for you.

If it gives them four hundred words of methodology, they will pick whoever was easier to summarise.

Keep every bit of the detail. Move it.

I want to be firm about this because it is where technical clients get nervous and where a lot of copywriters get it wrong.

The answer is never to strip out the substance. Your depth is the reason anyone should hire you, and a page that has been sanded down to reassuring vagueness will lose you the technical reader immediately. They can smell it.

The answer is sequence. Clear statement first. Evidence second. Depth third, for the person who wants it, on a page of its own if it needs one. Everybody gets served, in the order they need serving.

Clarity is not the same as simplifying

Worth separating these two properly, because they get confused constantly and the confusion is what keeps technical websites bad.

Simplifying means removing complexity. It makes the work sound smaller than it is, and technical readers correctly distrust it.

Clarity means keeping the complexity and organising it so that someone can find their way through. The complexity is still there. You have just stopped making the reader do the work of arranging it themselves.

A good technical page is not the easy version of a hard subject. It is the well-ordered version. Those are different things, and only one of them makes you sound less capable.

The test

Here is the only quality check you need, and it costs nothing.

Give your homepage to somebody who does not work in your industry. A friend, a partner, someone from a different department. Ask them one question: what does this company do, and who is it for?

If they hesitate, or answer with a phrase lifted straight off the page because they have nothing of their own to say, the page is not working. Not because they are the buyer. Because if someone intelligent and willing cannot extract it in thirty seconds, someone busy and sceptical certainly will not.

Most technical firms have never run this test. The ones that do usually find it uncomfortable and then find it clarifying, in that order.

The good news

Of all the problems a technical business can have, this is a comparatively pleasant one.

You are not trying to become something you are not. You are not inventing a story or manufacturing a difference. The substance is already there, in the heads of the people who do the work, and it comes out perfectly well in conversation. It just never survives the trip onto the page.

Getting it out is largely a matter of asking better questions, listening properly, and being willing to delete things. Which, conveniently, is most of what I do.

If your website is not doing your expertise justice, that is the work I do with energy and engineering firms. Or tell me about your business and I will tell you honestly whether it needs fixing.

Sharing is caring!