Picture the owner of a 40-person logistics company in Bangkok. On Monday a software vendor wants a decision on a three-year contract. On Wednesday the in-house developer asks whether to rebuild the booking system or patch it again. On Friday the accounts team wants a new invoicing tool. She has run the business successfully for fifteen years, but she has never written a line of code, and every one of these decisions feels like a test she might fail.
She doesn't need to learn to code. Leading technology well is not a technical skill. It's a leadership one: owning the outcome, asking questions until the answers make sense, and knowing which decisions are easy to undo and which are not. This guide covers all three.
Key Takeaways
- Technology decisions land on the owner's desk because they shape cost, risk and how the business runs, not because the owner needs technical skill.
- Your job is to define the outcome and the constraints; the specialists' job is to propose how to achieve them.
- Ten plain questions, asked consistently, will tell you most of what you need to know about a vendor or developer.
- Separate reversible decisions (decide quickly) from irreversible ones (slow down and get advice).
- Build a small circle of people you trust on technical detail, and bring in an independent adviser for the big, hard-to-reverse calls.
Why technology decisions land on the owner's desk
In a small or mid-sized business, almost every significant technology choice is also a business choice. A new system changes how staff spend their day, what customers experience, where your data lives and how much you'll spend for years to come. Those are leadership questions, which is why they end up with you even when someone else is more technical.
The stakes are real. Research by McKinsey and the University of Oxford on more than 5,400 IT projects found that large IT projects run 45 percent over budget and 7 percent over time, while delivering 56 percent less value than predicted (McKinsey, 2012). Those were big projects, but small businesses aren't immune to the same causes: unclear goals, shifting scope and too little attention from the people who own the result.
It's also worth remembering that most technology problems are not technology problems. As we explain in why digital transformation fails, projects usually stumble on purpose, people and process long before the software lets anyone down. Those are exactly the areas where a non-technical leader is strongest.
Owning outcomes, not specifications
The most useful shift a non-technical leader can make is to stop trying to judge the how and start being precise about the what and the why.
A specification says: "We need a CRM with custom objects, an API and a mobile app." An outcome says: "Every enquiry should get a reply within two hours, and I want to see the pipeline without asking anyone." The first invites you to evaluate things you can't judge. The second gives the specialists a target and gives you a way to measure whether they hit it.
When you own outcomes, your job looks like this:
- Define success in business terms. Faster responses, fewer errors, hours saved, revenue visible. Put numbers on it where you can.
- State the constraints. Budget, deadline, the people who must be involved, the data that must not be lost, the regulations that apply.
- Ask for options, not a single answer. Two or three approaches with their trade-offs tell you far more than one confident recommendation.
- Stay involved after the decision. Turn up to the reviews, look at the real system with real data and ask whether it's delivering the outcome you defined.
That last point is where many owners step back too early. Delegating the technical detail is sensible. Delegating the outcome is not.
Ten questions to ask any vendor or developer
You don't need technical vocabulary to have a sharp conversation with a vendor, an agency or your own developer. You need a consistent set of plain questions and the patience to keep asking until you understand the answer. If someone can't explain their answer in plain language, that tells you something too.
- What business problem does this solve, in one sentence? If the answer is a list of features, ask again.
- How will we know it's working? Ask for the measures they would use, and when you should expect to see a change.
- What will my team have to do differently? Every system changes someone's day. Find out whose, and how much.
- What does it cost in total over three years? Include licences, setup, training, support, integrations and the internal time it will take.
- Who will support us after go-live, and how? Ask about response times, who you'll actually speak to and what happens if that person leaves.
- Where does our data live, and how do we get it out? You should be able to export your own data in a usable format if you ever leave.
- What does it connect to? Which of your existing tools will it talk to, and how? Who maintains those connections?
- What's the smallest version we could start with? A pilot or first phase tells you more than any demo.
- What has gone wrong on similar projects, and what did you do? Good partners have honest answers. Be wary of anyone who claims nothing ever goes wrong.
- If we decide to stop in six months, what happens? Notice periods, data handover, sunk costs. This question tells you how reversible the decision really is.
Write the answers down and compare them across vendors. The differences are often more revealing than the answers themselves.
Reversible vs irreversible tech decisions
Not every decision deserves the same amount of care. Jeff Bezos put this neatly in his 2015 letter to Amazon shareholders, describing some decisions as "one-way doors" that are consequential and nearly irreversible, and most others as "two-way doors" that can be reopened if you don't like what's on the other side. He also warned that growing organisations tend to apply slow, heavy decision-making to decisions that could be made quickly.
The same split works well for technology in a small business.
| Usually a two-way door (decide quickly) | Usually a one-way door (slow down) |
|---|---|
| Trialling a tool on a monthly plan | Signing a multi-year contract |
| Running a pilot with one team | Migrating all your data to a new system and switching the old one off |
| Adding a simple automation you can switch off | Commissioning custom software your business will depend on |
| Changing a report, a form or a pipeline stage | Choosing the core platform that other systems will connect to |
| Testing a new channel for customer messages | Restructuring roles around a new system |
For two-way doors, set a short trial, agree what you'll measure and let the people closest to the work decide. The cost of being wrong is small, and the cost of being slow adds up.
For one-way doors, do the opposite. Get more than one opinion, talk to existing customers of the vendor, run a pilot first if you can, and make sure you understand the exit route. Often, you can turn a one-way door into a two-way one: a shorter initial contract, a phased migration that keeps the old system available for a while, or a pilot before a company-wide rollout.
Choosing a CRM is a good example. The decision to try one with a single team is reversible; committing the whole business to it, with years of customer history migrated in, is much less so. If that's on your horizon, our guide to CRM for small business covers the trigger points and what good looks like.
Building a team you can trust on technical detail
You can't check every technical judgement yourself, so you need people whose judgement you trust. That trust is built deliberately, not assumed.
Look for people who explain things clearly without making you feel foolish for asking. Look for people who tell you about problems early, including ones they caused. Look for people who talk about your customers and your staff, not only about the technology. Those traits matter more than any particular certification.
A few habits make the relationship work:
- Ask for decisions to be written up in one page: the problem, the options, the recommendation and the risks.
- Make it safe to say "I don't know" or "this isn't working". Bad news that arrives early is cheap; bad news that arrives at go-live is expensive.
- Involve the people who will use the system. Your operations staff will spot practical problems that a developer or vendor won't.
- Keep ownership of the important things in-house. Your data, your passwords and admin access, and your knowledge of how the systems fit together should never sit with one outside person alone.
If you don't yet have anyone technical on the team, that's fine. Many small businesses work with a mix of a trusted vendor, a part-time specialist and one internal "owner" for each major system who isn't technical but knows how it's used.
When to bring in an outside adviser
Sometimes you need a view from someone who isn't selling you anything and isn't the person who built the current system. An independent adviser is most useful in a few situations:
- Before a one-way-door decision, such as choosing a core platform, signing a long contract or commissioning custom software.
- When a project is drifting, with deadlines slipping and nobody able to explain clearly why.
- When internal opinions conflict and you can't tell whose concerns are technical and whose are about change.
- When you're planning a bigger transformation and want to get the sequence right before spending money.
A good adviser will ask more about your business, your team and your goals than about technology. They should leave you more confident in your own judgement, not more dependent on theirs.
You don't need to code to lead technology well
Technology decisions belong to leaders because they shape the whole business. You don't need technical skills to make them well. You need to be clear about the outcome, ask plain questions until you understand the answers, move quickly on reversible decisions and slow down on the ones you can't undo.
If you'd like a trusted sounding board for those decisions, our Strategic Consulting & Advisory and Leadership Coaching services are designed for exactly that: helping non-technical leaders make confident technology calls without needing to become technologists themselves.