LinkedIn content and personal branding playbook for software engineers

A LinkedIn content and personal branding playbook for software engineers is a short list of post types, each tied to an artifact from a system you already run, plus a filter for what you are allowed to publish. It is not a follower target, a morning-routine series, or a second job as a creator. The reader who matters is a hiring manager, a staff engineer on another team, or a teammate who will forward one paragraph into a design review. They need a named constraint, a number with a window, or a refusal. They do not need a recap of a public tutorial.

Engineers lose this game in a specific way. The work is real and the draft is empty, because the interesting sentences are under an NDA, a customer name, or an unreleased design. The fix is a smaller artifact, not a louder hook. Publish the tradeoff you can defend in public. Leave the hostname, the revenue, and the colleague's diff out.

Boykli is the writing and queue layer for that smaller artifact. Create posts drafts from a note, a YouTube URL, an article, a document, or series source text, and the writer has to keep your nouns and drop statistics, studies, quotes, and anecdotes that are not in the source. Voice Agent does the same job from a live interview: three drafts, and only facts that appear in the transcript. The queue publishes an approved draft to the personal profile you connect with LinkedIn OAuth. It does not post to a company Page, and it does not comment, like, connect, or message. That product decision is the same one in building Boykli: the words start from something you brought, and you read them before they leave.

If you are the founder, the buyer-facing cut of this playbook is the B2B founder personal branding playbook. Founders can often name a price and a refund count. Employed engineers usually cannot. This page is the employed cut: incidents, designs, measurements, and review rules that survive a comms check. If you run the engineering organization and the post has to explain a decision the org will live with, that cut is the CTO personal branding guide: technical storytelling with a constraint, a cost, and a number you can say in public.

Logged-in visitors can browse Radar and Algorithm without a plan. Writing, images, carousels, Voice Agent, publishing, and scheduling need a paid seat. BYOK is $29 a month. Managed is $88 a month. Prices are the public list on boykli.com.

Three ways engineers try to "build a brand"

The middle column is what most "personal branding for engineers" advice actually ships: pillars, hooks, and a weekly theme about leadership. Pillars are filing labels. They become posts only when each one names a fact from your week. A founder-shaped list of those facts is on the LinkedIn post ideas for founders page. Use it only when the fact is yours. A refund story from a company you do not run is someone else's post.

Eight post types an engineer can defend

Each type answers one question a stranger can ask after they read your name. The artifact is the minimum source. If you do not have it, or if policy says you cannot publish it, skip the type this week. Do not substitute a general claim.

The write mode is the Boykli control that fits the length. Short is about 30 to 75 words and the page label says 45–400 characters. Medium is about 100 to 250 words (400–1400 characters). Long is the room for an objection plus a metric (1400–3000 characters). YouTube, article, document, and series (2 to 8 posts) are the other modes. Tone, hooks, and the call to action are separate switches. LinkedIn's own composer is plain text with a 3,000-character post ceiling. It has no code-block button. How lookalike letters fake bold and monospace is the subject of the LinkedIn text formatting tool page. Boykli does not apply that swap. A diff belongs in sentences, or in a PDF carousel where each slide holds one field.

These eight are enough for a year of employed writing. A ninth type, the compensation screenshot, belongs only when the number is yours, the window is named, and you accept the replies. The writer will not invent a salary band. If the note does not contain the number, the draft should stay thin.

The examples below are shapes of notes. They are not records from Boykli's customers, and they are not a suggestion to publish a number your employer has not cleared.

Incident you can tell

This is the type other on-call engineers forward. They want the mechanism, not a lesson about blamelessness.

Example note:

Checkout returned 502s for 14 minutes, Tuesday 18:40–18:54 UTC. The payments client timed out at 8 seconds. A deploy doubled the workers and left the DB pool at 10. We raised the pool to 40. Error rate in that window was 18% of checkout attempts, then under 1% in the next hour. We did not change the timeout. We did not estimate revenue.

