Breaking down silos

We're at the beginning of a new era of work, probably in more than a few ways. The rise of remote work, globally connected teams, and the increasing size of the knowledge worker pool are all creating a new working environment. The tools we used to do our jobs in the last century are not serving us in the new one. We need ways to stay connected, to work deeply together, while being flexible enough to communicate across time zones and zip codes, all while keeping up with sets of departmental needs that continue to become more specialized.

In the early part of the 20th century, business owners learned to segment parts of their organizations and run them like independent operations — manufacturing and accounting, sales and supply chain management, and eventually software development, product design, marketing, and customer support. The last century was the era of specialization and efficiency. It was the golden age of Henry Ford, Taylorization, and the Toyota Way.

Photo by Birmingham Museums Trust on Unsplash

Times change

A lot has changed in the past hundred years, though — even over the past thirty years. As teams and departments have become more specialized, they have also grown closer together. We've learned (or at least, I hope we've learned) that sales and marketing have a deep impact on software development, and vice versa. And that changes to financial models impact how supply chains are managed as much as they impact how app interfaces are designed. Within any individual company, no matter how large or small, the work of each team is interconnected in a multitude of ways.

Teams need to connect with each other and communicate across their functional borders constantly. Customer support teams at tech companies need to work with product, design, engineering, sales, marketing, finance, and operations teams daily. They need to keep up with what's being delivered to customers today and what's in the pipeline for tomorrow. Meanwhile, they have to talk to all of those teams in the course of solving incoming customer issues. The bulk of the job, however, consists of working directly with customers. This one functional area is working across nearly every team boundary — including between the company and their customers — every day.

The tools the teams use, though, are typically custom built for the core function. Customer support tools (primarily help desk software) are almost entirely focused on organizing communication with customers. The team needs the level of detail, organization, and specialization that these tools provide, but it comes with a downside — the support teams become siloed in their ecosystem. While this is happening, the same situation is playing out among other teams. Engineering teams are siloed in their code and ticket systems and design teams are siloed in their systems and tools.

This has led to growth in cross-functional communication tools — real-time chat apps are a primary example. Every team has their own team-specific system in which they work, and then everyone in the company also works in the company-wide communication/collaboration tool. This has been a popular way to operate for about a decade now, and the recent spike in remote work and distributed teams has caused it to explode over the past few years. It's partly a way to mimic the in-person office experience and partly a way to compensate for the rise in team-specific tools and channels. It may feel like things are going smoothly at first, but very quickly people feel overwhelmed with the number of channels and systems they need to pay attention to in order to keep up with their work.

A lot of function-specific systems try to solve the communication problem in a couple of different ways. The most common method seen in customer support tools — and many others in different functional areas — relies on system integrations. The core software that the team works in has all the features the team needs to complete their main job, which is primarily talking to customers. On top of that, the software will usually integrate with the most popular tools that other teams use — project management tools, sales CRMs, general company communication platforms, and others. The idea is solid: give the team the best tools for the job they need to do and let them pass information to other teams directly through their tools of choice.

This breaks down in practice, however, when teams discover that communicating with other teams is one of the primary jobs they need to do. The most common integrations are one-way communications at best, displaying information from a support ticket in another team's system. The teams still need a way to work on problems together, rather than throwing information over a metaphorical wall and hoping for the best. In the best cases, those cross-functional partners will see the notification and jump into the customer support tool to help. More commonly, though, the customer support team has to go into all those other systems to follow up on the notifications that their integrations posted there. The tools gave them bridges to carry information out of their system, but they don't carry very much and they have a high one-way toll.

Another way to solve the problem is by bringing everyone's work into a common space. This shows up most often in the larger chat platforms, but it can also be seen in some other places. The logic is that as long as everyone in the company is already there, let's move all of our work out of our function-specific system and into the common space. It's compelling, but it doesn't pan out over time. Teams need the data and workflows that come with their function-specific tools. Customer support teams are more efficient working in help desk software tailored for their problems and jobs. And while managers and consultants like to talk about efficiency, the team members feel it in the form of friction when trying to do basic day-to-day tasks. It may be possible to give a chat app the ability to manage large teams across multiple high volume support ticket queues, but giving it the smooth experience of a custom-built support tool is a high bar to meet. And giving it the smooth experience of a custom-built design tool, developer tool, and sales tool at the same time is too much to ask.

Teams are finding that they benefit from having tools tailored to their work and from having easy, open communication workflows with their cross-functional team partners. In many cases, teams feel like their particular issues are unique to their team, company, product, and problem space so they start building their own solutions. Companies will sometimes have an internal team dedicated to building internal integrations and tools to solve these communication problems. It usually works…at first.

Building a suite of internal tools and sub-systems for the myriad web of internal teams at a company is not a small endeavor. Unless that is the primary job of the business, the work of updating and maintaining those tools is often deprioritized in favor of customer-focused — and revenue generating — development work. The end result is that internal teams like customer support find themselves using a cluster of half-developed tools, unmaintained scripts, and loosely connected off-the-shelf systems.

The future is interconnected

Teams shouldn't need to build their tools themselves. Systems should offer a powerful set of easy-to-use APIs, because that offers a lot of options for people who want to customize their systems for their use case. However, the tools teams use should be useful without those APIs. Customer support teams should not require a dedicated operations team or internal tools team to keep their systems running.

The future of support tools should be built for the people who use them, by people who understand the deeply specific needs of their teams. They should prioritize low-friction workflows and ease of cross-functional collaboration. Two-way communication between multiple systems should be the norm, and it should be standard out-of-the box rather than tacked into place with a series of half-featured scripts by teams who don't have the bandwidth to maintain them.

Today, companies are building tools for yesterday's teams. Teams work more closely together than ever before, often distributed across zip codes and time zones. People should be able to stay in their system of choice to do their work, and be able to work from there with anyone else at the company. Systems should offer deeper and richer integrations between tools so that people can get their jobs done whenever and wherever they are without the friction of working across a dozen noisy apps.

The future of customer support tools — and all function-specific tools — will be interconnected out of the box. We're building Yetto because we've been frustrated by this for years, just like thousands of other teams. We can't keep waiting for the future.