LinkedIn post ideas for engineers, and why tech posts underperform

Here is the finding that should shape how engineers approach LinkedIn: of the 1,628 technology posts in our corpus, only 59 reached the overall top decile. That is about 3.6% where 10% would be the neutral expectation, so technology content is roughly three times underrepresented among the posts that travel. The technology topic's median engagement rate is 0.39 per 1,000 followers against a cohort median of 0.40, and its median post drew 80 reactions and 7 comments against 122 and 12 across all 12,988 posts we scored in our study of what gets read on LinkedIn. The post ideas below are built around what that gap appears to be caused by, which is mostly format, not subject.

Why do technology posts rarely reach the top decile?

Start with the size of the effect, because it is larger than we expected. The technology topic holds 1,628 posts from 49 creators, which is one of the biggest topics in the corpus. If technology posts performed like everything else, roughly 163 of them would sit in the overall top decile. Fifty-nine do.

A second number makes the point more sharply. When we take technology's own top 10% (162 posts from 29 accounts, scored against other technology posts rather than against the whole feed), the median engagement rate of that group is 3.83 per 1,000 followers. The cohort-wide top decile begins at 5.95. In other words, the best technology posts, judged among themselves, mostly would not clear the bar to be top-decile posts overall. That is not true of the other large topics we looked at.

Three explanations are consistent with the data. They are not mutually exclusive and we cannot separate them with a correlational dataset, so treat this as reasoning about a real gap rather than a proven mechanism.

Explanation one: the format profile is the weak-content profile

Technology posts look, structurally, like the bottom half of the whole corpus. A third of them (33.2%) are shared articles. Only 11.8% are plain text, against 21.0% across the cohort. And 72.1% carry four or more hashtags, which is the highest figure of any topic we measured and nearly double the cohort figure of 35.0%. Every one of those traits is associated with weak performance elsewhere. Technology content has adopted the exact habits that correlate with not being read.

Explanation two: the person is missing from the post

Second-person language appears in 25.9% of technology posts against 36.4% across the cohort. Emoji appear in 2.8% against 6.1%. This is content written about a subject rather than to a reader, and typically the subject is a link. A post that reports what a company announced contains no claim anyone can agree or disagree with, so there is nothing to comment on, and comments are the scarce signal on this platform.

Explanation three: the audience is smaller and more specific

This one is not visible in our data but is worth naming honestly. A post about distributed systems is legible to a narrower slice of LinkedIn than a post about management, and engagement rate divides by follower count rather than by relevant follower count. An engineer with 3,000 followers of whom 200 understand the post is measured as though all 3,000 were candidates. That is a measurement artefact, not a failure of the content, and it means the numbers understate the value of good technical writing here.

One caveat on all three. Our technology bucket is topical, not occupational. It contains posts about technology written by journalists, investors, executives, and healthcare commentators as well as by engineers. So this is a finding about technology content on LinkedIn rather than about engineers specifically.

What separates the best technology posts from the worst?

We split the topic against itself: its own top 10% (162 posts from 29 accounts) against its own bottom half (814 posts from 26 accounts). The interesting result is how few things separate them.

Compare that to any other topic and the flatness is striking. In sales, second-person language runs 55.9% in the strong group against 27.3% in the weak one. In technology it is 28.4% against 26.9%: no difference. Questions: 16.7% against 15.7%, no difference. First-person openers actually run slightly lower in the strong group than the weak one. The language levers that work everywhere else are inert here.

What does move: hashtag discipline (49.4% against 79.6%), plain text (21.0% against 8.7%), numbers (42.6% against 32.9%), and getting the link out of the post (25.9% against 36.0%). Three of those four are mechanical rather than stylistic.

The practical implication is unusual and quite freeing. In most fields, improving your LinkedIn content means learning to write differently. For technology content, the biggest available gains come from stopping four specific habits: stacking hashtags, posting the link instead of the argument, letting the headline be the content, and writing about a company rather than about a decision.

The outcome gap is real even so: a median of 287 reactions and 37 comments in the strong group, against 50 reactions and 3 comments in the weak one. Three comments. A typical technology post on LinkedIn is a broadcast into an empty room.

What should engineers post instead?

The pattern across the strong technology posts is that they contain a claim someone could be wrong about, in plain text, with a specific detail that could not be generated from a headline. Here is one from the sample:

Nothing about it is clever. It is text, it is specific, and it enumerates real events. Note also the low comment count relative to reactions: 17 comments on 850 reactions. Technology posts get acknowledged more readily than they get argued with, which is another face of the same problem.

