Narrow Front Door, Visible Back Rooms

TL;DR: Most personal-brand advice tells a senior engineer going independent to build a broad identity and put it everywhere. For us that has it backwards. One narrow problem, named plainly enough that a stranger can repeat it, is what gets you in the door. The work you actually get hired for is often something else, and in my view the reason is other engineers. A peer who found you through the narrow thing becomes your advocate inside their company, and they pull you in for whatever that company needs this quarter. That only works if they can see what else you do. So keep the front door narrow and make the back rooms visible: a services page one click from your top posts, hub pages for each area, a one-line “I also do” pattern, and a blurb someone can forward in Slack without editing. Keep the hiring path and the buying path on separate pages too, because an employer and a buyer check different evidence.

Personal-brand advice for senior engineers has it backwards

The standard advice goes like this: figure out your “brand,” show the whole range of what you can do, and post everywhere so people see all of it. Full-stack, cloud, AI, security, leadership, all in one headline and one LinkedIn banner.

That advice was written for people whose problem is being invisible. A senior engineer with a decade or more of work behind them has a different problem. People can see them fine. What people can’t do is explain them. If someone asks a colleague “who do you know who could help with this?”, your name only comes up if the colleague can connect you to this. A broad identity gives them nothing to connect.

I think about my own career here. It’s broad on purpose. I built it on the diffuse, cross-cutting work nobody else wanted: a security program through SOC 2 Type II, an identity migration, a cloud move, service consolidation. That breadth is real and it’s the thing I sell. But nobody searches for breadth, and nobody forwards a link to it. Breadth is what you find once you’re inside. It can’t be the way in.

So here’s the model I use, and the one I’d hand to any senior engineer about to go fractional. The front door is narrow. The back rooms are real, and people can see them from the hallway.

Should a senior engineer niche down or stay broad when going independent?

Niche down the front door, not the business. Lead with one problem narrow enough that a stranger could describe it after reading one post. Keep everything else you’re good at running behind it, and don’t hide it.

The specialty that gets you referred is almost always narrower than the one that feels safe. It feels risky because you picture turning away work. But being an expert is relative. You don’t have to know more about AI security than everyone alive. You have to know more than the people in the room you picked. “Security for pre-Series-A AI startups facing their first enterprise questionnaire” is a small room. You can lead it. “Cloud and AI and leadership” is a stadium, and you’re one of thousands of people in it with the same label.

Narrow doesn’t lock you in either. When you widen from a spot where people already know you, those people come with you. When you start broad, nobody comes, because there was never a spot.

There’s a 2026 reason this matters more than it used to. Generalist explainers are what a chat assistant writes by default. If your public work reads like “an overview of cloud security best practices,” you’re competing with free, instant text. A narrow specialty tied to work you actually did is the one thing that text can’t fake.

A quick test for whether your front door is narrow enough: list every topic you published on in the last six months. Circle the one a stranger would pay you for. Then write three questions in that area that you answer better than the first page of search results and better than an AI assistant. If you can’t write three, the door isn’t narrow. It’s vague.

Why the work you get hired for isn’t the work that got you noticed

This is the part the brand advice misses entirely: other developers are an avenue into organizations. They advocate for you, and very often for a different purpose than the one they first knew you for.

Take how an engineer finds you. They’re stuck on something specific, like an auth migration, an agent that needs guardrails, or a Linux setup on a Mac. They search, find your post, and it’s useful. Maybe they read two more. At that point they don’t know you as a consultant. They know you as someone whose thinking holds up.

Six months later their company has a problem. Maybe it’s not the problem they read about. Maybe it’s an enterprise security review blocking a deal, or a team that has hit a wall, or an architecture call nobody internally wants to own. And that engineer is in the room, or in the Slack thread, when someone asks whether anybody knows a person who could help.

That’s the moment the front door pays off. And an advocate doesn’t just repeat your specialty. They reason from how you think to what else you could probably do. “He wrote the clearest thing I’ve read on X, and he’s run security programs before” is how a peer’s recommendation actually sounds.

