A senior developer. Strong candidate. Passed all the interviews. Got the offer.

And accepted it immediately — €10,000 below the approved range — because, and this is a direct quote:

“I didn’t want to make it awkward.”

The following week, a candidate with the exact same qualifications interviewed for the same role, with the same hiring manager, from the same budget. That candidate asked for more. And got it.

Same company. Same role. Same money sitting there waiting.

The only difference? One of them was willing to have a five-minute conversation.

This is not a rare story. It’s the default.

Only 39% of workers negotiated their salary for their current job. The rest left an average of $7,500 on the table. In Europe, the gap is smaller — but it’s still real, and it still compounds over years.

And here’s the part that makes it worse: 73% of employers say they would be willing to negotiate an initial offer, yet 55% of candidates never even ask. The door is open. Most people never walk through it.

Think about that ratio. Nearly three out of four companies are ready to give you more — and more than half of candidates don’t even try.

That’s not a negotiation problem. That’s a psychological one.

Why engineers, specifically, struggle with this

Engineers especially treat the “business stuff” like it’s beneath them or outside their expertise. They’ll spend three weekends optimizing a database query that saves 40 milliseconds, but won’t spend ten minutes on a phone call that’s worth €10,000 a year.

Sound familiar?

The instinct makes sense, honestly. Engineers are trained to solve problems with clean, provable answers. Code either works or it doesn’t. A salary negotiation is fuzzy, social, uncertain. It feels uncomfortable in a way that debugging never does.

But the discomfort is based on a fear that isn’t real.

94% of negotiated offers remain intact. Hesitation is largely based on misperception, not reality.

They are almost never going to rescind the offer because you asked for more. The worst realistic outcome is that they say no and you’re exactly where you started. But that almost never happens either — 85% of Americans who countered on salary or benefits received at least some of what they asked for.

Know what market you’re in

Before you negotiate, you need a number to anchor to. And in Europe, the range varies a lot.

A mid-level software engineer (3–5 years of experience) across Western and Central Europe earns roughly €65,000–€90,000 gross annually. Senior engineers in Western hubs earn €90,000–€130,000.

Senior Software Engineer salaries vary significantly across European markets: Germany averages around €111,800, the Netherlands €110,100, France €96,200, and Spain €83,400.

So if you’re in Amsterdam and someone offers you €80K for a senior role, you have data to push back with. If you’re in Milan or Madrid and you’re sitting at €55K with five years of experience, the same applies.

Know the band before the call. Use Glassdoor, Levels.fyi, and LinkedIn Salary to build your range. Come in with a number, not a feeling.

The moment most engineers give away their leverage

It happens before the negotiation even starts.

The recruiter asks, early in the process: “What are your salary expectations?”

And the engineer, eager to seem reasonable and not rock the boat, gives a number.

The moment you name a number, you’ve set a ceiling. If you say €70k and they were prepared to offer €80k, you just lost €10k. Always try to get them to name a number first.

The right answer to that early question is something like:

“I’d love to hear what the range looks like for this position first.”

Or: “I want to make sure we’re aligned on the overall package before I give a specific number.”

Most companies will give you a range. And now you’re negotiating from their number, not yours.

What’s actually negotiable (it’s more than salary)

Most engineers think of negotiation as a single moment: the offer comes in, you either push back on the number or you don’t.

But salary is just one piece. The full picture includes base salary, bonus, equity, signing bonus, remote flexibility, vacation, and start date.

A €72K base with a 15% target bonus and meaningful equity can easily beat an €80K base with nothing else attached. Run the full numbers before you decide.

If they can’t move on base, there are other levers. Ask for a signing bonus. Ask for an earlier performance review at 6 months instead of 12. Ask for an extra week of vacation, or full remote flexibility. In Europe especially, these elements have real tangible value — and companies often have more room there than on the base salary itself.

Most candidates don’t leave money on the table because they’re bad negotiators. They do it because they misunderstand where flexibility actually exists, and when to slow down.

The script, for those who hate scripts

You don’t need to be slick. You don’t need a rehearsed monologue. You just need to say something like this, calmly, after the offer comes in:

“Thank you so much — I’m really excited about the role. I’ve done some research on the market and, based on my experience with [X and Y], I was hoping we could get to [number]. Is there room to move in that direction?”

That’s it. Professional. Direct. Low-pressure.

Employers expect candidates to negotiate. It’s a normal part of the hiring process. Most will not withdraw an offer if you negotiate professionally and reasonably. Negotiating shows that you are confident in your value.

And confidence in your value — in a job market that explicitly rewards it — is exactly the thing that gets you further.

One more thing, because this newsletter is what it is

Your LinkedIn profile plays a role here, even before the offer lands.

When a recruiter already knows who you are — when they’ve seen your posts, read your thoughts, tracked your work — you walk into that conversation with a different kind of weight. You’re not just another CV. You’re someone they wanted.

That changes the dynamic entirely.

People who are visible, who have built a presence, negotiate from a position of strength. Because they have options. And both sides know it.

You don’t have to choose between being a great engineer and knowing what you’re worth.

You can be both. You just have to be willing to say so.

Was this useful? Share it with the engineer who just said yes without thinking twice.

A cover letter is a short document you attach to a job application, alongside your CV. Its purpose? To introduce yourself, explain why you’re applying, and add some context that a resume alone can’t convey.

For a long time, it was considered mandatory. A non-negotiable step. You applied. You attached the CV. You attached the cover letter. That was the formula.

But in 2026, things are more nuanced — and if you’re a Software Engineer, you’ve probably asked yourself at some point: do I even need to bother?

The AI elephant in the room

Here’s the honest question most people are thinking but few say out loud:

Now that I can open ChatGPT and get a perfect cover letter in 30 seconds, what’s the point?

And it’s a fair question.

Historically, one of the things a cover letter was supposed to demonstrate was your ability to write — your command of the language, your communication skills, your professionalism. If you were applying for a role in an English-speaking company and your first language wasn’t English, a well-written cover letter was a subtle but meaningful signal.

But now? Anyone can produce a polished, grammatically flawless letter with a simple prompt. The playing field has been leveled — or more accurately, it’s been flattened.

So if everyone can write a perfect cover letter, does it still mean anything?

What the cover letter is actually for now

Here’s my take: in 2026, the cover letter is no longer an exercise in style. It’s no longer about demonstrating that you can write well in English.

It’s your chance to tell your story — without being constrained by the brevity of a CV.

Think about it this way.

When you’re fresh out of university, a cover letter feels like torture. You have almost nothing to put in your CV, so you write a cover letter to compensate — to say “yes, my experience is thin, but here’s who I am and why I’m motivated.”

But something interesting happens a few years later. Once you reach 3 or 4 years of experience, the problem flips. Suddenly, you have too much to say. You’ve worked on multiple projects, navigated different tech stacks, led initiatives, made mistakes, learned things the hard way. And a CV — by definition — forces you to prioritize.

You’re compressing your career into bullet points. You pick the top three things from each role. You cut everything that doesn’t fit on two pages. You’re constantly choosing what to leave out.

And when you leave things out, you lose the story.

The CV tells what. The cover letter tells why.

Your CV is a list. A clean, structured list of what you’ve done. Dates, companies, roles, technologies.

It doesn’t have room to explain:

• what actually drove you to make a particular career move

• what you believe about how great software should be built

• what energizes you when you wake up in the morning

• why this specific role makes sense for where you’re heading

A cover letter gives you that room.

And when you’re mid-career, that space becomes genuinely valuable — because the things that set you apart are often not the things that fit in a bullet point. They’re the context around the bullet points.

What recruiters actually do when they open your application

I’ve been on the receiving end of hundreds of job proposals — and I’ve also spent time talking to people who review applications for a living. And the pattern is remarkably consistent.

The CV comes first. Always. It’s faster to scan, easier to filter, and most of the hard data is right there: companies, roles, years of experience, tech stack. A recruiter can make a preliminary assessment in under a minute.

The cover letter comes second — if it comes at all.

And this is where it gets interesting. When a recruiter does open a cover letter, they’re not reading it for grammar. They already assume it’s going to be well-written. What they’re actually looking for is something much simpler: does this person sound like a human being, or does this sound like everyone else?

The applications that get remembered are the ones where something unexpected comes through. Not unexpected in a gimmicky way — but in the sense that you can feel a real person behind the words. Someone who has actually thought about why they’re applying. Someone who knows what they want and can articulate it.

The applications that get forgotten — even when the CV is strong — are the ones where the cover letter reads like a press release. Lots of enthusiasm, very little substance. “I am very excited about this opportunity and I believe my skills align perfectly with your company’s vision.”

You’ve read it before. So have they. Dozens of times that week alone.

The irony is that most engineers — who tend to be precise, direct, and good at explaining complex things clearly — are actually well-positioned to write a genuinely interesting cover letter. They just don’t believe it’s worth the effort.

It is.

Okay, but what should it actually look like?

Keep it short. One page. Around 300–400 words. Three or four paragraphs, max.

The structure is simple:

1. Why this company / this role — be specific. Generic enthusiasm is the fastest way to get ignored.

2. What makes you a good fit — one or two things, with concrete examples.

3. What drives you — your philosophy, your motivation, the thread that connects your career decisions.

4. A clean close — no “I look forward to hearing from you at your earliest convenience.” Just something honest and direct.

And yes — use AI to get the form right. Absolutely. Let it help you with structure, tone, and polishing. That’s what the tool is there for.

But the content? That has to come from you.

The companies that read cover letters are reading them precisely because they want to know who’s behind the CV. If you hand them something generic — something that reads like every other application — you’ve wasted the opportunity.

The shift: from form to content

This is the key insight for 2026.

AI has commoditized the form. Everyone’s cover letter now looks professional, is well-formatted, and is grammatically correct.

What AI cannot do is give you a genuine story. It can’t tell a recruiter about the project you’re most proud of and why. It can’t explain what made you choose a career in engineering after studying something completely different. It can’t capture the specific way you think about problems.

That’s on you.

So the question is no longer “can I write a cover letter?” — thanks to AI, the answer is always yes.

The real question is: do you have something worth saying?

If you do — and most engineers with a few years of experience do — the cover letter is still one of the best tools you have to say it.

Cover letters haven’t died. They’ve just stopped being about form — and started being about substance. Use AI to get the form right. Then spend your energy on the content. That’s where the actual signal lives.

Spoiler: this is not a Meta story.

It is a story about you, your skills, and how you show them to the market.

Layoffs are the new normal, not the exception

Meta is not a special case.

Across Big Tech, layoffs have become a recurring pattern to fund massive AI bets: Amazon, Microsoft, Oracle, Intel, and others have all cut thousands of roles in the last 18 months to “reallocate resources” toward AI infrastructure.

The narrative is always the same:

“We are investing heavily in AI.
To stay lean and efficient, we have to reduce headcount.”

Look at the Meta numbers:

• About 10% of the workforce gone in one shot, roughly 8,000 people.

• Thousands of roles cancelled before anyone could even be hired.

• Around 7,000 people moved from “legacy” work to AI-related teams.

This is a systemic refactor of the org chart.

And if you treat your job as a static thing that someone owes you, you are acting like legacy code that nobody wants to maintain.

The real lesson: you are either a cost or a component

In these stories, companies publicly say they are cutting roles because AI lets smaller teams do more and they want to fund gigantic AI infrastructure budgets.

Read that again.

They are literally telling you the new mental model:

• Compute is an asset.

• Headcount is a liability.

Inside this model, every engineer becomes either:

• A cost center: someone who just “implements tickets”.

• A core component: someone who owns problems, influences direction, moves business metrics, and can drive or adopt AI-driven workflows.

Meta is reallocating thousands of people into AI-related work, not just firing.

So the message is not “you are doomed”.

The message is: if your role can be done by a smaller, more AI-augmented team, sooner or later someone will test that hypothesis.

You choose which side you are on.

The Code Monkey vs the Product Engineer

Imagine two backend engineers in a big company.

Same stack, same seniority, same salary.

Different mindset.

First one: the Task Taker.
They come online, open Jira, ask “what’s my ticket?”, ship the feature, log off.

Second one: the Product Engineer.
They still ship tickets, but they also:

• Talk with PMs and designers to understand why this feature matters.

• Measure impact: latency, revenue, churn, adoption.

• Share clear updates on Slack and LinkedIn when they solve hard problems (without secrets, just stories and lessons).

Now imagine a layoff meeting.

Management has to cut 10% of the team because AI tools will cover some repetitive tasks.

Who do you think they see as “still critical”?

Not the one who silently ships tickets that now a smaller AI-augmented team can handle.

The one who:

• Owns business outcomes.

• Shows leadership beyond code.

• Has a visible track record of solving relevant problems.

Same coding level. Different perception. Different outcome.

You cannot control layoffs, but you control your visibility

There is something brutal in this Meta layoff: many of the impacted people found out at 4 a.m. emails, with the press knowing almost at the same time.

It feels unfair.

It is unfair.

But you still have one lever that is completely under your control: how you present yourself to the market, every single week.

Think in terms of:

• Input: your daily work, the problems you solve, the systems you touch.

• Output: how you document and communicate that work.

Most engineers stop at the input.

“That’s what they pay me for.”

The problem is that when a recruiter, a hiring manager, or even your own leadership looks at you from the outside, they only see the output:

• A silent profile with a job title and no context.

• Or a profile with short posts about actual challenges, trade-offs, and results.

During a layoff wave, or right after, this difference is massive.

Layoffs compress the market, and LinkedIn becomes your CI pipeline

When 8,000 people are cut from one company, that talent does not disappear.

They all go to the same place: LinkedIn.

At the same time, other companies are doing similar cuts, often to fund the same AI bets.

So what happens?

• More engineers on the market.

• Fewer “classic” roles opened, more niche AI-adjacent roles.

• Recruiters with less time per candidate.

In this environment, your LinkedIn profile is not a static CV.

It becomes your continuous integration pipeline for opportunities:

• Each post is a new build of your professional story.

• Each project you document is a new deploy into someone’s memory.

• Each connection you nurture increases the “uptime” of your network.

If you refuse to “sell yourself”, you are basically:

Commenting out the only deployment pipeline for your career.

What to actually do this week

You don’t need to turn into a content creator.

