The High Touch Operating Model
How Your IT Organization Really Works
I have written about the Company Queue and Empty Landing Zones. About how High Touch delivery creates productivity disasters and expensive platforms nobody uses. But here's the question that matters: What exactly is High Touch delivery?
Most IT professionals know something isn't working. They feel the frustration of slow delivery times, the pain of constant firefighting, the disappointment of cloud investments that haven't delivered promised benefits. But they struggle to articulate what's broken because High Touch isn't just one thing - it's an entire operating model woven through every aspect of how IT organizations work.
High Touch is the water you swim in. It's so pervasive, so normalized, that it becomes invisible. You don't see High Touch delivery - you just see "how IT works." But once you understand its anatomy, you'll soon see it everywhere: in your org chart, your processes, your tools, your governance structures, even your job descriptions.
In this article, I'll dissect High Touch delivery across eight critical dimensions. By the end, you'll see your organization with new eyes - not as a collection of separate problems, but as a coherent system designed around principles that made sense decades ago but actively harm productivity today.
Eight Dimensions of Dysfunction
High Touch delivery manifests across eight interconnected dimensions. Each reinforces the others, creating a self-sustaining system that's remarkably resistant to change. Let's examine each one.
1. Process: The "Call the Expert" Pipeline
How High Touch Works: Your IT processes are built around the fundamental principle: "call an expert" Need a server? Call the infrastructure team. Want a firewall burn? Call the network team. Require a database? Call the DBA team.
This creates a predictable process pattern:
Service Request Submission - Users fill out forms describing what they need
Expert Interpretation - Specialists translate vague requirements into technical specifications
Manual Orchestration - Work gets handed off between multiple expert teams
Approval Gates - Committees review and approve at various checkpoints
Implementation - Experts do the work on behalf of the requester
Handover - The completed work gets "thrown over the fence" to the next team
Why You'll Recognize This:
Every IT interaction starts with "who do I need to call?" rather than "how do I do this myself?"
Your process documentation are runbooks for experts, not self-service guides for users
Change management processes assume every modification needs human review and approval
2. Organization Structure: Technology Silos Everywhere
How High Touch Works: Your IT department is organized around technology domains, not business services. You have teams for servers, networks, storage, databases, security, and applications - each with clear ownership boundaries and specialized expertise.
The org chart looks something like this:
Why You'll Recognize This:
When you need something that spans teams, you must coordinate across multiple managers
Team names reflect technologies (Windows Team, Oracle Team) rather than services (Identity Service Team, Compute Service Team)
Career paths are defined by technical specialization, not service delivery capability
3. Governance: Approval Gates and Risk Prevention
How High Touch Works: Your governance model assumes that risk is managed through human review and committee approval. Every significant change must be evaluated by experts who can spot potential problems and prevent bad decisions.
Architecture Review Boards: Committees that evaluate technical designs before implementation
Change Advisory Boards: Groups that assess the risk of modifications before deployment
Security Review Processes: Multi-week evaluations of new systems or significant changes
Why You'll Recognize This:
Governance processes add weeks or months to delivery timelines
Committee meetings are recurring calendar events that projects must schedule around
Risk mitigation means "get approval from the right people" rather than "build controls into the system"
4. RACI: Task-Based Separation of Duties
How High Touch Works: Your roles and responsibilities are defined by technical tasks, not business outcomes. RACI matrices map every conceivable activity to specific teams, creating a complex web of handoffs and dependencies.
For example, provisioning a new application environment creates this coordination matrix:
Why You'll Recognize This:
You have massive RACI matrices that nobody actually follows during emergencies
Simple changes require "touching base" with multiple teams who each own a piece
When something goes wrong, the first question is "whose job was that?" not "how do we fix it?"
5. Delivery Model: Projects and Operations Forever Separate
How High Touch Works: Your delivery model assumes building and running are fundamentally different activities performed by different teams with different skills and different funding models.
Projects (temporary teams with temporary funding):
Build new capabilities within defined timeframes and budgets
Optimized for delivery speed and feature completion
Success measured by on-time, on-budget delivery
End with "handover" to operations teams
Operations (permanent teams with ongoing funding):
Run existing systems with focus on stability and reliability
Optimized for predictable performance and incident response
Success measured by uptime and SLA compliance
Inherit systems they didn't build and can't easily change
Why You'll Recognize This:
You have project managers who don't work in operations and operations managers who don't work on projects
"Technical debt" discussions happen after projects end, when operations teams inherit incomplete solutions
Your best architects work on new projects while your operations teams struggle with legacy systems
6. Tooling: Expert-Mediated Everything
How High Touch Works: Your tooling landscape has two faces: simple interfaces for users to submit requests, and complex specialized tools for experts to fulfill them.
User-Facing Tools:
Service management systems (ServiceNow, Remedy) designed for ticket submission and routing work between teams
Service catalogs with broad categories and "describe your needs" text boxes
Approval workflows that route requests through human reviewers
Expert-Facing Tools:
Specialized management consoles for each technology domain
Monitoring tools that require deep technical knowledge to interpret
Configuration management systems operated by specialists
Deployment tools accessible only to authorized experts
Why You'll Recognize This:
Users can submit requests but can't see the actual work being done
Each team has their own tools that other teams can't access or understand
Self-service capabilities are limited to request submission, not actual provisioning
7. Industry Standards: ITIL, COBIT, and Process-Heavy Frameworks
How High Touch Works: Your IT governance follows established frameworks designed around expert-mediated processes and committee-based decision making.
ITIL/ITSM: Service management built around incident, problem, and change management processes that assume human intervention at every step
COBIT: Governance framework emphasizing controls, audits, and approval processes to manage risk through human oversight
PMI/PRINCE2: Project management methodologies built around phase gates, steering committees, and formal handovers between specialized teams
Enterprise Architecture: Frameworks (TOGAF, Zachman) that emphasize standardization through centralized review and approval
Why You'll Recognize This:
Your process documentation references ITIL processes by name (Incident Management, Change Management, Problem Management)
Governance discussions focus on "controls" and "approval authorities" rather than "capabilities" and "automation"
Training programs teach framework compliance rather than customer service or platform building
8. Metrics: Team Optimization Over End-to-End Outcomes
How High Touch Works: Your measurement systems optimize individual teams for their specific contributions rather than measuring end-to-end business outcomes.
Each team tracks their own performance in isolation:
Infrastructure Team: Server provisioning time (from request receipt to VM creation)
Network Team: Network change implementation time
Database Team: Database creation SLA compliance
Security Team: Security review completion time
Application Team: Code deployment frequency
Why You'll Recognize This:
Your dashboards show team-level metrics that can all be green while business users complain about slow delivery
Performance reviews focus on individual team contributions, not customer satisfaction
When delivery times are slow, each team can point to their metrics showing they're not the bottleneck
The System Was Designed for a Different Era
The High Touch operating model was a rational response to the realities of traditional, on-premises infrastructure. Your organization structure creates silos that require process handoffs because physical infrastructure genuinely required specialized expertise. Your delivery model is split across project and operations because building and running really did require different skills. Your approval gates exist because changes to physical systems were risky and difficult to reverse.
The High Touch operating model was designed for its era. When infrastructure meant physical servers costing hundreds of thousands of dollars, you absolutely needed experts to make purchasing decisions. When database deployments meant installing software on specific hardware configurations, the DBA's deep expertise prevented costly errors. When changes were infrequent and high-risk, approval committees provided valuable oversight.
Every dimension reinforced the others because they all solved real problems:
Technology silos made sense when each domain required years of specialized learning
Expert-mediated processes were necessary when users couldn't safely interact with complex systems
Approval gates prevented expensive mistakes with permanent infrastructure decisions
Project/operations splits aligned with the reality that building and running physical systems were genuinely different activities
RACI matrices clarified responsibilities in a world where handoffs between specialists were unavoidable
Team-level metrics worked when each team's contribution was distinctly separate
Process-heavy frameworks provided structure for managing complex, risky changes
Governance through committees was appropriate when decisions had long-lasting consequences
But cloud computing has fundamentally altered every assumption that made High Touch necessary:
Infrastructure is now software-defined and cheap to modify, not physical and expensive to change
Platforms hide complexity behind self-service interfaces, not expose it through specialized consoles
Mistakes can be quickly identified and easily reversed, rather than be costly and time-consuming to resolve
Changes can be frequent and low-risk through automation, not infrequent and high-risk through manual intervention
Resources can be provisioned instantly on-demand, not planned months in advance
Your High Touch operating model is optimized for infrastructure that no longer exists. What was once a perfect fit has become a fundamental mismatch. You're applying applying the on-premise solution to self-serve infrastructure, and that's why your cloud investments aren't delivering the promised benefits.
The Recognition Moment
As you read this breakdown, you probably recognized your organization in every dimension. The service request forms. The org chart with technology-based team names. The RACI that is probably gathering dust in a draw somewhere. The project handovers that never quite work. The specialized tools that only experts can use. The ITIL processes that add weeks to simple changes. The team metrics that show green while customers complain. The approval committees that meet monthly whether there's business urgency or not.
This recognition is crucial because High Touch isn't a collection of separate problems - it's a coherent system. You can't fix it by optimizing individual pieces (even though many have tried - does Scaled Agile ring a bell?). High Touch dysfunction requires a systematic response: transforming your entire operating model from expert-mediated to self-service. From processes built around "Call the Expert" to platforms built around "Do it Yourself."
What's Next? The Self Serve Alternative
Now that you can see High Touch delivery for what it really is - a complete operating model that was systematically designed for physical infrastructure but is mismatched to cloud technology - the question becomes: what's the alternative?
The alternative is the Self Serve operating model - an approach designed from the ground up for cloud technology's self-service, on-demand, pay-per-use capabilities. Where High Touch is built around "Call the Expert," Self Serve is built around "Do it Yourself." Here's how each of the eight dimensions transforms:
Process: From service requests to service interfaces
Organization: From technology silos to service-oriented teams
Governance: From approval gates to policy-as-code
RACI: From task-based handoffs to service ownership
Delivery: From project/operations splits to continuous improvement teams
Tooling: From expert consoles to user-friendly platforms
Standards: From ITIL to Scaled Agile (yes, really)
Metrics: From team optimization to end-to-end outcome measurement
In my next article, I will compare and contrast the High Touch and the Self Serve operating models across each of these dimensions. I hope to show you how you can achieve a step-change in productivity by shifting - over time! - from the former to the latter. Where today it takes months to deliver an IT service with your High Touch operating model, it will only takes minutes with Self Serve one.
The Transformation Is Possible
This isn't theoretical - organizations around the world have successfully transformed from High Touch to Self Serve operating models. They've moved from months to minutes, from expert-mediated to user-empowered, from process-heavy to platform-driven. Their teams are more productive, their users are more satisfied, and their businesses are more agile.
The technology exists. The patterns are proven. Your competitors may already be making this transformation. The question is: how much longer will you optimize an operating model designed for infrastructure that no longer exists?
Ready to transform your High Touch organization into a Self Serve productivity powerhouse? In my book "Months to Minutes," I provide the complete blueprint for systematic transformation across all eight dimensions. Because once you can see the system, you can change the system.