The invoices in this small business (small-to-medium business/SMB) covered the desk. This was my first impression as I walked into the back office of a small butcher shop after a change in ownership. The business had a loyal customer base and a new owner who knew the craft inside and out. What he didn’t have was a technology foundation that matched the realities of running a modern business.
The website was outdated. Accounting lived in spreadsheets. Inventory was partly on paper. The point-of-sale system worked but didn’t talk to anything else. And the physical invoices – stacked and spread across the workspace – were the operational system.
Nothing about the environment looked like enterprise IT. No diagrams. No governance. No formal processes. But the problems were absolutely technology problems. They were also business problems. And they were tightly connected.
The owner didn’t lack business expertise. He lacked a starting point. He needed to know where technology could help, what mattered first, and how to make decisions that wouldn’t hurt the business.
Small business doesn’t mean small technology decisions. It often means less room to get them wrong.
Small Business Doesn’t Mean Simple
Many assume smaller organizations face simpler technology challenges. Fewer people, fewer systems, fewer problems.
It doesn’t work that way.
SMBs still face decisions about:
- Cybersecurity
- Identity
- Cloud
- Applications
- Vendors
- Data
- Recovery
- Compliance
- Artificial intelligence (AI).
The scale changes. The complexity doesn’t necessarily shrink in proportion to organizational size.
A 100-person company still needs MFA, lifecycle management, privileged access controls, and an offboarding plan. A small manufacturer still needs to know where its data lives, how it’s backed up, and what happens if the primary system fails.
Technology complexity doesn’t drop just because headcount does.
The resources available to manage it often do.
That’s the real asymmetry.
And it raises an important service-management question: How much discipline does a smaller organization actually need?
When a “Simple Migration” Isn’t Simple
One of the clearest examples I’ve seen came from a Microsoft 365 modernization project. On paper, it looked straightforward: retire an aging file server and move documents to Microsoft SharePoint.
A simple migration. A quick modernization.
Except it wasn’t.
Once we started mapping the environment, we found:
- Business workflows embedded in the folder structure
- Inconsistent permissions
- Undocumented application dependencies
- Years of technical debt
- Budget constraints
- Very different levels of staff readiness.
What looked like a file migration quickly became a conversation about business processes, security, governance, application dependencies, financial priorities, and whether the organization was ready for the change.
In smaller organizations, technology decisions rarely stand alone.
They’re business decisions with technical consequences.
Where Are All the Specialists in a Small Business?
In a large enterprise, a decision like the Microsoft 365 migration might involve:
- Architecture
- Security
- Infrastructure
- Applications
- Procurement
- Legal
- Finance
- Project management
- Change management.
Each group brings its own perspective.
In a smaller organization, these questions don’t disappear when the departments do.
Someone still has to understand identity, evaluate security, assess vendor risk, plan recovery, manage change, and connect the decision to business outcomes.
Often, that “someone” is the same person.
This is where the breadth of technology leadership in smaller environments becomes apparent. It’s not that SMB leaders are “better” than enterprise leaders. It’s that the breadth of accountability is different.
Smaller organizations can require one technology leader to exercise judgment across infrastructure, security, applications, vendors, financial priorities, business continuity, and organizational change.
Scale is one dimension of leadership. Breadth is another.
Less Room to Learn Through Failure
Smaller organizations can also have less room to learn through failure.
Large enterprises can sometimes absorb:
- A poor vendor choice
- An underestimated project
- A platform mismatch.
The consequences can be significant, but the organization may have greater financial, technical, and staffing capacity to recover.
For an SMB, that cushion can be much smaller.
Choosing the wrong platform, underestimating an implementation, selecting a vendor that can’t support the business’s actual needs, or discovering that a backup solution doesn’t recover what the business expected can consume a meaningful portion of the technology budget, occupy a small team for months, or disrupt the business itself.
The failure doesn’t have to be catastrophic to matter.
In smaller environments, decision quality can matter more because the ability to absorb failure can be lower.
This is why discipline – not bureaucracy – matters.
Don’t Import Enterprise Bureaucracy to Small Business
This is where IT service management (ITSM) becomes especially relevant.
The answer to SMB complexity is not to recreate enterprise IT on a smaller scale. A 100-person company may not need a 15-person Change Advisory Board (CAB), an architecture review board, a multi-volume process library, or dozens of service metrics to demonstrate that IT is being managed.
These mechanisms can make sense when coordinating large organizations, complex environments, and multiple specialized teams. They don’t automatically scale down to a smaller organization.
But the underlying disciplines still matter.
A smaller organization still needs to understand risk before making a change. Someone still needs to own the service afterward. Vendors still need accountability. Recovery still needs to be tested. Incidents should still teach us something. And technology still needs to produce an outcome the business values.
Right-sized ITSM should mean less bureaucracy, not less discipline.
Keep what matters. Simplify the rest.
Minimum Effective Discipline
This leads to a practical idea: minimum effective discipline.
Instead of asking, “What enterprise process should we implement?” ask, “What is the minimum effective discipline necessary to make this decision responsibly?”
Consider a significant production change. A smaller organization may not need a formal CAB meeting with representatives from multiple departments. But someone should still:
- Understand the business impact
- Assess the risk
- Confirm who approved the change
- Know how to back it out
- Verify that it worked.
The process can be smaller. The discipline shouldn’t be.
This reframes ITSM from installing processes to exercising judgment. It focuses on the thinking that protects service value and business outcomes without assuming every organization needs the same mechanisms.
A simple five-question Technology Decision Test provides a starting point.
Technology Decision Test for Small Businesses
1. Business
What outcome are we trying to improve or protect?
If we can’t answer this clearly, why are we making the technology decision?
2. Risk
What happens if we’re wrong?
The answer should influence how much diligence, testing, expertise, and oversight the decision deserves.
3. Ownership
Who owns this after implementation?
Projects end. Services, systems, contracts, and responsibilities remain.
4. Dependency
What new vendor, technology, people, skills, or data dependencies are we creating?
Dependencies are easy to create. They can be difficult and expensive to unwind.
5. Recovery
If it fails tomorrow, what happens next?
A successful implementation isn’t the same thing as a recoverable service.
These questions aren’t about following a framework. The service-management disciplines behind them still matter. They provide a practical starting point without adding unnecessary overhead.
Minimum effective discipline isn’t about reducing rigor.
It’s about reducing overhead while preserving judgment.
Measure Complexity Differently in a Small Business
A smaller environment isn’t necessarily simpler. A smaller technology organization doesn’t necessarily mean smaller responsibility. And a smaller budget doesn’t necessarily mean smaller risk.
Perhaps we should also be more thoughtful about what we mean when we talk about scale.
Headcount, budgets, users, and geographic reach matter. But so does the breadth of decisions a technology leader and team must make.
The question isn’t whether a smaller organization needs enterprise IT processes. Usually it doesn’t.
The better question is:
What level of discipline protects the business from a technology decision it cannot afford to get wrong?
Small business doesn’t mean small technology decisions.
Sometimes, it simply means less room to get them wrong.
Small Business Technology FAQs
It’s the idea of asking what’s the minimum effective discipline needed to make a decision responsibly, rather than which enterprise process to install. Mark Patnaude’s point is that the process can shrink, but the discipline behind it shouldn’t.
Scale changes, but complexity doesn’t shrink in proportion to headcount. SMBs still face decisions on cybersecurity, identity, cloud, applications, vendors, data, recovery, compliance, and AI. What actually shrinks is the resource available to manage all of it.
Because mechanisms like a large Change Advisory Board or a multi-volume process library are built for coordinating large, complex organizations and don’t automatically translate to a smaller one. The underlying disciplines, like understanding risk, assigning ownership, and holding vendors accountable, still apply regardless of size.
A five-question starting point for any significant technology decision: what outcome are you trying to protect (Business), what happens if you’re wrong (Risk), who owns it after implementation (Ownership), what new dependencies it creates (Dependency), and what happens if it fails tomorrow (Recovery).
Large enterprises can often absorb a bad vendor choice or an underestimated project because they have more financial, technical, and staffing capacity to recover. For an SMB, the same mistake can eat a meaningful chunk of the technology budget, tie up a small team for months, or disrupt the business directly.
Right-sized ITSM means less bureaucracy, not less discipline. Keep the disciplines that protect the business, simplify or drop the rest, and use the Technology Decision Test as a starting point for judgment calls.
Mark Patnaude
Mark Patnaude is a technology executive and ITSM practitioner with more than 20 years of experience leading technology operations, infrastructure, service delivery, cybersecurity, and business transformation. He holds ITIL 5 Foundation certification and is the author of Technology Isn’t the Hard Part and 250 Years of Accelerating Change. He writes about technology leadership, service management, AI, and the connection between technology decisions and business outcomes.
