Nobody sets out to wreck a launch. The team presenting to a client on Tuesday morning did not know that the shared folder had been reorganised on Monday. The person who reorganised it was genuinely trying to help. They tidied up a structure that had been bothering them for weeks, moved a handful of assets into better-named folders, and went home feeling like they had done something useful.
But the hero film in the deck now points to a path that no longer exists. Oops.
This story captures something agencies consistently underestimate: that the distance between “this change is small” and “this change is safe” is far larger than it looks. In a tightly integrated IT environment, a folder rename, a permission adjustment, or a new tool getting wired in can have effects that only surface days later, in front of the wrong person and at the worst possible moment.
The takeaway – every change, however small, should be tested before going live and must be reversible if (when?) something unexpected happens.
That is not bureaucracy, it’s the difference between calm and panic.
What “small” changes actually touch
The problem with small changes is that they rarely stay small. IT environments in creative agencies are more interconnected than they appear from the outside: asset management tools connect to project management platforms, single sign-on systems govern access across a dozen applications, and file structures are referenced in links embedded in client-facing decks, live campaign dashboards, and internal wikis.
If someone changes part of that environment without realizing what else depends on it, they pull on a thread in a fabric they cannot fully see. Often nothing unravels, creating an unjustified confidence in their ability to tweak on the fly, but, occasionally, something does. When this happens it is, best case scenario, embarrassing, but it can be catastrophic.
The change nobody wrote down
Across the agencies we work with, the pattern when something breaks is consistent. We ask what changed recently. There is a pause. Then a collection of partial answers from different people: “I think someone updated the access settings last week”, “we added a new tool for the Henderson account”, “IT did something with the VPN on Thursday, not sure what exactly.”
Nobody is hiding anything, but changes that happen through Slack messages, quick conversations, and informal requests tend not to be logged properly and therefore can’t be rolled back easily.
A change you can’t roll back commits you to whatever got broken. When something goes wrong in this way you are not solving a technical problem, you are doing archaeology. Every hour spent doing archaeology is an hour not being spent on paid work.
Why “test before you change” feels hard in an agency
Creative agencies are not slow-moving organisations. Clients pay for responsiveness and tight delivery schedules and the ability to move quickly is often what differentiates a good agency from a fired one. In that environment, a change process that requires sign-offs, documentation, and testing before anything can be touched sounds appalling.
But testing a change before it goes live does not have to mean a lengthy formal process. For most routine changes, it simply means one person confirming that the thing they changed still works from the perspective of the person who depends on it.
What rollback actually means
Every change that touches anything client-facing or delivery-critical should have a clear answer to one question before it is made: if this doesn’t work what do we do next? If nobody can answer that, the change is not ready to go live.
Rollback does not have to be complicated. The level of preparation should match the level of risk. It can simply mean keeping the previous version of a file accessible before renaming or moving it or simply noting the previous settings.
How Cardonet makes this work in practice
The agencies we work with don’t build all of this themselves.
When we manage an agency’s IT environment, we deploy change management. Every change is logged with what was touched, who authorised it, when it happened, and what the rollback steps are. That record belongs to the agency. When something unexpected happens, the question – “what changed recently and how do we reverse it?” – has an immediate answer.
We encourage the discipline of testing changes from the right context. Before anything goes live that could affect a client-facing asset, a campaign tool, or a shared environment, it needs to be checked that it works from the perspective of the people who depend on it. That includes checking against the agency’s delivery calendar. A change that is safe on a normal Tuesday is not necessarily safe the Tuesday before a global launch.
The rollback question is part of how we plan changes, not an afterthought. For anything beyond low-risk routine changes, we document the reversal steps before the change is made. If something does not go as expected, we are executing a plan that was already written.
That is what reliable change management looks like in practice. A working relationship where the IT environment is managed with the same care and discipline the agency brings to the work itself.
Where to start
If you recognise the patterns in this article, the invisible changes, the single person who holds all the knowledge, the Friday afternoon tweaks that surface on Monday, the first step is a straightforward conversation about how your agency currently handles change and where the gaps are.
We do this regularly with creative and marketing agencies. It usually takes about thirty minutes to understand the current picture and work out whether there is something useful we can do together. If there is, that tends to be obvious quickly. If there is not, we will say so.
You can contact us here. No obligation.
FAQs
1. Our agency already has IT support. Why is change management still a problem?
Most IT support contracts are reactive. They cover what happens when something breaks. Change management is about what happens before something breaks: how changes are planned, tested, and made reversible before they go live. Many agencies have solid reactive support but no structured approach to change, which is where most disruption actually starts.
2. We are a small agency. Does this apply to us?
More acutely than you might expect. Smaller agencies concentrate IT knowledge in fewer people. When the person who understands the environment leaves, the exposure is immediate. Smaller agencies also have less capacity to absorb a disruption that hits at a critical moment.
3. How long does it take to see a difference?
Visibility comes within the first few weeks: a clear record of what is changing and who is responsible for each category. The operational change – fewer surprises, faster diagnosis when something does go wrong – is usually apparent within three months.
4. Can we keep some IT management in-house?
Yes, and for many agencies that is the right structure. We work alongside internal IT people or technically capable operations staff. We take ownership of higher-risk change categories and the underlying infrastructure. They continue to handle what they know well and are close to.
5. What does the transition involve?
Mapping the current environment. Agreeing which change categories carry which level of risk. Establishing clear communication between your team and ours. Most agencies are fully operational throughout. The first thing most notice is that “what changed recently?” has a clear answer without calling around.
You must be logged in to post a comment.