You need a simple, boring, repeatable routine.

Here is one you can start after finishing this email:

1. Refactor your LinkedIn headline
   Stop with “Software Engineer at X”.
   Try “Backend Engineer | Reducing latency in payment systems” or “Mobile Engineer | Building reliable consumer apps”.
   One line that says what problems you solve, not just where you sit.

2. Ship one small post per week
   Pick one problem from your work: a migration, a bug, a performance issue.
   Write 5–7 lines about: context, the problem, what you tried, what worked, and what you learned.
   No secrets, no NDAs broken, just your thought process.

3. Keep a private changelog
   In Notion, Obsidian, or even a Google Doc.
   Every time you solve something non-trivial, log it: date, context, what you did, impact.
   This becomes your internal “release notes” when you need to update your CV, your LinkedIn, or prepare for an interview.

4. Talk with one person per week outside your team
   Someone in product, design, data, or another company.
   Ask what they are struggling with, how AI is changing their work, what skills they value today.
   You are not selling anything. You are collecting requirements for your own roadmap.

None of this is “being an influencer”.

This is just observability for your career.

The Meta layoff as a warning signal, not a prophecy

If you are reading about Meta cutting thousands of jobs to pour billions into AI, and you think “this has nothing to do with me”, you are missing the real signal.

This is not about one company.

It is about a new default:

• AI is a first-class citizen in budgets.

• Headcount is a variable to optimize aggressively.

• Engineers who only ship code without owning outcomes or telling their story are easy to replace on paper.

So treat this layoff like you would treat a scary production incident:

• Don’t panic.

• Don’t ignore it.

• Run a postmortem on your own career.

Where are you still pure “cost center” in the eyes of others?

And what can you ship this month to change that perception?

You spend weeks on LeetCode, system design videos, mock coding sessions, and then freeze when someone asks:

“Tell me about a time you had a conflict with a teammate.”

That is where many strong developers lose the room.

Not because they are weak engineers.
Because they prepared for syntax, not for signal.

Companies are moving more and more signal into this part of the process.
Google, Airbnb and many big tech players already dedicate full rounds to behavioural and culture-fit interviews.

You can pass all the LeetCode in the world.
If your stories are weak, you still walk out with a rejection.

Let’s fix that.

What they are really testing

A behavioural interview is not about hearing a nice story.

It is about understanding how you work when things get messy: conflict, ambiguity, pressure, ownership, failure, trade-offs.

The interviewer is not asking, “Did you ever touch a hard project?”
They are asking, “How do you behave when the project stops being clean?”

That is why generic answers fail.

“We had to migrate a service, it was hard, we worked a lot, and in the end it went well.”

This answer says nothing.
No ownership, no decision-making, no proof.

The good answer is never the most dramatic one.
It is the one that makes your actions easy to see.

The usual engineer mistakes

Most engineers fail behavioural interviews in very boring ways.

First, they improvise.
They think, “I lived the experience, so I can just explain it live.”

But lived experience is not the same as a sharp answer.
A real project is messy.
An interview answer needs shape.

Second, they describe the team instead of themselves.

“We did this.”
“We decided that.”
“We shipped the feature.”

Nice.
But what did you do?

If your answer can be copied by five people from the same squad, it is useless.

Third, they overfocus on the tech.
They explain Kafka, Kubernetes, shards, pipelines, service boundaries.

The interviewer is often listening for judgment, communication, prioritization, and trust, not for a conference talk.

Fourth, they sound fake.
They try too hard to look perfect.
No mistakes, no doubts, no lessons learned.

That usually backfires.
Good interviewers know that real engineers have scars.

Use STAR without sounding dead

Yes, STAR still works.

Situation. Task. Action. Result.

The problem is not the framework.
The problem is when people answer like they are filling a tax form.

The trick is simple:

• Keep the situation short.

• Make the task clear.

• Spend most of the time on the action.

• End with the result and what changed because of it.

That third part matters the most.

Action is where your value lives.
Not in the background story.
Not in the company context.
In the decisions you made.

A good rule: if your answer spends two minutes setting context and thirty seconds on your choices, it is broken.

And add one more thing after STAR: reflection.
What did you learn?
What would you do differently now?

That small part makes you sound real.

Build a story bank

Do not prepare answers.
Prepare stories.

That one shift changes everything.

Most behavioural questions are just different wrappers around the same few patterns.
Conflict. Failure. Ownership. Pressure. Leadership. Adaptability. Feedback.

So instead of writing 30 answers, build a small story bank with 6 to 8 strong episodes from your career.

For example:

• A project that went off the rails and how you stabilized it.

• A disagreement with a teammate or manager.

• A production issue where you had to stay calm.

• A time you took ownership without being asked.

• A mistake you made and what changed after that.

• A case where you improved a process, not just a feature.

Now here is the important part.

Each story should be reusable.
One good production incident can answer questions about leadership, communication, pressure, prioritization, and customer impact.

This is exactly how good engineers think.
You do not build a new service for every request.
You build a few solid components and reuse them well.

Make your stories easy to trust

A strong behavioural answer is specific, but not overloaded.

You want enough detail to sound real, but not so much detail that the answer collapses under its own weight.

Here is a simple pattern that works well:

• What was happening.

• Why it was a problem.

• What your job was in that moment.

• What you did first.

• What you did next.

• What happened in the end.

• What changed in how you work after that.

Also, use normal words.
If you say “cross-functional stakeholder alignment across an evolving delivery landscape”, you already lost.

Say:
“We had two teams blocked on different priorities, so I booked a short call, showed the trade-off, and forced a decision.”

That sounds like a person.
And interviewers hire people.

Practise the right way

Most people practise behavioural interviews in the worst possible format: silently, inside their own head.

That does not work.

You need to say the stories out loud.
That is when you notice the weak parts:

• The intro is too long.

• The action is vague.

• The ending has no impact.

• The whole thing sounds rehearsed in a bad way.

A simple routine:

1. Write bullet points for 6 to 8 stories, not full scripts.

2. Say each story out loud in under 2 to 3 minutes.

3. Record yourself once. It is painful and useful.

4. Ask a friend one follow-up question after every answer.

5. Rewrite only the weak parts, not the whole story.

The goal is not to memorize lines.
The goal is to know your own material so well that you can adapt it live.

That is the difference between sounding prepared and sounding scripted.

The hidden link with your personal brand

This is also where a lot of engineers miss a bigger opportunity.

Your best behavioural stories are not useful only for interviews.
They are also raw material for your LinkedIn, your CV bullets, your self-review, and even the way you introduce yourself professionally.

The same principle keeps showing up everywhere: do not just list skills, prove value with specific examples.

That is why engineers who document their work well tend to look stronger in every career context.

Not because they are pretending.
Because they have already done the hard work of turning experience into evidence.

If you want to ace behavioural interviews, stop treating them like random HR theatre.

Treat them like career documentation.
Build a small library of proof.
Refactor it until it sounds simple, sharp, and true.

That is usually enough to stand out from the engineer who only prepared to solve the algorithm.

Multiple analyses across millions of posts show that LinkedIn reach has dropped roughly 40–50 percent in the last year for most creators.

This is not a bug.
LinkedIn rebuilt the whole machine under the hood.

What LinkedIn actually changed

Until 2025, LinkedIn used a stack of different models: one for feed, one for jobs, one for “people you may know”, and so on.

Now there is one big brain: 360Brew, a 150B-parameter AI model trained only on LinkedIn data.

(paper here)

Instead of asking only “which post gets the most quick reactions?”, 360Brew reads your profile, your post, and the reader’s context together, and asks a different question:

“Is this the right person, saying the right thing, to the right audience?”

If the answer is “I’m not sure”, your post simply does not travel very far.

From “who you know” to “what you talk about”

The old LinkedIn was about the social graph: your network, your connections, your follower count.

The new one is closer to an interest graph:

• What you talk about

• What people like you read and save

• What kind of conversations your posts start

This is why people with 5,000 followers can suddenly outperform people with 50,000 followers: the system prefers relevance and depth of engagement over raw audience size.

Your profile is now part of the ranking pipeline, not just a static page. Misaligned profile and content = weak relevance score = low reach, no matter how good the writing looks on its own.

Why your reach really dropped

Let’s cut the drama and list the main real reasons, based on data from AuthoredUp, and multiple LinkedIn analytics reports.

1. The test‑audience spiral

Every post starts with a small test group from your network. If they ignore it, the post dies there.

When you hit a bad streak, something sneaky happens:

• Post underperforms

• Next test audience is slightly worse

• Next post underperforms again

• Audience quality degrades further

Some data shows that in 67 percent of “my reach suddenly died” cases, impressions recovered in 2–3 weeks with no big changes, which means it was a spiral, not a permanent punishment.

2. Profile and content do not match

360Brew ranks profile + content together.

If your headline says “Backend Engineer” and your last 15 posts are generic career advice, morning routines, and soft skills, the system has no clear idea what you are an expert in.

Low clarity = low relevance = low reach.

You are basically shipping a microservice with no clear API.
The router does not know when to send traffic to you, so it just… does not.

3. Generic AI / templated content

LinkedIn’s own explanations and third‑party analyses all point in the same direction: the feed is full of AI‑generated sludge, and 360Brew is being trained to detect it.

Signals that correlate with underperformance:

• Same structure on every post (identical hook length, three equal paragraphs, question at the end)

• Recycled “viral” templates with zero personal detail

• Phrases that look like they came from a copy‑paste prompt, not from a real story

It turns out that posts with highly repetitive structure saw sudden, lasting drops in distribution, even when the topics were good.

4. Fake engagement and pods

Engagement pods and “comment for comment” groups are now easy to detect:

• Same 20 people, always commenting in the first 5–10 minutes

• Same short comments, with no depth

• Cross‑posting patterns across accounts

On average, creators who were detected as part of pods saw their organic (non‑pod) engagement drop by 30–45 percent for 4–8 weeks.

LinkedIn is not just ignoring fake engagement; it is using it as a negative signal.

5. Outbound links and over‑posting

Several large‑scale analyses show two patterns in 2025–2026:

• Posts with outbound links often get 50–70 percent less reach on average

• Posting every single day, especially several times per day, correlates with worse performance per post

Is this “official”? No.
Is it visible in the data? Yes — enough that most growth experts now tell people to go easy on links and avoid trying to brute‑force reach with volume.

What 360Brew actually rewards

Now the part you care about: what to aim at instead.

Across AuthoredUp’s millions of posts and multiple independent breakdowns, three signals show up again and again.

1. Saves

Saves are the strongest signal you can realistically influence.

• AuthoredUp data: saves drive around 5x more reach than a like, and around 2x more than a simple comment.

• Saved posts stay in feeds longer and get resurfaced more often, because they look like “reference material”.

If nobody ever saves your posts, you are basically writing tweets in a place that wants documentation.

2. Dwell time

Dwell time = how long people actually stay on your post.

• One study shows posts with 61+ seconds of dwell time have engagement rates more than 10x higher than posts that get only 0–3 seconds.

• Multiple algorithm breakdowns say the same thing: a post with fewer likes but strong dwell time will beat a post with many likes that everyone scrolls past.

Carousels and longer text posts win here because they inherently take time to consume.

3. Long, relevant comments

360Brew can read language. It knows the difference between “great post!” and a three‑sentence answer with a concrete example.

• Posts that spark real conversations stay visible longer.

• Comments from people who look credible in your niche are worth much more than random low‑relevance profiles.

Likes are the weakest of the important signals. Good to have, not enough by themselves.

The engineer’s checklist

Before blaming the platform, run this basic debug pass on your account:

1. Profile → Do headline and About clearly match the topics you post about?
2. Last 20 posts → Are they about 2–3 tight themes, or all over the place?
3. Structure → Do your posts all look and “sound” the same?
4. Engagement → Are you getting real comments, or mostly quick likes?
5. Behavior → Any automation tools, pods, or growth hacks in the last 3 months?
6. Links → How many posts in the last 10 had outbound links?

Then compare with this:

• Reach dropped 40–60 percent but fluctuates from post to post → normal in 2026, most people see it.

• Reach dropped 80 percent and stayed there for 10+ posts → you probably triggered one of the five patterns above.

In 4 percent of cases there was a true, sustained distribution hit, but every single one had at least one clear trigger: pods, links spam, guideline issues, or automation.

Stop guessing. Start shipping.

Here is the practical part — what to actually do for the next 90 days.

1. Lock in your topics and profile

Pick 2–3 topics that are close to your real work. For example:

• “Backend performance and scaling stories”

• “How we ship features faster without breaking prod”

• “Lessons learned mentoring junior devs”

Update your:

• Headline — make the topics obvious

• About — 3–5 lines that say what you build, who you help, and what you write about

• Featured — pin 2–3 posts or carousels that match those themes

You are telling 360Brew “this is my niche”.
Give it a consistent signal for three months.

2. Design posts for saves and dwell time

When you write, don’t think “how do I get likes?”.
Think “how do I make this worth saving?”.

Good candidates:

• Step‑by‑step breakdown of how you solved a production incident

• A small framework you actually use at work (how you estimate tasks, how you debug, how you do code reviews)

• A short “field guide” carousel: “How we reduced cold start by 40 percent”, “How I onboard a new dev in 7 days”

Aim for:

• 200–400 words of clear text, broken into short paragraphs

• Real numbers, real trade‑offs, concrete decisions

• One main point per post, not a shopping list of tips

If someone on your team says “I will save this to show it to a junior dev”, you are on the right track.

3. Write for comments, not reactions

At the end of a post, don’t ask “what do you think?”.
Ask something that an engineer can answer quickly from experience:

• “What is the worst rollback you had to do in production?”

• “What is one code review rule that you would never remove from your team?”

• “What is the last ‘small’ bug that cost your team a full day?”

One specific, low‑friction question beats ten generic ones.

Then:

• Reply to every meaningful comment with something that adds value (your take, a question back, an extra detail)

• Ignore “nice post” type comments or answer them only if you have something real to add

You are not farming comments.
You are starting conversations in public.

4. Go easy on links and growth hacks

For the next 90 days:

• Share very few posts whose main point is “click this link”

• If you must share one, make the post valuable by itself (your clear summary, your opinion, what you disagree with), and accept that reach may be lower — you are trading reach for clicks, by choice

