“Make me active on LinkedIn” describes an activity. It does not yet explain what your content should do. A short, specific brief saves you far more revision time than a long list of topics.
Name the reader before the topic
A frontend developer writing for engineering managers needs a different post from a frontend developer teaching beginners. Both can discuss performance, but one might explain delivery trade-offs while the other walks through a loading-state mistake.
Write down one primary audience and one thing you want them to associate with you. For example: “Product teams who need a frontend developer that thinks about accessibility.” This is more useful than “everyone in tech.”
Bring evidence from your actual work
Collect a few notes from work you can discuss publicly: a decision you made, a pattern you noticed, a question colleagues ask, or a mistake you now avoid. Remove client names and confidential details unless you have permission to share them.
You do not need impressive numbers to make a useful point. A clear explanation of why you chose a simpler solution can say more about your judgment than a vague claim about a large project. If you include a number, keep the source and context with the brief.
Explain your voice with examples
“Professional but friendly” means different things to different writers. Send two or three posts you like and explain what works: short openings, direct advice, Egyptian Arabic with familiar English technical terms, or calm explanations without exaggerated hooks.
Also send a few sentences you wrote yourself. These help a writer understand your usual sentence length and vocabulary. Do not ask for a copy of another creator’s personality. Use references to describe choices, not to borrow their stories.
Agree the boundaries
List subjects you do not want to discuss, information that must stay private, and claims that need your approval. Decide whether first-person stories can only come from your notes. Agree the language and the size of the first batch before work begins.
For automatic publishing, make the review step explicit. Who confirms the batch is ready? What happens when a draft needs a correction? A schedule should support a clear approval process, not turn uncertainty into a live post.
A brief you can send in one message
Use this outline: “I work in __. I want to reach __. I want to be known for __. Three topics I can speak about are __. My preferred language is __. Here are two examples of my writing: __. Please avoid __.”
That is enough to start a useful conversation. At PostedIn, we use that conversation to agree your content batch, prepare copy and images, and place the posts in your workspace for review. You can refine the brief as you discover which topics lead to worthwhile conversations.