Long mode can hold that note. The draft should keep 14 minutes, 18:40–18:54 UTC, 8 seconds, pool 10 to 40, 18%, and under 1%. It should not add a dollar figure you did not compute. "We did not estimate revenue" is a stronger line than a loss number you invented in the draft. If the comms team says the percentages stay internal, delete them before you write. A timeline without rates is still a post. A post with rates you were told not to share is a problem the queue cannot fix, because the queue sends the text you approved.

If the timeline is a sequence, series mode can split it. Post 1 sets the symptom. The last post says what you changed. "Part 2 of 5" is not allowed to be the only opening line.

Design decision

Staff interviews and design reviews both ask this: what were the options, what constraint made one of them win, what did that choice cost?

Example note:

We needed fan-out to 200 internal subscribers. Option A was a new broker. Option B was the queue we already run, with a single consumer group and a 30-second visibility timeout. We picked B. Cost: a subscriber that crashes mid-handler can see the same message twice, so handlers must be idempotent. We did not measure broker cost. We measured that B shipped in the same sprint because the client already existed.

Medium or long mode. Keep 200, the 30-second timeout, and the idempotency cost. Do not let the draft rename option B to a product you did not use, and do not add a latency percentile that is not in the note.

A document you already wrote is a better source than a reconstruction. Document mode uses the file, not the filename. Upload the design note you are allowed to share. If the file still contains an internal link or a customer name, delete those lines in the file first. The writer is instructed not to invent, and it will still quote what you left in.

Measurement

One number, one window, one environment, one exclusion. "The hot path went from 42 ms to 11 ms p50 on a replay of Tuesday's traffic, 1.2 million requests, same instance size. That excludes the cold start. We did not publish p99." A reader can attack the definition. They cannot accuse you of borrowing a benchmark from a vendor blog.

Skip this type in a week when you did not measure. "It feels faster" trains the audience to ignore the next number you publish. Short mode is enough when the sentence is complete. Medium mode is for the exclusion.

Review rule

The artifact is a rule you actually enforce, plus a before and after that you wrote yourself or that comes from a public repository.

I reject PRs that catch an error and log it without returning. Last week a handler logged a failed write and still returned 200. The caller retried nothing. The rule is: if you catch it, you return it or you handle it. Logging is not handling.

Do not paste a teammate's diff, their name, or a screenshot of the review tool. The rule is yours. Their patch is not your content. Short or medium mode. If you need the longer walkthrough, put the before and after on two slides of a carousel and keep the caption as the rule in one sentence.

Tool refusal

Engineers trust a refusal more than a roundup. "We tried to put traces in the same store as logs. Cardinality from one high-label endpoint priced us out in week two. We kept logs where they were and sampled traces at 5% on that endpoint only. We did not turn tracing off." Name the limit you hit. Skip the twelve-tool list. If a vendor sponsored the post, say so in the post. A hidden sponsorship is a different product from a design note.

Maintainer note

Open source is the cleanest artifact an employed engineer has, because the issue, the version, and the behavior are already public.

v2.4.1 stopped retrying HTTP 429 forever. The cap is 3 retries, then the error surfaces. If you depended on the infinite retry, pin 2.4.0. We will not put the infinite retry back.

Short mode. Link the release if you want. The post should still contain the behavior change, because many people will not click.

Hiring criterion

You can publish how you evaluate. You cannot publish who you evaluated.

The onsite exercise is a small service with one flaky test. I am listening for whether the candidate isolates the flake before they rewrite the service. I am not listening for a particular framework.

That sentence is safe if it matches the loop you actually run and your company is fine with it being public. A candidate's answer, their name, or a question you were told is confidential is not a post. When in doubt, skip the type. The other seven do not require a hiring story.

Scope decision

This is the employed version of a founder decision memo. The artifact is a choice about your own job: what you stopped owning, what you refused to staff, how you wrote the promotion packet.

I dropped two standing meetings and kept the on-call review. The review is 25 minutes, once a week, and it only covers incidents with a user-visible symptom. The other meetings were status. My manager agreed in writing. I do not have a productivity metric for the change.

Long mode. Keep the 25 minutes and the written agreement. Do not add a percentage of "time saved" you did not track. Career posts die when they become advice to strangers. They work when they stay a decision with a constraint.

