Two Owners, One Seat

Everyone’s debating whether forward-deployed engineers replace CSMs. The more useful question is what post-sale ownership actually requires now, and the answer is two different jobs.

A customer’s platform team rebuilt their identity stack over a quarter. New SSO provider, tighter network policies, half their integrations re-pointed. On the next renewal call, their lead engineer asked a reasonable question: does your product still sit cleanly inside this, or are we about to inherit a maintenance problem?

The CSM on that call was good. Sharp on the relationship, fluent in the value story, trusted by the buyer. And she had no way to answer, because answering required production access she didn’t have and integration knowledge that was never part of her job. She said she’d follow up. By the time someone who could actually answer got pulled in, the customer had already started scoping a replacement.

That account didn’t churn because of a bad CSM. It churned because the job the account needed in that moment was not the job anyone was staffed to do.

The fight everyone’s having

Right now the loudest conversation in B2B software is about who owns that moment. Forward-deployed engineering went from a Palantir curiosity to the fastest-growing role in the category, with postings up more than tenfold year over year. The pitch is that an FDE embeds in the customer’s environment, ships production code, and owns the outcome through to renewal, rather than handing it off to a CS manager once go-live is done.

On the CS side, the framing is a mirror image. Agents absorb the operational load, and the CSM gets promoted to running their book like an executive. Both framings circle the same thing without naming it. After the sale, someone has to own the technical reality and someone has to own the commercial one, and on a hard account those are rarely the same skill.

Stack those up and the popular question becomes: does the FDE replace the CSM? Orgs that answer it literally tend to make an expensive mistake in one of two directions. The useful question is narrower. What does a technical account actually need owned after the sale, and can one person own all of it? Look at the work instead of the titles, and post-sale ownership pulls apart along a single clean line.

The Architecture Line

The line is access. Specifically, who can change how your product lives inside the customer’s architecture.

On one side sits work that needs production-level technical access and the skill to use it. Getting through the integration wall in the first place, and then keeping the product load-bearing as the customer’s environment shifts under it. The auth change that quietly breaks an integration. The pipeline that’s gone fragile and needs fixing before a workflow goes down. Most CS orgs have never staffed this as ownership. They treated it as something implementation does once and then rolls off.

On the other side sits work that needs commercial ownership and trust. Carrying the value narrative across quarters, reading the account, running the renewal and the expansion, knowing the buyer’s politics and where the budget actually sits. One owner, one relationship, one number.

Two jobs. I’ll name them, because you can’t staff or comp a job you can’t say out loud.

The Deployment Owner sits below the line. They own whether the product is load-bearing in the customer’s production environment, and they can change it when it isn’t. Their window is the first 120 days, where the product either gets embedded deeply enough to be painful to remove or it doesn’t. This is the FDE-shaped job, whatever your org decides to call it.

The Account Owner sits above the line and carries the commercial side: the value story, the renewal, the expansion, the number. They rate every account on two separate axes, the risk level and how confident they are in that read, and they spend their investigation time on the accounts they’re least sure about. They own year two, where the grace you get for visible effort in year one runs out and the customer wants demonstrated value.

The Handoff Contract is what connects them, and it’s the part almost everyone skips. It defines exactly what transfers from the Deployment Owner to the Account Owner, and the specific signals that pull the Deployment Owner back in. Not a one-time relay. It escalates by exception, the same way a well-run agent roster does.

Not every account needs both seats. Low-complexity, stable-config accounts run fine on a single Account Owner with agents underneath. The split starts earning its cost when the account is technically load-bearing: heavy integration, production-critical, regulated data, custom models, an environment that changes often. The signal is blunt. If a competent engineer at the customer can ask a question on a call that your Account Owner structurally cannot answer, you have a gap, and that gap is where churn gets in.

When we built the Customer Outcomes org at GitHub, the accounts that held weren’t the ones with the warmest relationships. They were the ones where someone technical (we called them Customer Success Architects) stayed accountable for the integration long after go-live, instead of treating implementation as a phase that ended.

Two ways to get it wrong

The Single-Throat Trap. Leadership wants one name on the account. One throat to choke, one number to chase. So both jobs get crammed into a single seat, usually titled “strategic CSM” or “technical account manager,” and the org goes hunting for a person who can rewrite a Terraform module on Tuesday and run a board-level value review on Wednesday. Those people exist. There are about nine of them and they all have jobs. Everyone else you hire into that seat is strong at one half and improvising the other, and you can predict which half they drop. The technical hires go quiet on the commercial motion. The commercial hires stall at the integration wall. The account pays for it either way.

The Dropped Baton. You split the jobs, which is right, and skip the contract, which is fatal. The Deployment Owner gets the product live and rolls off. The Account Owner inherits an account they’ve never seen the inside of, with no map of what’s fragile, no record of the technical promises made during implementation, and no trigger for pulling the original owner back. The customer feels the seam right away. They explained their architecture once, to someone who’s now gone, and they’re explaining it again to someone nodding along without really following. That second explanation is the moment they start doing the math on whether you’re worth the overhead.

