RichardHam.co.uk Blog

Category: Technology

Technology insights and updates

  • When Systems Stop Relying on Guesswork

    A lot of avoidable operational pain comes from one simple source: somebody had to guess.

    They had to guess which model the workflow would choose. They had to guess whether a green dashboard meant the service was actually working. They had to guess how to recover something because the only real runbook lived in one person’s head. They had to guess which version of a draft was the right one to publish.

    That is a small sentence with expensive consequences.

    In my experience, many reliability problems are not caused by one dramatic bug. They come from layers of ambiguity that were tolerated because the system appeared to work often enough. The workflow usually picked the expected path. The dashboard was usually telling the truth. The operator usually remembered the recovery sequence. The content pipeline usually published the right version.

    Usually is not a safe operating model.

    Where the friction really sits

    The obvious failure is the outage. The more common failure is ambiguity that keeps making the whole stack harder to trust.

    Routing decisions

    If a system can choose between providers, models, or execution paths, then the decision logic needs to be durable and visible. Otherwise behaviour changes by accident.

    That is how teams end up with a platform that feels inconsistent even though each individual component is technically healthy. One person thinks the cheap path is the default. Another thinks the reliable path is. A third assumes the fallback only applies in a timeout case. None of that is a software problem at first. It is a policy problem.

    The fix is rarely glamorous. Write the rule. Keep it near the implementation. Make it obvious what happens first, what happens second, and what happens when the preferred path fails.

    Monitoring that tells the truth

    There is a big difference between “the process is running” and “the service is working”.

    A healthy-looking process table can still hide a broken dependency, a dead API path, a stale token, or an empty data plane. If the check only proves that something is listening on a port, it is not telling the operator what they actually need to know.

    Useful monitoring is usually the boring kind. Does the real workflow respond, with the right output, in the way the operator expects? Can someone tell whether a fallback fired? Can they see whether the service remained functionally correct rather than merely alive?

    If not, the dashboard is decoration.

    Recovery and repeatability

    A lot of infrastructure looks solid right up until someone else has to operate it.

    That is where repeatable recovery paths matter. Clear defaults. Known fallbacks. A documented sequence for fixing the obvious failure modes. The point is not to eliminate human judgement. The point is to stop every incident from turning into archaeology.

    Runbooks, checklists, and decision notes are not admin overhead for serious systems. They are part of the product if the product has to survive handover.

    Publishing discipline

    This applies to content as much as infrastructure.

    If the publishing path is fuzzy, you get duplicate posts, mismatched versions, archive drift, and copy that sounds assembled rather than written. That is not only a branding issue. It is the same operational problem wearing different clothes.

    The draft, the review step, the canonical source file, and the final publish target all need to be explicit. Otherwise the system eventually ships the wrong thing.

    Why AI multiplies the cost of ambiguity

    AI and automation raise the stakes because they convert vague process into machine-speed inconsistency.

    When a human operator is doing everything manually, weak process often shows up as wasted time. When workflows start routing, deciding, and acting on their own, the same vagueness becomes a production risk. The system can now repeat the wrong assumption quickly, quietly, and at scale.

    That is why I keep coming back to the same standard:

    • if it matters, write it down
    • if it repeats, make it reusable
    • if it can fail, define the fallback
    • if it is monitored, test the real behaviour
    • if it is published, keep one clear source of truth

    None of that is flashy. All of it matters.

    The useful kind of progress

    The best weeks are not always the dramatic ones.

    Sometimes the real progress is a tighter routing rule. A dashboard that finally reflects reality. A recovery path that no longer depends on memory. A publishing workflow that stops sending the wrong version into the public archive.

    That kind of work rarely looks exciting from the outside. It just makes the system calmer, safer, and easier to trust.

    And in practice, that is often the difference between something that demos well and something that survives production.

    If you want help turning AI or automation from a pile of moving parts into an operating model people can actually trust, start with AI & Automation Architecture or get in touch.

  • Release Readiness Starts Small

    Release readiness is one of those phrases people tend to associate with major milestones. A big launch. A freeze window. A final pre-production review. In reality, most release readiness work starts much earlier and looks much less dramatic.

    It usually begins with the boring choices teams make while nothing appears to be on fire.

    That is when dependency drift gets handled before it turns into surprise breakage. That is when decision records are written before the rationale disappears. That is when logs, checklists, and ownership lines are tightened while there is still time to do it calmly.

    By the time a release feels stressful, the underlying maintenance decisions have usually already been made.

    Drift is rarely dangerous all at once

    Dependency drift does not normally announce itself as a crisis. It accumulates.

    One package lags a little behind. A toolchain bump gets deferred because it is inconvenient. A warning sits in CI because it is noisy rather than urgent. A config difference between environments becomes accepted because nobody wants to touch it this week.

    Individually, each decision can feel reasonable.

    Collectively, they change the character of the next release.

    Suddenly the team is not just shipping a feature. It is shipping a feature while also discovering which old assumptions have quietly expired.

    That is why I think release readiness starts with maintenance discipline rather than ceremony. If the stack is allowed to drift without a conscious limit, the release process becomes a gamble disguised as a plan.

    Governance makes releases cheaper

    People sometimes hear the word “governance” and assume it means slowing things down. Bad governance does. Useful governance does the opposite.

    Useful governance reduces rediscovery.

    A lightweight decision record, a clear runbook note, or a short changelog entry can save a team from re-litigating the same question under deadline pressure. It is much easier to release calmly when the important context is already captured.

    That does not mean documenting everything. It means documenting the parts that would otherwise have to be guessed later:

    • why a dependency was pinned or deferred
    • which path is considered the supported one
    • what the fallback looks like if the preferred route fails
    • which checks count as real release verification
    • who owns the decision when the evidence is mixed

    Without those anchors, “release readiness” often becomes a frantic search for institutional memory.

    Verification needs to reflect live behaviour

    Another trap is treating pre-release verification as a box-ticking exercise.

    A test passing in isolation is useful, but it does not prove that the live behaviour matches the intent of the release. A service can be technically up while still being operationally wrong. A workflow can complete while routing work through the wrong path. A published change can deploy cleanly while still leaving the user-facing result inconsistent.

    That is why the best release checks are usually the least theatrical ones. They ask plain questions:

    • does the thing work from the outside?
    • did it use the expected route?
    • do the logs and outputs make sense together?
    • would another operator understand what happened from the artefacts alone?
    • if rollback is needed, is the sequence already known?

    Those checks do not make the process glamorous, but they make it credible.

    Small maintenance work changes the feel of a release

    You can often tell how ready a team really is by how the release conversation sounds.

    When the groundwork has been done, the language is calm. People are checking, confirming, and verifying.

    When it has not, the language becomes speculative:

    • “I think this should still be compatible.”
    • “We can probably fix that after deploy.”
    • “I’m not sure which version is on the live path.”
    • “That alert is usually harmless.”
    • “Let’s ship it and see.”

    That is not a release strategy. It is unresolved maintenance debt surfacing at the worst moment.

    The teams that avoid that pattern are not necessarily the most resourced. They are usually the ones that kept chipping away at the small corrections before the release window forced urgency onto everything.

    What I would tighten first

    If I wanted to improve release readiness without adding unnecessary process, I would start with a short list:

    1. Reduce unmanaged drift

    Know which dependencies, config deltas, and environment differences are tolerated and which ones are not.

    2. Write down the decisions that matter

    Especially the ones that affect supported paths, rollback logic, or verification expectations.

    3. Test the live outcome, not just the local command

    A clean build is not the same thing as a trustworthy release.

    4. Keep the rollback path boring

    If recovery depends on improvisation, the release is not actually ready.

    5. Make ownership obvious

    If something looks ambiguous during release, someone should know who decides.

    Readiness is a maintenance habit

    That is the real point. Release readiness is less a milestone than a maintenance habit.

    It comes from keeping the stack current enough to trust, the decisions visible enough to follow, and the verification honest enough to mean something. Teams that do that consistently make releases feel uneventful in the best possible way.

    And that is usually the goal. Not excitement. Predictability.

    If you are trying to make releases calmer by improving the operating model underneath them, the AI & Automation Architecture work covers exactly that kind of practical governance and delivery design. Or get in touch if you want help identifying where drift, ambiguity, or weak verification is making your next release harder than it needs to be.

  • The Case for Explicit Policies

    Reliable systems do not emerge from good intentions. They emerge when the rules are explicit enough that another operator can understand what the system is supposed to do without reverse-engineering its behaviour from the wreckage.

    That sounds obvious, but it is still one of the most common gaps I see in automation and AI work. Teams build the workflow, connect the services, and get something working end to end. Then they leave the important decisions half-stated. Which provider is preferred? When should the fallback fire? What counts as a real health check? Which version of a process note is authoritative? The system may run, but the operating model is still fuzzy.

    The problem is not that people are careless. It is that policy work often looks less urgent than delivery work. Until something breaks, the invisible rule feels good enough.

    Where ambiguity shows up first

    The first place ambiguity appears is usually routing.

    A stack with multiple models, providers, queues, or execution paths always contains policy whether the team writes it down or not. If the preferred provider is too expensive for low-value tasks, that is policy. If one model is allowed for drafting but not for final output, that is policy. If a workflow should fall back only on timeout and not on quality failure, that is policy too.

    When none of that is written down clearly, people start inferring intent from whatever happened last.

    That is how teams end up with arguments that sound technical but are really operational:

    • “I thought the cheaper path was the default.”
    • “I assumed the fallback only applied during outages.”
    • “I didn’t realise this job was meant to stay on the private model.”
    • “I thought the dashboard alert meant the workflow had already rerouted.”

    None of those are bugs in isolation. They are symptoms of unstated policy.

    Why observability is part of policy

    The same issue appears in monitoring.

    A lot of dashboards tell you that a process is alive. That is not the same as proving the service is doing the right thing.

    For AI and automation systems, a truthful check usually needs to answer something more useful:

    • did the workflow complete the task it was supposed to complete?
    • did it use the intended path?
    • did it return data that looks structurally valid?
    • did the fallback stay dormant when the primary path was healthy?
    • can the operator see enough detail to explain the outcome afterward?

    If the check cannot answer those questions, the dashboard may still be visually tidy, but it is not giving the operator what they need.

    This is why I think observability should be treated as policy, not just instrumentation. The team has to decide what “working” actually means. Otherwise the monitoring layer simply reflects a vague assumption instead of a deliberate standard.

    Reuse is how policy survives handover

    The other quiet benefit of explicit policy is reuse.

    If a team has to rediscover the same routing rule, the same rollback sequence, or the same publishing checklist every time, then the policy is not really part of the system yet. It still lives in memory.

    That is expensive in a small team and dangerous in a growing one.

    Good reuse does not have to be elaborate. Often it is just a set of plain habits:

    • keep one canonical source of truth for important workflows
    • write fallback conditions near the implementation
    • keep short runbooks for the obvious failure modes
    • use the same naming and review patterns across similar jobs
    • record decisions before context evaporates

    None of that feels exciting while you are doing it. But it changes the quality of handover completely. A new operator no longer has to absorb the entire history of the stack before they can act safely.

    What explicit policy looks like in practice

    In practical terms, I look for a few simple signals.

    1. The preferred path is obvious

    The system should make it clear what happens first, what happens second, and under which conditions the fallback is allowed to take over.

    2. The checks reflect user reality

    A green dashboard should mean more than “something is listening on a port”. It should tell the operator whether the real job still works.

    3. Recovery paths exist before the incident

    If the first time a team documents the rollback sequence is during a failure, the policy work happened too late.

    4. Repeated patterns are actually reusable

    If the same kind of workflow appears three times, there should be a shared pattern instead of three slightly different tribal versions.

    Why this matters more with AI systems

    AI systems raise the cost of ambiguity because they turn a fuzzy rule into machine-speed inconsistency.

    In a manual process, unclear policy wastes time. In an automated one, it can silently change outputs, route work to the wrong provider, or create a trail that is too vague to audit later.

    That is why I think trustworthy AI is less about magic prompts and more about explicit operating rules.

    If the rules matter, write them down.

    If the outcome matters, check the real behaviour.

    If the workflow repeats, make it reusable.

    That does not make the system flashy. It makes it dependable.

    And in production, dependable usually wins.

    If you are building automation that needs to survive handover, escalation, and real operational scrutiny, the AI & Automation Architecture work is designed for exactly that. Or get in touch if you want a second pair of eyes on the operating model before the ambiguity becomes expensive.

  • What Real Delivery Discipline Looks Like

    A lot of teams say they care about security and reliability. Fewer teams build delivery habits that prove it.

    That difference matters more than most strategy decks admit. Hardening work is easy to describe in principle. Everyone agrees that authentication should be stronger, fallbacks should be safer, and monitoring should be more truthful. The real question is whether those concerns are allowed to shape the delivery path itself.

    If they are not, the system ends up with good intentions and brittle behaviour.

    Hardening is not a final polish step

    One of the most persistent delivery mistakes is treating hardening as something that happens after the “real” build is done.

    In practice, the opposite is true. Security-sensitive choices usually need to be made while the implementation is still taking shape:

    • what credentials are allowed to reach which component
    • what action is taken when verification fails
    • whether a degraded path is acceptable or whether the job should stop
    • what evidence an operator needs before calling something healthy
    • how much trust the system gives to generated output by default

    Those are not edge details. They shape the behaviour of the whole stack.

    If the hardening conversation starts only once the workflow is already live, the team ends up retrofitting controls around assumptions that were never designed for scrutiny.

    Monitoring has to be able to disagree with the diagram

    A good architecture diagram can still hide a weak operating model.

    I see this most often in monitoring. Teams build checks that confirm whether the process is running, but not whether the real task is succeeding in a meaningful way. That produces the worst kind of comfort: the dashboard looks clean while the system is quietly failing at the thing that matters.

    Useful monitoring needs to be willing to contradict appearances.

    For example, I would rather know that:

    • the workflow completed but returned structurally bad output
    • the service stayed up but fell onto the wrong provider path
    • the API responded but the downstream data plane was empty
    • the fallback recovered execution but created a lower-trust result

    That kind of signal is less glamorous than a green uptime chart, but it is far more useful when somebody has to operate the platform at speed.

    Delivery discipline is mostly about reducing hidden surprises

    The phrase “delivery discipline” can sound heavier than it needs to. I do not mean process theatre. I mean building a path to change that does not rely on luck.

    In practical terms, the teams that do this well tend to share a few habits:

    They make verification part of the job

    A change is not finished because the command returned zero. It is finished when the operator can show that the intended behaviour is visible from the outside.

    They do not improvise every rollback

    If a deployment path matters, the recovery path should already exist before the incident.

    They keep release logic legible

    The more a release process depends on one person remembering unwritten exceptions, the less mature it is.

    They distinguish activity from progress

    A lot of work can happen in a sprint without improving the trustworthiness of the system. Good delivery discipline asks whether the change made the operating model clearer, safer, or easier to verify.

    Why this matters in AI and automation work

    Automation makes weak delivery habits more expensive because the system can now repeat them at scale.

    If a manual operator makes one bad judgement call, the damage is limited. If the workflow itself contains vague trust boundaries, shallow health checks, or unclear fallback rules, the same weakness can repeat every minute.

    That is why I treat discipline as a feature.

    Not in the moral sense. In the architectural sense.

    A disciplined delivery path gives the team:

    • safer defaults
    • clearer escalation points
    • more credible monitoring
    • easier handover between operators
    • fewer silent regressions

    That is not bureaucracy. It is what makes the rest of the system believable.

    What I would check first

    If I am assessing whether a delivery process is genuinely disciplined, I usually start with a small checklist:

    • are the trust boundaries obvious?
    • does the monitoring test real behaviour or just process existence?
    • can somebody explain the fallback path without guessing?
    • is there a documented way to verify the live result after a change?
    • would another operator know what “healthy” means from the artefacts alone?

    If the answer to those questions is mostly “not yet”, then the team probably does not have a tooling problem. It has a delivery-discipline problem.

    The good news is that this is fixable. Most of the gains come from clearer defaults, sharper verification, and a willingness to treat operational trust as part of the design instead of a layer you add afterward.

    That work is rarely flashy. It just means the system behaves like something serious.

    If your stack needs stronger delivery discipline around hardening, observability, or AI workflows, the AI & Automation Architecture and Security Strategy work is built around exactly those problems. Or get in touch if you want a practical review of where the delivery path is still carrying too much guesswork.

  • When Maintenance Starts to Look Like the Product

    One of the clearest signs that a system is growing up is that the most important work stops looking dramatic.

    There is less fascination with launch theatre and more attention on maintenance, review discipline, dependency hygiene, documentation, recovery paths, and the quiet operational habits that make future change cheaper than past change.

    From the outside, that can look unexciting. From the inside, it is often the moment the product becomes believable.

    Maintenance is where trust becomes visible

    Early-stage work is usually easy to narrate. New feature. New workflow. New integration. New capability.

    Maintenance work is harder to sell because it rarely produces a neat headline. But it is where a team proves whether it is building something durable or simply accumulating demonstrations.

    If the documentation sharpens, the dependency stream stays current, the review process gets clearer, and the operational logs start forming a usable trail, those are not background chores. They are evidence that the system can survive repetition.

    That matters because most real-world products do not fail during the polished demo. They fail during handover, under load, during maintenance, or when somebody new has to operate them without the full story.

    Governance is not separate from delivery

    A lot of teams treat governance as a separate lane from product work, as though it begins after the useful engineering is finished.

    I think that is backwards.

    Governance is simply the part of delivery that reduces ambiguity for the next decision. It is what turns one-off effort into something that can be inspected, repeated, and improved.

    That can show up in small ways:

    • proposal scoring that makes prioritisation legible
    • review guidance that reduces inconsistent judgement
    • issue tracking that records blockers instead of burying them in chat
    • branch hygiene that makes the delivery path safer
    • run logs that explain what changed and why

    None of that steals time from the product. In mature systems, it becomes part of the product because it changes the cost and risk of every future change.

    The product is bigger than the feature set

    This is the shift many teams eventually have to make.

    The product is not only the visible interface or the raw capability. It is also the collection of operating properties that determine whether the capability can be trusted. Can another operator pick it up? Can a failure be explained? Can a dependency be updated without drama? Can the next release happen without rediscovering everything from scratch?

    Once you ask those questions seriously, maintenance stops looking secondary.

    A healthy maintenance pattern normally improves at least one of these:

    • repeatability
    • auditability
    • reversibility
    • ownership clarity
    • change safety

    If the work improves none of those things, it may be motion without much payoff. But when it does improve them, it is absolutely product work.

    The hidden cost of pretending maintenance is optional

    Teams that down-rank maintenance tend to pay for it later in awkward ways.

    A roadmap becomes harder to trust because the underlying stack drifts. Delivery gets slower because every change has to rediscover old context. Incidents become more expensive because the recovery path is still tribal knowledge. Content and documentation diverge because nobody kept a canonical source of truth.

    None of that feels catastrophic at first. It just makes every subsequent piece of work more fragile.

    That is why mature engineering groups often sound calmer, not louder. They know that the best way to speed up later is to reduce the amount of avoidable uncertainty now.

    What good maintenance work usually has in common

    When maintenance is genuinely improving the system rather than just consuming time, I usually see a few shared characteristics.

    It leaves a clearer trail

    The next operator can understand what happened without interviewing the previous one.

    It reduces future decision cost

    A known pattern, documented rule, or reusable checklist means the same problem will be cheaper next time.

    It makes failures less mysterious

    Even when something still goes wrong, the team has better evidence and a cleaner path to recovery.

    It protects momentum instead of slowing it

    Strong maintenance work makes future delivery easier because the underlying operating model is less chaotic.

    Why this matters so much in automation and AI

    Automation magnifies both good and bad maintenance habits.

    If the workflow is opaque, poor maintenance leaves you with a black box that degrades quietly. If the workflow is well-governed, maintenance turns it into something operators can trust, audit, and extend without guessing.

    That is one reason I think governance, maintenance, and documentation matter more as systems become more autonomous. The machine may be doing more of the execution, but the human still has to understand the operating model well enough to own the outcome.

    That is impossible if maintenance has been treated as optional admin.

    The real signal of maturity

    The real signal of maturity is not that a team has stopped building. It is that the team has started building in a way that leaves the environment safer for the next change.

    That often looks like better maintenance because that is what it is.

    Not glamorous. Not particularly marketable on its own. But essential.

    And once a product reaches that stage, the maintenance work does not sit behind the product. It becomes one of the reasons the product is worth trusting in the first place.

    If you are trying to make systems easier to run, safer to change, and less dependent on tribal memory, the AI & Automation Architecture work is built around exactly that operating model. Or get in touch if you want help turning maintenance, governance, and delivery discipline into an actual advantage rather than a recurring source of drag.

  • The Hidden IT Debt That Kills Deal Value

    The Hidden IT Debt That Kills Deal Value

    If you’re preparing for a transaction, the technology side of diligence is one of the few places where a couple of weeks of work can move the price by hundreds of thousands of pounds. Almost every founder I’ve worked with through a sale has discovered the same thing: the IT debt they thought was tolerable was visible to the buyer’s diligence team and got used as leverage.

    This post is the version I wish more founders saw twelve months before the process starts. It’s a list of the categories of technology debt that consistently show up in due diligence and consistently move price.

    Unsupported Software in Production

    This is the single most common finding. An old database version, an unsupported operating system on a key server, a desktop app that hasn’t been updated in years, a finance system on a release the vendor stopped patching three years ago.

    To the buyer this signals two things. First, an immediate cost they’ll have to absorb to bring you onto a supportable footing. Second, evidence that operational hygiene isn’t a strength — which raises questions about everything else.

    The fix is usually not exciting. Inventory what you have, identify everything outside support, and either upgrade, replace, or document a deliberate compensating control. The work isn’t hard; it’s that nobody’s been paid to do it. Twelve months out from a sale is the right time.

    Identity and Access Sprawl

    Diligence teams routinely pull a list of accounts with administrative privileges across your core systems. The list is almost always longer than expected, and it almost always includes:

    • People who left the business months or years ago
    • Service accounts with admin rights and no clear owner
    • Shared accounts where the password is in someone’s notes
    • Personal email addresses still tied to systems
    • Vendors and ex-vendors with access nobody has revoked

    A buyer reads that list and sees risk. Specifically, they see that an attacker who compromises any one of those accounts has admin reach across the estate.

    The corrective work is straightforward — a structured access review, removal of dormant accounts, mandatory MFA on what remains, separation of normal-user and admin identities — but it takes time to do properly. Done in a panic during diligence, it raises more questions than it answers.

    Single Points of Failure

    Every business has a few. The contractor who set up the original infrastructure and has the only credentials. The one engineer who knows how the data warehouse actually works. The single internet line at the head office. The cloud account that’s billed to a personal credit card. The third-party processor your operations cannot function without.

    Buyers don’t expect zero of these. They expect them to be documented, with mitigation in flight. What kills value isn’t the existence of dependencies — it’s the discovery that nobody has thought about them.

    The fix is partly technical (redundancy, secondary suppliers, properly owned cloud accounts) and partly documentation. Mostly it’s documentation. A diligence team is far less concerned about a single supplier dependency that you’ve identified, scoped, and have a plan for than they are about one they’ve found you didn’t know existed.

    Audit and Compliance Gaps

    If you process customer data — and almost every business does — your UK GDPR position will be reviewed. So will your security controls against any framework you’ve claimed: Cyber Essentials, ISO 27001, SOC 2. Buyers will check that your claims match reality.

    Common findings:

    • Records of processing that haven’t been updated in years
    • Data Protection Impact Assessments that don’t exist for systems where they should
    • A Cyber Essentials certificate from two years ago, with the controls now lapsed
    • Audit logs that aren’t actually being retained
    • A list of subprocessors that doesn’t match the systems in production

    Each of these is a moderate fix in isolation. Together they paint a picture of compliance theatre, and that picture is hard to repair under deal-team pressure. The right time to look at this is when you have months, not days.

    Patching and Vulnerability Backlog

    Most diligence engagements I’ve been part of include a vulnerability scan or, at minimum, a request for evidence that one has been done recently. The result almost always includes a tail of unpatched vulnerabilities that have been accumulating quietly.

    What raises the buyer’s concern isn’t the existence of vulnerabilities — every estate has them. It’s the absence of a process that systematically tracks, prioritises, and resolves them. If your IT manager or MSP can’t produce a patching SLA and evidence that it’s being met, the buyer will assume the worst.

    A defensible patching position takes a few months to establish. You need an inventory, a prioritisation method, an SLA your team can actually meet, and the evidence that proves it. None of this is technically complex. All of it takes time.

    Cloud Cost and Architecture Surprises

    If you’re running on AWS, Azure, or GCP, the buyer’s team will look at three things: what you’re spending, whether the architecture is appropriate to that spend, and whether you have any commercial commitments (Reserved Instances, Savings Plans, Enterprise Discount agreements) that affect the post-deal economics.

    Common findings:

    • Tens of thousands of pounds a month going to over-provisioned compute or unused storage
    • Architecture decisions made early that no longer fit the business
    • Multi-year commercial commitments that lock the new owner in to a specific spend pattern
    • A cloud bill split across multiple accounts and personal cards with no clear ownership

    This is one of the easier categories to address pre-deal — a competent cloud architect can produce a remediation plan in a couple of weeks. But it has to be done before the buyer’s team finds it, because once it’s in their report, the saving is theirs to negotiate, not yours.

    Vendor Contracts and Lock-In

    Buyers will read your major technology contracts. They look for auto-renewal clauses that have just triggered, change-of-control provisions that require vendor consent, multi-year commitments at above-market rates, and termination penalties that affect the integration plan.

    Surprises here are particularly painful because they affect the buyer’s post-completion options, not just the price. A discovered change-of-control clause requiring a key supplier’s consent can delay or even block the deal entirely.

    The fix is contract-by-contract: a structured review of your top vendor agreements, identification of the issues, and either renegotiation or clear documentation. This is unglamorous work that founders generally don’t want to spend money on. The pre-sale period is the moment when it pays for itself many times over.

    What Pre-Sale Cleanup Actually Looks Like

    The pattern across all of these is the same. Each finding, taken alone, is fixable in a few weeks. The problem is that there are usually six or seven of them, they all need somebody senior to triage and prioritise, and the actual remediation involves coordination with internal teams, MSPs, vendors, and lawyers.

    A useful pre-sale technology engagement is typically two to four months of part-time work, starting twelve to eighteen months out from the process. The output is:

    • A clear inventory of the technology and security position
    • A prioritised list of findings that would matter to a diligence team
    • A realistic remediation plan with effort and cost
    • Resolution of the highest-risk items before the data room opens
    • Documentation that turns the remaining items from surprises into footnotes

    What you’re buying with that engagement is a much better starting point for the diligence conversation. The buyer’s team will still find issues — they always do. The difference is that they’re issues you’ve already identified, scoped, and either fixed or explained. Which means the conversation in the negotiation room isn’t should we adjust the price, it’s we agree this is in flight.

    If you’re a founder twelve months out from a planned sale, or a fund-side advisor preparing a portfolio company for exit, this is the right time to look at the technology position. The cost of doing it now is small. The cost of having it found in someone else’s report is not.

    If you’re preparing a UK business for sale and want a clear read on the technology position before the data room opens, this is the kind of work I do. The full description is on the Technical Transformation & M&A service page, and the private-equity sector page covers the buy-side and portfolio engagements. Or just get in touch for a 30-minute conversation.

  • What Is a Fractional IT Director and When Do You Need One?

    What Is a Fractional IT Director and When Do You Need One?

    Most growing businesses hit a point where “the IT person” isn’t enough — but a full-time IT Director isn’t quite justified either. That gap is where a Fractional IT Director makes sense.

    This post explains what the role actually is, how it differs from the alternatives, and the four situations where it consistently delivers the most value.

    What a Fractional IT Director Is

    A Fractional IT Director is a senior technology leader who works with your business on a part-time basis — typically one to three days a week, or a fixed monthly retainer. They take accountability for your technology function in the same way a permanent IT Director would, but without the full-time cost or the commitment of a permanent hire.

    The “fractional” model works because the skills you need — strategic technology planning, vendor management, digital transformation leadership, board-level communication — don’t require someone present five days a week. What they require is the right level of seniority and genuine accountability, applied at the right moments.

    A Fractional IT Director is not a consultant who gives you a report and disappears. They’re part of your leadership team, attending management meetings, owning the technology roadmap, and making decisions. The distinction matters because accountability is what you’re actually buying.

    How It Compares to the Alternatives

    Versus a full-time IT Director

    A permanent IT Director in the UK costs £80,000–£140,000 in salary, plus employer NI, pension, benefits, and recruitment fees. All-in, you’re typically looking at £110,000–£180,000 per year before you’ve accounted for notice periods, management time, and the risk of a bad hire.

    A fractional engagement at two days a week costs roughly a third of that. For most businesses under 200 people, the fractional model delivers the same strategic output at a fraction of the cost — because the strategic work doesn’t fill five days a week at that scale.

    Versus an MSP (Managed Service Provider)

    An MSP keeps your systems running. They manage your infrastructure, handle your helpdesk, patch your software, and respond when things break. That’s operations, not leadership.

    An MSP does not set your technology strategy. They don’t challenge your business on whether your current systems are the right ones for where you’re going. They don’t prepare you for an acquisition, challenge a supplier on contract terms, or give your board a view of technology risk. That’s what an IT Director does.

    The two roles are complementary, not interchangeable. Many businesses I work with have a good MSP and no IT leadership — the MSP is doing operational work well, but nobody is asking the strategic questions.

    Versus a project consultant

    A consultant is typically hired to deliver a specific, defined outcome — implement a new system, run a migration, deliver a security audit. The engagement ends when the project ends.

    A Fractional IT Director is an ongoing role with ongoing accountability. They’re not there to deliver a project; they’re there to lead the function. The difference becomes obvious when something unexpected happens. A project consultant is scoped to their deliverable. A Fractional IT Director is responsible for the technology estate in totality.

    Four Situations Where It Consistently Makes Sense

    1. You’ve outgrown your current IT setup but you’re not ready to hire

    Your business has grown. You have 50, 80, 120 people now. The IT that worked when you were 20 people isn’t keeping pace. Systems are patched together. Decisions are being made reactively. The person who “manages IT” is overwhelmed and operating without a strategy.

    You need someone to assess what you have, build a credible roadmap, and start making decisions — but you’re not yet at the scale where a full-time hire makes financial sense. A Fractional IT Director bridges that gap. They give you the leadership now, while the business continues to grow toward the point where a permanent hire becomes justified.

    2. You’re going through a period of significant change

    Acquisition. Merger. Rapid headcount growth. Office consolidation. Major new customer win that requires you to operate differently. These transitions put pressure on technology infrastructure in ways that aren’t always visible until something breaks.

    Technology change during business change requires senior leadership, not just good execution. Someone needs to be asking: what does our IT estate need to look like in 18 months, and are the decisions we’re making today consistent with that? That’s a Fractional IT Director’s job.

    3. You’re a PE-backed business without a technology leader

    Private equity portfolio companies often sit in an uncomfortable position — expected to operate with discipline and demonstrate progress, but not always structured to have senior technology leadership in place. IT gets managed by the CFO, the COO, or whoever happens to be technically literate.

    A Fractional IT Director fits the PE model well. They can operate across multiple portfolio companies, bring consistency to governance and reporting, and provide the oversight a portfolio board expects — without inflating the headcount cost structure of each individual business.

    4. You’re preparing for a transaction or exit

    Technology due diligence is a serious process. Buyers and their advisors will review your infrastructure, your security controls, your vendor contracts, your data management practices, and your ability to continue operating without key-person dependencies.

    Businesses that go into a process without technology leadership in place frequently discover gaps that cost them at the negotiating table — price chips, extended warranties, deferred consideration. A Fractional IT Director with experience of M&A processes prepares you on your own timeline, not the buyer’s.

    What the Engagement Actually Looks Like

    Most fractional engagements start with an assessment. Before we agree a retainer structure, I need to understand your current state — what you have, what the gaps are, and what the priorities should be. That typically takes two to three days and produces a clear picture of where to focus.

    From there, a typical engagement involves a fixed monthly commitment: attending your leadership meetings, owning the technology roadmap, overseeing your IT team or MSP, managing major vendor relationships, and being available when something needs a senior decision.

    The monthly commitment scales with complexity. A simpler business might need two days a month for strategic oversight and governance. A business going through a cloud migration or a major platform change might need two days a week for a defined period.

    The honest version: you’re paying for someone who is accountable for your technology, not just available to advise on it. That accountability is what makes the model work.

    If you’re trying to work out whether a Fractional IT Director is the right move for your business, the Fractional CTO / IT Director service covers how I work in more detail. Or if you’d rather just have a direct conversation, get in touch — I’ll tell you honestly whether I can help.

Powered by