Grab that basilisk fang and drive it into the heart of Tom Riddle’s diary. Wield Anduril and jump from the ramparts of Helm’s Deep. Seize Excalibur and slay your ancestral enemy: the service desk — eternal foe of data teams.
In the three years we have spent building Workstream.io, I have spoken with many data leaders about their most hated tool: the “service desk” used to manage the requests of others.
I use the term “service desk” broadly, because there are a lot of different ways that data teams do this.
One of our customers has a Slack channel called “data-sucks.” The name itself tells you much about people’s feelings. Other teams use Google forms, have implemented a tool like JIRA Service Desk, or, worst of all, leverage some horrifying combination.
Teams debate the ways that they can prevent, or reduce, these requests in the first place. Should we just make requests more difficult? Is it, perhaps, our team structure that exacerbates this problem? Are we stuck in the service trap? Do we need to invest more in proper documentation and training? Should we do more to enable self-service analytics?
These questions are asked, initiatives are undertaken, and on the other side is a terrible truth: the questions of others remain. As does the visceral, emotional and almost primal reaction of data teams.
And our stakeholders? They still hate making the requests, too.
Why do we all feel this way, and why are we still unable to do anything about it?
‘Why are data teams so bad at this? There are so many teams that have these intake [processes]—IT teams do it, engineering teams do it, design teams do it. Everybody has a ticketing thing, but you don't hear about engineers being like, ‘it's chaos.’ Is it because data stuff is fast enough to answer that you don’t need it? Why have we failed miserably at this when other teams have figured this out?’
– Benn Stancil, Chief Analytics Officer & Founder, Mode Analytics
Data teams hate their service desk because we want to focus on what we view as high-value, strategic work. (And we are right to do so).
Responding to service requests can often make us feel like we are not respected and do not contribute real value to the organization. These feelings are natural and inevitable for anyone who feels their role is overly “transactional.”
Yet this loathing is about far more than just the tools themselves. After all, the current generation of “service desk software” is a significant improvement from anything that came before: boiler room call centers where agents struggled to support frustrated, angry customers that rarely got the answers they wanted. A random phone number where you called your internal IT team, and left a voicemail that your computer was broken. The support systems that we hate today – such as ticketing, or chat – were born as vastly better experiences than their predecessors.
So while we may gripe about JIRA Service Desk, and its clunky and transactional UI, our loathing is about something much deeper: that service experiences – with a few notable exceptions like Zappos – are generally bad.
So when we repurpose the tools designed to facilitate those experiences, we signal quite a bit to ourselves and our peers about how we should all feel and behave. Our reference point becomes quite literally, that time when you were left on hold for hours, or when the abusive, raging customer screamed outlandish requests and obscenities at you.
There is just too much baggage associated with our service experiences for us to break out of this cycle. This means that we tragically all end up unhappy, and our teams can’t fully leverage the investments made in our data.
I most likely do not need to reference recent thought leadership for you to already know that there is a debate raging in the community: are data teams product teams or service teams?
Unlike traditional customer service or product development, which are distinct functions, data teams are support, product and engineering functions, all wrapped into one. The same team researches and scopes out product, plans and executes development efforts, triages bugs, and manages the expectations of a large, complex set of others.
The reality is that every data team has to balance their “product work” – defining, scoping and building data products that accrue long term value – with their “service work” – responding to the diagnostic needs of the business. And while the latter may be exciting in the rare case when the request is strategic, it is much more frequently annoying, whether it is the need to pull a number, or action feedback on a piece of reporting.
We all intuitively know this, and it is why even the most compelling discussions about data teams as product teams include deployment of the hated service desk to manage the non-desirable whims and distractions of the others.
As a corollary, it is also this need to balance product and support work that leads us to recognize that, for data teams, agile is “the worst form of government – except for all the others we have tried.”
The normal argument applied for why agile is not the perfect fit for data teams is that data work is more iterative, with no predefined end to performing analysis or insights. And this is true. Yet I would also argue that agile is not a perfect fit because the workflow of data work is more interconnected, collaborative and less modular than what has come before.
Service desks and agile frameworks were designed to make predictable systems – with a measurable input of tickets and a measurable output of features (or answers) – more efficient. But neither does a great job handling unpredictable, complex systems – where, for example, the same group juggles being both reactive supporters and proactive builders. It’s a complex world with two (or more) competing centers of gravity.
Despite their mutual deficiencies, we implement them both – thinking that if we can only manage expectations, or set clear priorities, these tools can be complementary. If we are smart, we can break out of the cycle. But ultimately, we fail in some way and still blame our service desk. After all, it represents all that we hate, and takes us away from that which we love (building data products).
We often think that the form factor of our service desk is the determining factor of our success. But is this really true?
One option – managing and delivering requests in a Slack channel – optimizes for collaboration and speed. Conversations happen between people, and are public for anyone following along. The argument for this model is that data conversations are not different from any other conversation in your organization, and they should be treated as such. But messaging is notoriously chatty, poor search leaves the conversation nearly untraceable, and expectations of nearly instantaneous response time are the norm.
Hence the most mature data teams, those that manage complex systems of technologies and people, and who execute the most ambitious projects, typically leverage some formal ticketing solution. This path helps manage expectations on response time, and frees teams from the constant interruptions that prevent deep work. Yet it sacrifices the speed by which people receive answers for the efficiency of those delivering them.
What both form factors miss is that data teams are not in service to others – nor are others in service to them. What they all miss is that we are, rather, all in service to each other, and dependent on one another.
We hate our service desk because its design forces us to make a decision on who should wield the power: ourselves, or the others? Is there a way out of this tragic cycle?
Yes! Kill your service desk and replace it with something new: a data concierge.
With a data concierge in place, teams can dramatically reduce the number of stakeholder questions, freeing up valuable time for your data team, and increasing the adoption of your data assets. A data concierge encourages better, more contextualized conversations and speeds the creation of shared consciousness of your data that helps us break free from the dreaded service dynamic that plagues so many teams.
In our next installment, we will dive more into the concept of a data concierge and how it can imbue shared consciousness of data in your organization.
Download our free e-book to learn how to kill your service desk today.
In this article, we discuss how data-driven teams can tame entropy and empower stakeholders with a single access plane for analytics.
Data asset entropy has been an issue for as long as data has been used in decision making. But in the modern organization, where analytics tools have exploded in number and type, entropy has become a huge stumbling block to effective data-driven operations.
The goal of your workflow is not just to uncover valuable wisdom from your data. It is crucial to communicate those actionable data observations to the organization which can use them to make decisions.
Receive regular updates about Workstream, and on our research into the past, present and future of how teams make decisions.