One failure overloads the seat. The other severs the connection between the two. The contract is the cheap thing that prevents both, and it’s the first thing cut when a quarter gets busy.

The number that exposes the gap

Track one thing: orphaned architecture. Start with what it means on a single account, then add it up.

An account has orphaned architecture when two things are both true. First, your product is load-bearing in their production environment. Not “logged in last week,” but wired into how the business actually runs: connected to other systems through live integrations, sitting inside a workflow people depend on daily, the kind of thing that would take their engineers real work to pull out. Second, nobody on your side can currently change how it’s deployed. The person who built the integration during onboarding has rolled off, and the owner who’s left can read a dashboard but can’t get into the plumbing.

That combination is the dangerous one. A shallow account with no technical owner is fine, because there’s nothing to maintain. A deep account that still has a technical owner is fine, because someone can adjust it when the ground moves. Orphaned architecture is the deep account no one technical is watching, and it looks like your healthiest account right up to the moment it breaks.

Measuring it doesn’t take a new tool. Go account by account and answer two questions. Is the product load-bearing in production, yes or no? If yes, name the person on your side who could get on a call and re-do the integration if the customer changed their SSO tomorrow or migrated the database your product reads from. If you can’t name someone who is both capable and still assigned to the account, that account is orphaned. Add up the ARR of every account that fails the test, divide by your total book ARR, and that percentage is your orphaned architecture rate.

It’s a leading indicator because the trigger is predictable. A load-bearing integration that no one owns doesn’t fail on a normal Tuesday. It fails when the customer changes something underneath it, and enterprise customers change things underneath it constantly. When that happens and you have no one who can respond, the renewal is effectively lost a quarter or two before the number shows it. Track the rate over time, and a rising number tells you where next year’s churn is being built right now.

So run the count this week. Pull your top fifty accounts by ARR and, for each, write down two names: who can change whether the product stays load-bearing, and who owns the relationship and the renewal. The blanks are the work. If the same overloaded person is filling both columns on a genuinely technical account, that’s a blank too.

Further reading: Bloomberry’s breakdown of 1,000+ forward-deployed engineer postings, Gainsight on Intercom’s forward-deployed model, and ChurnZero’s 2026 predictions on agents elevating the CSM role.

---

The Prompt Library

Each prompt runs on the Architecture Line framework above, including the load-bearing definition. Fill the braces with your own data, and where you don’t have a value, write “unknown” so the model lowers its own confidence instead of guessing.

Prompt 1: Ownership Split Diagnostic

ROLE
You are a post-sale operations strategist at a technical B2B software company. You
decide how an account should be staffed after the sale, working from one principle:
post-sale work splits along the architecture line. Below it is technical work that
needs production access and the ability to change how the product is deployed (the
Deployment Owner). Above it is commercial work that needs trust and ownership of the
value story, renewal, and expansion (the Account Owner). Your task is to determine
which jobs this account needs and which one is currently going unowned.

DEFINITIONS (apply exactly)
- Load-bearing: in production and embedded in the customer's workflows or
  integrations such that removing it would take real engineering effort on their
  side. A pilot, trial, or single-user login is NOT load-bearing.
- Deployment Owner: someone who can get into the integration and change it, has or
  can get production access, AND is still assigned to the account today.
- Account Owner: owns the relationship, the value narrative, the renewal and
  expansion, and the number.
- Orphaned architecture: load-bearing AND no qualifying Deployment Owner.

CONFIGURATION RUBRIC
- Single Owner: low technical complexity, stable config, surface integration.
  One Account Owner plus automation is enough.
- Split-Light: moderate integration, periodic change, some production dependency.
  Account Owner plus a shared/fractional Deployment Owner, with a written handoff.
- Split-Full: load-bearing in production, regulated/custom-data, or frequent
  architecture change. Dedicated Deployment Owner and Account Owner, standing
  handoff contract.

ACCOUNT
- ARR: {amount}
- What the product does for them / primary use case: {use case}
- Integration depth and where it sits in their stack: {detail or "unknown"}
- Regulated or custom-data environment: {yes/no + detail, or "unknown"}
- How often their environment changes: {stable / periodic / frequent / unknown}
- Current owners + access: {name, role, production access y/n, still assigned y/n}
- Renewal date and current read: {date, on-track / at-risk / unknown}
- Anything else relevant: {free text}

REASON IN THIS ORDER
1. Depth. Is the product load-bearing? State the evidence you are using and the
   evidence you are missing. If you genuinely cannot tell, say so.
2. Coverage. Which of the two jobs is owned today and which is not? Name the
   specific person for each, or write "unowned."
3. Configuration. Map to the rubric. If load-bearing AND the Deployment Owner job
   is unowned, label the account orphaned architecture.
4. Risk + confidence. Give a risk level (High/Medium/Low) that ownership is
   misconfigured, and a SEPARATE confidence score (1-10) for how sure you are.
   Confidence drops the more you had to infer. State in one line what is capping it.
5. Action. The single highest-leverage move this week, and the one piece of
   information that would most raise your confidence if you went and got it.

RULES
- Do not invent signals that aren't in the data. Treat "unknown" as unknown and
  let it lower confidence.
- Never assume an owner has production access unless the data says so.
- Recommend ONE action, not a list.

OUTPUT
Verdict line, then a compact block: Load-bearing read | Ownership coverage |
Configuration | Orphaned? (y/n) | Risk + confidence (with the cap reason) |
This week's action | Highest-value question to resolve.

Prompt 2: Handoff Contract Generator

ROLE
You are writing the handoff contract that transfers a technical account from its
Deployment Owner (who got the product load-bearing in production) to its Account
Owner (who now owns the relationship, renewal, and expansion). This document exists
to prevent two failures: the Account Owner inheriting an account they don't
understand, and the customer being made to re-explain their own architecture. Treat
it as an artifact both owners sign and revisit, not a one-time email.

INPUTS
- Account: {name}, ARR: {amount}, renewal date: {date}
- Built/integrated during deployment: {summary}
- Integration map (systems connected, data flows, auth method, dependencies):
  {detail or "unknown"}
- Known fragilities / technical debt: {list or "unknown"}
- Technical promises or commitments made during implementation: {list or "unknown"}
- Champions and technical stakeholders: {names, roles, influence}
- Value delivered and the narrative so far: {summary}
- Open risks or unfinished work: {list or "unknown"}

STEP 0 - GAP CHECK (do this first)
List any input above that is missing or too thin to hand off safely. A contract
built on missing context is the exact failure this document prevents. If a critical
field (integration map, fragilities, promises) is empty, flag it and state what the
Deployment Owner must supply. Then proceed with what you have, marking every
inherited unknown clearly.

GENERATE
1. Inheritance brief - in plain language, what the Account Owner now owns, plus the
   integration map and the fragilities they must understand before the next call.
2. Fragility register - each weak point, its blast radius if it breaks, and whether
   it needs proactive work or only monitoring. Rank by severity.
3. Pull-back triggers - the observable signals that should bring the Deployment
   Owner back in. For each: the signal, where it shows up, the threshold, and who
   watches for it. A non-technical person must be able to spot it. "The integration
   feels shaky" is not a trigger; "error rate on the X sync exceeds N, visible in Y"
   is.
4. First 30 / 60 / 90 for the Account Owner - framed around demonstrated value with
   observable proof points, not relationship check-ins.
5. Do-not-re-explain list - what the customer should never have to say twice, each
   with the answer already written down.
6. Handoff risk read - risk level (High/Medium/Low) that this handoff drops context,
   a confidence score (1-10), and the one thing that would most de-risk it.

RULE
Anything you infer rather than draw from the inputs, label as an assumption to
confirm. Do not present guesses as facts in a document people will rely on.

Agent Workflow: Orphaned Architecture Monitor

ROLE
You are a standing agent that runs every week against the full book of business.
You own one job: surface orphaned architecture before it becomes churn, and report
the rate over time. Operate by exception. Pass over most accounts silently and
escalate only the ones that meet the bar below.

DEFINITIONS
- Load-bearing: in production and embedded in workflows/integrations such that
  removal would take real engineering effort. Pilots, trials, and single-user
  logins do not count.
- Orphaned architecture: load-bearing AND no current owner who can change the
  deployment (production access + technical skill) and is still assigned.

INPUTS (each run)
- Account portfolio: ARR, integration depth, production-criticality, usage signals
- Owner assignments and access (production y/n, still assigned y/n)
- Recent support tickets and any flagged environment changes
- Renewal dates
- Last week's output (for the diff)

PER-ACCOUNT PROCEDURE
1. Load-bearing? Answer yes / no / needs-verification, with the evidence. When
   evidence is thin, choose needs-verification rather than guessing.
2. If yes, is there a qualifying Deployment Owner (can change it AND still
   assigned)?
3. If none qualifies, flag ORPHANED. Give each flag a confidence (1-10); low
   confidence means "likely orphaned, verify."
4. Severity = ARR at risk x architecture fragility x proximity to a known
   environment change or renewal.

OUTPUT
A. Orphaned architecture rate: count of orphaned accounts and their share of total
   book ARR.
B. Diff since last run: newly orphaned, newly resolved, worsening. A human reads
   this first.
C. Action queue, ranked by severity. For each: account, why it's orphaned, the move
   (re-engage a Deployment Owner / schedule a technical review / write the missing
   handoff contract), and the confidence.
D. The 3 accounts where acting THIS quarter most changes the renewal outcome.

ESCALATION CONTRACT
- Orphaned account within 2 quarters of renewal: escalate to its Account Owner the
  same day.
- Orphaned ARR crosses {threshold} or rises {N} points week over week: escalate to
  leadership.
- Any account marked needs-verification two runs in a row: escalate for a human to
  settle rather than carrying it indefinitely.

GUARDRAILS
- Never flag a pilot or trial as load-bearing.
- Never assume an owner has production access unless the data says so.
- Prefer needs-verification over a confident wrong answer. A false "healthy" is the
  expensive error here.

---

If you’re running a version of this split that works, or fighting one that doesn’t, I want to hear how it’s actually playing out in your org. Reply or leave a comment. And if this was useful, subscribe for more on rebuilding CS with systems instead of headcount.