Here's the thing about the person Daniel's describing. He's not describing someone with a lot of hobbies. He's describing someone with a specific shape of mind.
And he's describing it carefully, too. He doesn't say "well-read." He says the curiosity isn't superficial, that the person goes deep on an obscure technical question, then moves on entirely.
Which is exactly the part that doesn't fit anywhere. So he sent us this whole question about the intellectually restless generalist, and the paradox he's poking at is real. Conventional careers reward specialization, sustained attention to one narrow domain, and a title that tells everyone what you are. This person can do the work and can't explain themselves on a résumé.
He's got the shape of the problem right. And the questions he's actually asking underneath are the good ones. Where does this profile create distinctive economic value. What separates accumulating knowledge from applying it. And then the practical one, employer, hybrid role, or your own business.
And he specifically said he doesn't want the lazy answers. No consulting, no research, no gesturing at entrepreneurship and calling it a career plan.
That's the right instinct, because those three are what people say when they haven't thought about it. What he's really asking is where this gets priced, and whether the price survives contact with an org chart.
So let's define the profile properly, because the romantic version is useless. Broad curiosity, deep investigative ability, cross-disciplinary connection-making, high independent productivity when nobody's directing you.
And it's a trait pattern, not a compliment. That's the important part. Openness and Intellect are two facets of the same Big Five dimension, and psychologists separate them. Openness to Experience is the perceptual, aesthetic, emotional side. Intellect is the abstract, semantic, reasoning side.
Those two are not the same person, and the research says something counterintuitive about them. Which one drives the accumulation of broad knowledge.
Openness to Experience. Not curiosity, as it's usually measured. There's a 2018 study by von Stumm, six hundred and forty-nine people across four studies, and openness to experience predicted knowledge attainment, largely independent of cognitive ability. Curiosity didn't.
So the thing that feels like the engine, the wanting-to-know, isn't the thing that predicts the knowledge.
It's strange. And it means a lot of people describing themselves as intellectually restless are describing the wrong trait. They think they're curious. The better predictor is being open, which is closer to receptive. It's less flattering and more accurate.
So the profile is real, it's measurable, and it doesn't have a clean job title. Here's the documented version. Developer forum, 2022, someone posts asking whether anyone regrets being a generalist. He's done full stack, security, AI, mobile, automation, scraping, games, low-level C. His line is "I'm always interested by ten things at the same time."
Two hundred and thirty-six points. And his actual worry isn't employability. He says he has zero doubts about that. The fear is long-term regret. That he should have specialized before it was too late.
That's the thread the whole episode hangs on. He's not failing. He's just afraid he's failing slowly.
And the question underneath the fear is the one thing nobody answers. Not is generalism good. Where does this profile get priced, and what separates the person who accumulates from the person who ships.
So where does the market actually put a number on it.
The cleanest answer is a role called Forward Deployed Engineer. Invented at Palantir in the mid-2010s. Exported to Anthropic, OpenAI, Scale AI, Sierra, Harvey, Glean, Mistral, Databricks, most of them between 2023 and this year.
And what is it, exactly. Not the job description version.
A senior technical generalist who embeds inside a customer's operation. You run the discovery, you sit with the people who have the actual problem, and you ship production code. The difference from a normal senior engineer is structural. A normal senior engineer gets a spec and builds to it. An FDE is the person who works out the spec, in the room, with the customer, and then builds it themselves.
So the thing the résumé can't capture is the job.
The résumé is the reason the role exists. You cannot screen for this with a keyword. The title is almost a workaround for the fact that the underlying skill doesn't have a name.
What does it pay.
The sharpest data is a survey of fifteen hundred FDEs across a hundred and fifty-four companies. Median senior FDE compensation at a frontier lab, four hundred and eighty-five thousand. Growth stage, three hundred and fifty-five. Enterprise, three hundred and ten. Staff level at a frontier lab clears seven hundred and twenty-five thousand. Principals cross a million.
So a million dollars for a job without a clean definition.
And it sits thirty to fifty percent above the equivalent backend or machine learning engineer at the same company. Same desk, same building, different number. The premium is for the ambiguity, not the coding.
What's the actual week look like.
This is the bit that made me sit up. Forty-seven percent of the week is customer-facing. Thirty-one percent writing code. Twenty-two percent internal coordination. A normal senior engineer inverts that almost exactly.
So the bulk of the job is the part no engineering culture rewards.
The engineering culture built the ladder for the thirty-one percent. The customer-facing forty-seven is where the value is and where nobody's written a promotion rubric.
Let me push on that, because I want to know what the customer-facing forty-seven actually looks like hour to hour. Is it meetings, or is it something else.
It's closer to fieldwork than meetings. You're in the customer's building, watching how the work actually flows through their systems. You're asking the warehouse manager why she keeps a spreadsheet that duplicates what the ERP already does. You're noticing that the integration everyone described in the kickoff meeting isn't the integration that's actually running in production.
So it's observation before it's conversation.
Observation first, and then a very specific kind of conversation. The survey signal that stuck with me was "can run a discovery interview without a sales script." That's a skill that looks like talking and is actually diagnosis. You're not pitching. You're trying to find the real constraint, which is usually not the thing the customer wrote in the ticket.
Give me a concrete version of that. Customer says one thing, reality is another.
Classic pattern. Customer says they need a better model. You get there, and the model is fine. The problem is that three teams each maintain their own copy of the customer record, and none of them agree on which one is authoritative. The model was never going to fix that. The FDE's job is to see that in week one, say it out loud, and then decide whether to build around it or fix it.
And a pure specialist might not see it, because the specialist is looking at the model.
The specialist is looking at the model, correctly, because that's their job. The generalist is looking at the whole room. That's the trade. You give up some depth for the ability to notice when the depth is pointed at the wrong thing.
Why does the role exist at all. Somebody had to justify the salary.
Ninety-five percent of enterprise AI pilots produce no measurable impact on profit and loss. The model isn't the problem. The failure is the last mile, the part where a model that demos beautifully meets an organization with three legacy systems and a guy named Duane who owns the interface nobody documented.
Half of American healthcare, per your own theory, held together by one guy named Duane.
And Duane doesn't take meetings. That's exactly the gap. Someone has to sit with Duane, understand what the interface does, and ship the code that makes the model survive contact with it.
There's a line about that. The dominant hiring pattern at the frontier labs is no longer the model researcher.
"It is the person who makes the model survive contact with reality." That's Robert Tucker, and it's the whole thesis of the role in one sentence. And he's earned the right to say it, because his own position is that some people have been making things survive contact with reality for thirty years. The label is new. The work isn't.
Which raises the obvious objection. Is Forward Deployed Engineer a new role, or a rebrand.
Both, and the honest answer is that the tension is real. Andreas Horn has a line for it. "The title is being copied faster than the practice." Companies are renaming experienced integration engineers and calling it a new discipline.
And you can see why they'd want to.
Thirty-day bootcamp, credential attached, pipeline of candidates. There's a recruiter incentive for the title to read as brand new. If it's a rebrand, the premium evaporates and you're back to being an integration engineer with a fashionable business card.
And if it's real.
Then the labs have built a moat that isn't model quality. Tucker's argument is that the FDE buildout delivers revenue stickiness. Once an FDE has embedded with a customer, the model underneath becomes very hard to swap out. That's not engineering, that's lock-in wearing engineering's clothes.
How fast is the hiring.
This is where the sources get interesting, because they disagree. Postings up roughly eight hundred percent between January and September of last year on one count. Another source says eleven hundred and sixty-five percent year on year. When the people tracking a market can't agree on whether it's eight hundred or eleven hundred, that tells you the market is real and nobody has hold of it yet.
A market defined by its own measurement error.
Aaron Levie from Box said it plainly. "Forward deployed engineers, or equivalent, are about to become one of the most in-demand jobs in tech."
He's telling you the title isn't the thing.
The title is a handle for a shape of person the market has been trying to hire for a decade and failing to name.
So that's the concrete answer. That's the place a broad, translation-capable generalist is explicitly priced. Now the harder half of what Daniel asked.
What separates the person who accumulates from the person who ships.
Because I know plenty of people with wide knowledge who are not worth a million dollars to anyone.
The FDE survey answers this in its own way. The two highest-ranked hiring signals were "ships production code" and "can run a discovery interview without a sales script."
Neither of those is knowledge stock.
Neither of them. Nobody ranked "knows a lot of things." The market pays for producing a working system and for extracting the real problem from a customer who can't articulate it.
The discovery interview without a sales script is the one I'd underline. That's translation under pressure. Customer thinks they have a data problem, actually has a workflow problem. The generalist notices that because they've seen the pattern in four unrelated fields.
And Tucker's version of the test is whether the thing keeps working after you hand it off. That's the line. Value is measured after the handoff, not during the conversation. The intermediate artifact, a good conversation, a sharp memo, an interesting observation, isn't the product.
So the distinction is that the accumulator produces understanding, and the shipper produces a thing that runs when they're not in the room.
Which is uncomfortable, because a lot of intellectually restless people believe the understanding is the contribution.
And sometimes it is, to them. They're the beneficiary. That's a hobby with a good reputation.
The uncomfortable framing is that knowledge is the input, not the output. The output is a system someone else relies on.
So how does somebody prove they're on the right side of that line, when they don't have the credentials for it. Daniel asked that specifically.
Portfolio of independently produced work, which is his framing, and I'd agree with it. But I want to be precise about what that means, because "portfolio" gets used to mean "a website listing things I've read."
A book report with a domain name.
The portfolio that answers the question has shipped code in it. Things deployed, things with users, things with a maintenance history. The proof that you ship is a thing that shipped. There isn't a way around that.
And the things with users part is doing more work than people want it to. Users mean someone else's problem was solved.
Even ten users. Even one. The survey numbers suggested the people who'd done this could articulate what broke, what they'd do differently, and what the customer actually needed versus what they asked for. That's the thing that can't be faked in an interview.
So the answer to Daniel's credentials question is that the portfolio replaces the credential only if the portfolio is the work, not a description of the work.
The work is the credential. That's the whole sentence. If you built the thing, you don't need someone to certify you built it.
Now the breadth-versus-depth question, because I suspect the consensus here isn't what people want to hear.
It isn't. Multiple hiring guides converge on the same point. Below roughly five engineers, the full-stack generalist is the correct first engineering hire, because coordination cost is your largest expense and a generalist doesn't need to coordinate with anyone.
And above five.
It flips. There's a piece arguing that hiring for generalist speed too early sacrifices the precision you need for robust architecture. You get a system that's flexible everywhere and load-bearing nowhere.
So the resolution people reach is T-shaped.
Broad competence, plus proven depth in one area. And here's the honest problem with that framing. If the answer is "be broad but also have depth," then it's arguably just specialization with a wider aperture. The romantic generalist, the one who refuses to go deep, isn't what the market recommends.
The trap is hiring flat breadth. A generalist who is mediocre everywhere.
That's a line from a hiring guide, and it's harsh and it's accurate. Flat breadth is a cost to an organization, not an asset. The premium goes to the person who's deep in something and can also see sideways.
The profile Daniel described is an advantage under one condition.
That the breadth sits on top of something solid. Which reframes his whole question. The restless generalist who's never been the deepest person in any room isn't advantaged by their breadth. They're just distributed.
Let's take the career-design question, then. Employer, hybrid role, or independent business.
There's a thesis in the research I think actually reorganizes this. Tucker's "unblocked cohort" idea. AI doesn't create the generalist role. It removes the throughput constraint that used to force these people to need engineering teams behind them.
The older generalist had to hire three people to build whatever they'd thought of, which is why they ended up as a founder or a manager whether they wanted to or not.
Right, and the modern version can ship alone. Which changes the question from "what jobs suit generalists" to "what did generalists always want to do that they can now do alone."
That question doesn't have a settled answer. Which is why the career-design decision is harder, not easier.
Because the options now compete. Frontier-lab FDE median is four hundred and eighty-five thousand. Founding engineer equity is typically around one and a half percent. Full stack base is a hundred and thirty to a hundred and eighty thousand, roughly a quarter million fully loaded.
The independent route has a real opportunity cost against the frontier-lab number.
A significant one. The choice isn't "freedom versus security" in the abstract. It's the difference between a quarter million and half a million in cash, versus a small equity stake in something you control.
And "you control" is doing the work in that sentence.
It's the whole argument for the independent path. If the constraint on your productivity was always other people's throughput, removing that constraint changes what you can do alone, and equity in your own thing has a floor of zero and no ceiling.
But the honest limitations. The thread we started with, the guy worried about regret.
His line was that he has zero doubts about his employability but is afraid to regret it long term if he doesn't specialize. That fear isn't irrational. It's a bet about what compounds. Specialists compound depth and their rate accelerates. Generalists compound connections, and a connection is only worth something when the two things you're connecting turn out to matter together.
Which means the generalist's return is lumpy.
It's lumpy and it's back-loaded. You spend years acquiring things that don't seem to combine, and then occasionally two of them combine in a way that's worth a lot, immediately. That's a worse risk profile if you need steady income at thirty.
There's no study to hide behind here.
There isn't. As far as the research went, there's no peer-reviewed study measuring career or earnings outcomes for broad-curiosity generalists as a defined cognitive profile. The closest evidence is the openness and knowledge-attainment work and the research on openness and creative achievement. Suggestive, not conclusive.
The honest position is that we're reasoning from adjacent evidence.
From adjacent evidence, from a priced role that's two years old, and from a survey of one thousand five hundred people in that role. That's the state of the knowledge.
Which means the synthesis has to be modest. The profile isn't universally advantaged or universally disadvantaged. It's stage-dependent and context-dependent.
The FDE role is one place where the market has explicitly priced it. Not the only place, and not a guaranteed fit. Some broad generalists would be miserable embedded in a customer's building for a year.
Yeah. The role rewards translation and stamina, and rewards being in the room with other people's problems. If your curiosity is private, this is a bad fit no matter what it pays.
The generalists who thrive in it are the ones who find the customer's chaos interesting rather than exhausting.
There's one more angle on this, and it's sitting right over there.
The part I'd want to say about this is that I once spent eleven months building a thing that did exactly one job. One.
Eleven months for one job.
It read a water level. That's all it did. A sensor, a small board, a phone line, and a program that called a particular man if the level got too high. Eleven months, and I still think that was about right, because the hard part wasn't the sensor.
What was the hard part.
Deciding what "too high" meant. The water rises and falls all day. You cannot just set a number. You have to know the man. He wanted to know if it was going to be over by morning, not whether it was over right now. So the program learned to tell the difference between a rising level and a full tank.
You built a system around one person's judgment about what mattered.
There was one user. Four years and one user. I met him once, and in that conversation he told me the reading he actually wanted wasn't the level, it was the rate. Everything after that was easy. The eleven months before it was me guessing.
Do you know what happened to the system?
Still running. Somewhere. I get a message about it once a year.
A message from who.
The system. It's the only person I let set it up that way. That's all I'll say about that. The organization that wanted it stopped existing some years ago, and the message still arrives, because the man kept paying for the line out of his own pocket and then someone else did, and I have never asked who.
You've never asked.
It isn't my department. The thing works, and someone looks after it. That's more than most systems get.
You said you get a message. What does it say.
One word and a number. That's all I'll say. And before you ask, yes, I've been paying for the server myself since the start. Small amount, every month, out of my own pocket. My wife has opinions about it. She thinks we could have bought something for the house with eleven years of that. I think we bought something for the house anyway, because one water level sensor in a town I've never visited is the sort of thing that keeps a house standing when nobody's looking. She disagrees.
The knowledge wasn't the point. The relationship with the man was.
The knowledge isn't the product. The knowledge is what lets you notice the thing nobody asked about. The rate, not the level. That's the only useful sentence I know about this.
And the undercut.
I got it wrong once too. Different job, different water, I noticed something nobody asked about and I was sure for two months that it was the whole thing. It wasn't. It was Tuesday.
The profile Daniel's describing has a cost, and it's paid in exactly that way.
He's right that application beats accumulation. He's right that the market pays for the thing that keeps working after you leave. What I'd add is that the noticing and the applying are the same act most of the time. You notice because you have enough in your head to see what's missing. Then you build it, or you don't, and if you don't, you've wasted the noticing.
If the organization ceases to exist.
The thing can still be running. That's the part of this I'd keep.
The server fee. You've never told him.
He's dead. Don't make it a story.
Okay. So where does that leave the person who actually has this profile?
The honest place is that the market has priced it at least once, and the price is high, and the reason the price is high is that the supply is thin. Not because the profile is rare, but because most people with the profile never build the depth underneath it.
Which is the least romantic version of the answer. The value isn't in having wide interests. It's in having one deep interest plus wide ones, and then shipping something with your name on it that someone else relies on.
That's the honest version of where specialization fits too. The specialist who never ships is just as stuck as the generalist who never ships.
The open question I keep coming back to. The FDE title is being copied faster than the practice. If that continues, does the premium hold, or does it collapse into a rebrand of integration engineering with a better business card?
There's a second open question, and I think it's the more interesting one. If Tucker's right that AI removes the throughput constraint rather than creating a new role, then the question isn't what jobs suit generalists. It's what did generalists always want to do that they can now do alone, and nobody has a settled answer to that.
Because they've never been able to try before.
That's the part I'd leave people with. There's no study that measures career outcomes for this profile. The evidence we do have is suggestive and not conclusive. What there is, is a gap between what someone like Daniel's describing can now do alone and what their résumé can currently explain.
A man in a town nobody visits getting a message once a year about a water level that hasn't been a problem in a decade.
Which is a nicer place to end than most of what we found. If you have thoughts, reviews help. That's the pitch.
For more along these lines, there's episode fourteen, AGI's Crossroads; episode seven, Building Custom ASR Tools; and episode twenty, Architectural AI. This has been My Weird Prompts. Producer, Hilbert Flumingtop, who is not getting into the server fee on air.
Send us your own prompt on Telegram at t dot me slash MWP listener bot. We'll be back soon.
