/resources/personal-branding

Personal branding notes for engineers who dislike the phrase. 🌱

Most engineers I mentor find the phrase personal branding a little embarrassing, and I understand why. What I actually mean by it is narrower and less awkward: do work worth talking about, then make sure the right people can find out that you did it. These are the notes I share when somebody tells me they feel invisible.

What a brand actually is

Strip the word of its marketing baggage and it means something small and reasonable: the accurate sentence other people can say about your work. That is it. You are not building an audience, you are making sure the truth about your work travels.

You already have one, you just did not choose it

Your brand is the sentence your colleagues use when your name comes up in a room you are not in. That sentence exists whether or not you work on it. The only question is whether it matches the work you actually want to be handed.

Ask three colleagues, separately, to describe in one line what you are good at. Do not explain why you are asking.
Three different answers means you have a reputation but no position.
One answer you do not want (fixes the flaky tests, babysits the legacy module) is still your real brand, and it is quietly costing you the work you do want.
Write down the sentence you wish they had said. The gap between those two sentences is your entire plan.

Reputation is a memory problem, not a popularity problem

Opportunities arrive as a question somebody asks out loud: who do we know who understands payment retries, who could lead this migration, who can we put in front of this customer. You do not need a large audience for that. You need to be the first name that surfaces for one specific question.

Pick the question you want to be the answer to, and keep it narrow enough that somebody can recall it a week later.
Ten people who can describe exactly what you do beats a thousand who vaguely recognize your name.
Being known for one thing does not trap you in it. It gets you into the room where the next thing is decided.

Self promotion makes claims, visibility shows work

The part that feels embarrassing is announcing that you are great, and none of this requires that. Visibility means publishing the artifact and letting people draw their own conclusion. One is an assertion about you. The other is evidence that happens to have your name on it.

Assertion: I am strong at performance work. Evidence: here is how we took p95 from 900ms to 240ms, including the two things that did not work.
Before you post, delete every adjective about yourself. If the post still has value, publish it. If it collapses, it was self promotion.
Anything you would happily explain to a teammate at your desk is safe to publish. The audience changes, the register does not.

Write for the person six months behind you

The fastest cure for the cringe is changing who the work is for. When the reader is somebody stuck exactly where you were last quarter, you stop performing and start helping. Helpful is also the version of you that people remember.

Ask of every draft: would this have saved me two hours a year ago?
Keep the ugly specifics in. The exact error string, the version number, the wrong turn you took. That is the part people search for at midnight.
If nobody reads it, you still own a written record of your own thinking. That is the floor, and the floor already pays for the effort.

Be exact about credit

Most good engineering work belongs to a team. Claiming it alone is the fastest way to destroy the internal reputation you are trying to build, because colleagues talk to each other. You can be precise about your part without shrinking it.

State the scope honestly: I owned the migration plan and the rollback path, two other engineers wrote the adapters.
Use we for the outcome and I for the decisions you personally made.
Name the people whose work you built on. It costs nothing and people remember it for years.

Your brand is not what you say about yourself. It is the sentence other people can repeat about you accurately.

Substance comes first, or none of this works

This is the part that most branding advice skips, so I will be blunt about it. A reputation with nothing under it does not stay neutral, it collapses, and it takes longer to rebuild than it took to build.

Craft is the principal, reputation is the interest

A reputation is a claim on future work, and that claim gets audited. Every referral and every inbound conversation eventually ends in a room where somebody checks whether you can do the thing. If you cannot, visibility only makes the failure arrive faster and in front of more people.

Depth first: one area where you can go three questions deep, past the tutorial layer, into how it fails in production.
People remember being disappointed far longer than they remember being impressed.
The bar is not being the best in the world at something. It is being reliably useful and honest about the edges of what you know.

Signals that you are outrunning your substance

Run this checklist every few months. If several of these are true, stop publishing for a quarter and go build something difficult instead. Nothing bad happens when you go quiet for twelve weeks.

Your recent posts are all summaries of other people's ideas, with nothing from your own work in them.
You are writing about a tool you have never run under real load or real constraints.
You quietly dread getting a follow up question in the comments.
Your last three posts each took less time than any task you shipped that month.
People invite you to talk about a topic you last touched two years ago.

If you feel invisible, check your scope first

Feeling invisible at work is usually not a visibility problem. It is a scope problem: nobody talks about your work because none of it is currently worth talking about. That is fixable inside one quarter, and it is more satisfying than posting.

