There is a peculiar moment in almost every technology meeting when the conversation stops sounding like business and starts sounding like alphabet soup.
Someone mentions SSO, APIs, EDR, RTO, conditional access, zero trust, or an AI integration. A vendor confidently explains an architecture diagram containing fourteen boxes and twenty-three arrows. Everyone nods thoughtfully.
And somewhere in the room, a business leader is thinking: “I understood the word ‘cloud.’ Mostly.”
Here is the good news: you do not need to become an IT expert to make good technology decisions.
In fact, trying to become one may distract you from the part of the decision that actually belongs to leadership.
Great leaders do not need to know how every technology works. They need to know what questions to ask, which tradeoffs matter, who to trust, and how technology connects to the goals and risks of the business.
That distinction is more important than ever because technology decisions increasingly are business decisions. The National Institute of Standards and Technology’s Cybersecurity Framework 2.0, for example, explicitly includes executives, boards, acquisition professionals, lawyers, human resources professionals, and risk managers among the people who can use the framework to guide cybersecurity decisions. Its newer Govern function places organizational priorities, responsibilities, oversight, and risk strategy alongside the technical work of protecting systems. [nist.gov], [nist.gov]
In other words, this is not just IT’s table anymore.
Your Job Is Not to Know the Technology
Imagine your company needs a new accounting system.
A technical conversation might involve APIs, authentication methods, database architecture, identity providers, backup mechanisms, and integrations.
Those things matter tremendously.
But they are probably not the questions the CEO should spend Friday night studying.
The leadership questions are different:
Will this system make the business easier or harder to operate?
What problem are we actually solving?
What happens if the system becomes unavailable?
What information will it contain, and how sensitive is that information?
Can employees realistically use it?
Can it work with the technology we already depend on?
What will this decision cost us over three to five years, not simply on the first invoice?
How difficult would it be to leave this vendor?
And perhaps most importantly: What could go wrong?
Technical specialists can investigate how a system delivers those outcomes. Leadership decides whether those outcomes are good enough for the business.
Think of it like purchasing a commercial building. The CEO does not need to calculate the structural load of every beam. An engineer can do that.
But the CEO absolutely needs to understand whether the building fits the company’s plans, what it costs, what risks come with it, and whether the inspection uncovered anything alarming.
Technology deserves the same division of labor.
Start With the Problem, Not the Product
One of the easiest ways to make a bad technology decision is to fall in love with a solution before clearly defining the problem.
This happens particularly easily with fashionable technology.
Someone sees an impressive demonstration. A competitor announces something shiny. An executive comes back from a conference enthusiastic about AI. Suddenly everyone is discussing products before anyone has written down what success is supposed to look like.
Reverse the sequence.
Instead of saying: “We need an AI solution.”
Try: “Our employees spend too much time searching for information across our systems. Can technology reduce that time without exposing sensitive information?”
Instead of: “We need to move everything to the cloud.”
Try: “Our current systems are expensive to maintain and difficult to access remotely. What approach gives employees reliable access while keeping our operational and security risks acceptable?”
That little change is powerful.
Once the business problem is clear, features become evidence rather than entertainment.
A dazzling demo can then be met with the single most useful question in technology procurement: “How does that help us solve the problem we identified?”
Sometimes the room becomes noticeably quieter.
That is useful information too.
Ask for Outcomes in Plain English
Strong technology leadership requires another deceptively simple skill: refusing to pretend you understand something when you don’t.
If someone says a new solution “leverages a cloud-native, zero-trust architecture through federated identity,” you are allowed to ask:
“What does that mean for our business?”
That is not an unsophisticated question.
It is an excellent one.
A knowledgeable technical advisor should be able to move between technical details and business consequences.
For example: “Employees will sign in using their existing company accounts. We can require stronger authentication, disable someone’s access centrally when they leave, and avoid maintaining another separate password system.”
Now there is something leadership can evaluate.
That approach mirrors an important principle behind NIST CSF 2.0. Its high-level cybersecurity outcomes are deliberately intended to help organizations understand, prioritize, assess, and communicate risk without prescribing one particular technical method for achieving them. [nist.gov]
Executives should expect the same translation from their advisers.
Evaluate Risk, Not Just Features
Technology comparisons love checkboxes.
Product A has 47 features. Product B has 53. Therefore Product B wins.
If only business were that easy.
A better decision considers what the technology introduces into your organization as well as what it provides.
Suppose two vendors offer nearly identical functionality. One supports multifactor authentication, centralized sign-on, detailed security logging, straightforward data export, and a documented process for handling vulnerabilities. The other is cheaper but weak in those areas.
Those differences may not make the prettier sales demo.
They can matter enormously after deployment.
CISA’s Secure by Design initiative argues that technology manufacturers should treat customer security as a core business requirement rather than an optional technical feature. Its guidance specifically highlights protections such as multifactor authentication, logging, and single sign-on as capabilities that should be available without additional cost. [cisa.gov]
For a business leader, the broader lesson is simple: When buying technology, you are also buying its risks.
Ask what data the product touches. Ask how access is controlled. Ask whether your organization retains its data if the relationship ends. Ask what happens during an outage. Ask how the vendor communicates security incidents.
You do not have to personally perform the security assessment.
You do need to make sure somebody competent does.
Think Beyond the Sticker Price
Technology pricing has an unfortunate habit of behaving like airfare.
The first number is rarely the whole number.
A system might cost $1,000 per month, but require implementation services, migration work, employee training, upgraded devices, additional security tools, premium support, and another subscription to make the first subscription communicate with something you already own.
A better question than “How much does it cost?” is: “What is the total cost of achieving the result we want?”
That includes obvious expenditures, but also operational costs.
Suppose cheaper software saves $6,000 annually but requires employees to manually copy data between systems. If that process consumes eight hours of staff time every week, the supposedly cheaper choice could be considerably more expensive.
The opposite can happen too. Expensive software packed with sophisticated capabilities may be a poor investment when employees need only a fraction of them.
Technology ROI is not about buying the least expensive tool.
It is about understanding what business value you’re getting in exchange for the full cost and complexity you’re accepting.
Pay Attention to Adoption
There is another technology metric that specifications conveniently leave out:
Will your employees actually use the thing?
The theoretically perfect system can be an operational disaster if it requires seventeen clicks to perform something employees do fifty times per day.
Technology exists inside workflows, habits, deadlines, and human behavior.
Before making a significant purchase, let the people who will actually use the product participate in the evaluation. Run a pilot when practical. Watch someone complete a real task instead of relying entirely on a polished vendor demonstration.
And listen carefully when employees discover workarounds.
They usually do.
Poor usability does not necessarily stop work. Instead, work leaks around the system through spreadsheets, personal applications, duplicated records, unofficial AI tools, or processes nobody formally approved.
AI provides a timely example. IBM’s 2025 Cost of a Data Breach Report found that 63% of breached organizations in its research lacked an AI governance policy or were still developing one. Among organizations reporting an AI-related security incident, 97% lacked proper AI access controls. [www-api.ibm.com], [ibm.com]
The leadership lesson goes beyond AI: if the approved technology does not match how people actually work, employees may find their own technology.
That becomes a business problem remarkably quickly.
Know Which Decisions Are Reversible
Not every technology decision deserves six months of committee meetings.
Some decisions are easy to reverse. Test a productivity application with five employees for a month, discover it isn’t useful, cancel it, and move on.
Others create gravity.
An organization-wide accounting platform containing years of financial records is enormously harder to replace. So is a core line-of-business application deeply integrated into workflows, reporting, customer processes, and security systems.
Leaders should therefore ask: “If we’re wrong, how difficult is it to undo this decision?”
The harder a choice is to reverse, the more diligence it deserves before commitment.
That includes evaluating contract length, migration requirements, integration dependencies, data portability, support arrangements, and exit costs.
You are not merely selecting software.
Sometimes you are selecting a relationship your organization might live with for years.
Make Vendors Demonstrate, Not Declare
Vendor conversations become much more productive when leaders replace adjectives with evidence.
“We have enterprise-grade security.” Show us.
“Our support is excellent.” How is support delivered, what are the response commitments, and what happens when the first person cannot resolve the issue?
“We integrate seamlessly.” Show us the integration with the products we actually use.
“Our platform is easy to migrate away from.” Describe the export process and show us what we receive.
This is not hostility. Good vendors should welcome specific questions because specificity allows them to demonstrate real strengths.
Be especially wary whenever an important claim cannot be translated into something observable, contractual, measurable, or independently assessed.
“Best-in-class” is marketing.
A documented recovery process is information.
Get Comfortable Saying “I Don’t Know”
Perhaps the strongest technology sentence a leader can say is: “I don’t know enough about that. Explain it to me.”
Technology conversations sometimes create a strange pressure to perform knowledge. People hear unfamiliar terminology and nod because everyone else is nodding.
That is how assumptions survive meetings.
Effective leaders puncture the illusion.
“What happens if that fails?”
“Why do we need that?”
“What alternative did you consider?”
“What assumptions are you making?”
“What would make you recommend against this?”
“What would our employees notice if we changed nothing?”
Questions like these do not require technical expertise. They require curiosity and judgment.
And they reveal an enormous amount about both the technology and the people recommending it.
Build a Simple Technology Decision Framework
For significant investments, leadership can make decisions more consistent by scoring every proposal against the same basic framework.
You do not need a 78-tab spreadsheet. Start with six questions:
- Business fit: What measurable business problem does this solve?
- People fit: Will employees realistically adopt it?
- Financial fit: What is the full cost of implementation, operation, support, and eventual replacement?
- Risk: What security, privacy, compliance, continuity, and vendor risks are we accepting?
- Compatibility: How well does it fit our existing systems and future plans?
- Reversibility: What happens if we decide to leave?
Then bring in technical specialists to validate the technical claims underneath those questions.
That creates a healthy partnership.
Leadership owns the why and acceptable tradeoffs.
Technical experts validate the how, feasibility, and technical risk.
Neither replaces the other.
Where an MSP Fits Into the Conversation
For small and midsize organizations, maintaining deep internal expertise across cybersecurity, cloud services, networks, identity, backup, hardware, software licensing, and rapidly changing AI tools can be challenging.
This is one place a managed service provider can help.
An MSP such as Ethixa Solutions can serve as a technical translator and evaluator, helping leadership understand how proposed technology fits the organization’s existing environment, what dependencies or risks may accompany it, and which questions deserve closer examination.
The value is not making leadership decisions for the business.
It is giving leaders better technical information with which to make them.
That relationship works best when the technology conversation begins with business goals rather than products.
The Best Technology Leaders Are Not Necessarily Technologists
Technology will keep changing.
Today’s must-have platform will eventually become tomorrow’s legacy system. Today’s exciting AI capability will become an ordinary checkbox. New acronyms will continue appearing, presumably because the technology industry has collectively agreed that words take too long.
Trying to personally master all of it is a losing game.
Fortunately, that isn’t leadership’s job.
A strong leader knows what the organization is trying to accomplish. They understand what risks the business can tolerate. They ask uncomfortable questions. They insist on plain-English explanations. They surround themselves with people who know more than they do in specialized areas.
Then they make the decision.
You do not need to know how every server, API, security control, AI model, or cloud service works.
You need to make sure the people advising you do.
That is not a technical skill.
That is leadership.
Leave a Reply