• Drop all automation, pods, and tricks. They are technical debt on your distribution.

Think like an engineer: remove flaky dependencies before you debug the core system.

5. Commit to a boring schedule

You don’t need to post every day. In fact, several data sets suggest that over‑posting correlates with worse performance per post.

A sane plan for a busy developer:

• 2 posts per week (for example, Tuesday and Thursday)

• 1 “big” piece per week (carousel or long text)

• 15–20 minutes per weekday commenting thoughtfully on other people’s posts in your niche

Do this for twelve weeks.
Then look at your saves, comments, and average dwell‑time proxy (long posts vs short):

• If saves go up and comments get longer, you are training the right signals

• Reach will follow with a delay, not instantly

No hacks. No pods. No magic template. Just 90 days of specific, on‑topic posts that real people actually read and save.

It’s not exciting.
But neither is refactoring a 2,000‑line legacy function — and you still do it when it matters.

Why I spend evenings drafting emails instead of watching Netflix.

And also why more and more people are doing the same.

Because this is clearly not just a personal obsession anymore.

Platforms like Substack keep growing, more creators are launching newsletters, and some of them are turning a simple email into a serious business.

So the real question is not “how do you start a newsletter”.

It’s: why do people do it at all?

The “new magazines” in a noisy world

Social feeds today are a mess: hot takes, drama, and tons of useless content pushing for one second of attention.

All this noise brought back an old need: curated content, with a clear voice, that feels more like a magazine than an endless feed.

A good newsletter is exactly that.

Recurring issues, a focused topic, and a person who selects what is worth your time, directly in your inbox instead of on a newsstand.

For readers, it is a way to step out of the algorithm and get signal instead of noise.

For writers, it is a place where you do not have to shout to be heard: you simply show up, consistently, in front of people who asked to listen.

The practical reasons

There is also a very practical side.

A newsletter helps people in at least three ways:

• It sharpens your thinking.
  Writing forces you to put order into your ideas.
  You move from “I kind of get it” to “I can explain it”.

• It builds leverage.
  One good article keeps bringing you opportunities (offers, collaborations, messages) long after the day you publish it.

• It opens career options.
  Substack has passed 5 million paid subscriptions, and tens of thousands of writers get paid for what they publish.
  At least 50 newsletters earn more than $500K per year, and the top creators together make over $40M a year in recurring revenue.
  The Pragmatic Engineer, for example, has passed 1 million readers and became a serious business built on a simple mailing list.

Most people will never reach those numbers.

But they don’t need to.

Even a small newsletter can lead to:

• more job offers

• side projects that find their first users

• consulting opportunities

• or simply a much stronger professional identity.

The personal reason I write this newsletter

For me, the deepest reason is not money or audience size.

It is a person.

At University, I was far from the top student.
I came from a high school with very little maths, so Computer Science hit me hard. I was slower than others, and for a long time I did not feel “naturally suited” for this field.

My close friend was the opposite.

He was faster on the exercises, passed the exams I failed, and became the person I looked up to. He saw potential in me before I saw it in myself, and he often highlighted my strengths when I couldn’t.

We studied together.
He helped me, explained concepts, and pushed me when I slowed down.
He was my first real mentor.

Then, during our internship in the University lab, something broke on his side.

He was under pressure to prove his value, but he struggled to perform at the level he expected from himself. Instead of noticing what was behind it, the professors he was writing his thesis with reacted in a way that only increased his anxiety.

Little by little, that constant pressure pushed him into a kind of burnout.
He stopped believing in his own abilities, and what used to be passion turned into stress.

In the end, he decided not to continue with the Master’s degree.
Our academic paths split there: I went on with the Master’s, while he moved into a full‑time role that had very little to do with what he really wanted.

For about two years, he stayed in that job: no real programming, no joy in his day‑to‑day work.
Every time I saw him during that period, I could feel he was… switched off.

In the meantime, my path slowly changed direction.

Even if I had started as the “weaker” one, year after year I became more passionate about Software Engineering.
When I entered the job market, that growth accelerated.

In just a couple of years, I:

• started in a consulting company

• got promoted

• moved to a product company like TheFork

• got promoted again

• and began receiving an impressive number of job proposals on LinkedIn, almost every day.

All this time, my friend was there, watching this progression from close range.

He kept asking me how I was doing it.
He told me I was good at “selling myself” on LinkedIn and said he wished he had the same ability.

The irony is that I never really felt “good at selling myself”.

I felt like I was just doing what seemed natural: taking care of my profile, answering messages, sharing small pieces of my journey.
So when he said those things, I mostly felt grateful — and almost guilty.

Grateful, because I knew exactly how far I had come from that insecure student who thought Computer Science was “too hard” for him.
Guilty, because I knew he had been one of the first to believe in me, and now he was stuck in a role where he couldn’t use his real strengths.

And he still hated the idea of “selling himself”.

That’s where the urgency came from.

I felt I could not just sit and watch anymore.
I was so thankful for everything that had happened in my career that it felt wrong not to try to use that experience to help him.
I knew I wasn’t doing anything magical. It was just a set of behaviours applied with consistency.

So helping him did not feel like a sacrifice.
It felt like the most natural thing you do for a friend: cheer for him, sit next to him, and show in practice that what you are doing is not out of his reach.

I invited him to my place and proposed a kind of “side project”:

every week, for as long as needed, we would:

• fix his LinkedIn profile

• do LeetCode together

• go back to the basics of programming after years away from code

• and work on how he talked about himself, even if he hated it.

This became our weekly ritual for about a year and a half.

At the beginning he had zero confidence.
He did not believe he could come back into the game, and anything that looked like self‑promotion made him feel sick.

Slowly, repetition did its job.
His coding skills slowly came back.

His LinkedIn started to look like the profile of a real engineer, not an accident.
He started interviewing again… and eventually he found a company where he could do what he is actually good at: programming.

Every time I write the sentence:

“Are you a Software Engineer who hates the idea of ‘selling yourself’?”

I have his face in mind.

But he is not the only one.

Some time later, I found myself doing something similar for another University mate — this time mostly through chats and calls, with much less intense “weekly sessions”.

She was also stuck in a role that did not reflect her skills, with the same mix of low confidence and resistance to visibility. We talked, I shared similar advice, we worked on her profile and mindset in small steps… and she, too, eventually found her way back to a job that fit her much better.

Seeing this happen more than once made something click.

If two people from my small circle were struggling like this almost in silence, it was clear there must be many more engineers out there in the same situation, just without someone next to them to go through LinkedIn, interviews, and mindset.

A newsletter felt like the most honest way I could try to reach those people: not by pretending to “save” anyone, but by writing down the same guidance I would give if we were sitting at the same desk, side by side.

That is the real root of this newsletter.

I write because I do not want more people like them to quietly leave the right path just because no one ever gave them the tools — and the push — to express their value.

Why people really do it

Some people start a newsletter for money.
Some for status.
Some to have a direct relationship with their audience.

But often, under the surface, the reason is much simpler.

You have something to say.
You are tired of waiting for someone to “discover” you.
You want to help the previous version of yourself not to disappear.

In my case, there is also a sense of fairness.

When you see a capable person, full of potential, slowly drift away from the career they deserved just because others misjudged them, it leaves a mark.

A newsletter can be a small act against that.

Not just content.

A way to make talent visible.

A way to give words to people who have value but struggle to show it.

And that is why, in the end, so many people start a newsletter.

The replies are predictable: “What’s the secret?”, “Which hook are you using now?”, “Are carousels still the meta or not?”

Engineers read that stuff and think: “Ok, LinkedIn is now TikTok with a tie. I’m out.”

That’s the wrong takeaway.

Because under the noise, there are real trends that matter for your career, not for vanity metrics.

Let’s go through them one by one, from the point of view of a dev who hates “personal branding”.

Trend #1 – LinkedIn is becoming your changelog

In 2026 most serious hiring managers check LinkedIn before your CV.

They don’t read your posts like a fan.

They scan your profile like a codebase.

• What have you shipped in the last 12–18 months?

• What kind of problems do you solve?

• Do other people trust you?

The new trend is simple: your activity tab is your public changelog.

Not a museum of one post every six months.

Short weekly posts about real bugs, trade‑offs, rollbacks, post‑mortems, are the “commits” that show how you think.

The old meta: “optimize your headline”.
The 2026 meta: “ship small, honest updates every week”.

If you treat LinkedIn like a release log of your brain, you are already ahead of 95% of devs.

Trend #2 – Comments are the new cold email

Every growth “guru” talks about going viral.

But look at how actual engineers are getting interviews today: it’s not through viral posts, it’s through consistent, smart comments on niche conversations.

You see a Staff Engineer at your dream company talking about a migration from monolith to services?

You jump in with:

• a question about their fallback strategy

• a tiny experience you had with a similar migration

• a short “here is what broke for us when we tried X”

No pitch.

No “please check my profile”.

Just value.

The trend: recruiters don’t just search by job title anymore.

They search by keywords inside comments and posts.

If you never comment, you are basically opting out from half of the opportunities.

Think of comments as tiny pull requests on someone else’s thread: easy to merge if they add value.

Trend #3 – The “visible IC” beats the “ghost manager”

Another LinkedIn trend: companies now showcase individual contributors more than ever.

Lead engineers write public retros.

Security people talk about incidents (sanitized, of course).

Platform teams post about the tools they build.

Why?

Because tech brands understood that real engineers are more credible than any corporate page.

This means that if you are an IC who is a bit visible on LinkedIn:

• You become the “face” of your team.

• You get tagged in launches.

• You are the one that recruiters remember.

On the other side you have the “ghost manager”.

Invisible online.

Unknown outside the company.

Plays it safe… until the next reorg.

In a market where AI is eating the boring tasks, being the visible IC is a form of job security.

Trend #4 – “Skill stories” beat keyword stuffing

Old SEO‑LinkedIn advice: put every keyword in your About section.

Backend, frontend, microservices, Kubernetes, Agile, DevOps, Machine Learning, Blockchain, you name it.

The 2026 trend is different.

LinkedIn is moving more and more towards content‑based signals: how you talk about a skill in context, not only where you list it.

Example:

Instead of:

“I worked with Kubernetes, Docker, microservices, AWS.”

You post:

“We reduced p95 latency by 28% after moving this one endpoint out of a noisy cluster. What worked: feature flags, progressive rollout, and brutally simple dashboards.”

Same tech.

Completely different signal.

You didn’t just list tools.

You told a skill story: problem → constraints → decision → result.

For engineers who hate selling, this is perfect: you are just documenting what happened at work.

Trend #5 – Niche beats generalist feed

Your LinkedIn feed is a mess because you never trained it.

Right now, one trend I see: good engineers are aggressively curating a niche feed.

They:

• follow specific PMs, Staff Engineers, founders in their domain

• mute generic “motivation” accounts

• save and comment on posts that are exactly in their area

Result?

Two things:

1. They always have ideas for posts (they just react to interesting problems in the feed).

2. They show up exactly where the right eyes are.

This is not about becoming an influencer.

This is about being part of a very targeted conversation.

Like hanging out in the right Slack channel, not in a huge public Discord.

Trend #6 – “Quiet signals” now matter more

LinkedIn is shipping new features all the time, but the big change is how recruiters use quiet signals.

Things that didn’t matter before, now matter a lot:

• how often you update your profile

• how many colleagues endorsed you recently

• whether you engaged with content related to their tech stack

You don’t see these things as metrics, but their search tools do.

That’s why a very passive profile is the new outdated CV.

Even a small routine helps:

• once a month: update one bullet in your Experience

• once a week: one comment on a technical topic

• once every two weeks: one small post, 5–10 lines, about a lesson from work

Nothing flashy.

Just small pings to the graph, like heartbeats.

So what do you actually do?

You don’t need to chase trends.

You need a small system that aligns with these trends:

• Treat your profile and posts as a changelog, not a billboard.

• Use comments as tiny proof‑of‑work, not as networking spam.

• Tell skill stories, not buzzword lists.

• Curate a niche feed that feeds your brain, not your anxiety.

• Keep sending quiet signals instead of disappearing for 12 months.

If you do this, LinkedIn stops feeling like a fake stage and becomes what it should have always been for engineers: a searchable log of the impact you have at work.

Most Software Engineers will ignore this advice because it looks “too business-y”.

That’s exactly why you should steal it.

If you hate the idea of “selling yourself”, the 2-pager is one of the cleanest hacks you can adopt: no cringe, no storytelling theater, just a clear spec of who you are and where you fit.

Let’s port it into our world.

What a 2-pager really is

Forget the coach-speak.

A 2-pager is a lightweight personal doc, usually 1–2 pages, that answers five brutal questions:

• Who are you.

• What you’ve actually built.

• What you’re scary-good at.

• What proof you have.

• What you want next.

No fluff, no “driven, passionate, highly motivated” nonsense.

Think of it as:

Your README.md as a senior engineer, formatted for humans instead of GitHub.

Not an application.

A conversation starter.

Why engineers need one even when not job searching

Right now, most devs show up to networking calls naked.

Best case: random small talk, a couple of generic questions.

Worst case: “So… if you hear about something, let me know.”

And then silence.

A 2-pager fixes three classic bugs:

1. It makes you easier to forward.
   When someone wants to introduce you, they need something clear to attach.

2. It makes your value legible.
   Non-engineers do not understand “I work on backend stuff in Go”. They understand “I helped reduce checkout failures by 30%”.

3. It makes you remembered.
   A clean 2-pager is 100x more memorable than “Senior Engineer at Company X, working on internal tools”.

You are basically reducing friction in the “referral pipeline”.

How a 2-pager looks for a Software Engineer

Let’s make it concrete.

Page 1 and (maybe) page 2.

Plain text, simple layout. No design degree needed.

You can structure it like this:

Header

• Name, role, location.

• One line: “Senior Backend Engineer focused on B2B SaaS, payments, and platform reliability.”

Who I am (short intro)

3–4 lines, max.

• What kind of problems you like.

• What type of teams you thrive in.

• 1 sentence about your edge (e.g. “I sit between engineering and product and speak both languages”).

What I’ve built

3–6 bullets, each one like a mini case study.

• Context → Action → Result.