Ask your lead for the piece of work nobody wants: the flaky pipeline, the undocumented service, the alert everyone mutes.
Take something in your system from mysterious to explained, then write the explanation down. Owning a hard truth about the system is instant credibility.
Fix the thing that wastes everyone's Monday. Internal reputation is built almost entirely on removing other people's pain.

Your experience is the only moat you have left

Anything that can be summarized from documentation is now free and effectively infinite. What cannot be generated is the specific thing that broke in your production system on a Tuesday, the constraint your team actually lived with, and the decision you regret. Write from there.

Prefer we tried this and here is what happened over here is how this framework works.
Include the numbers, the constraints, and the option you rejected. Those three things cannot be faked.
Failure writeups land better than success writeups, and they are much easier to write honestly.

Build the thing first. A brand is a description of work that already exists, never a substitute for it.

Choosing what you want to be known for

Positioning is just deciding, in advance, what you want people to say about you, and then making that easy for them. Most engineers skip this step and then wonder why their reputation feels blurry.

Narrow beats impressive

Full stack engineer who loves learning is not a position, it is a description of almost everybody. Narrowing feels like it shrinks your options and it does the opposite: it makes you the obvious call for a smaller set of things, which is how any call reaches you at all.

Weak: frontend developer passionate about clean code.
Better: React performance, specifically large tables and slow renders.
Better: the engineer who takes over messy legacy frontends and makes them shippable again.
The test: could a recruiter or a colleague repeat it a week later without looking it up?

Positioning templates you can fill in today

Pick one, fill it in, then say it out loud to somebody. If it sounds like a brochure it is still too broad. Keep editing until it sounds like something a specific person would come to you asking for.

I help (who) do (specific outcome) by (the method or skill you actually use).
I am the person my team calls when (this specific thing) breaks.
I write about (narrow topic) for (specific audience), from the perspective of somebody who (your real context).
I am a (role) working on (domain), and the problem I care most about is (problem).
Fill the blanks using things you did in the last six months, not things you hope to do next year.

Build the position out of what you already have

Most people already have a position and cannot see it, because their own experience feels ordinary to them. Do the inventory before you go shopping for a fashionable niche.

List the last ten things people came to you for help with, then cluster them. The biggest cluster is your position.
List what you have shipped, and what was unusual about the constraints: scale, legacy, a tiny team, a regulated domain, terrible data.
List the two topics you keep reading about on weekends without anyone asking you to.
Where those three lists overlap is your bet.

One specialty plus one context

The strongest positioning I see is a technical specialty paired with a context that is genuinely yours. The specialty makes you findable. The context makes you distinct from every other person with that same specialty.

Design systems plus accessibility inside regulated products.
Node services plus cost and reliability at small team scale.
Data pipelines plus the specific mess of healthcare data.
Frontend plus teaching, if explaining things is genuinely something you do more than most.

It is a bet, not a tattoo

Choose for the next twelve to eighteen months, not for life. The reason to commit at all is that compounding needs a consistent direction. Repositioning later is cheap once people already trust that you finish what you start.

Review it twice a year with one question: is this still what I want to be asked about?
When you do shift, bring people with you by writing the bridge piece: what the old area taught me and why I am moving.
A reputation for judgement transfers across topics. A reputation for one library does not.

Pick one narrow thing you can be the answer to. Vague positioning has exactly the same effect as no positioning.

Build the internal reputation first

There is a smaller, faster market for your reputation and you are already inside it. The people you work with decide your scope, your promotion, and who they vouch for. This is also the least embarrassing place to start, which is why I always start mentees here.

Your first audience is twelve people

Your manager, your skip level, your tech lead, the two senior engineers whose opinions carry weight in reviews, your PM, and the people on the teams you depend on. That group has more influence over the next two years of your career than any online audience will.

Write the list of twelve actual names. Vagueness here defeats the exercise.
Next to each name, mark whether that person could describe what you are working on right now. Most cannot, and that is the whole problem.
Everything else in this section is aimed at that list, not at strangers.

Keep a work log and update it every Friday

Ten minutes a week. Not for your ego, but for the two conversations where your work gets described by somebody other than you: your performance review, and the calibration room your manager walks into without you.

One line per item: what changed, who it helped, the number if there is one, and a link to the PR or the doc.
Include the invisible work: the review comment that caught a real bug, the onboarding you unblocked, the incident you took at 2am, the intern you paired with.
Keep it in your own notes, not on a company drive you lose access to the day you leave.
Six months of Friday notes writes your review in an hour, and doubles as raw material for everything you publish.

Write the document nobody wants to write

