Data Teams: Kill Your Service Desk

Can we transcend the service desk trap, while still satisfying the needs of business stakeholders?

Photo by Jaime Dantas on Unsplash

Seize Excalibur and slay your ancestral enemy: the service desk — eternal foe of data teams.

In the two 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?

Because service experiences suck

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).

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.

Because data teams are neither product nor service teams

There is a debate raging in our community about whether data teams are fundamentally 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’s 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 both 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).

Because service desks are about power dynamics

We often think that the form factor of our service desk is the determining factor of our success. But is this really the case?

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 conversations 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?

3 ways to kill your service desk

Ultimately, the success of teams is not about the efficiency by which we deliver requests, or deliver feature stories — but by our ability to create a shared consciousness about the data that pushes our organization forward.

As explained by General Stanley McChrystle in his book Team of Teams (Portfolio/Penguin, 2015), the modern world is “complex,” where the speed and interdependence of activity makes it “impossible to tell which events might lead to what kind of results.” Traditional systems and teams are — to put it simply — linear and modular. Systems are designed to transform inputs into outputs, be they ore into bars, vehicle parts into cars, or customer issues into resolutions. Personnel can be divided into modular sub-teams performing specific tasks, where relatively little context about the prior or next step in the process is required to fulfill one’s role.

In contrast, complex systems are multi-dimensional and interdependent. Inputs come from multiple dimensions simultaneously, and outputs follow any vector. To handle this world, team members need both shared consciousness — sufficient understanding and compassion of the work of others — and be empowered to execute — meaning they can leverage their knowledge to make independent decisions.

This is the world that data driven teams inhabit: a complex one. It is the space between data people and the others, where every person needs access to the shared consciousness required to execute at any moment. It is a world that traditional management systems were not designed for, nor can even fathom.

Building on General McChrystle’s concepts, here are 3 suggestions for transcending the service desk trap, while still satisfying the needs of business stakeholders:

1. Proactively build documentation that lives and breathes with your team. Most data teams already maintain some documentation for end users. This documentation usually lives in traditional formats — as a one off Google doc, or a corporate intranet that is completely separate from the data asset itself. But as Drew Banin, co-founder of Fishtown Analytics, indicated in his seminal talk “The Post Modern Data Stack” delivered at Coalesce 2020, content and conversations need to live in line, so that it’s easy for everyone to access and consume: “In the future…we will have dedicated mediums to discuss data in context. This is going to come in two forms. One is for pushing out data to consumers…in this feed consumers will be able to subscribe to the information that is relevant to them. Another medium…is that you and your peers will be able to have conversations about your data in context.” Building on his ideas, I believe this will include:

• Frequently asked questions. Repetitive questions from business users are a burden for data teams, and a huge waste of your time. With better documentation, those repetitive questions can be promoted and made public for any user to discover.
• Training content: this can include recorded videos or a written how-to guides, maybe on how to self-serve, best leverage basic functionality like filters, or understand the underlying data.
• Lifecycle and certification status: make it clear to end users where an asset is in its lifecycle, and if it is actively supported by your team.
• Status page: Consider using data quality and observability solutions, or even dbt, to build and maintain “status pages” for your most critical data assets. This lets end users understand if the data should be trusted without asking you.

2. Invest in understanding your users. Truly understanding your users is critical, otherwise how can you build solutions that meet their needs?

This begins at the beginning — before you build anything. You need to understand the problems the business experiences before you even consider a solution, or where to focus your efforts. And once you start building something, be sure to engage with others collaboratively to get their feedback and establish trust.

Over time, invest in understanding your users — both anecdotally and proactively. Conduct user interviews to understand what folks use the most, and how it informs decisions that they make. What are the common pain points they experience when interacting with your data?

You then want to triangulate subjective feedback with numbers. Mine whatever resources are available to understand what assets are trending in your environment, and are regularly used.

Through all of this, you can better understand where your work is most valuable, and where your roadmap should be headed. And if you can understand how your products are used, you have unique insight into how data fits into day to day decision making.

3. Consider implementing a data concierge solution to provide everyone with knowledge about their data, whenever and wherever they need it, on demand. A data concierge frictionlessly imparts the understanding of one person to another. It orients the user to exactly what they are reading, and it validates and contextualizes its source. It helps them understand what questions others have asked, and not only what the answer was, but what was then done about it. It treats every piece of data, and every output, like a product people need to be onboarded to, and it teaches them how to use it correctly.

Conclusion

In the next 10 years, every organization will be using multiple tools to consume and analyze data. Data teams will never reach their full potential if we continue to be bound by the constraints of tickets, prioritized backlogs, and power struggles. In order to operate in a truly data-driven manner, we need to rise above the misperception of “us versus them” and find new ways to collaborate with “the others.” The service desk, one of our most collectively maligned tools and activities, will be replaced by something that we love and which helps us work together more effectively.

We need to take an active role in shaping our future, to ensure that everyone — data practitioners, and others — are alway empowered by the collective knowledge of our most important asset: data.