A week, from note to a queued post

Three specific posts a week is a full cadence on top of an engineering job. One is a maintained cadence. Zero is the correct count in a week with no artifact you can publish. Daily posting usually collapses the eight types into tips.

1. Pick one artifact from the last seven days. A PR description you wrote, a design note, a benchmark, a release note, a review rule, or a sentence you said in a design review and would say again in public. A product incident you observed yourself counts, including a car software update. The note rules for that kind of post, written against the quoted search owners type, are in building Boykli.
2. Write the source note in plain sentences. Include the nouns: system, constraint, number, window, option you refused, and what you did not measure. If a sentence needs a customer name, an internal hostname, an unreleased feature, or a colleague's performance, delete that sentence now.
3. Check the comms or open-source policy before you write, not after the draft sounds good. A polished draft is harder to abandon than a rough note. If the answer is no, stop. The playbook has nothing to say to a policy that forbids the post.
4. On boykli.com, confirm a paid seat. Browsing Radar does not write. On BYOK, save the OpenRouter key before you write. Google AI Studio is only required for Voice Agent and for a YouTube watch when the video has no captions.
5. Choose the mode that fits the note. Short or medium for a review rule or a release. Long for an incident or a scope decision. Document mode when the design note is already a file. Series only when the decisions are actually sequential. Carousel when each slide can hold one field of the same note, at 2 to 8 slides. The caption is still a post, and it should repeat the decision in words.
6. Read the draft against the note. Delete any statistic, customer, or anecdote that was not in the source. Each draft allows two refinements. "Cut the second paragraph" is a refinement. "Make it more me" spends one of the two on a guess, because there is no stored profile of you. Posts are written with Grok 4.6. There is no model picker on Create posts.
7. Read it at phone width before it is queued. The LinkedIn post preview page is the check for line breaks and the fold. A 3,000-character incident with the cause in paragraph six is a post people will not finish. Move the change and the number up.
8. Queue the approved draft on the personal profile you connected. Pick the slot yourself. A public reading of when posts tend to travel is the best time to post on LinkedIn guide. Boykli does not pick the hour for you, and it does not post while you are asleep unless that slot is one you already approved. The queue will not publish without a generatable plan.

Managed accounts have a monthly cap of 130 post refinements, inside a broader cap of 210 posts, 150 carousels, 150 images, and 25 Voice Agent sessions. BYOK has no Boykli generation cap. You pay OpenRouter for chat and images, and Google AI Studio for Voice Agent. Platform keys are never used on a BYOK seat. An AppSumo lifetime code redeemed at /redeem is a BYOK seat, one code for one account. An existing paid seat blocks redeem.

If the week's work is a public talk or a long design doc you may share, you do not retype it. A YouTube URL becomes one post, and a separate 2–8 slide PDF if you want slides. An article URL works the same way. Both still require you to read the draft. A page the fetcher cannot read does not become a confident summary. The longer version of writing from a decision you already made, without a generic prompt, is LinkedIn thought leadership automation.

What distribution you should expect

A technical post does not get a special lane. LinkedIn still has to retrieve the post and then rank it for people who follow you and, sometimes, people who do not. The public description of that split is the LinkedIn algorithm guide. Boykli's Algorithm page is a reading of those public notes. It does not show your impressions, and the product does not connect to LinkedIn analytics.

What you can control is whether a stranger can repeat the point after one read. "Pool went from 10 to 40, timeout stayed at 8 seconds" is repeatable. "Reliability is a team sport" is not. Out-of-network distribution, when it happens, happens because someone who already follows you spent time on the post or responded with substance. Pods, comment scripts, and connection spam are outside this playbook. The queue does not do those things, and you should not bolt them on. How that fails is covered in grow a LinkedIn audience without pods.

Comments are part of the work and a small part. Reply when you can add a constraint or a correction. "Thanks, great point" trains nothing. One useful reply is enough. You do not owe the thread a second shift.

Headline, About, and Featured

