A confession I hear a lot
"I don't understand this stuff." Owners of companies that bill millions say it, people who manage teams of 30, who negotiate with banks and suppliers without blinking. And they say it with a certain embarrassment, as if it were a flaw.
It isn't. You don't have to understand technology to lead your company's technology well, just as you don't have to be an accountant to read a balance sheet or a lawyer to sign a contract. You have to know what to ask, which answers are good, and when someone is selling you smoke.
That can be learned. And it's shorter than it seems.
What you do have to decide yourself (and nobody else)
There are four decisions you can't delegate, because they're business decisions, not technical ones:
1. What problem you want to solve. "We lose quotes because nobody follows up." "It takes us three days to reply to a customer." "I don't know what I'll bill next month." You know this better than anyone. A provider who starts talking technology before understanding your problem is heading the wrong way.
2. What solving it is worth. If quote follow-up costs you €5,000 a month, solving it is worth up to €30,000. If it costs you €300, it's worth €2,000. This figure sets the budget, and only you have it.
3. What risk you accept. Can a system email customers without anyone reviewing? Can it apply discounts? Can it access accounting? Every company has its threshold. Decide it before, not after the first scare.
4. Who is in charge. Someone in your company has to be the point of contact. Not a technician; someone who knows the business and has authority to decide. If nobody is in charge, nothing moves.
The questions to ask any provider
These are the ones I'd ask if I were in your shoes. And the ones I answer, unprompted, for every client:
"What concrete problem does this solve and how will we measure it?" If the answer is vague ("it improves efficiency", "it digitalizes your company"), be wary. If it's concrete ("it cuts response time from 2 days to 5 minutes, and we'll measure it like this"), good.
"What happens when this fails?" Everything fails at some point. A good provider has a plan: who fixes it, how fast, at what cost. A bad one tells you it won't fail.
"Who owns what you build?" The code, the access, the accounts, the data. They have to be yours. If you depend on the provider to access your own system, you have a serious problem the day the relationship sours.
"What does year two cost?" Licenses, maintenance, updates, support hours. The implementation price is half the story.
"Can I talk to a client of yours who did something similar?" The answer should be yes, without hesitation.
"What won't you do?" A serious provider has clear limits and tells you. One who says yes to everything either doesn't know or will disappoint you.
The most reliable sign of a good technology provider: they explain things in terms of your business (time, money, customers, risk) and not in terms of technology. If you leave a meeting without understanding what was proposed, the problem isn't you.
How to read a proposal without being technical
When a quote lands, look for these five things. If any is missing, ask for it before signing:
- The problem it solves, in one sentence, in your words.
- What's included and what isn't. A concrete list. "Integration with your invoicing" must say which one and how.
- Timeline with partial deliveries. Not "12 weeks", but "week 3: this, week 6: that". So you see progress and can stop if something goes wrong.
- What they need from you. Data, decisions, your team's time. If they don't say it, you'll find out mid-project.
- What happens after. Support, maintenance, training. And who owns everything.
One-page quotes with a price and three lines of description are the ones that end in arguments. Four-page ones with all of the above are the ones that end in results.
The most common leadership mistake: delegating the decision, not the execution
Delegating execution is right: you're not going to code it yourself. Delegating the decision is a mistake: the provider doesn't know what matters to your business.
What the mistake looks like: "Let the IT guy decide which CRM we get." The IT guy picks the one he knows, or the most complete, or the cheapest. None of those criteria is "the one that makes my salespeople close more".
How it's done right: you define the problem and the expected result. The provider proposes options with pros, cons and costs. You choose with that information. The provider executes.
One hour of your time a month on this is worth more than any tool.
How not to depend on anyone (including me)
This is what I require in all my projects and what you should require too:
- Everything in your name. Domains, hosting, tool accounts, code repositories. You are the owner; the provider has access.
- Understandable documentation. A document explaining what exists, how it works and how to access it. Readable by another technical person without calling the original provider.
- No exotic technologies. If a provider builds with a tool only they know, you depend on them forever. Ask for standard technologies any professional can maintain.
- Passwords and access in a password manager you own. Not in the provider's email.
If your current provider pushes back on any of these points, that's valuable information about the relationship.
A management ritual that works
With the business owners I support we set this up, and within three months the change in control is obvious:
Once a month, 45 minutes. Three things get reviewed: what was done and what result it gave (with numbers), what gets done next month and why, and which decisions need your approval.
A living one-page document. The automated processes, the tools in use, what each one costs, who manages it. Updated every month. When someone proposes something new, you look at it first.
A rule for new things. Any new tool has to answer "what problem does it solve and what does it replace" before being purchased. If it replaces nothing, it's one more layer of complexity.
None of this requires understanding technology. It requires management discipline, which you already have because you run a company.
In short
Leading your company's technology means defining problems, setting the value of solving them, deciding the acceptable risk and demanding clarity from whoever executes. None of that is technical. All of it is leadership.
If you'd like someone alongside you in that role, translating technology into your language and executing with judgment, that's exactly what I do in the monthly digital partnership. And if you'd rather start with a no-commitment conversation, book a 15-minute call. I'll explain, in your language, what I'd do first in your company.