• “Led migration from legacy monolith to modular services for payments, cutting checkout latency by 40% and incidents by 25%.”
  (→ FYI I have already written an article about how to write this type of sentences)

Avoid tech-dump bullets like “Kubernetes, Docker, Terraform, Kafka, Redis…”.

Lead with impact, not tools.

Superpowers

3–5 bullets that describe how you work when you are at your best.

Examples:

• “Turn vague product ideas into technical plans that non-tech stakeholders understand”

• “Take over messy legacy systems without complaining and gradually refactor them”

• “Calm in production incidents, fast at isolating root causes”

Proof points

Links only:

• GitHub (if not empty).

• 1–3 talks, posts, or PRs you’re proud of.

• Open-source contributions, side projects, conference appearances.

No links? Start small: a single post where you break down a bug you fixed.

What I’m looking for

Even if you are not “looking”, give direction.

• “Types of problems I’m excited about in the next 2–3 years.”

• “Ideal environment” (stage, domain, team shape).

You can keep it broad:

• “Product engineering roles where I own a problem end-to-end and work close to business impact.”

When to actually use it

Engineers think documents live in folders.

This one lives in conversations.

You use a 2-pager when:

• A friend says, “I can introduce you to our Head of Eng”
  You reply, “Perfect, here’s a short 2-pager that explains what I do. Feel free to forward it”

• You have a coffee with someone from your dream company.
  After the call: “Thanks for your time; here’s a concise overview of my background in case it’s useful to share internally”

• You speak at a meetup.
  On follow-up: “If you ever need someone with this profile, here is a 2-pager that sums up my work”

Notice what you are doing.

You are not begging.

You are making it easy for other people to sell you when you are not in the room.

How to write yours without cringing

If you are a dev, the main blocker is not Canva.

It’s shame.

You feel you are “bragging”.

So here’s the trick: write it like you write post-mortems.

• Be specific.

• Stick to facts.

• Attach numbers when you can.

• Remove hype.

You are not saying, “I am a 10x engineer”.

You are saying, “Here is the diff I have made to real systems”.

If it helps, open a doc and literally start from this prompt:

“If a friend wanted to pitch me for a role tomorrow, what 2 pages would I want them to have in front of them?”

Write in your natural voice.

Then refactor:

• Kill adverbs (“very”, “highly”, “extremely”).

• Remove any sentence that doesn’t increase clarity.

• Cut it until a busy VP could scan it in 45 seconds.

Save as PDF.

Put a short link in your email signature or LinkedIn contact info.

And then, next time someone says, “Sure, send me something about you”, you won’t send yet another lifeless resume.

You’ll send a 2-pager that actually represents how you think and what you build.

You were asked to invert linked lists and balance trees while your real job was shipping features, fixing bugs, reading legacy code, and talking to people.

But at least there was one implicit assumption: on the job, you would still have to think and code with your own brain, even if you copied from StackOverflow (by the way RIP StackOverflow).

AI breaks exactly this assumption.

The old contract: puzzles as a proxy for “thinking”

LeetCode-style interviews were always a strong bet on two ideas:

1. If you pass, you are probably smart enough and can code.

2. If you fail, it’s “just” a false negative we can live with.

Big Tech knew this was high-precision, low-recall. They explicitly accepted that many good engineers would be filtered out in exchange for fewer false positives.

The problem: even in 2018, many people already pointed out that this format:

• Favors people with time and energy to grind puzzles.

• Punishes great engineers who don’t optimize their life around brain teasers.

• Has almost zero overlap with what you actually do at work.

It’s like judging a marathon runner only by a 100m sprint at 7:30 in the morning and deciding that anyone who is slow at that time of day “does not have the engine”.

Work assignments were a partial fix:

• You get a realistic mini-project.

• You work with your tools.

• Then you explain decisions, trade-offs, and code in a review.

Here the storytelling and the ability to modify your own solution under feedback become as important as the code itself.

What AI really changed (and it’s not just “cheating”)

The big shift is not “AI can now do LeetCode”.

The big shift is that, at work, AI is starting to beat you at the micro-level of code:

• Boilerplate generation.

• “Straightforward” optimizations.

• Translations between stacks and frameworks

Multiple studies already show the tension: using AI speeds up coding a bit, but degrades conceptual understanding and debugging skills if you lean on it too much.

So the job itself is changing:

• Less value in being a human compiler.

• More value in being the human who guides the compiler.

Trying to interview in 2026 by banning auto-complete, docs, and AI is like hiring a data scientist and forcing them to “prove” themselves with paper-and-pencil matrix multiplications.

Yes, they “can” do it.
But if they do it every day at work, something is very wrong.

Why puzzle interviews become less and less defensible

In this new world, classic coding interviews rest on three assumptions that are no longer safe:

1. “If you pass my puzzle, you’ll be good at the job.”

2. “If you fail my puzzle, you probably wouldn’t be good anyway.”

3. “On the job, you will actually need this exact style of bare-hands problem solving.”

AI erodes all three:

• You can now “one-shot” many puzzles with AI tools that exist specifically to do that.

• Teams in production rarely write complex algorithms from scratch; they integrate services, reason about systems, manage complexity, and debug AI-generated mess.

• Almost nobody codes completely alone without docs, StackOverflow, or AI anymore.

Continuing to run interviews with zero tools while the daily job is “AI pair-programming plus system thinking” creates an insane mismatch.

It’s like banning calculators for a senior accountant interview, when their daily work is 90% ERP systems and Excel.

The hidden risk: skill atrophy and interview inflation

There is another uncomfortable angle:

As more of your real work gets abstracted behind AI suggestions, your raw “by hand” skill will naturally atrophy.

Anthropic’s research shows that people who used AI for a coding task performed worse on a subsequent conceptual quiz than people who coded by hand, even though they had just solved that same type of problem.

So if interview formats stay frozen in the “no tooling, solve this from scratch” era, then:

• The average working engineer will get worse at those bare-hands tasks.

• Passing the interview will require special training that does not resemble the work.

That means an inflation effect: fewer and fewer normal engineers (who do real jobs with AI) will be able to pass a process that ignores the way real work is done.

Where interviews will have to move

Given all of this, I don’t think coding interviews disappear.

But if they don’t change, they will become a parody.

Here is where they almost have to go. And yes: I think we’ll start to see this transition in 2026.

1. From “can you code?” to “can you supervise?”

Instead of proving you can write everything by hand, interviews will try to measure:

• Can you detect when AI code is wrong?

• Can you debug and refactor AI output?

• Can you keep conceptual control over a large codebase written half by machines?

An interview might look like:

“Here is a feature that an AI assistant implemented for us. Something is off. Find the bug, explain what the AI did, and propose a cleaner structure.”

You’re not racing the AI.
You’re managing it.

2. Work assignments with “transparent AI”

Take-homes won’t die, but they will change rules:

• You’re explicitly allowed to use AI.

• You must record or describe how you used it. (this will show your explainability skills)

• In the review, you walk through prompts, decisions, and corrections.

What they care about is:

• Did you blindly accept AI output?

• Did you understand the domain?

• Can you adjust when requirements shift?

The value moves from “raw typing” to judgement and communication.

3. Interviews that mirror a real workday

Companies that are serious will build interviews that look like a compressed workday:

• You get a small backlog, incomplete specs, maybe a bit of messy legacy.

• You work with your usual tools: editor, tests, docs, AI.

• You ask clarifying questions to a fake “product owner” (the interviewer).

Signals they extract:

• Can you slice the problem?

• Can you negotiate scope?

• Can you say “no” with arguments?

• Can you leave the codebase slightly better than you found it?

This is much closer to the “audition” idea many hiring leaders are pushing: it should feel like work, not like a TV quiz.

What to do as an engineer (in 2026, not 2016)

If the real game shifts, your preparation must shift too.

Instead of only asking “how can I get better at LeetCode?”, ask:

• How do I think clearly about problems while tools write code?

• How do I prove that I can own a feature end-to-end in an AI-heavy world?

• How do I show my ability to debug, explain, and make trade-offs?

Practically:

• Use AI in your daily projects, but force yourself to explain every non-trivial piece of code it generates.

• Keep artifacts of your decisions: docs, ADRs, diagrams, incident write-ups. These will become your “portfolio of judgement”.

• When you practice interviews, simulate your actual workflow: editor + tests + AI, and focus on narrating your thinking.

If interviews stay stuck in the past, you will still have to “play the game” sometimes.
But your long-term leverage will not be beating the CPU at puzzles.

It will be becoming the person who tells the CPU what to do, why it matters, and when it’s wrong.

What to do as CTO

If you are a CTO, AI is already changing your company’s daily work.

If you don’t touch your hiring process, it will quietly start optimising for the wrong engineers.

Right now:

• Your developers ship with auto-complete, AI pair programmers, and strong tooling.

• Your interviews often still ban all of this and test who performs well in a sterile, tool-free puzzle lab.

That gap is your problem to fix, not your recruiters’.

If you keep the old process, three things are very likely to happen:

1. You filter out exactly the people you need
   You’ll reject strong product engineers who are great at supervising AI, understanding systems, and shipping value, because they don’t match an outdated “puzzle athlete” profile.

2. You burn your seniors on low-signal interviews
   Your best people will spend hours running ceremonies they don’t believe in, instead of mentoring, designing systems, and building your AI roadmap.

3. You build an org that can’t absorb AI safely
   You’ll hire people tested on bare-hands coding, then ask them to manage AI-generated code at scale, with no evidence they can spot when the machine is confidently wrong.

Your job in 2026 is to re-spec what “good engineer” means for your company and then align the interview loop to that spec.

Concretely:

• Make interviews look like work: real repo, real constraints, tools allowed, AI allowed, and focus on how candidates drive the tools, not how they suffer without them.

• Redefine your signals around judgement, communication, system thinking, and ability to debug and refine AI output, instead of raw typing speed or memorised tricks.

• Protect senior time: automate or outsource the low-signal early filters and keep your best engineers for the conversations where they can actually recognise future teammates.

• Close the loop: measure which interview signals correlate with performance after 6–12 months, and be ruthless in deleting formats that don’t predict anything.

If you don’t do this, you won’t just have “annoying” interviews.

You’ll have a hiring system that is perfectly tuned to find engineers for a job that no longer exists.

In the first edition, we treated LinkedIn like a coding interview:

• Problem 1: Stop the scroll

• Problem 2: Keep attention

• Problem 3: Don’t return void at the end

It was all about patterns: hooks, layout, value.
Nice theory, but now it’s time to get our hands dirty.

Today we do something different:
same idea → three levels of post, each one more “optimal” than the previous, just like going from:

• “Accepted, but slow”
  to

• “Beats 100% in time and memory”.

And we keep it on real topics you actually care about: bugs, growth, and the 2026 market.

Problem 1 (Easy) – The Bug Fix 🟢

You fixed a small bug.
Standard day in the life of an engineer.

Most people think: “This is not worth a post.”
So they either ignore it or write something like:

“Fixed a pagination bug today. Learned a lot.”

That’s the console.log version of a post.

Let’s refactor it 3 times and see how much nicer it can become.

Level 1 – “It works, but meh”

Today I fixed a small pagination bug in our admin dashboard.
On page 3, one user was missing from the list.

It was caused by a mismatch between 0-based and 1-based indexing between backend and frontend.

I corrected the indexing and added a couple of tests so it doesn’t happen again.

Not horrible.
If this shows up in your feed, you might not hate it.
But you’ll probably scroll.

Level 2 – “Readable and human”

LitCode #1 – The user that kept disappearing

Today I fixed one of those “small” bugs that slowly drive everyone crazy.

On page 3 of our admin dashboard, one user kept disappearing from the list.
No errors. No alerts. Just numbers that didn’t match.

After a bit of digging I realised we were mixing 0-based indexing on the backend with 1-based indexing on the frontend.
Classic.

I picked one convention, fixed both sides, and added tests on the “boring” middle pages, not just page 1 and the last one.

The best part?
Support stopped getting those “I swear there is a user missing” tickets.

Now it feels like a mini-story.
You see the problem, the confusion, the relief.

Level 3 – “Beats 100% in time + memory”

LitCode #1 – The 1% bug that was wasting hours

On paper, our admin dashboard was “stable”.
In reality, something felt off.

Every now and then, a user would quietly disappear from page 3.
Not deleted. Not filtered. Just… missing.

No logs.
No red exceptions.
Just support tickets saying “your tool is lying to me”.

I finally traced it back to a stupid detail:
backend using 0-based indexing, frontend using 1-based.
One off‑by‑one, hours of confusion.

I aligned the conventions, added tests in the middle of the list, and wrote down the contract in plain language so nobody has to rediscover it in 6 months.

The fix was 5 lines of code.
The impact was giving people back trust in the data they look at every day.

Same bug, completely different feeling.
Level 1 is “ok”.
Level 3 is something a tech lead would happily read to understand how you think.

Problem 2 (Medium) – The Growth Story 🟡

Now we move from “bug” to personal growth.

Topic idea:
“The first time I realised my career was stuck, even if I was shipping stuff.”

Level 1 – “LinkedIn diary”

A few months ago I felt stuck in my career.
I was working hard, but nothing big was changing.
So I decided to take my growth more seriously and focus on improving every week.

It’s vague.
Everyone can say this.
You forget it instantly.

Level 2 – “Concrete and specific”

LitCode #2 – The year I realised shipping wasn’t enough

One year ago my career looked “fine” on paper.
I was shipping tickets, fixing bugs, doing code reviews.

But every time a more interesting opportunity came up inside the company, my name wasn’t in the conversation.

That was the moment I understood something uncomfortable:
it’s not enough to do good work.
People also need to see it and understand it.

So I changed one habit.

Every Friday, I write down one thing I moved forward that week:
what the problem was, what I tried, what finally worked.
Sometimes it becomes a LinkedIn post, sometimes it stays in my notes.

After a few months, two things happened:

• I had real stories ready for performance reviews and interviews.

• People started associating me with the type of problems I like to solve.
  Same work as before.
  But now it’s visible.

Better.
Concrete, you can almost copy‑paste the system.

Level 3 – “Beats 100% because it’s relatable and sharp”

LitCode #2 – The invisible year on my CV

I once had a year in my career that looked completely empty from the outside.

I was shipping features.
I was fixing production issues.
I was helping teammates debug their stuff.

