The Deflation Point

The boredom that arrives after a delivered outcome is information, not a flaw.

“Make us AI-native.”

It is the kind of brief that sounds like ambition and works like a trap. There is no version of that sentence an FDE can deliver, because there is no point at which it is finished. You could spend three years inside that mandate and still not be able to say the thing is done, because nobody defined what done would look like before you started.

Compare it to a real outcome. Get the time to process an exception down from two days to twenty minutes. Take a workflow that currently needs three people reviewing every case and get it to one person reviewing only the cases that genuinely need a human. Those have an end. You can stand in front of them and know whether you got there.

The difference matters more than it looks, because the FDE’s only reliable instrument for knowing they have finished is a feeling. And that feeling only works if the finish line was drawn in advance.

The loop

The work has a shape, and it repeats.

You arrive knowing almost nothing about the customer. Sometimes not much about the domain either, though that part is less important. The first weeks go into getting deep enough into how their operations actually run to find the highest-value problem you can solve, the one where the cost is real rather than just annoying. Then everything narrows onto solving it.

That stretch is intense and fast and completely absorbing. You are learning a business from the inside and building the thing that changes it at the same time, and there is nothing else like it.

And then you get there. The outcome lands. The numbers move. The people who were sceptical start using it without being asked.

And you deflate like a balloon.

There is a version of the next few months where you stay. You hold the account, you answer the questions, you make small incremental improvements, you sit in the standups. You can do this. Plenty of FDEs do. But it is not the work that pulled you into the role, and the flatness you feel is not a character defect to manage. It is information.

The case for moving on

Naval Ravikant has talked about getting bored easily, the pattern of finding a challenge, getting good enough at it, and then needing the next one. He landed on angel investing partly because it suited that wiring. The FDE role runs on the same engine. The appetite for a problem you do not yet understand is what makes you good at the front of an engagement, and it is the same appetite that makes the maintenance phase feel like wearing someone else’s coat.

This connects to something I have argued before, that FDE teams are an investment in discovery rather than a services business. If that is true, then an FDE’s time is close to the most expensive research budget the company has. Spending it on steady-state maintenance is less an act of loyalty to the customer than a misallocation of the one resource that exists to find the next thing worth building. The boredom is that budget objecting to being parked.

The case for moving an FDE on is not really about keeping them entertained. It is that every new engagement is another source of product input, and those inputs are the whole point. A new problem, a new operation, a new set of edge cases, that is where the patterns worth building into the product actually surface. The more times an FDE goes through the loop, the more of that signal they generate. Leave them on one account refining what already works and the stream slows to nothing. You are paying a discovery cost and getting maintenance in return.

Where the work actually ends

So where does the FDE’s job end.

Not at the demo. I want to be careful here, because it would be convenient to claim the work finishes the moment the solution technically functions and the boring part belongs to someone else. It does not. Adoption is the FDE’s job. Earning the trust that gets people to route their real work through the thing is the job, and it takes longer than the build and it is rarely fun. An outcome nobody uses is not an achieved outcome.

What is not the FDE’s job is everything after that. Maintenance. The steady-state support, the small fixes, the questions that have settled answers now. That should sit with a separate team, the way it did before we started blurring these lines, or increasingly with an agent that can absorb the long tail of small requests. The FDE got the customer to the outcome and made it stick. Keeping it running is genuinely different work, and it does not need the most expensive person in the building.

None of this is a prohibition. You can keep the FDE on the account. You can take the open-ended mandate and bill against it month after month. There is nothing wrong with any of that, and for some companies it is exactly the right business to be in. But it is a services business, and the honest thing is to call it one. The problem is never that an organisation does support work. The problem is an organisation doing support work while telling itself, and its investors, that it runs an FDE team. Once that happens the label stops meaning anything, and you lose the one thing the model was meant to buy you, which is discovery.

Worth saying that moving on does not have to mean leaving the customer. The next challenge is often inside the same organisation, a different process, a different outcome, a fresh problem worth the immersion. What it cannot be is the same solution on a drip.

Telling the difference

The danger in all of this becomes obvious the moment you say it out loud. Boredom is not a precise instrument. It can show up early, before the outcome is actually achieved, before any trust has been built, at exactly the point where the unglamorous adoption work begins. Following it then is not discipline. It is abandonment dressed up as temperament. The hard part is telling the two apart, knowing whether you have gone flat because the defined outcome is genuinely behind you, or because the fun part is over and the patient part has started. The first is a signal to move. The second is a signal to stay.

Which is why the defined outcome carries so much weight. It is the only thing that lets you trust the feeling at all. If you agreed up front what done looks like, and adoption was part of that picture, then the deflation afterwards is real data. If you never defined it, the boredom has nowhere honest to point, and you will either drift into permanent support or leave too early and call it instinct.

So the vague brief turns out to be the actual enemy. “Make us AI-native” does more than waste time. It removes the FDE’s ability to know when they are done, and a role that runs on knowing when you are done struggles to function without that line.

There is a simple test in all of this, for an FDE and for whoever runs the team. Look at the gap between an outcome landing and the FDE rotating onto the next defined problem. It should be short relative to how long the outcome took to reach. If they move on quickly, the model is working. If they are still on the same account a long stretch later, making small improvements, one of two things is true. Either the outcome was never defined, so nobody can tell it has been reached. Or it was reached, and the team has quietly become a services business that happens to use the word FDE.

Neither is fatal, and both are worth knowing. The deflation that follows a delivered outcome is the cheapest diagnostic you have for telling which one you are living in.

So the question is not really whether FDEs get bored. It is what your organisation does when they do.