Most developers' experience of LinkedIn is a feed of motivational posts with one sentence per line and a closing question nobody wants to answer.
That format exists because it worked, once, for a certain kind of account. It is not the only thing that works, and for a technical audience it is actively counterproductive.
What actually reads well from an engineer
The posts that land are specific, concrete, and about a real thing that happened.
I spent four hours yesterday on a bug in our export feature. The fix was one line. The interesting part was that the cause was an assumption I made three months ago and had stopped thinking about.
No hook formula, no line breaks after every clause, no closing question. It works because the first sentence contains a real detail and the second promises something the reader cannot predict.
This is not a different technique from the one that works elsewhere. It is the same technique without the costume.
The three things to drop
"I'm excited to announce." Everyone knows this means an announcement is coming and most people scroll past on reflex. Lead with the thing itself.
One sentence per paragraph throughout. Some line breaks help LinkedIn's rendering. Every sentence as its own paragraph is a mannerism, and on a technical subject it makes the writing harder to follow rather than easier.
The engagement question. "What do you think?" and "Agree?" are requests for a favour. If you have a real question, ask it. Otherwise end the post.
What to keep
Short paragraphs. Two or three sentences. LinkedIn renders long blocks badly and people read on phones.
A hook that is a fact. The first line decides whether the rest is read, which is true everywhere. A concrete detail works better than a tease.
Whitespace between ideas. Not between sentences.
Length
100 to 220 words is the working range for most posts. Up to 350 for a genuine technical breakdown. The limit is 3,000 characters and you should be nowhere near it.
Long posts are not more substantial. They are usually the same content with more setup.
The thing engineers get right by default
Technical people tend to include specifics because specifics are how they think. That instinct is correct and undervalued.
"Firestore, a scheduled function, and one model call per scan" beats "a modern serverless architecture" every time. The specific version is more interesting, more credible, and impossible to write unless you actually did the work.
The temptation on LinkedIn is to strip specifics out because the platform feels like it wants generalities. Resist it. The specifics are your advantage.
Who is actually reading
Worth being clear about, because it changes what to write.
Your LinkedIn audience is a mix: other engineers, former colleagues, recruiters, and people in adjacent roles who half understand what you do. That is different from X, where the audience self selects toward people who care about the specific thing.
The implication is not to dumb it down. It is to make the point legible without requiring the detail. Keep the specifics, but make sure someone who skims the technical part still gets what happened and why it mattered.