Uh-oh. This system isn’t a castle... It’s a folly.
8 simple steps to recover when a new system isn't meeting expectations.

Where is this all going?
What follows is a framework to retrieve all bad system implementations.
It’s written to be actionable and memorable.
All you’ll need to remember at the end of this piece is the mnemonic below.
Let’s go!
Let those without mistake cast the first withering glare
We’ve all been there, right?
That thing just isn’t meeting your expectations.
It happens in our personal lives – perhaps more than we’d care to admit.
The person you thought was trustworthy, isn’t.
The car you thought would make you happier, hasn’t.
The holiday you thought might de-stress you, didn’t.
So, what to do when a new system implementation doesn’t deliver everything you’d hoped?
Problems, problems everywhere
Let’s set the situational foundations.
You decided to go through a tech change project.
This means resources were put into:
Identifying a problem.
Finding solutions.
Setting a budget.
Scrutinising best fit.
Requirements analysis.
Implementing.
Testing.
Training.
Launching.
Bedding in.
And now, it’s live.
The system; your castle: a fortress against those tyrannical problems hampering growth. Inside the walls of the castle, your community of users can thrive.
But, instead of thriving, the castle inhabitants are murmuring discontentedly.
It’s awkward to admit given the scale of the effort, but something is just… not right.
(Here we seamlessly break from metaphor and start just talking about systems — pretend not to notice).
Perhaps there’s a functional gap.
Perhaps there are performance issues.
Perhaps users weren’t trained well enough.
Perhaps the UX is just not good enough.
Either way, the reality is unavoidable. Users aren’t taking to it. It’s not working. Higher-ups can see. A castle might’ve been the aim, but you’ve ended up with a folly, mon ami.
(“The metaphor is back now — make up your mind. And did you make that rhyme on purpose??”)
And so the question becomes, “With little budget, time, or will to do an immediate ‘rip and replace’”, what is a brand to do?
Fear Not
Reasonable organisations accept mistakes as part of a learning cycle, as long as those mistakes aren’t a total disaster (which some botched system projects can be).
Fortunately, we’re not talking here about the Sistine Chapel being burned down.
No invasive species were unwittingly released into an ecosystem, razing to the ground pre-existing natural habitats.
You didn’t just create a machine with general intelligence far greater than a human. (Quite the opposite! Artificial Stupidity.).
Anyway… whether the blame lies with you or not, in your position as a tech leader within a brand there are opportunities to turn this folly folly (not a typo…) into a positive perception of you and your work.
Here’s how…
Step 1: Recognise
(TLDR: publicly acknowledge the challenges.)
Start before the ‘why’.
Leap not to ‘Why is this happening?’, nor ‘What shall we do about it?’. We’re getting there, but via ‘it is happening’.
A ‘public’ acknowledgement of the problem is foundational.
Here’s why it matters:
Having a leader acknowledge a problem puts everyone at ease: simply, they see that you see.
Acknowledging problems early builds trust in your perceptiveness, communication and competence.
Being the first to acknowledge a problem sets you up to manage it as you think it should be managed. Think of it as your own little ‘first-mover advantage’.
Acknowledging challenges creates an environment where people feel comfortable sharing their insights on the issues. You strengthen your hand by getting that feedback.
You feel good for exhibiting behaviours you want to see from others — this is being a role model.
The Actionable Bit
Here’s a plan to front up the castle/folly dilemma. Slightly different executions for in-office vs remote businesses.
In-Office:
Do the acknowledgement in person, at a ‘Town Hall’ or ‘All Hands’ meeting if your organisation already has one of those.
If not, do via Loom video (or akin) and share it on Slack, Teams, email; whatever comms channel will reach all necessary parties.
Remote Business:
Straight to a Loom video with a quick follow-up meeting scheduled for you to answer questions (and increase the probability everyone watches the Loom).
The structure:
⦾ Context — Explain why you’re giving the address. No judgment, no blame.
⦾ Issue acknowledgement — A quick overview of the issues you’re aware of to date.
Really — keep it short. Non-technical stakeholders (and probably some of the technical ones…) will glaze over if you don’t keep this bit to an overview. The deep dive comes later. You’re doing this bit so your audience knows what you are aware of at an issue-level, ready for the next step in this list.
⦾ The resolution plan — your space to say:
What steps will be taken to resolve the issues.
What timeline you’re working to.
How often updates will be communicated.
Where updates will be communicated.
What you need from everyone else.
The Result
Team coherence and unity around the challenges. Increased confidence that the challenges will be met.
Step 2: Explore
(TLDR: data work, basically).
This is a witch-hunt!
Figuratively, only, of course. The witches are safe for now. It’s for problems the torches are burning.
Get all of the issues out in the open.
Up to now, you might only have a partial view of why the system is failing. Step 2 — get a full view.
The Actionable Bit
Start by getting the issue management system right.
Related databases for Issues and Actions mean easier tracking of multiple actions against one issue and a lot less effort on data entry.
I use Notion — other tools are available!
Who you ask for input, and how you ask, is what matters next.
Get time with your stakeholders
Show them the format you want the issue data in
Share the issue manager
Agree a timeline for them to input
Follow up until done
The Result
All issues are known and visible to all stakeholders. The ‘problem outline’ is complete. Everyone feels more in control.
Step 3: Troubleshoot
(TLDR: AKA, root cause analysis.)
You — being the talented, dynamic problem-solver we know you are, immune to flattery and internet charm — already have your methods for identifying the underlying problems causing issues in your tech stack.
Here is the step in the process to do just that.
This article gives an overview of some established RCA (root cause analysis) frameworks if needed.
The Actionable Bit
Bring a ‘Root Causes’ database into your Issue Manager.
Then:
Relate the databases to:
Generate actions from the Root Causes table.
Roll up the root cause data and bring it through to the Issues and Actions table so that all tables have root cause data.
Set up notifications to ping the appropriate people in Slack/Teams whenever noteworthy things happen/don’t happen in the tables.
The Result
Problems are properly understood. Solutions are therefore easier to find.
Step 4: Resolutions
(TLDR: create a set of solutions for your team to choose from.)
Some issues from the implementation, like—
‘Our suppliers are not supporting us well after launch’
‘Our team is showing resistance to the new system/change’
‘Some of our customers had a bad experience with us because of issues with the new system’
—have many possible actions which could form a solution.
This step in the recovery process exists for these cases, where there isn’t any one clear path forward for an issue because of its size, complexity or generality.
This step in the process is to create an array of solution options against those issues.
The Actionable Bit
Against each relevant issue, create a list of potential solutions.
Use the actions table to chair a solutions meeting with stakeholders and get their feedback.
Also for the meeting:
Take feedback from stakeholders
Welcome additional ideas for actions
Discuss which actions should be taken
Determine the priorities of actions
Confirm owners of actions
Add deadlines
The Result
Team confidence builds in you and the recovery process. The plan gets stronger with multiple brains inputting solutions.
Step 5: Iterate
Simple. Make your actions better by refining them with the feedback gathered in the last step.
Step 6: Endorsement
(TLDR: get sign-off on your plan.)
You’ve done things properly so far.
Owned the challenges.
Got a full picture of what the issues are.
Given everyone visibility of what’s happening.
Found the root causes of the issues.
Come up with lots of solutions.
Got feedback from stakeholders.
Improved your actions with that feedback.
Kept everybody in the loop as you went.
Now, tick the final box — get the endorsement of the stakeholders on what you plan to do.
The Actionable Bit
Keep the format simple.
“These are the issues we all see”.
“These are the root causes”.
“From the solutions we worked on, these are the ones I’m going to action”.
”This is when I’ll update you again”.
“Everybody happy with the approach?”
Once you’ve got a ‘yes’ from all the key stakeholders, move to the next step.
The Result
You have a solid, logical plan, formed with stakeholder input and full endorsement to action it.
Step 7: Venture
(TLDR: go forth and do.)
Plan approved. Time for you to venture forward.
(You think I’m stretching things a bit to fit the mnemonic now, right? Is thou back not stiff from sitting on that high horse all day? You get the gist. Do you know how hard it was to think of a word beginning with ‘v’ that fit here?).
Go and execute the plan.
Step 8: Evaluate
(TLDR: reflect and learn from the experience.)
Probably the most valuable step of all.
By this point, you’ve clawed it back. Either the system implementation is retrieved, or you’ve attempted to retrieve it correctly.
Now to capitalise on the hard-earned lessons from the experience.
The Actionable Bit
Run a project retrospective.
Gather as many valuable actions from the retro as possible.
The Result
Everyone feels more empowered to handle comparable work better next time.
Well Done, Friend
You’ve climbed the steps to a better place!
It wasn’t easy. The staircase is long and steep.
But, you were the difference-maker. The leader. The architect of recovery. Bravo. I hope you learned something valuable.
I’ll leave you with the mnemonic one more time, below.
Until next time!
Suggestions for further learning.
If you like the ideas here, you’d probably get something from learning more about ‘Intellectual Humility’.
For a quick intro, I wrote a LinkedIn post about it and how it applies to a retail systems context.
I also wrote a second LinkedIn post trying to example intellectual humility by telling a story about a mistake I made in a previous job, and what I learned from it.
For a more in-depth overview, my source material for those posts was this podcast.