This isn’t only a hunch about engineers. It’s how B2B buying works now. Gartner describes buying groups ranging from five to 16 people across as many as four functions. When the purchase has a technical side, engineering is likely one of those functions, and an engineer is the person most likely to look up your public work before anyone books a call. In TrustRadius’s 2024 survey of more than 2,000 technology buyers, 50% said they sought out former colleagues or known peers to discuss options (62% for enterprise), and 78% of buyers building a shortlist picked products they’d already heard of before starting research. That survey is about software, not fractional engagements, so read it as the general pattern rather than a stat about consultants. The pattern still holds: people inside the company, relying on names they already trust, filter the list before a buyer ever sees it.

The peer who reads your posts is that filter. That’s why I don’t think of engineers as a secondary audience next to “real” buyers. Buyers sign the contract. Peers put your name on the shortlist. You need both, so plan for both.

Advocates can’t recommend a room they’ve never seen

Here’s where the model breaks for most people who get the first half right. They niche down, the narrow posts work, engineers find them, and then the engineer’s company needs something next door to the specialty. The advocate doesn’t know you do that. You’ve made sure, very carefully, that every page says one thing.

An advocate can only recommend what they’ve seen. They won’t dig through your archive trying to guess whether the AI-agents person also does SOC 2 readiness. They’ll recommend whoever they already know does SOC 2 readiness, or nobody.

So the back rooms don’t belong in the headline. They belong one click away from any page someone lands on. The front door answers “what is this person for?” The hallway answers “what else could I bring them in for?” The common failure is building a front door and then bricking up the hallway, because focus got read as hiding everything else.

This site is my own test case

I don’t want to argue this in the abstract, so here’s the example I can show you: the site you’re reading.

It’s broad, and not by accident. The topic guides cover AI engineering, security for startups, engineering leadership, Elixir and the BEAM for AI systems, and Omarchy on Apple Silicon. That last one is the interesting case. Omarchy is a trend topic. Engineers who would never search “vCISO” do search for how to run it on a Mac, and I put it on an M1 MacBook Pro because I wanted to run it, not to sell anything.

The question isn’t whether that post brings in the wrong audience. It brings in exactly the audience I described above: engineers inside companies. The real question is whether the path from there to the rest of the site is visible. So the guide doesn’t stop at the install. It goes from the install to what happens when an agent runs with the safety off, then to whether you can put it on a company laptop under SOC 2. A reader who arrived for keybindings leaves having watched me reason like a security lead. That’s a back room, and the reader walked past it without having to go looking.

The site does the same thing mechanically. Every post that belongs to a guide ends with a link to the full guide. Every post ends with a one-line hook picked from its tags, so a security post asks about security work and a hiring post asks about hiring work. And the buying path is a single page: how I work with founders, which lists engagement types, starting prices, how scoping works, and who it’s not the right fit for. If an engineer who found me through Omarchy wants to know whether I could help with their company’s audit, I don’t want them guessing. That page is there so the answer takes one click.

I’m not claiming the site is finished. I’m saying the structure is deliberate, and every piece of it is something you can copy.

What does an employer check that a fractional buyer doesn’t?

An employer checks whether you’ll fit and grow over years. A fractional buyer checks whether you can fix one specific problem soon, at a risk they can live with. Those are different questions, answered by different proof, so they need different pages.

Senior engineers going independent often need both paths live at the same time. You take fractional work between roles, or you keep a full-time offer open while you test consulting. The mistake is running both from one page that tries to answer both questions and ends up answering neither.

On this site, those are two different pages on purpose. The resume is the hiring path: full work history, named outcomes. The consulting page is the buying path: what I’ll take on, how it’s scoped, and when I’m the wrong call.

Both pages follow one rule: every line pairs an action with a result someone could check. “Responsible for cloud infrastructure” is a duty. “Moved production off GCP onto Azure and cut $350K in infrastructure spend in six months” is an outcome, and a skeptic can ask about it. “Led identity work” is a duty. “Migrated 225K+ users off AWS Cognito onto Auth0 without forcing a logout” is an outcome. Duty lists don’t let anyone compare you with anyone else. Outcomes do. Generic AI-written phrasing makes it worse: it’s a duty list with better grammar.

