“You can’t manage what you don’t define … and ITSM defines the value chain of modern business.”
Technology is no longer a back-office function; it’s the front door to your customer, your employee experience, and your ability to scale. But if you’ve ever heard someone say “ITSM is dead,” they probably weren’t dealing with the realities of operating across legacy infrastructure, Agile sprints, and a non-technical business model all at once.
This series is for leaders and teams navigating that complexity. Each week, we’ll break down one core concept from ITSM, anchored in ITIL 4, but expanded through the lenses of DevOps, SRE, Lean, COBIT, VeriSM, and real-world implementation.
Whether you’re running a corporate service desk, modernizing your enterprise infrastructure, or aligning software development with business value, this newsletter will provide you with a weekly playbook to drive better outcomes across your organization.
Where We’re Going: A 12-Week Journey
- Why ITSM Still Matters: Debunking myths and aligning IT with business transformation
- The Service Value System: How to connect strategy to execution through value streams
- Governance Without Gridlock: Balancing agility and accountability in service delivery
- The Service Value Chain: Using Engage, Plan, Build, and Support to run your ops
- Guiding Principles as Decision Filters: Making faster, more intelligent choices across teams
- Modern Service Desk Operations: From ticket takers to business enablers
- Infrastructure as a Product: Treating core systems with the same rigor as software
- Change Enablement in a DevOps World: Replacing fear of change with velocity and trust
- Service Knowledge & Configuration: Building a system of record that helps
- Service Portfolios & Productization: Defining, marketing, and managing IT services
- Continual Improvement That Sticks: Driving performance with tangible, measurable outcomes
- Culture, Coaching & Long-Term Buy-In: Making service management part of how you operate
Kicking Off with Week 1: Why ITSM Still Matters
Let’s start by addressing the elephant in the room: if we’re all Agile, DevOps, and cloud-native now… why do we still need ITSM?
Because when every part of the business depends on technology, managing services is managing the business.
In Week 1, we’ll dig into the evolving role of ITSM in a fast-moving world, why it’s more relevant than ever, how it supports agility instead of blocking it, and how to use it as the foundation for reliability, scale, and strategy.
ITSM has been declared dead more times than we can count, usually by people who have never had to troubleshoot a failing release during a customer event or explain a Severity 1 issue to an executive.
The truth is: ITSM isn’t outdated – it’s evolved. And it’s still one of the most powerful tools your business has to grow faster, scale smarter, and support better.
Here’s why:
ITSM Aligns Technology with Business Goals
“We’re not in IT to fix printers – we’re here to move the business forward.”
One of the most significant shifts in ITIL 4, and modern ITSM overall, is the recognition that technology doesn’t exist in a vacuum. Gone are the days when IT just “kept the lights on” while business leaders made the real decisions. Today, every business goal, whether it’s revenue growth, customer satisfaction, regulatory compliance, or operational efficiency, relies on services that technology enables.
But here’s the twist: alignment doesn’t mean agreement. You can have endless meetings where IT and the business “agree” on priorities, and still deliver misaligned outcomes. ITSM addresses this by embedding value-driven thinking directly into how services are designed, operated, and improved.
What ITIL 4 Gets Right:
- The Service Value System (SVS) replaces rigid process charts with a holistic model: you start with demand and end with value. In between, you engage, plan, design, deliver, support, and improve.
- It’s no longer about managing IT tickets; it’s about managing how technology contributes to business outcomes.
Example:
If the business wants faster employee onboarding, ITSM helps define the onboarding service, standardize it, automate it where possible, and measure its impact on productivity. No guesswork. Just measurable value delivery.
Aligning IT to business without ITSM is like planning a wedding by saying “everyone just do their part.” You might get the flowers and the cake, but don’t expect a ceremony that ends well.
Practical Takeaways:
- Define a value for every major service. If a system or workflow doesn’t tie back to customer or employee value, ask: Why are we still supporting it?
- Use service mapping to translate tech into outcomes. A CMDB isn’t just about inventory; it’s about showing how a slow database affects your e-commerce revenue during a holiday sale.
- Establish regular strategy alignment meetings. Not just IT status updates. Use a shared language: business capabilities, outcomes, value streams … not server uptimes and ticket queues.
- Appoint business relationship managers (or their equivalent). These people are bilingual: fluent in both business goals and IT services. They’re critical to keeping alignment real, not theoretical.
ITSM Enables Scale Across Diverse Teams
“Agile builds it, Infra runs it, the Service Desk supports it… and everyone blames each other when it breaks.”
Sound familiar?
Modern enterprises aren’t monolithic. You’ve got sprint-based dev teams, traditional PMO-led waterfall initiatives, a hybrid infrastructure stack (on-prem, cloud, probably something mysterious under someone’s desk), and a service desk trying to make sense of it all while juggling password resets and CEO laptops.
Without a unifying operating model, this becomes a game of broken telephone with real-world costs: missed SLAs, duplicated work, inconsistent support, and mounting technical debt.
This is where ITSM shines.
ITSM as the Language of Scale
Think of ITSM as the translator and traffic controller that lets teams with vastly different charters work together without stepping on each other.
- Infrastructure teams use change enablement to avoid surprise downtime.
- Developers get a service catalog to request environments without [insert your chat tool of choice 🙂 ] begging.
- Support teams use a known error database to escalate smarter, not harder.
- Business stakeholders gain visibility into uptime, capacity, and impact without needing to ask five teams for answers.
It’s not about slowing things down; it’s about scaling without breaking.
Modern Scale Requires Shared Guardrails
Scaling technology isn’t just about adding more servers or deploying faster. It’s about delivering consistently across different models and organizational cultures.
- Got DevOps teams that want autonomy? Cool. Just wrap that autonomy in change logging and risk classification.
- Running a waterfall ERP upgrade? ITSM brings structure to testing, comms, and incident response.
- Supporting a frontline workforce? ITSM ensures tickets, outages, and knowledge flow from Tier 1 support to engineering.
You need different teams doing different things, but they need to do it on a shared foundation.
“Without ITSM, scaling IT is like building a skyscraper with every team using a different blueprint and hoping the elevator works when it’s done.”
Practical Takeaways:
- Build a shared service taxonomy. Ensure that everyone uses the same definitions for services, support levels, and ownership. One team’s “incident” is another team’s “known issue.”
- Implement service-level agreements (SLAs) and operational-level agreements (OLAs) across teams. When everyone understands expectations, escalation paths become smoother and less political.
- Use ITSM tools as a collaboration layer, not just a ticket system. Integrated workflows between development, ops, and support can create transparency and eliminate redundancy.
- Assign service owners, even if a service spans teams. Someone needs to be accountable for uptime, improvements, and user experience across infrastructure, apps, and support.
ITSM Complements Agile and DevOps
“Agile ships it. DevOps deploys it. ITSM makes sure it doesn’t explode at 2am.”
It’s easy to assume that ITSM and Agile/DevOps are opposites: one born in process, the other born in speed. But that’s outdated thinking.
In reality, ITSM is the backbone that keeps Agile and DevOps stable as they scale.
Think of it like this:
- Agile helps you move fast in sprints.
- DevOps enables you to release frequently and with confidence.
- ITSM ensures that all that speed doesn’t leave a wake of incidents, compliance violations, or confused users in its wake.
These aren’t competing frameworks; they’re layers of the same system, each optimizing for different kinds of value.
Where the Fit Works
- Agile needs structure beyond the team level. User stories are great, but at some point, that feature needs testing environments, change controls, and support runbooks.
- DevOps needs accountability. CI/CD is incredible, until a change tanks production and there’s no audit trail, risk assessment, or rollback plan.
- ITSM adds the safety rails. Practices like change enablement, incident management, and service request fulfillment give fast-moving teams structure without friction.
When done right, ITSM doesn’t slow down Agile or DevOps; it makes them safer and more sustainable.
“Agile without ITSM is like driving a race car with no pit crew. You’ll go fast … until something breaks and there’s no one left to fix it.”
The Balance That Works
Agile and DevOps drive speed: sprints, iterations, rapid deployments. But speed without structure is risky. That’s where ITSM comes in.
It’s not about slowing things down with bureaucracy. It’s about ensuring that what you ship quickly can also be supported well.
Here’s the balance modern teams need to strike:
- Agile and DevOps prioritize speed and iteration
- ITSM ensures stability and continuity
- Agile builds quickly
- ITSM ensures those builds are supportable and recoverable
- DevOps empowers team autonomy
- ITSM provides alignment across departments and functions
- Agile encourages frequent releases
- ITSM manages the risk that those changes introduce
You don’t need 50-step change approvals or weekly CAB meetings to make this work.
What you do need is:
- Policy-based change models
- Automation and integrated workflows
- SLAs and SLOs that move at the speed of delivery
When done right, ITSM becomes the guardrail, not the roadblock. And that’s what makes velocity sustainable.
Practical Takeaways:
- Map your DevOps pipeline to ITSM workflows. For example, automate change records from deployment events and link incidents back to user stories or commits.
- Use standard change models. Define low-risk changes (e.g., updating static web content, non-production releases) that can be approved automatically.
- Include ITSM roles in Agile teams. Bring service managers or operations leads into sprint planning so that production readiness is part of the ‘definition of done’.
- Run post-incident reviews as retrospectives. Treat incidents the same way Agile treats failed sprints: with blameless reviews, learnings, and backlog items.
Modern ITSM Is Flexible and Framework-Agnostic
“One framework to rule them all” is a fantasy. The real world runs on mashups.
Walk into any modern enterprise and you’ll see a blend of methodologies at work. One team is sprinting in Agile, while another is running on Waterfall. DevOps is automating pipelines, and the service desk is holding everything together with ITIL practices.
This isn’t dysfunction, it’s reality.
And the good news? ITSM no longer requires a one-size-fits-all model. ITIL 4 is built to be framework-friendly.
It encourages organizations to adopt what works, drop what doesn’t, and integrate practices from across the ecosystem, including Agile, DevOps, Lean, SRE, COBIT, FitSM, VeriSM, and more.
You’re Building an Operating Model, Not Joining a Religion
ITSM today isn’t about strict rulebooks. It’s about building a flexible, scalable operating model that adapts to your organization’s complexity and maturity.
You might:
- Use value streams and continual improvement from ITIL
- Apply incident response and SLIs from SRE
- Run Kanban boards and daily standups from Agile
- Incorporate automation and CI/CD pipelines from DevOps
- Layer in Lean principles for waste reduction and flow
The glue is clarity: What practices are used, why, and how they tie back to business value.
“The best ITSM framework is the one that your team actually uses … without rolling their eyes.”
Practical Takeaways:
- Document your hybrid operating model. Make it clear which frameworks influence your practices, and how they interrelate.
- Avoid purist thinking. If a team resists ITIL terminology but effectively follows SRE principles, embrace it and build bridges, not barriers.
- Use value streams to unify your toolchain. Whether it’s Jira, ServiceNow, or spreadsheets (hey, we’ve all been there), your ITSM model should reflect how value flows across tools and teams.
- Train teams cross-functionally. Give DevOps engineers exposure to service management thinking. Let service managers understand DevOps pipelines and Agile rituals.
The Modern ITSM Stack: A Takeaway Framework
Let’s tie it all together with a simplified view of how ITSM fits into the broader business machine. Think of it as your organization’s value delivery engine:
- Business Goals – Define outcomes like growth, customer retention, or regulatory compliance
- ITSM Backbone – Provide structure and governance through frameworks like ITIL 4 and COBIT
- Execution Practices – Deliver value using Agile, Scrum, DevOps, and SRE
- Support and Operations – Ensure reliability through monitoring, CMDB, and a responsive service desk
- Improvement Loop – Drive continuous growth using CSI, Lean principles, and OKRs
Every layer plays a role. And the strongest teams ensure these layers work together, not in silos.
Ask Yourself (and Your Team):
- Is our service desk a cost center or a driver of employee and customer experience?
- Are incident learnings making their way back into the roadmap, or dying in postmortems?
- Does infrastructure have a voice in product planning and delivery?
- Are we treating ITSM as a value enabler or just the ticketing system?
ITSM is no longer just about process. It’s about clarity, collaboration, and value creation across the business.
When done right, it helps you scale with confidence, support what matters most, and ensure that your technology investments deliver on their promise.
This is how service management becomes a competitive advantage, not just a framework.
Coming Up Next: The Service Value System: How to connect strategy to execution through value streams
In Week 2, we’ll explore the ITIL Service Value System, not as a theoretical model, but as a practical tool for navigating cross-functional chaos. You’ll see how it connects strategy, execution, and improvement in a way that makes sense to business leaders, developers, and support teams alike.
If your teams ever ask, “Why are we doing this?” or “How does this ladder up to anything meaningful?”, next week’s issue will help you answer… with clarity and confidence.
Final Thought
ITSM isn’t dead. It just stopped wearing the tie and started speaking in product terms.
Today, it’s less about control and more about coordination. Less about process for its own sake, and more about creating reliable, supportable, and valuable outcomes across every part of the business.
If you can get your infrastructure, developers, service desk, and business leaders speaking the same language, that’s not just IT alignment. That’s a competitive edge.
Share this with a teammate who’s ever had to ask, “What does ITSM actually do for us?”
Follow the series to stay ahead as we break down ITSM into actionable, modern practices every week.
Drop a comment: How are you blending frameworks like Agile, SRE, and ITIL in your organization today?
Let’s build smarter. Not just faster.
See you next week.
