I have worked with LDC and LDC Via for well over a decade now, and it remains my main professional home for the work I do. Like many small companies, however, we are far better at delivering for clients than we are at regularly refreshing our own website.
This time, Ben and his excellent UI skills have once again come to the rescue. He has produced a clean, modern single-page redesign that puts everything front and centre. It covers what clients most commonly ask for, provides clear links to everything else, and does so in a way that is simple, fast and easy to navigate. It is a huge improvement on what we had before.
If you have not already seen it, I would encourage you to take a look at https://ldcvia.com/
For someone who’s been technical for their entire working life and who still sells such skills to clients, it may seem odd that this blog contains so many non-technical posts. The simple answer is that these are the things I think I can help to fix longer term.
A great deal of technical work is largely a question of knowledge, pattern recognition, and experience. Once you have seen the same types of problems often enough, staying current is relatively straightforward 1.
After it is established in each client that you genuinely have been here before and understand the need, working through issues becomes a matter of dealing with one technical problem after another using either the client’s chosen platforms or whichever best-of-breed solution is suitable 2. The path to delivery is usually proven, even if the exact solution is not yet known.
Integration, delivery, and many of the wider challenges around technology don’t work the same way. The difficult part is not the code or the platforms. It is the human behaviour, the organisational design, and the processes wrapped around the technology. Those are the areas where progress is slower, resistance is higher, and inefficiency is often tolerated. They are also the areas where I believe many organisations could make meaningful improvements.
That is why you see so many non-technical posts here. Despite being a geek by preference and by nature, these are the problems I now find that clients find the hardest to resolve.
There will still be plenty of deeply technical material to come, particularly in the new year.
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.
That time has rolled around again when a major client decides to shift direction. In this case, the client has moved to an “internal first” approach in which all projects are by preference run by internal staff rather than consultants or vendors. Part of a rather neat way of upskilling their permanent people.
I have been through this two or three times before. It is an expected part of the corporate life cycle. The challenge is not the decision itself, but how you handle it. Given the nature of what I do and the skillset I have, I am usually involved in several projects at once, each with its own timeline and statement of work. Even though I have been working on multiple projects over the last couple of years for the same global group, they will not all finish neatly at the same time. About half will wrap up at the end of the financial year. but one will carry on for a couple of months beyond that.
This leaves me with only a 50 percent commitment for the first 2 months of 2026. Normally this is not a problem. You simply take on additional clients, join my fellow LDC Via members on other projects, and carry on as any consultancy would. This time is a little different because I have been on call for this particular client for more than a year. Moving back to a restrictive and rigid time allocation could spoil an excellent existing relationship.
So how should I handle it?
In this case, skill development has come to the rescue. Like everyone else, I have been upskilling in AI and related technologies, but the deeper I dug into the true nuts and bolts of its implementation rather than simply jumping on the bandwagon, the more I realised how serious a discipline it really is. AI integration is far more than bolting a chatbot on top of your database. There is an enormous amount of nuance and variance in structure and architecture if you want it to be genuinely useful to a client.
Add a few months of relatively fluid time, and the situation more or less screams “deep dive learning”. Fortunately, there are proper boot camps where you effectively become a developer for a couple of months, work in sprints, and demo at the end of each one. It is an intense way of learning, and the one I have enrolled in and paid for should fill the gaps in the AI knowledge I have identified from my work so far.
It also means I will remain on call for the major client through January and February, giving them the level of delivery they want at the price that suits us both. I get the learning in, and the next client benefits from everything I have picked up.
What surprises me is how new this mindset seems to be for some colleagues. This is not contractor thinking. This is consultancy thinking. You plan ahead by at least three months, build your capabilities, and make sure that for the next engagement you’re stronger than the last.
And on that note, if you are looking for a technical PM or an integration architect at the end of February, do feel free to knock on my door. Or speak to LDC Via and we will see how we can help.
A sneaky little tip for project managers is to try to move your project delivery times to be out of sync with the usual delivery patterns for your organisation.
Most projects tend to aim for the same delivery date, often tied to the end of a large corporation’s financial year, usually December. That seems sensible enough on paper, but in practice, it causes a predictable pain.
In today’s service-oriented infrastructures, where there’s a shared pool of resources, budgets, and dependencies, any delay in one project tends to ripple across the lot. As a result, all the deliveries bunch up at the same time. That’s fine; because as managers and architects we are paid to deal with that kind of thing, but what we often forget is that everyone else is paid to do the same thing at the same time.
The outcome? The last few months of any given financial year are pure mayhem. Every team wants extra time, extra effort, and extra support from all the shared support teams to push their project over the line. Everyone’s pulling on the same people and systems at once.
If I had my way and could get involved right at a project’s inception, I’d always try to schedule its delivery for a quieter time of year, when other projects aren’t all competing for the same shared effort. It’s a small adjustment that I find makes a huge difference to delivery quality, stress levels, and overall sanity in your teams.
