Software to manage FDE teams

If you searched this phrase, you are probably not an individual FDE evaluating a runtime. You are a CRO, a VP of Sales, a Head of Solutions, a VP of Engineering who just inherited a forward deployed function, or the person whose bonus depends on deals unblocking and customers staying live. You have hired, or are about to hire, forward deployed engineers into a job the market invented faster than the tooling did, and you would like to manage the resulting team without pretending a ticket board is an operating system.

That distinction is the whole article. There is already a list for the five-verbs runtime, the best FDE ops platforms, written for the people who ship customer-specific code and the leaders who need deploy, host, vault, version, and hand off to be true. This list is adjacent and deliberately different. It is management software: the layer that answers estate, custody, handoff, and utilization questions for the person who runs the org, not the person who writes the bridge.

The hiring wave that created this shopping trip is documented. Business Insider reported that Indeed's index of forward deployed engineer postings sat 5,230 percent above its January 2025 baseline by April 2026, after sitting 543 percent above that baseline a year earlier, roughly 729 percent growth year over year. Those are indexed values, not raw job counts. Bloomberry counted 1,165 percent year-over-year growth across 1,000 postings through October 2025, with a median disclosed salary of $173,816, and found that 45 percent of postings placed FDE as its own dedicated team, 38 percent inside engineering, and only 14 percent inside GTM or sales. OpenAI has stood the function up by name. Palantir, which defined the Delta versus Dev split years ago, still sets the template everyone else is copying. The management wave behind that hiring wave is not documented, because most companies copied the seat and then opened Jira.

They opened Jira because that is what "software to manage a team" has meant for a decade. It is the wrong instinct for this function. An FDE team does not primarily produce tickets. It produces running, one-customer systems that hold customer credentials and generate revenue. Managing the team means managing that estate. If your current answer to "what is live at which customer, who holds the keys, and what happens if Priya resigns" is a standup, you do not have management software. You have a meeting.

What "manage" actually means for an FDE org

Four jobs, and only four, earn a place on this list. Everything else is a neighboring problem with its own software.

Estate visibility. Can you enumerate, from a screen rather than a memory, every customer-specific build currently running, which customer it belongs to, who in your org owns it, and whether it is healthy? If assembling that list is a project, you cannot manage the team, because you cannot see the work. This is the leadership version of FDE ops: not the five verbs as a runtime, but the five verbs as a picture you can take into a forecast call.

Credential custody. Can you tell a customer's security team, in one sentence, where their secrets live and who can read them? Custody is a management problem because the liability sits with the company, not with the engineer who happened to receive the key in a Slack DM. Zero-access custody (engineers reference secrets and cannot read values) is the architectural answer. A password-manager policy is the aspirational one.

Handoff. When an FDE changes seats or leaves, does the account move as a reassignment of org-owned work plus a note plus retained versions, or does it move as a two-week scavenger hunt? Handoff is the management test that reveals whether visibility and custody were real. The emergency version of this test is written up in when a forward deployed engineer leaves. This article is about the software that makes the emergency boring.

Utilization. Are your FDEs overloaded, idle, or load-balanced in a way that would survive a forecast? Utilization on an FDE team is not billable hours and it is not ticket throughput. Those metrics, imported from consulting and support, reward the wrong behavior. The useful signals are live builds per person, accounts per person weighted by integration depth, time-to-first-value on new accounts, and whether any one engineer is a single point of failure on revenue-bearing systems. You will not get those signals from a timesheet. You get them as a byproduct of an enumerable estate. The operating cadence that uses those signals (estate review, deal debrief, handoff drill, the first ninety days) already lives in how to run an FDE team. This list will not rewrite that guide. It will tell you which software makes those rituals cheap, and which software impersonates them.

Notice what is absent: a pipeline CRM, a quota dashboard, a sprint board, a resource-request form. Sales engineers and FDEs will keep using whatever CRM the revenue org already runs. Bloomberry found that exactly zero percent of FDE postings mentioned a quota, which is a clue. Software that tries to manage this team as a sales motion will be ignored by the people you hired to write production code, and software that tries to manage them as a sprint team will be routed around the first time a customer needs something on Thursday.

How we evaluated this list

Every entry below is scored, in prose rather than a grid, against those four jobs. We also asked a fifth, unromantic question: will FDEs actually put real customer work into this system, or will they keep the real estate on laptops and update the management layer afterwards? A management view of a shadow estate is a fiction with a login. The only management software that works for this function sits on top of where the work actually runs.

