An “Admin rampart” is an odd but very real construct. It is a defensive structure, usually built by one team, silo, or functional area to protect itself from the perceived aggressions of another.
Explanation
Often the creation of “Admin Ramparts” is the unintended consequence of a well-meaning initiative. A large corporation realises that it is drowning in paperwork and process, to the point where it is actively impeding delivery to the business and even to itself. In response, it launches a drive for simplification or boundary breaking.
In practice, this rarely breaks down the old issues. Instead, new processes are created in the hope that they will simplify delivery. The critical flaw is that the existing processes are very often not removed first. Another layer is simply added on top, usually by the team creating the new framework. This is done to demonstrate progress and the aim of simplifying delivery.
Meanwhile, the areas whose boundaries and controls are being challenged frequently respond by placing even more dependencies in front of their current processes, as they feel they are losing control of their own deliveries and so want to place responsibility safeguards in place for the inevitable “blame game”; sometimes these dependencies become cyclic and impossible to achieve for a new delivery. The result is that regardless of whether you follow the new route or not, you still have to complete all of the old steps as well, often just under a different name.
This back-and-forth, without ever dismantling what already exists, produces admin ramparts. These become great walls of paperwork that serve to deflect blame, avoid responsibility, and maintain control, rather than enable delivery.
Disclaimer: As always these posts are not aimed at anyone client or employer and are just my personal observations over a lifetime of dealing with both management and frontline associates.
Now this is an incredibly dull subject, but one that many companies continue to struggle with when it comes to integrations.
All integrations, by their very nature, are quite brittle processes.
They often involve converting data from one format to another, and because they cross multiple systems and ownership boundaries, they can be difficult to pin down when things go wrong.
Many of the endpoint systems that are integrated into have very restrictive support models, and security rules often mean that each team can see only a limited part of the picture.
So, once the project work has been completed and everything is technically “working,” as it should, then the real challenge begins, which is how do you actually support it in the long term?
Of course there will be issues around monitoring, workflow, ownership, and escalation paths, but ultimately it comes down to one thing:
Responsibility.
People rarely want to follow a formal process that leads to them having to pay for it to be fixed. Instead, you’ll hear, “Oh, X is broken, call Y.”
It’s human nature, and integrations tend to encourage this kind of finger-pointing.
“It’s your bit that’s broken, not mine.”
The best tip I’ve found for handling this is to ask a very simple question…
Is this a new piece of code, a new application, or a new machine? If so, who are you paying to look after it?
That’s the crux of the matter. If there’s no budget, then most departments will quite rightly say, “That’s not our responsibility,” unless it’s a simple configuration change or something that clearly falls within their existing remit.
But integrations rarely work like that.
They almost always introduce new code, new objects, or new dependencies.
So, the next time you’re trying to work out who owns a piece of integration work, just follow the money.
Whoever is being paid to maintain it is responsible for it. If no one is, then you haven’t yet found an owner. And if someone is willing to take the funding or resources, then they are, by definition, the right people to make responsible.
It’s a simple question, but it saves a lot of pain.
My colleagues and I work as a genuine small consultancy. We’ve been that way for a long time, That means we rarely work through agents. Agencies do a lot for contractors and take a lot of the boring stuff away, but without them, much of that suddenly lands on your own desk. Here are the biggest things you’ll need to handle financially when you’re a small business working with the giant multinationals.
1) Working at risk
“Working at risk” is big-company shorthand for starting work before a contract is fully signed, meaning you might not get paid. It happens because internal contracting and approval processes often move far slower than the need to deliver. Large consultancies accept this as normal. If you’re used to agency work, you won’t have seen it because your contract sits with the agency. As a real company, you will face it regularly.
2) Slow payments
Large organisations pay slowly, sometimes very slowly. Even with everything done correctly, you may wait months (45 or even 90 day terms are common), and practical delays can push invoices being paid out to six months. there is rarely malice in this; it’s just how the corporate machinery works. You will need enough cashflow to cover at least six months of outgoings without incoming invoices when first starting out.
3) “Bad” software (that’s actually just hideously complex)
You might run your own invoicing on tools like FreshBooks, Xero or QuickBooks. Your clients will likely use things like Coupa, Planview and other enterprise platforms. From your vantage point, they can seem dreadful or illogical. In reality, you’re seeing only a tiny slice of a system coping with huge complexity. Expect odd workflows and fields that make little sense in isolation. Be patient, ask for a short walkthrough, and build simple internal checklists so you submit things right first time.
4) Being treated like a multinational
Flattering? Yes. Fun? Not really. Many procurement teams are set up to deal with Accenture, PwC, Deloitte, and the like, so the template master services agreement you’re handed will be written with them in mind. Hire a good lawyer you get on with, and have them mark up practical adjustments for a company your size. Most procurement people are sensible; if you clearly explain what’s unreasonable, they’ll often accommodate it, provided you stay constructive rather than combative.
5) Invisible thresholds
Everything can be cruising along nicely and then, bang, You’re suddenly pulled into confrontational calls and quizzed on billing details that were fine last year, sometimes over very small amounts. What’s happened is you’ve crossed an internal threshold: end of financial year timing, a budget code boundary, or a spend level that pushes approvals to a higher tier. None of this may be visible (or shareable) to you. Don’t take it personally. Break invoices down, align to the right periods, and help them route approvals cleanly.
6) Absorbing costs and tasks
You may be asked to absorb items you’d normally pass on as expenses to a project such as, ISO certifications, bits of hardware, software licences, and so on. Big consultancies often bundle these into their rates or already hold the certifications, so the client expects “sure we’ll cover that” when asked. As a small company, you’re competing with that standard. Decide what you’ll absorb, what you’ll explicitly scope and price, and where you’ll simply say “that’s out of scope, here’s the cost”. Transparency helps, but be prepared to shoulder some admin and paper work to keep things moving.
Final thoughts
Working with huge companies is absolutely doable, and rewarding, if you plan for the realities: accept some risk (carefully), maintain strong cash reserves, get proper legal support, expect bureaucracy, and keep your documentation spotless. Do that, and you can go toe-to-toe with the big players while keeping the advantages that make small firms valuable: speed, focus, and high skill.
The Grandfather Trap is the slow erosion of an organisation’s ability to perform essential tasks because long-standing users retain legacy permissions while new users cannot obtain them. Over time, fewer and fewer people can actually do the work.
Explanation
“Grandfathering” is common in sales: long-time customers keep their original pricing as a loyalty perk. In corporate IT, a similar pattern appears with access and permissions.
A group of users who have “always done the job” may hold rights that are now discouraged or outright forbidden such as local admin rights, access to deprecated tools, or exemptions from modern controls. They keep the lights on because those privileges let them work around new constraints. But when new staff join, they can’t get the same rights. Processes and security settings have moved on; the forms have changed; risk appetites have tightened.
Crucially, when those changes were introduced, few had the time, or the courage, to retrospectively remove legacy rights from existing users. Grandfathered users often hold soft power, and if you pull their access and something breaks, the blame lands on the person who removed it. So the path of least resistance wins: change the form for tomorrow, leave yesterday untouched.
This creates a time bomb. People leave, get promoted, or move teams. The population of users who can perform essential functions shrinks until, one day, the last “grandfather” goes, and something critical fails. No one else has the permissions (or the old tool) to fix it. You get a major incident and real financial impact. And because each step towards tighter controls was individually justified, accountability is diffuse, even though the outcome harms the organisation.
Disclaimer: As always these posts are not aimed at anyone client or employer and are just my personal observations over a lifetime of dealing with both management and frontline associates.
One of the core differences I’ve found between the highly technical work I did for most of my career and the more managerial, higher-level work I’ve focused on in the last decade is the need for certifications.
When you’re purely technical, certifications are often slightly looked down on. Think back to the old MCSE days: we’d do boot camps, pass them in droves, and they became less and less relevant. On top of that, so much technical work is done in ways the vendor never intended. Salesforce and IBM are both particularly famous for this.
In integration work I often found ways to do what they didn’t want you to do or to get round things without paying extra. Certifications mattered very little. You went to technical interviews, had proper conversations, and your reputation for solving problems, plus the evidence on places like this blog, proved you were worth the money.
In the managerial space, it’s harder. Almost everyone can talk the hind legs off a donkey. People are very good at making a case because they’ve sold projects and big ideas for years, and they’re used to selling themselves. So when I reviewed my CV (as I do every six months) and asked, “What can I update to show I’m better at my job for a client?”, there wasn’t a great deal I could change. I had more projects under my belt and more experience, of course, but it didn’t give me much I could actually update. Unlike technical roles, much of management has been, frankly, the same for decades, if not centuries.
So what to do? Well, I’ve sounded out clients informally and looked at what potential roles are wanting, and I’ve landed on a list of qualifications, courses, and bits of paperwork I should complete to demonstrate the progression I want to show as an individual and a consultant. Quite a lot of them are stuff I have been actually practicing for many years, so passing should hopefully be a case of phrasing my existing knowledge in the format the examiners want, but some will be genuine learning, and that is always fun.
This post is mainly a line in the sand for me, something I can update over time, but it should also give others an indication of what you might need if you’re heading down a similar path. They are as follows:
