After more than a decade of leading data teams at various organizations, including startups and enterprises, I’ve seen centralized functional organizations, centers of excellence, start-up one woman shows and agile, zombie agile, pods, squads, the federated, the „data as a product“ model. But after all the pivots, restructures, and retrospectives, I’ve landed on a conclusion that might raise eyebrows: most data teams should function as service teams—with the critical caveat that they adopt ITIL principles
From Chaos to Clarity: The Journey
Despite near-universal claims of being data-driven, the promised strategic importance of data teams has faltered. LinkedIn is filled with posts about data executives having the kids’ seat at the grown-up executive table, persistent data leader turnover, burnout, toxic leadership and difficulty many data professionals have attaining stable employment. Data is supposed to be the most valuable element on Earth and data teams were supposed to be C-suite strategic importance. Somewhere between the dashboards, ad-hoc requests, broken pipelines, and angry stakeholders, the vision began to break for most organizations.
The issue most people face is not ambition or even ill-will. While CEO commitment to data-driven organizations is often genuine, the perception of data as merely an „innovative“ or „tech“ function undermines its potential:
This „innovation“ label often leads to insufficient structural support for sustainable delivery, resulting in overloaded, reactive teams with ambiguous remits. Consequently, shifting priorities—from platform building to executive reporting and ML model design—fuel burnout, unmet expectations, and diminished stakeholder trust.
The „tech“ label often prioritizes tool adoption over decisions supporting sustainable, cash-flow positive business growth. This can lead to a fragmented tool landscape, inflated operational expenses from excessive subscriptions and vendor lock-in, and significant technical debt that is difficult, if not impossible, to resolve due to poor documentation and inconsistent technical practices.
Perhaps a strategic pivot, rather than intensified effort, is now required.
Why „Service Team“ Isn’t a Dirty Word
For many, calling a data team a „service team“ feels regressive. It conjures images of ticket queues, low morale, and disempowered analysts. But that’s a caricature—not a reality.
A true service model, especially one grounded in ITIL (Information Technology Infrastructure Library), is about reliability, clarity, and accountability. It means:
- Defined service offerings (what we do and don’t do)
- SLAs and expectations (how fast, how good, how often)
- Change management (structured evolution over chaos)
- Incident response (what happens when something breaks)
Under this model, data teams stop being overwhelmed generalists and start being trusted partners. Data teams are empowered to create service designs that generate value for the business. Stakeholders know what to expect, and data professionals have the structure to do high-quality work without firefighting every day.
Why ITIL? And Why Now?
ITIL brings a mature, battle-tested framework to service management. While it was born in IT, its principles are relevant relevant to data:
- Service Design: Creating analytical output, data pipelines and schemas as reliable services, not one-off artifacts.
- Service Transition: Ensuring new solutions are tested, documented, and onboarded properly.
- Service Operation: Analytical output’s visibility pressures data leaders to prioritize it, often at the expense of maintaining uptime, quality, and timely delivery. Consequently, essential maintenance is frequently relegated to a rushed, secondary concern.
- Continual Improvement: Regularly reviewing and evolving services based on feedback and metrics.
Adopting ITIL equips data teams with the language and processes to manage complexity while maintaining velocity. Its framework, process library, and practitioner community empower data leaders and practitioners to deliver efficient organizational value.
What does workflow in an ITIL-Grounded Data Service Team
- An internal portal lists all available services (e.g., dashboard creation, data model support, data quality monitoring).
- Stakeholders submit requests through structured intake forms that include business context.
- Work is triaged weekly based on SLAs and team capacity.
- Status is transparent. Progress is visible.
- Incidents (like broken reports or delayed pipelines) have documented resolution paths.
This is not bureaucracy. This is professionalism.
The Common Objections (And My Response)
“But what about innovation?”
Service doesn’t mean stagnation. With a stable foundation, teams can carve out capacity for proactive work. ITIL even encourages continual improvement.
“Aren’t we just building a help desk?”
No. We’re building a trusted service function. That’s a different posture: empowered, structured, and focused on outcomes.
“Isn’t ITIL too heavyweight?”
Only if you implement it blindly. Like any framework, ITIL should be adapted to your context. You don’t need every process day one.
The Bottom Line
Not every data team should be a service team. But in most organizations, where demand outpaces supply and stakeholders need clarity, a service-oriented data team grounded in ITIL may be the most sustainable, scalable, and effective model available.
It took me ten years to come to this conclusion. I hope it takes you less.