The buyer’s version of that rule is a little different. A founder buying fractional work wants to see what the engagement looks like before they book the call: the first thirty days, the deliverables, what’s left behind when you go. I wrote out what 90 days of a fractional security engagement actually looks like for exactly that reader. An employer would never ask for that post. A buyer reads it before a first call.

The back-rooms checklist

This is the part to actually do. None of it requires a rebrand.

1. Put the services page one click from your top posts. Pull your five most-visited posts. From each one, count the clicks to reach your services or contact page. Anything over one is a leak. Fix it with an end-of-post line that matches the post’s topic plus a nav link to the services page, not a generic “hire me” banner.
2. Build a hub page for each area you take work in. A topic guide with a short intro and an annotated list of posts shows range without putting range in your headline. Every post in the area should link up to its hub. The hub is the hallway.
3. Bridge or fence every side topic. For each hub, write one sentence connecting it to a problem you get paid to solve. Omarchy bridges to endpoint security and SOC 2. If a topic won’t take a sentence, fence it off clearly as a hobby section so it doesn’t blur what you’re for.
4. Use a one-line “I also do” pattern. At the end of a narrow post, add one sentence that names the adjacent room: “If you found this because of the migration, I also run security programs for companies about to face their first audit.” One sentence, one link. It’s a door, not a pitch.
5. Write a forwardable blurb. Three sentences: what you do, who it’s for, and a link to the best proof. Put it on your about or consulting page. Recommendations travel through internal chat now, and a blurb someone can paste unchanged survives that trip much better than “check out his site.” Point its links only at pages you control, because a blurb built to be copied is also easy for an impersonator to copy. Your personal brand is an attack surface covers how to harden that.
6. Separate the hiring page from the buying page. A resume with outcomes for employers. A services page with engagement types, scope, and fit for buyers. Link between them, but don’t merge them.
7. Rewrite your three weakest profile lines as action plus result. Where there’s no number, write down what you’d need to measure next time so there is one.
8. Map your likely advocates. List ten engineers who’ve engaged with your work: replies, DMs, people who’ve forwarded your posts. Note where each works now and one problem their company plausibly has that you solve. You’re not going to pitch them. You’re checking whether your site would show them that you solve it.

That last item is the whole model as a test. Pick one of those ten people. Land where they’d land, on the narrow post they first read. Can you get from there to the thing their company needs in one or two clicks, without already knowing it’s there? If not, the back room exists and nobody can see it.

Where this goes wrong

A few ways engineers get half of this right and lose the value.

The front door is a list. “Fractional CTO | AI | Cloud | Security | Leadership” is five doors, so it’s no door. Pick the one a stranger would pay for and lead with it everywhere: the headline, the homepage opener, the one-line description.

The back rooms are louder than the front door. Range belongs one click away, not on the landing page. If a visitor’s first impression is a grid of twelve services, you’ve recreated the broad identity with better CSS.

The side topics are orphans. Writing about something outside your core is fine, and trend topics are often how peers find you first. An orphan topic with no bridge back leaves the visitor unsure what you’re for, and an unsure visitor neither refers nor buys.

The paths are merged. A page that tells a recruiter about your team leadership and a founder about your 90-day scope in the same scroll serves neither. Split them.

The channel is a bet, not a system. Posting narrow things and hoping the right engineer finds them isn’t a plan. Distribution is the one asset that makes everything else work, and for an independent engineer, the specific version is a body of narrow, useful public work with a visible path from any piece of it to what you sell.

Read this next

If you’re deciding which narrow problem to lead with, start from the work you’ve already done that nobody else wanted. The career I built on work nobody wanted is about why diffuse, cross-cutting work builds the broad map that becomes your back rooms. And if you’re a founder who got here because an engineer on your team forwarded this, the hallway goes both ways: here’s how I work.