Every team has a gap: the service with no runbook, an onboarding guide that went stale six months ago, a decision people relitigate every quarter because it was never written down. Filling one of those gaps buys more internal reputation than a year of good comments in standup.

A runbook for the service you are on call for, written the week after an incident while the details are fresh.
A postmortem that is genuinely blameless and specific about the system rather than the person.
A short design doc before you build, including the two options you rejected and why.
An onboarding page written in your first month. Nobody is better placed than the newest person to describe what was confusing.

Answer in the channel, not in DMs

The same answer typed into a public channel does two extra things: it is searchable for the next person who hits the problem, and it builds a quiet record of what you know. This is the lowest effort visibility habit that exists.

When a DM question is not sensitive, ask if you can move it to the team channel, then answer there.
After you solve something painful, post the fix with the literal error message in the text so search finds it later.
Answer some questions slightly outside your area too. Being reliably helpful is a reputation by itself.

Give the internal talk before the external one

A fifteen minute walkthrough for your own team is the cheapest speaking practice available and it has an audience that actually benefits. Do it three or four times before you go anywhere near a meetup stage.

Offer your team fifteen minutes on the thing you just built or just debugged.
Reuse the design doc you already wrote as the outline. You do not need new material.
Record yourself once and watch it back. Uncomfortable, and worth more than any advice on delivery.
Take the same talk to a local meetup next quarter. Organizers are usually short of speakers, and the second delivery is always the good one.

If the people you already work with cannot describe what you do, no external audience will fix that for you.

Writing when you think you have nothing original

This is the objection I hear most: everything has been written already, and better. It is true and it does not matter. Almost nobody publishes anything, so the bar is not originality, it is specificity.

Recent beats expert

The best person to explain something is rarely the expert who has forgotten what was confusing about it. It is the person who solved it three weeks ago and still remembers exactly where they got stuck. That window closes quickly, so write while you are still slightly annoyed.

Write for yourself three months ago. That reader is real, specific, and easy to picture.
Say your level plainly. Nobody minds a piece that opens with what I learned doing this for the first time.
The things you assume are too obvious to write down are usually the things missing from the internet.

Where the material actually comes from

You are not short of ideas, you are short of a capture habit. Every item below is something you already earned by doing your job. Keep a running list so you never start from a blank page.

Anything that took you more than two hours to figure out.
Any question you had to ask a senior engineer, along with the answer.
Any error message you searched for and found nothing useful about.
Any two tools or approaches you compared, and what actually decided it.
Any code review comment that changed how you think.
Any incident you were part of, written up carefully and with permission.
Any documentation you had to read three times because it was badly written.

Formats you can finish in one evening

Ambition is what kills drafts. The definitive guide never ships. Pick a small container and fill it, then pick another one next month.

The debug log: symptom, wrong theories in the order you had them, actual cause, the fix, what you would check first next time.
The comparison: two options, the criteria that mattered for your situation, the call you made, and the regret.
The explainer: one confusing concept, one working example, under 700 words.
The checklist: the steps you now follow so that mistake never happens again.
The reading note: what a paper or a source file actually taught you, in your own words.

Publish at eighty percent and let people correct you

Being wrong in public and fixing it cleanly is a credibility gain, not a loss. What damages you is being defensive about it. Agree, edit the piece, credit the person who caught it, move on.

Add a visible note at the top when you update something. Public corrections make everything else you wrote more trustworthy.
Hedge honestly where you are unsure, and say plainly what you have not tested.
Separate criticism from abuse. Engage the first properly and ignore the second completely.
Nothing you publish this year will be read by as many people as you currently fear.

Publish on ground you own, then share it

Put the piece on your own site or blog first, then share it where the people are. Platforms change their reach and their rules whenever they like, and your archive should not depend on any of them.

Publish at your own address first, then repost or link with a canonical reference back to it.
Rewrite the opening lines for each place you share it. The same three sentences never work everywhere.
Keep one index page listing everything you have written. It becomes the single most useful link you own.

You do not need an original idea. You need one specific experience, described honestly, in a format small enough to finish.

A cadence a full time job can absorb

Almost everyone who abandons this abandoned a schedule they could only hold for six weeks. Design for your worst month, not your most motivated week, and the whole thing survives.

The monthly floor

This is the rhythm I actually recommend to people working full time. It adds up to roughly two or three hours a month. Anything beyond it is a bonus and never the baseline you feel guilty against.