The second shape that works is the counterintuitive statistic with an implication attached, which is close to what a good engineering blog post does in its first paragraph:

Thirty-seven comments against thirty-one reactions from an account with under 3,500 followers. That ratio is the thing to aim for. It happens because the post does not stop at the fact: it draws a consequence, and the consequence is contestable.

Twenty-five post ideas for engineers

Decisions and trade-offs:

• Why your team chose one technology over the obvious alternative.
• A migration you did and what it actually cost in engineer-weeks.
• The abstraction you added and later removed.
• Something you built that you would now buy, or the reverse.
• A performance problem and the three things that were not causing it.
• The bug that took longest to find, and why it hid.
• A design you rejected, with the reasoning.

Operations and reality:

• What your on-call actually looks like in a normal week.
• An incident write-up, sanitised, with the timeline.
• The alert you deleted and nothing broke.
• Your deployment process, honestly described.
• What your test suite does not cover and why that is a choice.
• The legacy system nobody will touch, and what keeps it alive.

Craft and career:

• What you look for in a code review, in order.
• The interview question you ask and what the answers reveal.
• Advice you were given early that turned out to be wrong.
• What changed about your work when you moved from senior to staff.
• The non-technical skill that has mattered most.
• How you decide whether to fix or rewrite.

Opinion, where the comments live:

• A widely recommended practice you think is wrong for most teams.
• Where your field's conventional wisdom has not caught up with reality.
• What a tool is genuinely bad at, written by someone who likes it.
• The metric your industry reports that measures nothing.
• Why a popular architecture is usually premature.
• What you think will be obviously wrong about current practice in five years.

Notice that none of these is “here is an article about a new framework.” Every one of them requires you to have an opinion and to be identifiable as the person holding it. That is the entire difference between the strong and weak halves of this topic.

A useful filter before writing any of them: would a competent engineer at another company learn something they could not get from the documentation? If yes, publish. If the honest answer is that you are summarising something publicly available, you are writing a link post with extra steps, and the data on link posts is unambiguous.

The other filter is discomfort. The posts in the opinion group above are the ones most engineers skip, because being publicly wrong about a technical claim is embarrassing in a way that being publicly wrong about management is not. That asymmetry is real and it is also why the opinion posts are the ones that get read. If nobody could disagree with your post, nobody has any reason to reply to it, and replies are the currency here. A good compromise is to state the claim confidently and the confidence level honestly: “I think this is true for teams under thirty engineers and I am less sure above that” invites correction instead of attack. Structural shapes for doing this well are catalogued in LinkedIn post templates.

How should an engineer format a LinkedIn post?

The mechanics matter more here than the prose, given how flat the language findings are.

On length: across the whole corpus, the median visible hook is 206 characters in the top decile and 205 in the bottom half. Hook length does not separate winners from losers, in technology or anywhere else, so stop optimising it. What matters is what happens in those characters. The full treatment is in how long a LinkedIn post should be.

On links: the hashtag and link findings both point the same way, and the honest position on links is that the studies disagree with each other and LinkedIn denies a penalty exists. What our data shows is an association, not a mechanism. The competing evidence is laid out in the external link question, and the hashtag argument is in whether LinkedIn hashtags still work.

On text versus image: technology posts default to images (42.5% of the topic) and the strong half uses fewer of them. That fits the wider corpus finding that images over-index in the bottom half, covered in text posts versus image posts on LinkedIn.

How do you write about work your employer owns?

The constraint most engineers hit first. The interesting material is under an NDA, or under a policy, or simply under an unwritten expectation that you do not discuss internal systems. That constraint is real and it removes less than people assume.

What is usually protected: customer data, security specifics, unreleased plans, revenue and cost figures, and anything that identifies a named client. What is usually not protected: the general shape of a problem, the reasoning behind a decision, the trade-offs you weighed, and what you personally learned. You can write “we moved a write-heavy service off a relational store and here is the argument we had about it” without naming the service, the numbers, or the company.

Two habits keep this safe. Check your employer's external communications policy once, properly, rather than guessing forever. And when in doubt, describe the class of problem rather than your instance of it, and swap real numbers for ratios. “We cut p99 by roughly a third” carries the same weight as the raw figure and discloses nothing.

One thing not to do: post about an incident while it is ongoing, or about a system that is currently under attack. That is not a policy question. It is an operational one, and it is the sort of post that ends careers rather than starting them.

