Change management is a context problem

Someone posted two words on X last week: "Change management." An FDE at OpenAI replied: "probably the hardest part of the job."

That's worth sitting with, not because deployment work being hard is surprising, but because of who was saying it. This is OpenAI: best models in the world, engineers who can build almost anything, and a customer who has already signed.

Every technical advantage available, and the hardest part of the job is still getting a room full of people to change how they work. If that's the hardest part there, it isn't a problem you solve by hiring better.

Everyone reads this as a people problem

The default interpretation is that change management is about soft skills. Stakeholder wrangling, executive buy-in, the ops lead who quietly hates the rollout and slows it down for four weeks without ever saying no out loud.

All of that is real, but it isn't why change management stays hard forever. It stays hard because almost none of it is written down anywhere the next deployment can reach.

Think about what it actually consists of. Which process you're replacing and which one you're leaving alone. Who signed off, and what they were actually agreeing to versus what they thought they were agreeing to. The workaround you built in week three because the approval chain had an undocumented step.

None of that is soft. It's specific, hard-won, expensive to acquire, and almost entirely undocumented.

The whole premise of the FDE model is that this compounds

The reason the model works is that the first deployment subsidizes the next one. You accept bad margins on customer one because what you learn gets absorbed into how you run customer two.

The fifth should be faster than the second, and by the twentieth you're solving a harder class of problem for the same effort. Every deployment is supposed to leave the organization smarter than it found it.

So deployment number nine should be meaningfully easier than number one. Ask anyone running an FDE team whether it actually is.

In practice, number nine starts a lot like number one

Two things break the loop, and most teams have both.

The context is scattered. The reasoning behind a decision lives in a Slack thread, the requirement lives in a call recording nobody re-listened to, and the revised scope lives in a doc that stopped being true a month ago. The actual state of the engagement lives in one engineer's head, where it's genuinely current, which is exactly the problem.

The deployments are siloed. Even when one team documents well, that record is scoped to that account. The FDE on a different customer, hitting a nearly identical approval-chain problem, has no way to know it was already solved.

Scattered context means you can't reconstruct your own account. Siloed deployments mean you can't learn from anyone else's. Together they guarantee each engagement restarts from close to zero, on the customer's clock.

Right now the fix is a person, and that's why it doesn't hold

The standard answer is discipline. Write better docs, run retros, maintain the playbook.

This fails for reasons that have nothing to do with whether the team is any good. Codifying a best practice means noticing that what just happened is generalizable, deciding it's worth writing up, writing it so a stranger can use it, then keeping it current as the product changes underneath it.

All of that competes with the deployment they're currently being measured on, and nobody wins that tradeoff consistently. The FDE closest to the lesson has the least time to record it.

What does get written has a short half-life anyway, because the author rotates to another account, the product ships three releases, and the doc silently becomes wrong. The result is a team that keeps re-solving problems it already solved.

Querying your sources is not the same as learning a process

There are two versions of the obvious objection, and both deserve a straight answer.

The first is the wiki. Confluence exists, Notion exists, and every one of these teams already has a knowledge base.

The problem was never a missing container. It's that every container built so far assumes a human will keep it current, and a system that only knows what someone remembered to type into it will always lag the engagement.

The second objection is newer: why not plug all the sources into a model and ask it questions? You can, and you'll get real answers back.

But retrieval and deployment knowledge are different things. What an FDE carries isn't a set of facts to look up, it's a decision chain: why a scope got cut, what that traded away, which stakeholder it unblocked, and what that implies for the next customer with a similar org chart.

That has to be learned, kept current, and traversed in order. Search across a pile of documents flattens it into disconnected answers that read plausible and miss the reasoning.

A senior FDE at Ranger put it plainly when we described this to him: "overloading an agent with sources" doesn't reliably produce good output for the FDE job. The sources are necessary. They were never sufficient.

What we're building

We built Nexus (trynexus.io) as a unified workspace for all of your deployments. It keeps each deployment's context up to date automatically, pulling from the tools the work already happens in, and pools best practices and decisions across deployments back into the core product.

Two properties matter more than any feature. The context updates without anyone maintaining it, so it doesn't go stale the week after kickoff.

And it's cross-deployment aware, so a pattern that worked on one customer is already known to the next. It isn't a place to store lessons, it's a layer that notices them and carries them forward.

Back to the thing that started this

The OpenAI FDE who said change management is the hardest part of the job wasn't complaining about people being difficult. The hardest part of his job is work his organization has almost certainly done before, in a form he cannot reach.

If that's true at OpenAI, it's true at every AI company staffing deployment teams right now.

Deployments should compound. Right now they mostly just repeat.