Alexander KadyrovAlex Kadyrov
  • Blog
  • Case Studies
  • Experiments
  • About

New Job Titles Always Get Mocked. That's Usually When the Buyers Arrive.

  • Jun 4, 2026
  • •
  • 3 min
Share:
Alex Kadyrov
Alex Kadyrov

Forward Deployed Engineer · Dubai

The troll cycle for "Forward Deployed Engineer" is pretty predictable at this point. A job posting circulates. Engineers reply that it's just consulting with a new name. Someone finds a profile of a developer who was doing basic web apps two years ago and is now billing at five times their old rate as an FDE. A thread builds. It gets mildly viral.

The mockery isn't entirely wrong. There are people using the label to repackage work that didn't change. That's real.

It's also what happens to every professional label that starts reaching buyers.

The opportunists show up when a label starts working

"Growth Hacker" had a wave of this. "Scrum Master" attracted people who'd been project managers for years and updated their title. "Fractional CTO" brought out consultants who'd been working part-time for years and suddenly had a frame that let them raise their rates. "Customer Success Manager" replaced "Account Manager" on a lot of business cards without the job changing.

The pattern is consistent: opportunists don't chase obscure labels. They chase labels that are working — that buyers are searching for, that show up in job descriptions, that mean something in a procurement conversation. The rebranding is following real demand.

This is what the trolling gets wrong: the people gaming the label and the people doing genuine FDE work are two separate populations. The label being misused doesn't mean the label is fake. It means the label reached the point where misusing it is worth something.

The buyers aren't watching the LinkedIn threads

The people hiring Forward Deployed Engineers aren't in the replies. They're looking at what Palantir built its deployment model around and what OpenAI structured a $4 billion deployment company around. They're trying to explain to their procurement department what they need — and "engineer who embeds at client sites and figures out what's actually broken before writing code" doesn't fit on a line item.

"Forward Deployed Engineer" does.

The critics already understand the work. They don't need the label. The buyers need the label. The trolling and the purchasing decision happen in completely separate rooms.

The Fractional CTO pattern is the clearest precedent

Same objection, almost word for word. "It's just a part-time CTO with a better name." Correct. And the rebranding wave happened there too — consultants who'd been doing part-time advisory work for years suddenly had a frame that justified higher rates. Companies still pay five figures a month for fractional CTOs. The label didn't collapse under the mockery, and the trolling peaked right around when mainstream adoption accelerated.

The label held because it solved a specific problem for buyers — they could now describe, budget for, and procure something that previously required an awkward paragraph of explanation. That's all a label needs to do.

I came to it late, which is its own kind of data point

I'd been doing the same work since at least 2021 — go into a client's environment, watch how things actually move, build for what you find rather than what was described — without a name for it. When I saw "Forward Deployed Engineer" in a job description, the work was instantly recognisable. The label was new. The pattern wasn't.

The number of open FDE roles globally grew 42× between 2023 and 2025. That growth happened alongside the mockery, not before it.

The practical question is which room you're optimising for

If you're doing embedded delivery work, you have two audiences when it comes to how you describe yourself.

Your peers — who already understand what you do, don't need the label, and have legitimate frustration with the people who picked it up last month.

Your buyers — who need a frame they can bring to procurement, and are increasingly landing on FDE because that's what the organisations they respect are using.

The trolling comes from the first group.

The revenue comes from the second.

Found this useful?
Share:

If your organisation has a problem that software should have fixed already, the engagement model starts with embedded discovery — figuring out what's actually broken before writing code. Book a call if that's the right starting point.

In this article

  1. The opportunists show up when a label starts working
  2. The buyers aren't watching the LinkedIn threads
  3. The Fractional CTO pattern is the clearest precedent
  4. I came to it late, which is its own kind of data point
  5. The practical question is which room you're optimising for
Alex Kadyrov

Alex Kadyrov

Forward Deployed Engineer · Dubai

20+ years of production engineering. I embed inside client environments, diagnose what's actually broken, and deliver working systems in 4–8 weeks — built to run without me.

New articles by email

No spam. Unsubscribe any time.

Keep Reading

Before You Automate, Ask If You Should Be Doing This at All

Before You Automate, Ask If You Should Be Doing This at All

A marketing agency founder came to me with an operations problem: five low-ticket clients consuming more than their fair share of her team's time. Twenty minutes in, I realized the answer had nothing to do with automation — it was a pricing decision she hadn't made yet.
Read More →Jun 2, 2026
I Built a Free Dubai Budget Planner Because We Kept Getting the First Month Wrong

I Built a Free Dubai Budget Planner Because We Kept Getting the First Month Wrong

A free calculator for every upfront cost before signing a Dubai lease — rent by cheque count, security deposit, broker fee, DEWA deposit, Ejari, and appliances — plus full monthly living costs. Built after three consecutive apartment moves where the total still managed to surprise us.
Read More →May 31, 2026
How to Find Out if Your Idea Is Worth Building Before You Spend Anything

How to Find Out if Your Idea Is Worth Building Before You Spend Anything

There are seven ways to test an idea before you write a line of code. Each one answers a different question. Picking the wrong tool gives you the wrong signal — and you end up building something the signal never actually supported.
Read More →May 29, 2026
Get in TouchBook a CallCase StudiesLinkedInTelegram
© 2026 Alex Kadyrov. All rights reserved.Site MapTerms of UsePrivacy Policy