Should an engineer post on LinkedIn or write a blog?

Both, in a specific order, because they do different jobs and the common failure is treating them as substitutes.

A blog post is durable and searchable. It accumulates value for years, it can be long enough to actually teach something, and it is the artefact a hiring manager reads before an interview. A LinkedIn post is ephemeral and distributed. It reaches people who were not looking for it, which a blog almost never does.

The efficient pattern is to write the blog post and then write the LinkedIn post as an independent argument rather than a trailer for it. “New post on our blog about database migrations” is the weak-half pattern in one sentence: the link is the content and there is nothing to respond to. The version that works states the single most contestable claim from the piece, argues it in three hundred words, and mentions in the comments that a longer treatment exists. You keep the reach and you keep the durable artefact.

This also solves the input problem. Most engineers who stall on LinkedIn stall because they think each post needs a new idea. It does not. One piece of technical work generates a blog post, three LinkedIn posts arguing different parts of it, and a conference talk. The material is not the constraint.

Does it matter if AI helped write your technical post?

Two separate questions get conflated here, and only one of them matters.

The first is whether readers can tell. Often, yes, and for technical content the tells are expensive: a post that hedges everything, that lists trade-offs without picking one, or that describes a technology in the register of its own marketing site reads as someone who has not done the work. Engineers are an unusually good audience at spotting this, because the specific detail is exactly what they are reading for.

The second is whether it is against the rules. LinkedIn's Professional Community Policies ask members to only share information that is real and authentic and to disclose synthetic or altered media. Using a model to help you draft is not prohibited. Publishing a technical claim you have not verified is a different problem, and it is the one worth worrying about, because in engineering being confidently wrong in public is more costly than being quiet. The current state of detection is covered in whether LinkedIn can tell AI wrote your post.

Is LinkedIn worth an engineer's time?

Judged on reach alone, technology is a harder room than most, and we would rather say that plainly than sell you a channel. But reach is the wrong measure for this audience.

The reason engineers post is usually one of four things: to be findable by better employers, to be credible when they later want to start something, to help their company hire, or to work out what they think by writing it down. None of those require a top-decile post. A write-up read by forty of the right staff engineers and two hiring managers has done its job. The engagement number attached to it is close to meaningless.

So set the target accordingly. Comments from people whose names you recognise. Profile views from companies you would work at. Replies that argue with your reasoning rather than congratulate you. If you want the general benchmarks for context, they are in what counts as good LinkedIn engagement and you can run your own posts through the engagement rate calculator. Read them as context rather than as a target.

How do you start if you have never posted?

1. Take the last technical decision you made and write the version you would send a colleague at another company. Not a tutorial. The reasoning.
2. Cut the first two sentences. They are almost always context you added for yourself. The claim should be in line one.
3. Delete every hashtag except one.
4. Remove the link. If the post cannot stand without it, the post is a link with commentary, which is the weak-half pattern.
5. Add one number from your own work: latency, cost, engineer-weeks, incident count. Numbers separated the strong from the weak here at 42.6% against 32.9%.
6. End on the implication, not the summary. Give someone something to argue with.
7. Reply to every comment in the first hour. See the first hour after posting.

Repeat weekly for two months before drawing any conclusions. Two posts is not a sample. The examples from this topic, with their real reaction and comment counts, are on the technology post examples page if you want to read the strong half before writing.

The usual caveats apply to everything above. These are correlations, not causes. The cohort skews toward established creators with 1,000 or more followers across 65 accounts. Engagement counts were lifetime totals at the time of collection, so older posts had longer to accumulate. And all text findings describe the visible hook above LinkedIn's “see more” fold rather than full post bodies, which matters more for technical writing than for most, because the interesting part of an engineering post is usually below it.

The short version on LinkedIn post ideas for engineers

Technology content underperforms on LinkedIn, and the cause looks mechanical rather than intellectual: link shares, hashtag blocks, and posts written about a subject instead of by a person. Only 59 of the 1,628 technology posts we measured reached the overall top decile. The strong half of that topic is text-heavy, hashtag-light, number carrying, and willing to end on something contestable. None of the usual writing advice applies, because none of the usual language markers separate strong technology posts from weak ones. The LinkedIn post ideas for engineers that work are the ones where you say what you decided, what it cost, and what you would do differently.

Posting in a different role?

The patterns move with the role, so each of these is measured against that group's own strongest and weakest posts rather than the cohort average: founders, fractional executives, freelancers, job seekers.