But if you looked at my CV or my LinkedIn, that entire year could be summarised as:
“Software Engineer at Company X”.

No stories.
No examples.
No proof of how I think.

When a recruiter asked “What are you most proud of from your last role?”, I had to dig in my memory on the spot.
It felt like opening a huge log file with no filters.

That day I decided something simple:
I will never again let a full year of work turn into a one‑line bullet point.

Now, every week, I write down one problem I moved forward.
Sometimes it’s a LinkedIn post, sometimes it’s a private note.
But it means that when I need examples, I don’t have to “remember”.
I just scroll my own history.

It doesn’t make me a genius.
It just means my career is no longer compressed into a single vague line.

Here the “growth” is something you can feel in your stomach.
You see the before/after without any bullet point.

Problem 3 (Hard) – The Market Take 🔴

Now the hardest category:
saying something real about the 2026 market without turning into a rant or a LinkedIn guru.

Topic example:
“Why being ‘good’ is not enough in this market.”

Level 1 – “Complaining mode”

The market is really bad right now.
Companies only want very senior profiles.
It’s hard to stand out when there is so much competition.

Everyone feels this.
But this version doesn’t help anyone.

Level 2 – “Honest but constructive”

LitCode #3 – Being good is not enough in 2026

This market is tough, especially if you are “just good”.

Not a genius.
Not a disaster.
Just someone who writes solid code and closes tickets.

The problem is that from the outside, “good” looks identical for thousands of engineers.
Same stack. Same job titles. Same keywords.

When companies have 200 CVs on the table, they don’t optimise for “fairness”.
They optimise for clarity:
“Who is sending me the clearest signal that they can solve my kind of problems?”

That signal rarely comes from your CV.
It comes from the trail of work people can actually see: posts, side projects, talks, even a well‑written bug story.

You don’t need to be louder.
You need to be clearer.

Already helpful.
Now let’s push for that “I’d send this to a friend” energy.

Level 3 – “Beats 100% because it’s sharp and kind at the same time”

LitCode #3 – The market doesn’t punish you for not being a genius. It punishes you for being a ghost.

A lot of good engineers are having a bad time in 2026.
Not because they suddenly forgot how to code,
but because from the outside, they look identical to everyone else.

Same job titles.
Same tech stack.
Same “passionate about clean code” in the bio.

When a hiring manager scrolls through profiles, they’re not thinking:
“Who is the smartest person here?”
They’re thinking:
“Who gives me the most confidence that they can handle the problems we actually have?”

Confidence doesn’t come from buzzwords.
It comes from evidence:

• the way you describe a production issue,

• how you explain a trade‑off,

• how you talk about results, not only tools.

That’s why I’m obsessed with turning normal work into small stories.

It’s not about playing influencer.

It’s about making it stupidly easy for a stranger to see:
“Oh, this person solves exactly the kind of problems we struggle with.”

The market is brutal, yes.
But being invisible in a brutal market is even worse.

No bullets, no generic guru talk.
Just a very clear picture of what’s going on and what you can do.

If you want to practice this:

• Take one real bug → write Level 1, then push it to Level 3.

• Take one growth moment → again, Level 1 to Level 3.

• Take one opinion about the market → same game.

You’ll see that the magic is not in having “cool ideas”.
It’s in doing the refactor step instead of shipping the first draft.

They mean: they spam “Easy Apply”, never talk to humans, and open LinkedIn only when they are already burned out in their current job.
Then they think the problem is their CV, their stack, or the market.

I’ll be brutal: your problem is not the market.
Your problem is that you’re invisible.

This issue is a 30‑day challenge and a routine to fix exactly that, with 30 minutes a day. No mindset talk, no “believe in yourself”. Just a plan you can follow and measure.

The 2 boring secrets nobody tells you

The first secret is stupidly simple: make it a habit.
If you use LinkedIn only when you’re desperate, it’s like going to the gym once a year before summer and expecting a six‑pack. You don’t need intensity, you need repetition. 30 minutes a day for 30 days beats one insane weekend of 200 applications.

The second secret: stop thinking there’s a direct hop between you and the job you want.
Real life is more like a routed network than a LAN cable. Most good opportunities come from weak ties, second‑degree connections, and people who have simply seen your name around for a while. And time is what increases the probability that one of these paths turns into a real opportunity: the longer you stay consistently visible, the more “routes” the network can build for you in the background.
Your job is not “DM the hiring manager and get hired”. Your job is to light up more and more nodes around you until one of those paths becomes a real lead.

With those two rules in mind (habit and multi‑hop thinking), here is how to use your 30‑minute daily budget for the next 30 days.

You have 30 minutes per day

If your routine feels like a second full‑time job, you’ll quit in a week.

So we fix a hard limit: 30 minutes per day, max.
Inside that time, you only do three things:

• send connection requests

• write or reply to messages

• react to posts and leave meaningful comments

No endless scrolling, no “I’ll just check the feed”. Treat LinkedIn like a CLI tool: open, run commands, close.

Days 1–3: set the board

Your first job is not “get interviews”.
Your first job is: build the right graph of people around you.

In the first 3 days (still 30 minutes per day):

• Pick 3–5 target companies you’d be happy to join.

• For each, find:

  • 2–3 engineers with similar stack

  • 1–2 senior / lead / staff

  • 1 recruiter or hiring manager

Save their profiles. Follow them. Turn on the little bell for 5–10 of them so you see their posts.

You’re not asking for anything yet. You’re just mapping the system.

Days 4–10: comments before DMs

Most devs jump straight to “Can you refer me?”.
That’s like opening a pull request on a repo where you never even starred the project.

Your rule for this week: comment first, connect later.

When someone from your list posts:

• Skip “great post”.

• Leave a comment that adds a tiny piece of value from your experience.

Example:

“We hit a similar performance issue when we moved from X to Y.
We solved it by [small, concrete detail]. Curious if you tried something like that.”

If you do this 3 times per week, in 7 days you are already less invisible than 90% of job seekers.

Connection templates (for shy engineers)

After a couple of comments and maybe a like from them, you send a connection request.

Keep it simple and specific:

“Hey [Name], I liked your post on [topic] – especially the part about [detail].
I work on [your stack/context], similar problems.
I’d like to add you here and keep learning from your updates.”

For someone in a target company:

“Hi [Name], I’m looking at [Company] because of your work on [product / tech].
I’m a Software Engineer focused on [your stack].
If it’s ok for you, I’d like to add you and ask you a couple of questions about the engineering culture sometime.”

No “can you refer me” yet. You’re doing what good engineers do: you’re warming up the system before sending heavy traffic.

Your monthly “connection quota”

To make progress, you need numbers.
A realistic monthly baseline:

• 40 connection requests sent (around 10 per week)

• Expect 50–70% acceptance if your profile is not a desert

And yes, this works better if your profile is not empty:

• clear headline: “Software Engineer | [stack] | interested in [domain]” instead of meme words

• About with 4–5 bullet points about what you build, not “passionate, motivated, driven”

You don’t need perfection. You need enough clarity for a stranger to say “ok, this person is real”.

Days 11–20: start the right conversations

Now you have:

• a small but better network

• some people who have seen your name in comments

• a few accepted connections

Time to send DMs that don’t feel like begging.

For an engineer in a target team:

“Thanks for connecting, [Name].
I’m exploring companies that work seriously on [topic], and [Company] keeps coming up.
If you were me and wanted to prepare for a future interview there, what 1–2 things would you focus on?”

For a recruiter:

“Hi [Name], thanks for accepting.
I’m not spamming applications everywhere, but over the next months I’d like to move toward roles where I can do more [backend / data / infra].
If you’d like, I can send a very short summary of what I do, so you can see if it aligns with any pipeline you follow.”

Your goal is information and visibility, not a favor on day one.

Days 21–30: show your work (without becoming an influencer)

In the last third of the month, you publish a couple of posts.
Not “thoughts about leadership”, not quotes. Small case studies.

Twice in 10 days, write something like:

“Last week I had to [problem].
The naive solution was [X], but it broke because [reason].
Here’s the simple version of what actually worked:

• step 1

• step 2

• step 3
  If you’ve solved this in a cleaner way, I’m all ears.”

You don’t need likes from the whole internet. You just need the right 5 people in your graph to see that you can think and ship.

Combine this with your routine:

• still 10 connection requests per week

• still 3 meaningful comments per week

• plus 2 posts in 10 days

All inside 30 minutes per day.

What “success” looks like after 30 days

If you do this properly for one month, realistic outcomes look like:

• more profile views from recruiters and engineers in your target area

• 3–10 actual conversations (DMs, quick calls, async help)

• a few messages like “Hey, we might open a role soon, want me to keep you posted?”

Is it a guaranteed offer? No.
But if you keep this routine for 90 days, you compound harder than any “100 applications per day” strategy.

The best part: you did it without trying to become an influencer, without posting daily, and without pretending to be someone else.

You just acted like a good engineer who understands networks: send small, consistent packets to the right nodes, let the weak ties do their job, and stop expecting a single direct hop to magically solve your career.

Let’s turn it into an experiment

Let’s make this concrete.
If you start the 30‑day challenge today, track just three simple metrics while you follow the routine in this article:

• number of new followers

• total impressions (posts and comments)

• number of profile views

Nothing fancy, just a small table or note in your phone.

At the end of the 30‑day challenge, come back to this article and drop a comment with your numbers and what changed for you.

If you do the challenge seriously, your future self will have a much harder time saying “LinkedIn doesn’t work for me”.

A few days ago, a LinkedIn News brief updated the picture: demand for forward-deployed engineers jumped by roughly 1000% in 2025, but many engineers still ignore these roles because they see them as “grunt work”, less prestigious than classic product engineering.

So we have a role companies are screaming for, that most devs either don’t really understand… or actively avoid.

Perfect topic for The LinkedIn Engineer.

So, what is a Forward-Deployed Engineer?

Strip away the buzzword.

A Forward-Deployed Engineer (FDE) is a software engineer who sits in the field, close to customers or business teams, and ships custom solutions on top of an existing platform (often AI) to solve very specific problems.

Instead of building a generic feature for “millions of users”, you go deep on one client, one business line, one messy workflow… and you make the system actually work in real life.

You are half builder, half translator.

You speak code, but you also speak “we are losing money here every day”.

Why is it suddenly everywhere?

Context is simple: in 2025, AI moved from demo mode to production for a lot of companies.

They now have powerful models and platforms, but almost no idea how to plug them into legacy systems, dirty data, and political process mess.

They don’t want:

• a researcher who only writes papers

• a consultant who only writes slides

• a support engineer who only closes tickets

They want someone who:

• embeds with the client

• understands the real problem

• builds the PoC

• hardens it

• gets it running in their infra

• and brings learnings back to the product team.

This end-to-end loop is exactly how FDEs describe their work at AI-first companies like OpenAI, Anthropic, Palantir and others.

The day-to-day (without the fluff)

Let’s drop the marketing.

A typical FDE cycle in 2026 looks like this:

1. You get a vague business request
   “We want to use AI for customer support” or “We need to reduce fraud.”

2. You turn it into a concrete problem
   You sit with operators, read logs and dashboards, find the real bottleneck, and design a clear technical plan.

3. You build a PoC
   You code fast: scripts, integrations, agents, pipelines. It’s rough, but it proves value.

4. You ship it for real
   You refactor, add observability and guardrails, deal with infra constraints, security, and compliance.

5. You close the loop
   You see patterns across different clients and feed them back into the core platform, so the product evolves based on what you saw in the field.

It’s not a “talking” role.

You still have hands on keyboard.

The difference is that your backlog is written in business pain, not just in JIRA tickets.

Is it just a fancy “customer-facing engineer”?

A lot of senior voices are openly saying: “Forward-Deployed Engineer is just a new label for what devs should have been doing anyway: talking to users and working with the business.”

And they are not totally wrong.

XP and Agile have been telling us for years that developers should be close to the problem, not just to the repo.

What is new:

• The AI angle: you are often the one who makes LLMs and agents safe, observable, and actually useful in production.

• The role fusion: instead of separate solution architect, data scientist, and customer success, the FDE often replaces two or three of these profiles at once.

That is why FDEs are becoming one of the better-paid profiles, and why job postings exploded between 2024 and 2025.

Why many engineers still run away

Even with all the hype, early 2026 data is clear: demand is exploding, but engineer interest is much softer.

Common fears you hear:

• “This is just firefighting for demanding clients.”

• “I’ll end up doing support, not engineering.”

• “I’ll lose technical depth and become the person for calls.”

In some companies, that risk is real.

If the culture is “the customer is always right”, you get random requests, 10 PM calls, and no real product ownership.

So you need to filter these roles aggressively, not accept them blindly.

When an FDE role makes sense for you

You should at least keep an eye on FDE roles if:

• You are already “that person” in your team
  You are the dev PMs and sales pull into calls because “you explain things well”. You get pinged to unblock weird prod bugs with half the info, and you still deliver.

• You like product, not only code
  You care about why something matters, not just how to implement it. You ask “what metric are we moving?” before you open the editor.

• You are curious about AI systems
  Many FDE roles now sit between infra, data, and AI agents. You don’t have to be a researcher, but you must be comfortable with evals, guardrails, monitoring, and real integrations.

If that sounds like you, this role can be a career accelerant, not a weird side quest.

Because you learn exactly what the 2026 market pays the most for: turning advanced tech into measurable business impact.

How to position yourself (starting today)

Even if you don’t apply to an FDE role tomorrow, you can start acting like one now.

In your current job:

• Volunteer to join at least one non-technical stakeholder call per month.

• Take one vague request and drive it end-to-end: clarify, design, build, ship, measure.

• Document the before/after with concrete numbers, not just “refactored X”.

On LinkedIn and your CV, skip “implemented feature X”.

Write like an FDE:

• “Reduced manual review time by 40% by building Y for the operations team.”

• “Deployed Z to production in 6 weeks, integrating 3 teams and 2 legacy systems.”

You are still showing Proof of Work, but now it is directly tied to revenue, cost, risk, or time.

That is exactly what hiring managers for FDE roles are scanning for in 2026.

If you are already doing this, you might be closer to “Forward-Deployed Engineer” than you think.