Every Friday, ten minutes: update the work log, dump any idea from the week into your notes.
Once a month, one ninety minute block: write and publish one piece. Put it in the calendar as a real event with a real time.
Once a month, one contribution that is not about you: a genuinely useful reply, a careful review of somebody's work, an answer to a question.
Once a quarter, one bigger thing: an internal talk, a meetup talk, an open source contribution, or a project you finish and write up.
Twice a year, one hour: reread your positioning, then update your profiles and resume straight from the work log.

Separate collecting from writing

Writing feels impossible after a full day of engineering because people try to do both jobs in the same sitting. Collecting happens in five minute scraps all month. Writing is one block where you already know what you are going to say.

Keep one note file called drafts and dump raw fragments into it with zero editing.
Each fragment needs two things: what happened, and one line on why it was interesting. That is enough to rebuild it a month later.
On writing day, pick the fragment that still annoys you the most. That irritation is what makes a piece readable.

Protect the floor, drop everything else

There will be a launch month, an incident month, a sick family member, a quarter that flattens you. The habit survives only if you decided in advance what gets dropped first.

Never drop the Friday ten minutes. It costs almost nothing and everything else is built on top of it.
Drop the monthly piece first. Skipping one month is invisible to everyone but you. Quitting is not.
When you are behind, publish something short instead of nothing. A 300 word note counts.
Coming back after a gap needs no apology post. Just publish the next thing.

Track output, not applause

If you measure likes you will slowly start writing for likes, and the writing gets worse in a way you cannot feel while it happens. Measure the things inside your control that actually compound.

Count published pieces per quarter, talks given, and people helped in public.
Log every inbound message you get and what triggered it. The pattern tells you which topic is landing.
Look at engagement numbers once a quarter, not daily. Treat them like weather, not feedback.
The real signal takes about a year: somebody you did not expect describes you as the person who does your thing.

One piece a month for two years beats twelve pieces in one month followed by silence. Design for the bad month.

Making yourself easy to find and easy to verify

Once somebody hears your name, they look you up, and they decide in about thirty seconds whether you are worth a reply. What they find should be consistent, current, and boring in exactly the right ways.

Search your own name

Do it in a private window, and add your city or your stack if your name is common. Whatever comes up on the first page is your real first impression, whether or not you designed it.

Is there anything on the first page that you own and can edit today?
Does the same photo appear across the top few results?
Is anything badly out of date: an old title, a dead project, an account you abandoned in college?
Fix in this order: the profile that gets the most traffic, then your own site, then everything else.

One canonical home you control

One page on your own domain that you can update in ten minutes. It does not need to be a design showcase and it does not need animations. It needs to answer two questions fast: what do you do, and what have you actually done.

Who you are and what you work on, in two sentences at the very top.
Three to five pieces of proof: projects or writing, each with one line on what it is and what it took.
What you are open to right now: roles, freelance, mentoring, or nothing.
One way to reach you that you genuinely check.
A current resume link, and a date on the page so people can see it is alive.

Consistent enough that people know it is one person

Somebody finds your talk, then a profile, then your code, and has to decide those are all the same person. Make that instant. It is a five minute job that most engineers never do.

The same photo everywhere. The same one, not a similar one.
The same one line description on every profile, word for word.
The same handle wherever it is available, and a note to yourself about where it was not.
Every profile points at your canonical home, and your home points back at each profile.

Make your proof scannable

People do not read your repositories, they skim the top of your profile for ten seconds. Whatever sits highest is what gets read, so put your strongest work there and explain it in one sentence each.

Pin three to six repositories that match the position you chose, not whatever you pushed most recently.
Give every pinned repo a one line description and a README that opens with what it does and why it exists.
Archive the tutorial clones. A few finished things beat forty abandoned ones.
When your best work is closed source, write about it instead. A careful writeup is proof too.

Say what you want, plainly, where it can be found

A surprising number of opportunities never reach people because nobody knew they were open to them. One clear sentence about what you are looking for converts better than an entire portfolio, and it costs you one sentence.

Specific works: senior frontend role at a product company, remote or hybrid in Bengaluru.
Open to opportunities does not work. It gives the reader nothing to act on.
Update it the week your situation changes, and remove it when you are not looking.
Put the same sentence at the end of anything you publish. One line, no pitch.

Assume every opportunity starts with somebody searching your name for thirty seconds. Make those thirty seconds accurate.

How reputation turns into opportunities

The mechanics are less magical than they look from outside. Very little arrives from strangers at scale. It arrives through individual people who know something true about you and are willing to say it.

Referrals are the channel that actually works

Referrals are a small share of applications and a large share of hires, which is the entire argument for reputation compressed into one sentence. Any hiring manager prefers a name that somebody they trust will vouch for over a resume from a queue.