The failure data in the background is the same data that created the FDE hiring wave, and it is why this is a leadership purchase rather than an engineering convenience. MIT's Project NANDA, as reported by Fortune, found 95 percent of enterprise generative AI pilots produced no measurable P&L impact. S&P Global Market Intelligence, as reported by CIO Dive, found the share of companies abandoning most of their AI initiatives jumped from 17 percent to 42 percent in a year, with the average organization scrapping 46 percent of proofs of concept before production. Gartner forecasts that more than 40 percent of agentic AI projects will be canceled by the end of 2027. Your FDE team exists to pull your customers, and your own product, out of those percentages. Management software that cannot see the last-mile estate cannot tell you whether that is happening.

Cost context, because this purchase will be compared to headcount. The Bureau of Labor Statistics puts 2024 median pay for software developers, quality assurance analysts, and testers at $131,450, with 15 percent projected growth from 2024 to 2034. FDE compensation sits above that median, in a market Business Insider and Bloomberry both describe as exploding. Every week an FDE spends reconstructing an estate that should have been a screen is the most expensive reporting project your company will run. Every departure that becomes a rebuild is a customer incident priced in the same dollars. That is the business case, and it does not require a new vocabulary.

1. Archway: management that sits on the runtime

Archway is on this list for a reason that will annoy anyone who wanted a pure management suite: the management view is a property of the runtime, not a separate product. Bridges (serverless functions connecting your product to one customer's systems) are scoped to a customer from the moment they exist. Because the platform already knows which customer every piece of running code belongs to, estate visibility is a screen. You can see what exists, what is running, and who in the org owns it, without asking anyone to update a tracker after the fact.

Walk the four jobs.

Estate visibility is native. The customer is a first-class fact, not a naming convention in a shared cloud account. Leaders get the inverse of what FDEs get: FDEs ship more customer builds without consuming the product roadmap; leaders see the resulting estate without conducting an archaeology project. That is the picture you take into a forecast call, a board packet, or a customer's security review.

Credential custody is architectural. Secrets live in an AES-256 vault with zero-access custody. Engineers reference them in code and never see the values. For a revenue leader, this is the sentence you want in writing before the next enterprise procurement: we hold your credentials in a vault our engineers cannot read. It converts a trust exercise into an architecture answer, which is the only conversion that survives a change of FDE.

Handoff is a same-org reassignment plus a note plus retained versions. It is not a package, not a zip of scripts, not a wiki export. When someone changes seats, the bridges stay running, the history stays with the organization, and the successor inherits the actual estate rather than a description of it. That is the management property Palantir-shaped teams spend years building internally, described without romance in Nabeel Qureshi's account of the original model: the field only compounds if what it produces is retained by the institution.

Utilization, honestly: Archway does not pretend to be a timesheet, a staffing planner, or a CRM for the pipeline. What it gives you is the raw material those tools always lacked, which is the live estate per person. Builds per FDE, accounts per FDE, concentration risk (one engineer holding five critical customers), and the shape of the book are readable because the work lives here. Pair that picture with the operating cadence in how to run an FDE team and you have utilization as a leadership metric rather than a vibe. Do not expect the platform to tell you whether someone spent Tuesday in discovery calls. Expect it to tell you whether Tuesday's work produced something the company still owns on Friday.

There is AI-powered coding help in the editor. It is a feature, not the product, and it is even less the management product. Faster drafting is good. It is not how you see the estate.

Pricing is two bridges free, then $45 per bridge per month. For a team lead or a CRO, that means the management layer can be piloted on one real account this week without a procurement cycle. Put two customer builds on it, run one reassignment, and ask the four jobs against the result. If the screen answers them, you can stop assembling dashboards.

Pick Archway if you want estate visibility, credential custody, and handoff as properties of where the work runs, and you are willing to let utilization be inferred from a real estate rather than imported from a ticket board.

2. Roll-your-own dashboards: warehouse plus a wiki

The most common "management software" for FDE teams is not a product. It is a Looker or Metabase dashboard pointed at a warehouse, fed by a spreadsheet, annotated in a wiki, and demonstrated in the weekly meeting as if it were a system of record.

Credit the impulse. Leaders should want a picture. The dashboard that lists customers, named FDEs, and a red/yellow/green for "integration status" is trying to do estate visibility, and at three accounts it even works. The failure is upstream of the chart. Dashboards report on data someone typed. If the real builds live on laptops, in personal cloud accounts, and in one-off VMs, the dashboard is a well-designed view of a fiction. The wiki page holding the credential map is a second fiction, usually two months stale. The warehouse is a third, lagging whatever an engineer remembered to log.

Custody is out of scope. A dashboard cannot vault a key. The best version of this pattern connects to a real secrets manager in your cloud, which is real secrets infrastructure and still typically readable by the people who deploy, which means custody is a policy. Handoff is a checklist in the wiki. Utilization is a homemade ratio of accounts to names, blind to integration depth, so the FDE with one nightmarish regulated customer looks idle next to the FDE with eight thin webhooks.

The predictable end state is a reporting layer that leadership trusts more than the operators do. Operators know the dashboard is downstream of their goodwill. When goodwill is scarce, the dashboard is the last thing they update. You then manage the team off a picture of last month's estate, which is how surprises get into QBR slides.

Pick roll-your-own dashboards if the work already runs on a sanctioned platform that emits a trustworthy event stream, you have someone to maintain the pipeline, and you are honest that the dashboard is a window, not a floor. If the work does not already run in one place, build that first. The window can wait.

3. HRIS and spreadsheets: headcount without an estate

Workday, Greenhouse, a shared Google Sheet with columns for name, level, manager, and "accounts." This is how a lot of FDE orgs are managed today, especially at the 11-to-200-person companies that Bloomberry found holding 58 percent of FDE roles. It is not an insult. Headcount systems are good at headcount.

They know who is employed, what they are paid, who they report to, and when they are on parental leave. Those are real management facts. They are not FDE-ops facts. An HRIS will never tell you which version of the Acme sync is running. A spreadsheet of account assignments will tell you who is supposed to own Acme, which is not the same as where Acme's credentials live or whether the successor could redeploy a fix. The spreadsheet is also where utilization theater happens: a leader counts accounts per FDE, notices an imbalance, reassigns a logo, and discovers three weeks later that the logo was the easy part and the six undocumented jobs behind it were the job.

Spreadsheets fail in a specific way that looks like success. They are easy to start, easy to screenshot, and easy to believe. They scale by becoming untrue. The moment the sheet and the estate disagree, operators stop updating the sheet, leadership keeps reading the sheet, and the org now has two sources of truth, one of which is formatted for executives. Custody is a column that says "in 1Password" with no way to verify. Handoff is a row with a new name in it. Tribal knowledge stays in heads because the sheet has nowhere structural to put it.

Use HRIS for what it is for: hiring, leveling, comp, leave, the people side that how to staff an FDE team covers. Do not ask it to manage artifacts. The BLS occupational data will tell you what software people cost in general; it will not tell you what your five FDEs are currently running for paying customers. Those are different databases.

Pick HRIS and spreadsheets if you have one to three FDEs, a handful of accounts, and you are treating this as a stopgap you will replace the week the estate outgrows a tab. Write down the replacement date. Stopgaps without dates become the system.

4. Generic project tools: a ticket board wearing a management hat

Jira, Linear, Asana, Monday, Notion roadmaps, the professional-services PSA tool a well-meaning COO rolled out because "we need utilization." This is the aisle most buyers walk into after they type "software to manage FDE teams" into a search bar, and it is the aisle this article exists to walk them back out of.

Project tools are excellent at the job they were built for: coordinating work that looks like a queue. FDE work looks like an estate. A ticket can say "build the Acme SAP connector." It cannot be the connector, host the connector, vault the credential the connector uses, retain the version that is live, or reassign the running system when the assignee leaves. Teams that manage FDEs through tickets get very good at reporting sprint hygiene and very bad at answering the four jobs above. The board is always greener than the estate.

Utilization is where this category does the most damage, because it offers a number. Hours logged, tickets closed, story points completed, "capacity" as a percentage. Those numbers will be used in forecast meetings. They will also train your FDEs to optimize the board rather than the customer, which is how a function built to unblock revenue starts to look like an internal agency with a backlog. Bloomberry's finding that FDE roles do not carry quotas and mostly do not even mention OTE is the labor-market's way of saying this is not a managed-services motion. Importing managed-services software into it is a category error with a seat license.

There is a legitimate, narrow use. A light board for the work that really is a queue (a shared pool of small requests, an internal intake from sales that needs a qualification gate) can sit next to the estate platform without pretending to be it. The qualification gate and the sales rules of engagement belong in how to run an FDE team, not in a more expensive tracker. If the board is where sales files requests and the platform is where FDEs ship, you have a division of labor. If the board is where leadership thinks the team lives, you have a shadow estate.

Pick generic project tools if you need a thin intake queue for pre-qualified requests, you already have somewhere else for the running work to live, and you will not let utilization on the board become the utilization you manage to.

5. Internal builds: Palantir-shaped, Palantir-priced

The companies that made the FDE role famous largely built their own machinery for seeing and transferring field work, over years, with dedicated platform teams and requirements most vendors will never see. Palantir's public writing on Deltas versus Devs is the cultural artifact; the actual internal systems are the expensive part, and they are not for sale. If you are going to manage an FDE org at Palantir-like scale, with Palantir-like constraints, building internally buys total control: your identity provider, your vault, your audit story, your handoff workflow, your compliance regime, no external dependency.

The honest accounting is what kills most internal-build proposals once it is written down. The scope is not a dashboard. The scope is estate visibility plus credential custody plus handoff plus a utilization picture that is true because it sits on a runtime, which means you are now building an FDE ops platform and calling it management software. Each of those jobs is a product, not a feature. The timeline is quarters before the first leader sees a trustworthy screen. The cost is permanent: internal platforms need staffing forever, and the moment they lag, your FDEs are back on laptops, except now there is an official management layer they are not feeding. Price the platform engineers against $45 per bridge per month and be certain the difference buys something your customers can feel.

There is also a cultural failure mode specific to management-shaped internal tools. Because they are built for leadership reporting, they optimize for the chart. Operators experience them as surveillance-plus-data-entry. The sanctioned path gets slower than the laptop, the estate forks, and leadership gets a more beautiful view of a less true system. Governance theater is how AI transformations fail in public; an internal FDE "command center" that nobody ships through is the same play, staged for a smaller audience.

Pick internal build if FDE ops is strategic to you at a scale where owning the machinery beats renting it, you can staff it indefinitely, your requirements genuinely exceed what purpose-built platforms cover, and you are prepared to build the runtime, not only the slides about the runtime.

What this list deliberately leaves out

The five-verbs runtime list. Best FDE ops platforms is the companion, not a competitor. That list evaluates Archway, roll-your-own cloud, GitHub plus CI, Modal, app platforms, and internal builds as places to run customer-specific code. This list evaluates how you see and transfer the team that produces it. Archway appears on both because the management view is native to the runtime. The other runtime entries do not become management software by wishing.

AI coding assistants. Faster writing is not management. If anything, assistants increase the rate at which the estate grows, which increases the value of visibility, custody, and handoff. Archway ships coding help as a feature of the editor; we still would not put an assistant on a management-software shortlist.

Professional-services automation and PSA suites. They will be pitched to you the moment someone in finance hears "utilization." They assume a bench, a rate card, and a timesheet. FDE orgs that adopt them start to bill like consultancies and stop compounding like product companies. If you wanted a consultancy, the hiring market is full of them. If you wanted the Palantir-shaped loop where field work feeds the product, PSA software fights you.

CRMs for the pipeline. Salesforce, HubSpot, whatever already holds the pipeline: keep using them for deals. Do not ask them to hold running integrations. A serious FDE ops platform does not try to replace the AE's CRM. The FDE needs an estate.

How to choose, as the person who runs the function

If you have one to three FDEs. Do not build a management stack. You have no slack for it, and your "estate" still fits in one person's head, which is exactly the risk. Put two real customer builds on Archway's free tier, reassign one of them as a drill, and see whether the four jobs become answerable from a screen. The operating habits (qualification gate with sales, a weekly estate review) still matter; steal them from how to run an FDE team rather than inventing a tool that pretends to be those habits.

If you have five to fifteen FDEs. This is where the management problem becomes real: dozens of customers, the first painful departure, a CRO who wants a number, a security team that wants a sentence. The decision is usually Archway versus a dashboard-plus-sheet versus an internal build. Ask one question in the room: is our picture of the estate produced by the system the work runs on, or by the goodwill of the people who run it? If the answer is goodwill, you are one busy month away from a fiction. This is also the stage where staffing and structure start to bite; hop to how to staff an FDE team for the people math and come back here for the artifact math.

If you searched this phrase because a departure is already in motion. Stop shopping. Run the handoff playbook, then buy the thing that would have made that playbook an afternoon. Shopping during an incident produces a tracker. You do not need a tracker.

If you are a revenue leader being asked to fund this. Fund it as deal infrastructure, not as engineering overhead. The business case is deals unblocked, time-to-first-value compressed, credentials answerable in a sentence, and core product engineering not consumed by customer-of-the-week work. A platform line item priced per bridge is small against any of those. A dashboard project that does not change where code runs will not move them. Customer-specific integrations are the inventory you are funding; management software that cannot see that inventory cannot defend it.

If you already bought a project tool and feel defensive. Keep it for intake. Do not extend it. The sunk cost is a seat license, not an architecture. The expensive thing is the estate you still cannot enumerate.

The category is management of artifacts, not management of people

People-management software is a mature market. You already own some of it. Artifact-management software for forward deployed teams is a young market, because the teams themselves are young outside the handful of companies that invented the role. What changed is that everyone else now has the team without having the machinery, at the exact moment enterprises started walking away from AI initiatives for want of last-mile engineering.

Managing an FDE org is a four-job problem: see the estate, hold the credentials, transfer the work, and read utilization from something true. Ticket boards, HRIS tabs, and homemade dashboards each cover a slice and then quietly claim the rest. Archway covers them by being the place the work runs, which is an unglamorous way to get a management view and, currently, the only way that does not depend on your best engineer updating a sheet.

If you want the runtime-shaped companion, it is best FDE ops platforms. If you want the noun, it is what is FDE ops. If you want to try the thing this list is circling, two bridges are free. Speed for the people who ship. Custody and control for the person whose name is on the forecast.

Sources and notes

• Business Insider (Cadie Thompson and Lakshmi Varanasi, May 2026): Indeed index of forward deployed engineer postings (543 percent by April 2025; 5,230 percent above the January 2025 baseline by April 2026, roughly 729 percent year over year) and the Indeed pay range of about $170,000 to over $200,000. Figures are indexed values, not raw job counts. https://www.businessinsider.com/forward-deployed-engineer-jobs-in-demand-2026-5

• Business Insider (July 2025): OpenAI standing up a forward-deployed engineer function, as described by Oliver Jay at Fortune Brainstorm AI. https://www.businessinsider.com/openai-forward-deployed-engineers-accelerate-ai-projects-2025-7

• Bloomberry, "What I learned analyzing 1K forward deployed engineer jobs" (updated January 25, 2026): 1,165 percent year-over-year posting growth; median $173,816 from disclosed ranges; 45 percent dedicated FDE team / 38 percent engineering org / 14 percent GTM or sales; 58 percent of roles at companies with 11 to 200 employees; 0 percent of postings mention a quota; 8 percent mention OTE. https://bloomberry.com/blog/i-analyzed-1000-forward-deployed-engineer-jobs-what-i-learned/

• Fortune coverage of MIT Project NANDA, "The GenAI Divide: State of AI in Business 2025" (August 18, 2025): 95 percent of enterprise generative AI pilots showed no measurable P&L impact. https://fortune.com/2025/08/18/mit-report-95-percent-generative-ai-pilots-at-companies-failing-cfo/

• S&P Global Market Intelligence, as reported by CIO Dive (March 14, 2025): share of companies abandoning most of their AI initiatives jumped from 17 percent to 42 percent; average organization scrapped 46 percent of AI proofs of concept before production. https://www.ciodive.com/news/AI-project-fail-data-SPGlobal/742590/

• Gartner press release (June 25, 2025): more than 40 percent of agentic AI projects will be canceled by the end of 2027. https://www.gartner.com/en/newsroom/press-releases/2025-06-25-gartner-predicts-over-40-percent-of-agentic-ai-projects-will-be-canceled-by-end-of-2027

• Palantir, "Dev versus Delta: Demystifying engineering roles at Palantir." https://blog.palantir.com/dev-versus-delta-demystifying-engineering-roles-at-palantir-ad44c2a6e87

• Nabeel S. Qureshi, "Reflections on Palantir": original FDE model and the field-to-product loop. https://nabeelqu.co/reflections-on-palantir

• U.S. Bureau of Labor Statistics, Occupational Outlook Handbook, Software Developers, Quality Assurance Analysts, and Testers: 2024 median pay $131,450; 15 percent projected employment growth, 2024 to 2034. https://www.bls.gov/ooh/computer-and-information-technology/software-developers.htm

• Archway product claims are first-party and match the published product facts at https://www.tryarchway.ai/ (llms.txt).