Josh DargieInfrastructure · Cloud · Software

Blog / vendors

Managing IT vendors when you're not technical

You don't need to understand the technology to manage IT vendors well. You need written scope, one accountable name, and exit terms.

Plenty of business owners tell me some version of the same worry: "I can't manage my IT company because I don't understand what they do." I think that gets it backwards. You don't manage an IT vendor with technical knowledge; you manage them with the same tools you'd use on a contractor renovating your building. Clear scope, one accountable name, proof of work, and a clean way out. You already know how to do all four.

Here's what each one looks like when the trade happens to be technology.

If it isn't written down, it isn't agreed

Most vendor disputes I get asked to referee have the same root: the scope lives in somebody's memory of a phone call. The vendor believes they're maintaining "the server." You believe they're maintaining "the IT." The gap between those two sentences is where outages, surprise invoices, and finger-pointing live.

You don't need to write anything technical. A single page in plain language does it: what systems are covered, what "supported" means for each, how fast they respond to what kind of problem, what's included in the monthly fee, and what costs extra. If a vendor resists putting that on paper, that resistance is the most useful information you'll get from them. Vague scope always resolves in the vendor's favour, and I made the same point about builders and installers in project scoping: the cheapest time to argue is before the work starts.

One name owns the outcome

When email breaks, the email vendor blames the domain company, the domain company blames the internet provider, and you spend a day as an unpaid switchboard operator between three help desks.

The fix is structural. One vendor, named in writing, owns "it works end to end" for each area, including chasing the other parties when the fault is theirs. Fewer vendors generally beats cheaper vendors for exactly this reason. And if nobody on your side owns the relationship, appoint someone, even part-time; I've written before about when that turns into a first IT hire, but long before that point it's just a named person who reads the invoices and holds the list of what you own.

Documentation is a deliverable, not a favour

Here's the test I give every business owner: if your IT vendor vanished tomorrow, could the next one take over from what you hold in your own hands?

For most small businesses the honest answer is no. The passwords, the network diagram, the list of what renews when, the domain registrar login: it all lives with the vendor. That arrangement is dependency dressed up as convenience, and it quietly converts "we're unhappy but it works" into "we can't afford to leave."

So make documentation a paid, scheduled deliverable, in the contract, reviewed yearly. Admin credentials in your custody, an inventory of accounts and licences and renewal dates, and a one-page map of how your systems connect. A good vendor already has most of this and will hand it over without drama. A vendor who bristles at the request is telling you what the exit will be like.

Negotiate the divorce while you're still friends

Every vendor relationship ends eventually: they get acquired, their service slides, you outgrow them. The time to set the terms of the ending is at the start, when everyone's agreeable.

Three things belong in writing before you sign. Notice periods that are symmetrical and short, measured in weeks, not a year of auto-renewed lock-in. A handover clause: on exit, they provide credentials, data exports, and reasonable transition help at a stated hourly rate. And confirmation, in plain words, that your data, your domain names, and your licences are registered to your business, not to them. Owners are always surprised how often that last one fails; losing your domain to a former vendor is a far worse outcome than any bill.

You can hold the clipboard without holding a screwdriver

None of this requires you to learn what a VLAN is. It requires scope on paper, one accountable name, documentation you physically possess, and exit terms agreed in advance. Vendors respect clients who run things this way, and frankly, the good vendors prefer them.

If you'd rather have someone technical on your side of the table, that's what my fractional CTO arrangement is for: a few hours a month reviewing the invoices, the scope, and the vendors' homework, with no products to sell you and no side to take but yours.

← All posts

Start with a conversation

Thirty minutes, no charge, no pitch.

Tell me the problem. I'll tell you whether I'm the right person for it, and if not, who is.