The headline is the standing line under your name, capped at 220 characters. It should say the role, the kind of system, and the employer or the project, in nouns a recruiter already searches.

Staff engineer. Payments and on-call at Northwind. I write about pools, timeouts, and the numbers we refused to publish.

That is a headline. "Passionate builder | AI | thoughts on leadership" is a label that matches every other profile in the search result. Rewrite the headline when the role or the system changes. Do not rewrite it to match this week's hook. The week's post can be a pool-size incident without the headline changing. The LinkedIn headline page separates that 220-character line from the opening line of a post. They are different jobs.

About can hold three sentences: what you own, what you will not talk about in public, and where the code or the writing lives. Featured should be two or three posts that still match the headline. A viral tips post from two years ago teaches the wrong reader to follow you. Pin the incident, the design decision, or the maintainer note.

The company engineering blog, when you have one, is a different surface. It goes through review, it ranks for the company's name, and the URL belongs to the company. Your personal profile is the place a future teammate checks to see if you can explain a system without a committee. Do not paste the blog post and the profile post as duplicates on the same morning. Run the profile post as the smaller artifact: one decision, one number, a link to the essay if the essay is public.

FAQ

Do I need a large following before this is worth doing?

No. The first useful outcome is a stranger who can repeat the point, or a recruiter who references a specific post. That can happen from a few hundred relevant followers. A large audience that followed you for career tips will not forward a pool-size incident. Write the incident anyway. The audience definition used on this site is repeatability and a later conversation, not a follower count.

Will my employer object?

Sometimes, and they are allowed to. Read the policy before you draft. Production percentages, customer names, security details, unreleased designs, and other people's performance are the usual stops. A public release note, a talk you already gave, an open-source change, and a career decision about your own calendar are the usual clears. If you are unsure, ask the person who owns comms and accept a no. Boykli will publish what you approve. Approval inside the product is not approval from your employer.

Should I paste code?

A few lines, in sentences, when the lines are yours and public. The LinkedIn composer will not render a fenced code block. Backticks show up as backticks. A long function becomes a gray rectangle of monospace lookalike letters if you run it through a Unicode formatter, and spaces in that trick do not line up. Put the longer walkthrough in a 2–8 slide PDF. Square is 1080×1080 and portrait is 1080×1350, which is the subject of the carousel dimensions page. One claim per slide. The caption still has to stand alone, because many people never swipe.

How often should a working engineer post?

One defended post a week beats five tips. Two is a stretch during an incident-heavy week. Zero is correct when you have nothing you can publish. Batch the writing if you want the posts to leave on a schedule. A two-hour block that queues several approved drafts is the batch scheduling workflow. The clock does not create the artifact. You still need the note.

Can an AI ghostwriter do this if I hate writing?

It can draft from a note or from a Voice Agent transcript. It cannot attend the incident or clear the comms review. Paste the note, or say the note out loud, then delete anything the draft added. A prompt that says "write a thought leadership post for a staff engineer" produces the middle column of the first table. The source still has to be yours. How a topic-only prompt fails is the ChatGPT to LinkedIn guide. Create posts stays on Grok 4.6 either way.

Is this for job seekers, or for people who are staying?

Both, and the posts are the same. A hiring manager and a future teammate forward the same design decision. A post written as "open to work" advice dates immediately. A post written as "we kept the timeout at 8 seconds" is still true when you are not looking. If you are looking, say so in the headline or Featured, not by bending every incident into a moral about resilience.

What does a week of this cost?

The seat is the cost on the Boykli side. BYOK is $29 a month and uses your OpenRouter key for chat and images, with no Boykli generation cap. Managed is $88 a month and uses platform models inside the caps above. You still need a paid seat to write, to make the carousel, to use Voice Agent, to publish, or to schedule. Browsing is free. Cancelled access continues until current_period_end if that date is still in the future.

Where should the profile link go?

One link is enough. Use the personal site, the public GitHub, or the company engineering blog if the essays are public. A link-in-bio stack of twelve offers looks like the tips account in the first table. The posts themselves should be readable with no click. The link is for the person who already decided you can think.