Not because I hate people. Not because I don’t want impact. Simply because I don’t have the vocation to take responsibility for other people’s growth (at least now), performance reviews, and careers — and that’s exactly what good managers do.

At the same time, the global narrative for 2026 is still obsessed with “engineering leadership”, “orchestrating cultural change”, “upskilling talent”, and all of that. If you only read those posts, it looks like there is only one way to grow: become a manager and start playing politics.

That’s the script I want to challenge.

IC vs Manager: different problems, not different levels

In that LinkedIn post, I said it very clearly:

I love brainstorming ideas, studying solutions for hard problems, and seeing those problems become bigger and bigger.

That is IC energy.

The IC path is about:

• Solving technical problems (systems, data, architecture, performance).

• Designing solutions that have a disruptive impact on the product.

• Influencing others through clarity, examples, and technical judgment — not authority.

The management path is about:

• Solving human problems (motivation, conflicts, misalignment).

• Taking responsibility for people’s growth, careers, and well‑being.

• Translating business priorities into team execution, and dealing with stakeholders all day long.

One is not a promotion of the other.

It’s like switching from refactoring code to refactoring organizations.

If you don’t feel that “people-growth” vocation

Let’s talk directly to you if you are in this spot:

You see managers around you who genuinely love “growing people”. They get energy from 1:1s, coaching, and performance reviews. They talk about “unlocking potential” and they mean it.

You, instead, don’t feel that same fire. You care about your teammates, you like helping them, but you don’t wake up thinking “I want to dedicate my career to developing other people”.

Here is the key message:

You don’t have to feel guilty for this, and you are not broken.

You don’t “owe” the world a management vocation. You don’t have the duty to force it, to fake it, or to wait until it magically appears.

Careers are not one‑time, irreversible decisions.

They are a continuous negotiation between:

• What the market needs.

• What you can do well.

• What you actually feel like doing in this specific season of your life.

If right now you don’t feel that strong call to own other people’s careers, it’s perfectly valid to say:

“This is not for me — at least, not now.”

And then double down on the IC path without shame. If one day something changes, you can revisit the decision. But forcing a vocation rarely ends well — for you or for the people you’d manage.

The damage of accidental managers

When someone becomes a manager just because “that’s the only way to grow”, you get accidental managers.

They liked debugging production, now they debug people. But they never really wanted that job.

Typical outcomes:

• They micromanage because they are frustrated and miss coding.

• They don’t really cultivate talent; they protect their ego and their title.

• They create bottlenecks instead of unblocking others.

This doesn’t just slow down a team.

It feeds a system where:

• Individual Contributors are seen as “not ambitious enough”.

• Management seats are occupied by people who don’t care about mentoring.

• The next generation of devs has even fewer good role models.

Bad managers don’t just ruin sprints. They quietly ruin careers.

The economics of IC in 2026 (especially in Europe)

The old corporate rule was: more direct reports = more money.

In 2026, that rule is weaker, especially in serious European tech hubs. Research and market data show companies cutting useless middle‑management layers and investing more into high‑leverage technical roles and platform teams across Europe.

What they pay for now is:

• People who can design resilient, scalable systems that handle AI‑heavy, data‑heavy workloads.

• ICs who can connect architecture, cost, security, and user experience in one single picture.

• Engineers who reduce risk and complexity across multiple teams — without needing a huge org below them.

That’s why dual career ladders (IC vs Management) are becoming more common: in mature models, Staff / Principal Engineers can reach compensation levels on par with Directors when they own critical systems and decisions.

You’re not “leaving money on the table” by staying IC.

You’re just choosing to solve high‑value technical problems instead of managing headcount — the exact mindset behind The European Engineer, where the whole goal is helping senior devs in Europe treat the IC path as a serious, high‑paying, long‑term career, not as “what you do before you become a manager”.​

What good IC‑friendly companies look like

In my post, I listed a few traits of companies where you can truly grow as an IC.

They usually:

• Have clear company values, not just buzzwords on a slide.

• Are often product companies, or at least less “body rental” style consulting.

• Keep the hierarchy relatively flat, so ICs can talk directly to decision‑makers.

• Are either young or at least fast at changing direction when the market moves.

• Stay informal enough that titles matter less than impact.

• Provide parallel career paths: IC and Management, same dignity.

Across Europe, more companies are realizing they need strong Staff‑level ICs to handle AI‑native platforms, multi‑agent systems, and complex architectures, not just more layers of managers.

If your current company doesn’t offer this, that’s not your failure.

It’s just the wrong environment for your type of ambition.

A practical way to choose your path

Forget job titles for a moment.

Ask yourself:

“Do I want to spend my best energy fixing systems, or fixing people problems?”

If you:

• Love deep work, hard technical problems, and seeing your designs go from idea to production.

• Enjoy mentoring, but don’t want to own performance reviews.

• Prefer impact through systems instead of through direct reports.

…then staying IC is not cowardice. It’s clarity.

On the other side, if you:

• Feel excited by helping others grow and mediating conflicts.

• Get energy from coaching, feedback, and aligning humans.

• Are okay with your results being visible only after months.

…then management can be a beautiful path.

Just don’t pick it by default.

If you feel that pressure to become a manager but you don’t feel that inner vocation, allow yourself to say “no”. You’re not refusing growth. You’re choosing the kind of growth that actually fits who you are right now.

But as of March 2026, the foundation of what defines a “top performer” has shifted. We have moved from an era of high-volume production to an era of high-leverage direction. If you are still trying to get promoted by showing off your coding velocity, you are measuring a ghost.

The Old Model: Measuring Manual Output

For decades, evaluating a Software Engineer was a proxy for measuring manual labor. We used metrics to track what was essentially a manufacturing process:

• Throughput: DORA metrics, cycle time, and PR frequency.

• Technical Excellence: Mastery of complex syntax and manual debugging.

• Glue Work: Mentoring juniors through manual code reviews.

In that world, the engineer was a high-end craftsman. The more “artisan” your code was, the more indispensable you were. You were evaluated on your ability to generate solutions manually.

The 2026 Disruption: Execution is now a Commodity

The adoption of Agentic AI and Spec-Driven Development has turned the old model upside down. When an AI agent can generate a functionally perfect microservice in 30 seconds, the value of “writing code” has plummeted toward zero.

If a Junior can produce the same output volume as a Staff Engineer by using the right agents, the old review system collapses. To get promoted now, you have to prove value in the areas the machine cannot touch.

1. The Critical Skill: Noise Filtering and Signal Extraction

In 2026, the biggest threat to a project isn’t a lack of code; it’s an explosion of “noise”. AI can generate endless documentation, thousands of unit tests, and infinite architectural variations.

• The New Requirement: Information Synthesis.

• In the Review: You are now evaluated on your ability to cut through the static. Can you identify which 5% of the AI’s output actually matters for the business logic?

• The Promotion Factor: Promotions now go to the engineers who keep the system “quiet” and focused. If you allow the AI to add unnecessary dependencies or 5,000 lines of “boilerplate” just because it can, you are seen as a liability, not a senior.

2. The Responsibility Trap: Who owns the Bug?

We are seeing a massive surge in AI-generated code reaching production. This has led to a dangerous side effect: the erosion of ownership. Developers are drifting into a state of “passive monitoring”, trusting the AI to get it right because it’s faster.

• The Conflict: More AI code in production means more “alien” logic. If you didn’t write it, you don’t feel like you own it. This makes recognizing and fixing bugs nearly impossible during a crisis.

• In the Review: Managers are now testing for Mental Traceability. If a bug hits production, can you explain the logic behind the AI-generated code? Or do you shrug and blame the model?

• The Promotion Factor: To move up, you must prove you have full control over what you’ve generated. Ownership in 2026 means being able to debug a system you didn’t manually type. If you lose control of the logic, you lose your seniority.

3. From “Writing” to “Risk Arbitrage”

The cost of creation is now zero, but the cost of a mistake in production is higher than ever.

• The Shift: Judgment over Execution.

• In the Review: You are no longer praised for “clean code”. You are evaluated on your Audit Proficiency. Did you catch the subtle security flaw in the generated auth logic? Did you spot the hidden cost implication in the AI’s infrastructure proposal?

• The Promotion Factor: You aren’t paid to create; you are paid to “verify and sign off”. Your “signature” on a PR is now a legal-like guarantee of safety and business alignment.

4. Strategic Decomposition (The “Spec” is the Product)

As coding moves to the background, the real engineering happens in the Problem Space.

• The Shift: Precision of Intent.

• In the Review: Managers are looking at your “Specs”. Are they ambiguous? Does the AI require ten iterations to understand you, or is your mental model so clear that the system is built correctly on the first try?

• The Promotion Factor: High-performers translate messy business “vibes” into surgical technical requirements. If you can’t describe the problem with mathematical precision, you are useless in a world of autonomous agents.

5. The “AI Leverage” Quotient and Orchestration

Efficiency is no longer about typing faster; it’s about Systemic Orchestration.

• The Shift: The Human-to-Agent Ratio.

• In the Review: You are evaluated on how you’ve optimized your workflow. A top-tier engineer handles the scope that previously required a 5-person team. The review asks: “How many agents are you successfully orchestrating?”

• The Promotion Factor: Sticking to manual processes is now seen as a lack of competence. To get promoted, you must show that you can manage a fleet of AI agents like a manager handles a team.

6. Managing “Infinite” Technical Debt

AI makes it dangerously easy to create massive amounts of code. If you don’t control it, you’ll end up with a codebase that no human can ever audit.

• The Shift: Negative Code Growth.

• In the Review: Are you making the system simpler or just bigger?

• The Promotion Factor: The best engineers in 2026 are those who use AI to delete code. If you can achieve a business goal by removing 1,000 lines of legacy mess and replacing them with a lean logic, you are a hero.

The Bottom Line

Performance reviews in 2026 are no longer about your hands; they are about your head.

The Software Engineer has evolved into a Technological Conductor. You are not evaluated on how well you play the violin, but on how well the entire orchestra performs under your baton.

If you enter your 2026 review boasting about “lines of code” or “sprint velocity”, you are telling your manager that you are a commodity. To be promoted, you must demonstrate architectural judgment, noise filtering, and the ability to take full responsibility for the final result.

Competing purely on your ability to write syntax is a losing game.

It is exactly like early blockchain mining. Trying to out-code an AI today is like a single computer trying to win a race against a global network of ASICs. You are competing against infinite, instant compute. You cannot win on speed. You cannot win on volume. And very soon, you will not win on accuracy either.

As AI takes over the execution layer, the amount of manual code we write drops dramatically. This change has created a massive, silent crisis across the industry. The true victims are not the managers, the directors, or the tech leads. The true victims are the current Juniors.

The Paradox of Friction

If the AI does the heavy lifting, a terrifying problem emerges at the base of the industry.

Historically, you learned to program through hard work and frustration. You learned about database locks because you accidentally crashed production at 3 AM and had to fix it while sweating over your keyboard. You learned memory management by staring at broken code for three days straight.

That friction was how you learned. That intense struggle is exactly what built the mental models you needed to understand complex systems. You did not just learn the syntax. You learned how the machine actually works.

If AI removes the friction, how do you learn? If an agent instantly hands you the perfect function, you get the output, but you lose the journey. You lose the struggle that makes you a true engineer.

This leads to a chilling question.

In ten years, will we still know how to build software?

If nobody is forced to sweat through the logic, an entire generation will forget the technical details behind the tools they use. We risk becoming operators who simply talk to black boxes we fundamentally do not understand.

The Luckiest Generation

This exposes a brutal unfairness in the current market. The last generation of Senior Developers hit the jackpot.

They built their careers before the AI boom. They were forced to endure the manual labor of software engineering. They accumulated years of painful problem-solving. Now, at the peak of their careers, they have been handed the ultimate multiplier. They can use AI to 10x their output because they possess the deep, hard-earned knowledge to steer it, architect around it, and fix its mistakes.

Or at least, until they forget how to code too. Because if you stop exercising a muscle, it gets weak. Even Seniors risk losing their edge if they blindly trust the output.

But the Juniors are stranded. The traditional entry-level job is gone. Nobody will pay a recent graduate a salary to write boilerplate code, fix minor CSS bugs, or build simple CRUD endpoints. The AI does that for free, instantly.

The 9 skills you should have if you are a Junior in 2026

So, what do you do? If the "junior coder" role is dead, how do you enter the market? You must completely pivot. You must stop competing on syntax and start competing on reality.

Here is your new baseline. These are the 9 concrete skills you must master to survive and grow.

1. Reading is the new Writing You will not be hired to write 10,000 lines of code. You will be hired to review them. In a Spec-Driven Development environment, your role shifts dramatically: you must review mountains of technical specifications and outputs before the code even begins to exist. Your job is to "spot the lie". You must develop a ruthless ability to read through complex logic, identify broken business rules, and find security vulnerabilities in seconds. If you want to maintain control over the system, you must be a world-class reader. If you can’t validate the spec, you can’t own the product.

2. Connect the Dots AI is incredibly good at local solutions. It is terrible at global thinking. It will write a perfect isolated function that completely destroys your database architecture when deployed. Your job is to see the whole board. You must understand how the frontend affects the backend, how APIs interact, and how data flows. You must become a systems architect from day one.

3. Master System Design AI can easily generate a perfect software architecture. But it will be a generic one. AI does not know the messy reality of your company. It does not know the decisions made in meetings or the hidden human variables. Every architecture must fit the exact system you are working on. You must develop a holistic view to gather all this real-world context in your mind. Your job is to understand the whole picture so you can give the right constraints and the exact context to the AI.

4. The Art of Asking Questions In the AI era, the world is divided between those who get results and those who don't. The difference is rarely technical—it’s the ability to ask the right questions. Socratic questioning and critical thinking are your new "IDE". Asking the right question is how you express deep thought and force the AI (and yourself) out of generic patterns. This is the ultimate human advantage: AI can answer anything, but it cannot decide what is worth asking.

5. The Human Problem As Tom DeMarco and Timothy Lister established in the classic book Peopleware, most problems in software development are not technical. They are human. AI does not understand office politics. AI cannot read the room when a stakeholder is angry. AI cannot negotiate a feature cut with a stressed Product Manager. If you can mediate between cold code and messy human emotions, you become essential.