Your reachable network is not your follower count. It is the people who could describe your work to a hiring manager without your help.
One former colleague who rates you highly is worth more than ten thousand impressions.
Which means the highest return activity available is being genuinely good to work with, in front of people who will move around the industry.

Keep a warm list of twenty

Twenty people: former colleagues, past managers, people you met at meetups, people whose work you follow and have actually spoken to. Networks decay silently. Somebody you have not spoken to in three years is not a referral, they are a stranger with a shared memory.

Once a month, send two messages with no ask attached: something you thought they would find useful, or a specific congratulation.
When you publish something, send it to two people who would actually care. Not a broadcast.
Reply to everybody who reaches out to you, even briefly. This is most of the work.
Do not save the list for the month you need a job. That is the one moment it will not work.

Make it effortless to refer you

When somebody offers to refer you, they have to write a paragraph about you to a person they respect, and that is where most referrals quietly die. Remove that work and your referral rate changes immediately.

Send four lines they can paste: what you do, two specific things you shipped, what you are looking for, and your resume link.
Name the team or the role you are targeting. Vague requests get dropped without malice.
Give them a graceful exit, in writing, so a no costs them nothing.
Follow up once, a week later. Once.

Ask on a schedule, not in a panic

People can tell the difference between a message from somebody who has been around and a message from somebody who has surfaced because they are suddenly job hunting. The fix is unglamorous: stay in touch when you need nothing.

Refresh your profiles and your work log every quarter so you are never rebuilding under pressure.
If you are in a layoff or a real hurry, say so directly. Honesty gets far more help than a casual tone that fools nobody.
Offer something real in return: a review, an introduction, a look at their code, an hour of your time.

Say yes to small asks, selectively

Reviewing a resume, answering a beginner's question, running one mock interview, taking one mentorship call. These compound in ways that are genuinely hard to predict, and each costs an hour. Selectively matters, because saying yes to everything is how people burn out and vanish.

Set a fixed capacity, one or two hours a month, and hold the line at it.
Prefer the asks that arrive with context and a specific question. Those are the people who will act on your answer.
The people you help early are the ones who refer you later. I have watched that happen more times than I can count.

Reputation converts through people, one at a time. Optimize for being somebody worth vouching for.

The ways this goes wrong

I have watched every one of these happen to engineers I mentor, and to people I have worked with. None of them come from trying too little.

Becoming a content creator with no craft behind it

The failure mode is publishing more than you build, until your entire output is commentary on other people's work. It is seductive because posting returns feedback in hours and engineering returns it in months. It ends with an audience that cannot survive a technical conversation.

Hold a ratio you can defend: if you cannot point at real work behind a quarter of posting, stop posting that quarter.
Never write authoritatively about a tool you have not run under real constraints.
The bar is not that everything you publish is expert. It is that everything you publish is honest about what you actually did.

Optimizing for engagement

Hot takes, padded lists, and manufactured controversy all work on the metrics while quietly costing you the thing you were building. The audience that arrives for heat is not the audience that refers you for senior work.

If a post would embarrass you in a design review, do not publish it.
Never get reach by punching down at beginners or at other people's tools. Engineers remember who does that.
Rewrite any headline that promises more than the body delivers. Nobody trusts the second one from you.

Maintaining a persona you cannot sustain

If the version of you online is more certain, more polished, or more relentlessly positive than you are, you will resent it within a year and quietly abandon it. The maintainable version is you with the boring parts left in.

Write in the voice you use in a code review, not the voice of a keynote.
Say I do not know in public sometimes. It is one of the most credible things you can write.
If you are dreading your own posting habit, the persona is wrong. It is not a discipline problem.

Trying to be everywhere at once

Five platforms in parallel is how this collapses inside two months. Depth on one surface plus your own site is enough for years, and it is what most of the people you admire are quietly doing.

Pick the one place where people in your niche already gather, plus your own site. That is the whole stack.
Add a second surface only once the first is a habit you no longer think about.
Reposting the same piece is fine. Producing original material for every platform is not sustainable.

Waiting until you are senior enough

The most common failure by a wide margin is never starting. People wait for a title, for a threshold of expertise, or for a topic nobody has covered. None of those ever arrive, and in the meantime the compounding they were waiting for has not begun.

The archive is the thing that compounds, and it starts the day you publish something mediocre.
Treat your first ten pieces as practice. Publish them anyway and let them carry a date.
Nobody is watching closely enough for your early work to hurt you. That is the real freedom in starting now.

The version of this that works is slow, specific, and grounded in work you actually did. When it starts to feel like performance, you have drifted.