# Change management: why an FDE's job isn't done on go-live day

> Your system can run flawlessly and still fail if, two weeks after go-live, users quietly return to their old Excel files.

Original: https://fdetimes.net/en/guides/fde-change-management-after-go-live/

Picture this: the demo is done, the client has signed off on acceptance, and the dashboard is all green. Two weeks later you open the logs and find the system running fine. The only problem is that almost nobody is using it.

For an FDE, this is the most frustrating kind of failure. There is no incident, no bug to fix, and no complaint in any ticket. Users have simply gone back to the old way of working. Six months later, when the contract comes up for renewal, the client asks what the system has actually delivered.

Planisware, a project management software vendor, states plainly that its clients often assume most of the work is done once the system is ready to deploy, and that this is not true.

Tryolabs calls the remaining work the FDE's "last mile": user onboarding, change management and integration into workflows. This work is not separate from the engineering. It determines whether the system you built creates any value.

## Why is a single training session usually not enough?

Most engineers take "user training" to mean a slide presentation before go-live, with a demo, a Q&A and a guide sent round by email. That approach misses one important detail: knowing how to use something and being able to do it are not the same thing.

Prosci's ADKAR model breaks each person's journey through change into five outcomes, one for each letter: Awareness, Desire, Knowledge, Ability, Reinforcement. Knowledge is knowing how to change; Ability is putting the new skills and behaviours into practice.

A classroom session only reaches Knowledge. An accountant can nod along through the whole demo and still have no idea what to do when the first crookedly scanned invoice turns up.

The two ends of the model are often skipped as well. At the start, Prosci warns that sending employees an announcement does not mean they have Awareness, that is, an understanding of why the change is needed.

At the end, Reinforcement means sustaining the new way of working and stopping users from slipping back into old habits. According to Prosci, without this step users may revert to the old way, and the project risks not delivering the benefits it set out to achieve.

**Key point:** Sending an announcement email does not mean users understand why they have to change.

## A concrete case: an invoice-reading agent for an accounting team

Suppose you deploy an agent that extracts invoice data for a 12-person accounting team at a distribution company. The agent reads PDF files and fills in the fields in the ERP system; fields with low confidence are pushed to a queue for human review. Technically, everything works.

Here is what your job looks like at each stage.

**Awareness.** Don't start with an email saying "from Monday, the team is switching to a new tool". Sit down with the chief accountant and ask: "At month-end, how many evenings does the team spend keying in invoices by hand?" Her answer is the reason for the change, and it has to come from someone in the team, not from the vendor.

**Desire.** Understanding the reason does not mean wanting to change. An accountant who has keyed in invoices by hand for years may worry that the new tool will expose old mistakes, or make them redundant. Invite two people from the team to give input on how the review queue is organised, so the system carries their own contribution.

**Knowledge.** The training session uses the company's own real invoices, not demo data. You deliberately include bad cases such as blurry photos, two-page invoices and obscured tax codes, because those are the cases users will meet in their very first week of real work.

**Ability.** In the first week after go-live, each person processes their daily invoices on the new system while you sit beside them. You note every time someone is about to open Excel. Each of those moments signals a spot where the system does not yet fit how the work actually gets done.

Tryolabs describes the goal of this stage in exactly those terms: removing the friction between a system that works and how people actually work.

**Reinforcement.** After 30 days, you review the logs: who is still processing through the system, who has dropped off, whether the review queue is backing up. You work with the chief accountant to build the system into the official month-end close, so that the new way becomes the default rather than just an option.

## The next trainer must be someone on the client's side

There is one risk the five stages above do not address, so it needs a parallel track of its own: you will leave, and the person you trained most thoroughly may also leave the company.

A Tungsten Automation FDE job posting includes in its job description targeted train-the-trainer sessions and technical documentation written specifically for each client. The stated reason: to reduce knowledge loss when client staff leave.

In the accounting case, this means choosing two people, not one, and having them lead the training for their colleagues while you only listen and fill in gaps.

The documentation also needs to be written for the right reader. Don't write a README for developers; write one page on "what to do when an invoice is pushed into the review queue", with screenshots from their own system.

Tryolabs describes the end goal as a client organisation that is more capable and fully owns what has been built. If nobody knows how to run the system after you leave, you haven't finished the handover.

## The one-page plan

The table below is a template you can use on your next project. The most important column is the last one, because each stage counts as achieved only when there is observable evidence.

| Stage | What the user is asking | What the FDE does | Evidence it is achieved |
|---|---|---|---|
| Awareness | Why do we have to change? | Let the team lead name which task costs the most effort | Users can state the reason in their own words |
| Desire | What do I get out of changing? | Invite users to give input on the design | Users proactively bring hard cases to try |
| Knowledge | How do I use it? | Train on real data, including bad cases | Everyone handles a hard case on their own during the session |
| Ability | Can I do it on real work? | Sit alongside users in the first week, fix remaining friction | Daily invoices are processed on the new system |
| Reinforcement | Will we go back to the old way? | Review logs after 30 days, build it into the official process | Nobody is still running a parallel process in Excel |

## Four common mistakes

The first mistake is treating go-live as the finish line, so the entire project timeline goes into code and no week is left to sit with users. The second is training with clean demo data, which leaves users confident in the classroom and caught off guard as soon as they meet real work.

The third is assuming that an announcement is enough for users to understand why they must change. An email from management only says that change is coming; users have to be able to state the reason in their own words. The fourth is relying on a single "power user". When that person leaves, all the knowledge goes with them.

For engineers looking to move into FDE roles, this is also an advantage on a CV. Instead of writing only "built an invoice extraction pipeline", add how many people you onboarded, how many were still using the system after 30 days, and whom you trained to go on teaching their colleagues.

When reading job descriptions, look for phrases such as "user onboarding", "change management" or "train-the-trainer". Tryolabs places user onboarding and change management within the FDE's remit, and Tungsten Automation's job posting writes train-the-trainer directly into the job description. So have a specific story ready for each phrase.

Planisware calls training a part of change management, with a large impact on both user adoption and performance. Code makes your system work, but whether users keep using it after you leave depends on this part of the job.

**Try this week:**

- Pick a tool you have shipped, check the logs to count who actually used it in the last 2 weeks, then talk to 2 people who don't use it and ask how they are doing that task instead.
- Write a one-page change plan for your current project using the five-stage table in this article, with each row stating the evidence that shows it has been achieved.
- Reread 3 FDE job postings, mark the phrases 'user onboarding', 'change management' and 'train-the-trainer', and prepare a story with numbers from your own projects for each one.

## Sources

- [Forward Deployed Engineers | Tryolabs](https://tryolabs.com/services/forward-deployed-engineers)

- [Planisware Engage – Empower your team faster](https://planisware.com/planisware-engage)

- [Forward Deployed Engineer – Churn Prevention (Tungsten Automation)](https://careers.ta.com/companies/tungsten-automation/jobs/85436356-forward-deployed-engineer)

- [The Prosci ADKAR® Model | Prosci](https://www.prosci.com/methodology/adkar)

- [ADKAR Reinforcement: How To Sustain Change | Prosci](https://www.prosci.com/blog/adkar-model-reinforcement)

- [Awareness in The Prosci ADKAR® Model: Definition, Examples and Best Practices](https://www.prosci.com/blog/adkar-model-awareness)