6. Deep Domain Expertise The AI knows Python perfectly. The AI does not know the specific business rules of the logistics company you work for. You must become obsessed with the real-world domain. Understand the business model, the costs, and the user’s pain points. If you hold the context of the business, you hold the power to direct the technology.

7. Cross-Disciplinary Translation The walls between departments are falling. You can no longer just speak "developer". You need to speak "design" to the UX team, "revenue" to the sales team, and "strategy" to the founders. You must become the translator who connects the business goal and the technical execution.

8. Be Innovative AI only follows instructions. It does not wake up and decide to improve the product. You must become a promoter of bottom-up approaches. Do not just sit and wait for the next task. Be proactive. Look at the business, find hidden problems, and propose new ideas to solve them. Suggest new approaches that add real value to the project. This human initiative is something no machine can replicate.

9. Cultivate your Infinite Context Window An AI agent might have a huge context window, but it does not live in the real world. Your human context window is infinitely larger. You can accumulate context for months and years. When you take deep ownership of a product, you naturally become a central hub. You remember why an architecture was chosen three years ago. You know which client requested a weird edge case. You accumulate years of unwritten rules and team decisions. If you actively manage this historical knowledge, you become irreplaceable. You become the living memory of the company.

If you are a Junior reading this

The traditional ladder is broken, but you do not need it anymore.

In practice, you are now required to work on the exact skills that a Senior developer used to start acquiring only after years in the field. You lost the luxury of easing into this career by writing meaningless CSS and boilerplate. But you also gained the ability to operate at a level that used to take a decade to reach. You get to skip the typing phase and go straight to the thinking phase.

Stop waiting for a Senior to hand you a perfectly written ticket. Stop hiding behind the code editor. Go find a messy business problem. Use AI to do the heavy lifting, and use your brain to make sure it actually works in the real world. Take full ownership of the final result.

The market will never again pay for a junior typist. It will only pay for a junior problem solver.

The friction has not disappeared. It has just moved from the syntax to the system. The syntax belongs to the machine. The system belongs to you.

They are waking up to a terrifying realization: their entire workforce was architected for a completely different industrial epoch.

They built armies of specialized workers to solve the friction of building software. That friction is now gone.

This sudden shift has created a pervasive fear of replacement. Developers are terrified that AI will simply delete our profession and leave us jobless. I look at the market data and see a very different trajectory. We are not facing mass unemployment. We are facing a radical mutation in our degree of diversification.

We are heading toward the "1-man company" hypothesis. Instead of being replaced, we will become fractional entities. We will mutate into "fractional software engineers" who sell specialized orchestration to multiple employers, startups, or even other 1-man companies.

The Inversion of Risk

To understand why this is happening, we have to look at how the concept of professional risk has completely flipped.

A decade ago, a full-time, open-ended contract was the ultimate guarantee of safety. Freelancing was viewed as a chaotic, high-risk gamble. Today, that logic is fundamentally broken.

A traditional full-time job is a single point of failure. You are a business of one, selling 100% of your inventory to a single client who can terminate your revenue stream on a Tuesday morning via an automated email. That is a catastrophic risk management strategy.

Paradoxically, the freelancer model is becoming the safer harbor. Having five different clients paying you for fractional work allows you to diversify your risk. If one startup goes under, you lose 20% of your revenue, not 100%. Operating as a 1-man company is rapidly becoming the only rational way to hedge against corporate volatility.

The Evaporation of the Middle

This fractional shift is creating an hourglass market. The middle layer is completely evaporating.

Companies are aggressively flattening their hierarchies. They are actively eliminating intermediary roles like traditional Product Managers and Engineering Managers. They no longer want a chain of command to translate business needs into code. They want deep transversality. They demand Product Engineers and Technical Leaders who can touch the database, understand the unit economics, and ship the feature autonomously.

We see this in the startup ecosystem too. The old rules are dead. Previously, a startup would reach Product-Market Fit and immediately hire 200 people to scale operations. That era is over. Today, highly successful companies hit massive scale and actively choose to remain incredibly lean. They scale revenue, but they freeze headcount. The market simply has no room for the corporate middle class anymore.

The Three Digital Drivers

This transition into an army of 1-man companies is accelerated by three fundamental forces in the digital world.

1. The Dev as an Agency A software engineer is no longer just a typist of syntax. Armed with AI models, a single developer can act as an autonomous agency. You can generate the marketing copy, design the UI, write the complex backend logic, and analyze the user data. The developer is no longer a cog in the machine. The developer is the machine.

2. Democratized Infrastructure The barrier to entry has collapsed. Cloud computing, API ecosystems, and global payment gateways like Stripe have driven the cost of launching a digital product to near zero. Capital is no longer the bottleneck for creating software. The only true limit remaining is capturing the market’s attention.

3. The Redefinition of Security As mentioned, the math of safety has changed. The infrastructure allows you to serve multiple nodes simultaneously. You can build micro-SaaS products while consulting fractionally for a Series A startup. You own your means of production.

The Biological Ceiling

If the economics of the 1-man company are so superior, why won’t every single person adopt this model? Humans do not scale like software.

True entrepreneurship requires a tolerance for chaos, financial instability, and chronic stress. The burnout rate for solopreneurs is brutal. Taking full responsibility for every failure is a psychological burden that most people actively want to avoid.

Furthermore, we are strictly bound by the 24-hour limit. No matter how much AI leverage you deploy, you eventually hit a ceiling where growth requires delegating to other human beings. This is an absolute rule for "Deep Tech". You cannot build a quantum computer, cure complex diseases, or launch a fusion reactor from your bedroom. The deepest innovations still require massive capital, complex human friction, and multidisciplinary teams.

Crossing the Physical Chasm

So far, the 1-man company model has been restricted entirely to the digital world. SaaS, media, and consulting are playgrounds of pure information. A tectonic shift is coming.

What happens when robotics gets its ChatGPT moment? What happens when Embodied AI becomes cheap, reliable, and accessible?

We will witness the birth of the 1-Man Orchestrator. Imagine a former software engineer who no longer deploys code to AWS servers. They deploy instructions to a swarm of autonomous drones, automated forklifts, or robotic manufacturing arms.

This will create true "Micro-Multinationals". These will be companies consisting of two or three individuals. They will coordinate physical fleets via software APIs and generate the physical output of a 1990s manufacturing plant. The bridge between digital logic and physical atoms is being built right now.

Hardware Forgives No One

Before we crown ourselves the kings of robotic empires, we must acknowledge the brutal laws of physics. Software costs 20 dollars a month and scales infinitely. Atoms are heavy, expensive, and unforgiving.

If you want to orchestrate physical labor, you will inevitably hit three massive walls.

First, the Capital Wall. Hardware requires serious money. Software needs electricity. Robots need steel, lithium, physical maintenance, and massive upfront CapEx. You can bootstrap a web application over the weekend. You cannot bootstrap a fleet of delivery robots without millions in funding.

Second, the Liability Wall. If your web application has a bug, a database drops and you lose a few customers. If your autonomous robotic arm has a bug, it might crush a warehouse worker. You will go to prison. The physical world demands rigorous compliance, safety protocols, and massive insurance policies. You will need a heavy, structured corporate shield just to absorb the legal liability of moving atoms.

Third, the Supply Chain Wall. Moving physical goods is not like routing data packets. Physical production relies on incredibly complex, slow, and heavily guarded oligopolies. Ports, shipping routes, and raw material extraction are controlled by massive entities. You cannot disrupt a cargo ship with a Python script.

The Orchestration Era

Five years ago, the theory of the "1-man company" orchestrating both digital and physical empires sounded like an extreme cyberpunk fantasy. It was an improbable thought experiment. Today, the contours of this reality are becoming incredibly concrete.

It is completely normal to feel disoriented. The death of the corporate middle class, the brutal layoffs, and the rise of AI agents create a deeply uncertain environment. But we must not confuse uncertainty with doom.

This is actually a message of massive hope. We are living through the most empowering time in human history to be a builder. A single individual has never wielded this much raw leverage. The fact that the old corporate safety net is vanishing also means that the old corporate ceilings are gone.

Code might be becoming a commodity, but human ingenuity is not. We are stepping into a chaotic, unmapped territory. But the potential on the other side of this transition is absolutely massive.

Remember that the most powerful technology ever to exist still has absolutely no rivals. It is human intellect and its ideas. The creative and decision-making process remains firmly in human hands.

In the future, what will matter is not being an engineer. What will matter is being smart, being organized, and being innovative.

And none of that depends on the technology.

When I wrote it, it sounded like a mild provocation. Fast forward to today, and it is no longer a prediction. It is a survival strategy.

We are living in an era of massive uncertainty for tech workers. Layoffs have reset the market, AI agents are writing boilerplate faster than we can type, and the classic “Software Engineer” role is experiencing an identity crisis.

If you are wondering what your next career move should be, the answer is not learning another JavaScript framework. The answer is stepping out of the code and into the product.

1. What exactly is a “Product Engineer”?

Let’s clear the confusion immediately: a Product Engineer is not just a Full-Stack developer with a trendy new title. It is a fundamental shift in ownership.

A traditional Software Engineer is measured by Output. They receive a well-defined Jira ticket, they write the code, they pass the tests, and they close the ticket. Their concern is how to build it.

A Product Engineer is measured by Outcome. They care about the business metrics. They care about user retention, churn, and revenue. Their primary concern is what to build and why we are building it.

A Product Engineer is an engineer who has the technical chops to ship a feature end-to-end, but the business acumen of a Product Manager. If a requested feature makes no sense for the user, they push back before writing a single line of code.

2. How did we get here? A brief history.

To understand why this role exists, you have to look at the evolution of abstraction layers in our industry.

• Phase 1: The Silos (2010s). We had strict boundaries. Frontend devs wrote HTML/CSS. Backend devs wrote Java. DBAs touched the database. Sysadmins deployed. It took 5 people to ship a button.

• Phase 2: The Full-Stack & DevOps era (2015-2022). Cloud infrastructure (AWS, Vercel, Supabase) abstracted the servers away. Frameworks evolved. Suddenly, one engineer could build and deploy the entire technical stack.

• Phase 3: The Product Era (Now). The technical barriers to entry have collapsed entirely. We have solved the problem of how to build software quickly. The new bottleneck is deciding what is actually worth building.

We reached a point where companies realized they were extremely efficient at shipping code that nobody wanted. The gap between “the person who talks to the user” (PM) and “the person who builds the thing” (SWE) became too expensive. So, the roles began to merge.

3. The 2026 Reality: Why you must become one right now.

Why is this transition so urgent? Because the value of pure, raw “Hard Skills” is deflating rapidly.

Let’s be brutally honest: if your only professional skill is translating a perfectly written set of requirements into TypeScript or Python, you are in danger. You are competing directly with AI models that do exactly that—translation of intent into syntax—for pennies, instantly, and without complaining.

Syntax is becoming a commodity. Writing code is no longer the scarce resource.

AI cannot talk to a frustrated customer on a Zendesk call, understand the nuanced reason why they are abandoning the checkout flow, and intuitively prototype a UX fix that aligns with the company’s revenue goals. A Product Engineer can.

4. The rise of the Micro-Team and Solopreneurs

There is another massive macroeconomic trend pushing this: the rise of Lean Startups, Product-Led Growth (PLG) companies, and Solopreneurs.

Capital is no longer free. Startups cannot afford the bloated teams of 2021, where every feature required a PM, a UX Designer, an Engineering Manager, and three devs. Today, the most successful tech companies are incredibly lean. They want Micro-Teams: 1 or 2 highly leveraged Product Engineers who can iterate directly with the market.

If you are a Solopreneur or an indie hacker, you already know this. You are forced to be a Product Engineer because you don’t have a PM to write your specs. You have to figure out the market fit yourself. Companies are now looking for this exact “founder mentality” inside their own ranks.

5. How to make the switch (and what to stop doing)

You don’t become a Product Engineer by asking your HR department for a title change. You become one by fundamentally changing how you operate on a daily basis.

If you want to survive this shift, you have to kill the “Ticket Taker” mindset. Here is how you operate now:

• Stop worshipping clear requirements: If you only thrive when someone hands you a perfectly groomed specification, you are vulnerable. The market doesn’t pay a premium for execution anymore. Be the one who puts clarity on ambiguity. Take a messy, unstructured business problem and define the technical path forward yourself.

• Talk to the stakeholders: You are the bridge. Right now, you are the crucial intermediary between the real-world and the technology. You need to step out of your IDE and understand the constraints of the business, the goals of the founders, and the dynamics of the market. When you hold the context of the real world, you dictate how the technology should serve it.

• Look at the damn metrics: You cannot care about the product if you don’t know how it’s performing. Get access to your analytics tools. If you deploy a feature and never check if users are actually engaging with it, you are still just a coder.

• Prioritize “Time to Value”: Building the perfect, scalable architecture for a feature nobody wants is a massive waste of time and money. A Product Engineer ships fast to validate the idea, and refactors later when the market proves them right.

Conclusion: Start to focus on Context

We have already entered a transition phase. With AI writing the bulk of our code, the true added value of a developer has shifted. You are no longer just writing software, you are Engineering the Context.

Yes, you still need to make the effort to stay in full control of the AI-generated code. You cannot afford to blindly trust the black box and lose your grip on the architecture. But while you maintain that control, you must restructure how you work.

Your goal is no longer to be a “coder”. Your goal is to be organized, smart, and deeply connected to the real world.

AI has the syntax, but it has no memory of what actually happens outside your IDE. Your new job is to remember the details, connect the dots between user problems and technical solutions, and stimulate the creativity that algorithms lack.

These are the new hard skills. Stop focusing on syntax. Start focusing on context.

This person is rarely the “Rockstar” who ships the most complex algorithms. This person is the Glue.

In 2022, Tanya Reilly (Principal Engineer) coined the term “Being Glue” in a seminal talk that changed how we look at engineering careers. Her thesis was brutal but necessary: Glue Work is essential for the success of the team, but it is often fatal for the career of the individual.

1. The Anatomy of Glue Work

What exactly is Glue Work? It is the set of tasks that makes a team successful but is not strictly “shipping code”. Think of a brick wall. The bricks are the features, the code, the shipped products. The mortar is the glue. Without mortar, the wall collapses. But when people admire a wall, they only count the bricks.

You know you are the Glue Employee if you find yourself constantly:

• Updating Documentation: Because “someone has to do it”.

• Onboarding: Teaching the codebase to every new hire because you are the most approachable.

• Unblocking: Debugging other people’s environment issues so they can keep working.

• Mediating: Translating between Product Managers and Engineers.

• Sentinelling: Catching edge cases in meetings that others missed.

2. The Trap: High Value, Low Visibility

The paradox is that Glue Employees are often the most valuable members of the team. Managers love them because the team runs smoothly. But come promotion time, the conversation often goes like this:

Manager: “You are incredible. The team loves you. But we can’t promote you to Senior yet.”
Glue Employee: “Why? I helped everyone ship their projects!”
Manager: “Exactly. You helped. But you didn’t own a complex technical deliverable yourself. Your coding output is lower than your peers.”

This is backed by research from the University of Pittsburgh (The “No Club” study), which identified Non-Promotable Tasks (NPTs).

They found that these tasks are vital for the organization but carry zero weight in performance reviews. Crucially, they found that women are expected to volunteer for these tasks 44% more often than men, creating a structural barrier to advancement.

3. The Concept of “Technical Capital”

To understand why this happens, we need to talk about Technical Capital. Imagine your career credibility as a bank account.

• Every time you solve a hard technical problem, ship a feature, or fix a critical bug, you deposit Technical Capital.

• Every time you do Glue Work (meetings, docs, coordination), you are spending time without depositing capital.

The Economic Reality:

• Senior/Staff Engineers have a lot of Technical Capital. They can afford to spend it on Glue Work. In fact, doing Glue Work is part of a Senior role (multiplying the team).

• Junior/Mid Engineers have empty bank accounts. If they spend all their time on Glue, they go into debt. They become “The person who takes notes”, not “The Engineer who builds systems”.

4. The Strategy: How to Survive Being Glue

If you are the Glue, you don’t need to stop caring. You need to change your strategy based on your level.

For Junior & Mid-Level Engineers: The “Oxygen Mask” Rule

The advice isn’t to be a selfish jerk. It is to follow the airline safety rule: “Put on your own oxygen mask before assisting others.”

Your oxygen is Shipping Code. If you don’t ship, you suffocate.

• The 80/20 Rule: Dedicate 80% of your time to your assigned tickets. Only 20% goes to helping others.

• Redirect, Don’t Solve: When a new hire asks for help, don’t fix it for them. Point them to the documentation. If the doc is broken, tell them to update it as they learn. That’s how they learn, and how you save time.

• Avoid “Housekeeping” Glue: There is “Technical Glue” (Code Review, Architecture Design) and “Housekeeping Glue” (Scheduling meetings, taking notes, organizing team building). As a Junior, aggressively avoid the Housekeeping Glue. It creates zero Technical Capital.

For Senior & Staff Engineers: From “Doing” to “Sponsoring”

At this level, you should be doing Glue Work. But you must ensure it’s visible and strategic.

• The Brag Document: Never do Glue Work secretly. Keep a “Brag Doc” where you list every interaction: “Unblocked Team B by fixing the CI pipeline”, “Mentored Alice to ship Feature Y”. Bring this to your performance review.

• Sponsorship: Instead of doing the work, sponsor it. If you see a gap (e.g., missing tests), don’t write them yourself. Create a ticket, assign it to a Junior, and mentor them through it. You get credit for leadership; they get credit for the code.

• Frame it correctly: Change your vocabulary.

  • Bad: “I helped with the meeting.”

  • Good: “I aligned stakeholders to unblock the Q3 roadmap.”

5. A Note for Managers

If you lead a team, identifying your Glue is actually very difficult. Why? Because your dashboards are lying to you. The Glue Employee often has fewer closed tickets than the rest of the team, because they spent their week helping others close theirs.

To find them, ignore the charts and look for the “Vacation Anomaly”:

• Who is the person that, when they go on vacation, causes the team to suddenly feel chaotic?

• Who is the person mentioned most often in the “Thanks” channel, but least often in the “Shipped Features” channel?

That is your Glue. If you don’t reward them, two things will happen:

1. Burnout: They will quit because they feel taken for granted.

2. Regression: When they leave, your team’s velocity will drop mysteriously by 30%, because the “invisible work” is no longer getting done.

Conclusion

Being the Glue is a superpower. It means you understand the system, not just the syntax. But you must be a Strategic Glue.

Don’t let your helpfulness become your handicap. Build your Technical Capital first. Then, and only then, use it to hold the wall together.

And then... silence. No signups. No feedback. No revenue. Just a server bill and a bruised ego.

Why does this happen? Because as engineers, we are trained to solve technical puzzles. We get our dopamine hit from “getting it to work”. But the market doesn’t care about your architecture. The market only pays for the value you deliver.

If you want to transition from a Coder to a Builder, you must fix the biggest bug in your operating system: The “Solution-First” Mindset.

1. The Two Types of Risk

To understand why we fail, we need to distinguish between two types of risk.

1. Technical Risk: “Can this be built?”

   • Example: Can we build a fusion reactor? Can we build a bridge to Mars?

   • Reality: For 99% of SaaS ideas, the Technical Risk is zero. You know you can build a To-Do app. You know you can build a CRM. The question isn’t can you, but should you.

2. Market Risk: “Will anyone pay for this?”

   • Example: Does the world need another project management tool? Will people pay for an AI recipe generator?

The Trap: Engineers love mitigating Technical Risk because it’s within our control. It feels like work. It feels productive. But successful Builders obsess over Market Risk. They refuse to write a single line of code until they have proof that the problem exists and is painful enough to warrant a solution.

2. How to find “Boring” Problems

If you shouldn’t start with code, where do you start?

You start with Friction.

The best business ideas usually don’t look like “revolutionary tech”. They look like frustrated people trying to do their job. Don’t look for “cool” ideas. Look for “Boring” problems.

Here is a heuristic to find them:

• The Excel Index: If a business is running a critical process on a messy, shared Excel file that crashes every day, that is a SaaS product waiting to be built. Excel is the biggest competitor of B2B SaaS, and it’s vulnerable.

• The “Copy-Paste” Loop: If a human is manually copying data from an Email to a CRM, or from a PDF to a spreadsheet, that is an automation script people will pay for.

• The “Bleeding Neck”: In sales, they distinguish between “Vitamins” and “Painkillers”.

  • Vitamin: “An app to organize my bookmark collection”. (Nice to have, but nobody pays).

  • Painkiller: “A tool that stops my AWS bill from exploding”. (Must have. Companies will throw money at you).

Rule of thumb: If the problem doesn’t annoy the user enough to make them open their wallet, it’s not a business. It’s a hobby.

3. The Validation Stack (Before npm init)

So, you found a potential problem. Your fingers are itching to type npm init. Stop.

Writing code is the most expensive way to test an idea. It costs time, energy and server money. You need to run a Validation Algorithm first.

Step 1: The “Smoke Test” (The Doorway)

Build a simple Landing Page. Do not build the app. Use a no-code tool (Framer, Carrd) or AI to spin it up in an hour. Describe the value proposition clearly: “I help [Target Audience] solve [Problem] by [Solution]”. Add a “Join Waitlist” or “Buy Now” button.

Run $50 of ads or post it in relevant communities (Reddit, niche forums).

• If nobody clicks? You just saved yourself 3 months of coding. Kill the idea.

• If people sign up? You have a signal. Proceed to Step 2.

Step 2: The “Mom Test” (The Interview)

You need to talk to humans. But be careful: if you ask your mom “Is my idea good?”, she will lie to protect your feelings. You need to use The Mom Test method (by Rob Fitzpatrick).

Bad Questions (Hypothetical):

• “Would you use this app?”

• “How much would you pay for this?”

• “Do you think this is a good feature?”

Good Questions (Historical):

• “Tell me about the last time you encountered this problem.”

• “How do you currently solve it?”

• “How much does that current solution cost you (in money or time)?”

• “Have you tried looking for other solutions? Why didn’t they work?”

If they aren’t already trying to solve the problem (even clumsily), they won’t buy your software.

Step 3: The “Wizard of Oz” MVP

This is the ultimate secret of Solopreneurs. In the movie The Wizard of Oz, the scary giant head was just an old man pulling levers behind a curtain. You can do the same.

Don’t build the backend automation yet. If you are building an “AI Logo Generator”, put up a form. When a user submits a request, you generate the logo manually (or use Midjourney) and email it to them. From the outside, it looks like software. On the inside, it’s just you.

This allows you to test if people are happy with the output without building the engine. Do this until the manual work becomes too much to handle. Then write the code to automate yourself out of the loop.

4. Handling the Pivot

What happens if the validation fails? What if nobody signs up for the waitlist?

Celebrate. Seriously. You just avoided the most common failure mode in our industry: building a ghost town. Validation is not about proving you are right; it is about finding the truth.

In 2026, the cost of trying an idea is near zero. The “Builder” is not someone who never fails. It is someone who fails fast and cheap.

• Coder: Spends 3 months building -> Fails -> Quits.

• Builder: Spends 3 days validating -> Fails -> Pivots -> Wins.

Conclusion: Fall in love with the Problem

The transition from Coder to Builder is painful because it requires us to suppress our builder’s instinct. It requires us to spend time in the “messy” real world, talking to humans, understanding their boring struggles and facing rejection.

But this is the only way to build something that lasts. The world doesn’t need another To-Do List app built with the latest JS framework. It needs solutions to real, expensive, boring problems.

Don’t write code to prove you are smart. Write code to make a problem disappear.

If you wanted to cross that line, the path was steep. Launching a startup meant writing a Pitch Deck, raising Venture Capital and immediately hiring a team to cover the skills you lacked: Sales, Marketing, Design, Operations.

In 2026, this boundary has blurred. We are witnessing the rise of a new archetype: the Solopreneur. But be careful not to confuse this with “freelancing” or a get-rich-quick scheme. It represents a new evolutionary path for the modern engineer.

1. Did you notice how job descriptions changed?

Before we look at independent founders, look inside your own company. Have you noticed the shift?

Five years ago, companies hired “Backend Developers” to write Java. Today, they are desperately looking for “Product Engineers”. They want engineers who have Ownership. They don’t just want you to close Jira tickets; they want you to understand the user, challenge the requirements and care about the metrics.

Why? Because in a world where AI can assist with the implementation details (the “How”), the human value shifts towards the decision making (the “What”).

The “Solopreneur” is simply the extreme expression of this trend: an engineer who takes 100% ownership not just of the Technical Stack, but of the Value Chain—from writing the first line of code to earning the first dollar.

2. The Third Path: Serving the Niche

Traditionally, if you wanted to build a product, the default path was building a Startup. Whether bootstrapped or VC-backed, the logic was usually the same: you build a product, you hire a team to support it and you aim for scale. You solve problems by building an organization.

But there is a vast universe of problems that don’t require an organization to be solved. There are thousands of micro-markets and specific niches that are too small for a traditional company to target efficiently (because their overhead is too high), but are highly profitable for a single individual with low costs.

This is where the Solopreneur thrives. Thanks to AI acting as a multiplier, a single engineer can now build and maintain a professional-grade product to serve these niches. You don’t need to recruit a team or manage overhead to validate a B2B idea. You can achieve Product-Market Fit on a smaller, more efficient scale.

It’s not about replacing startups; it’s about unlocking a market layer that was previously inaccessible to individuals.

3. Defining the Solopreneur

So, what is a Solopreneur? It is a technical founder who leverages this technological augmentation to build a high-revenue software business with little to no headcount.

They are not selling their time (Freelancing). They are building Systems. They operate with the professional mindset of a Founder, but with the lean infrastructure of a single individual.

Let’s analyze three engineers who exemplify this evolution.

Case Study 1: The Full-Stack Visionary

Who: Pieter Levels (@levelsio) The Shift: From “Code Quality” to “Market Reality”.

Pieter is the pioneer of this movement. But his innovation wasn’t technical; it was philosophical. While most engineers were arguing about which JS framework was “cleaner”, Pieter was deploying ugly PHP code that solved real problems for Digital Nomads (NomadList). The Lesson: He proved that users don’t care about your tech stack. They care about value. He used his engineering skills not to build the perfect codebase, but to build a business engine that runs largely on autopilot.

Case Study 2: The B2B Builder

Who: Marc Lou (@marclouvion) The Shift: Solving the “Engineer’s Block”.

Marc spent years failing at complex startups. He realized his problem was “Over-Engineering” and lack of marketing. He realized that thousands of other “Product Engineers” had the same problem. So he built ShipFast: a boilerplate product. The Lesson: He treated the business process as a software problem. He identified a repetitive task (setting up a SaaS) and refactored it into a product.

Case Study 3: The Engineer-Marketer

Who: Danny Postma (@dannypostma) The Shift: Coding the Distribution.

Danny realized that the hardest part of a startup isn’t building the product, but finding customers. Instead of hiring an agency, he applied engineering to marketing. For his product HeadshotPro (AI photos), he didn’t manually write blog posts. He wrote scripts to generate thousands of programmatic SEO landing pages. The Lesson: Marketing is another system that can be engineered.

Conclusion: The “Digital Urban Flight”

We are witnessing a macroeconomic shift that resembles Urban Flight.

For decades, everyone moved to the “Big Cities” (Big Tech Corps) because that’s where the resources, the infrastructure and the safety were. But now, those cities are overcrowded and expensive. The recent layoffs are not just a temporary crisis; they are a sign that these organizations are resizing. They are realizing they became too heavy, and they are shedding weight to return to efficiency.

This is triggering a Decentralization of Talent. Just as people leave the city to build their own houses in the countryside, engineers are leaving the monoliths to build their own micro-entities.

We are seeing an explosion of small, independent companies. Will most of them fail? Yes. That is the nature of the market. But the ones that survive will operate on a new model: Diversification.

The Solopreneur doesn’t need to build the next Uber or Facebook. Thanks to AI lowering the cost of building, you can now launch 3, 4 or 5 different micro-products. You don’t need one giant “Home Run”; you can have a portfolio of “Base Hits”—niche services that, combined, create a robust, highly profitable business.

This is the new “Middle Class” of the tech economy. A decentralized network of Builders who don’t rely on a single employer, but on a diversified ecosystem of products they own and control.