Legal teams need specialized tools. IT teams want consolidated tech stacks. How do they bridge the divide?

Custom operating stacks are part and parcel of successful business operations. For IT, there is Okta, Microsoft and G-Suite. Sales teams have Klarity, Gong, and Salesforce. There’s Netsuite for finance and Workday for HR. For some time now, a significant missing piece of this rapidly growing quilt has been bespoke technologies created for in-house legal teams. Despite being a ubiquitous function, not to mention one of the most expensive and sought-after resources in any company, most legal teams are still left to make do with systems that were ultimately built for something else. 

There is a clear need for systems that have been purpose-built for legal teams and the specific problems they solve, a core stack for the function. The General Counsel at any modern company should have a standard operating stack in place, but that’s simply not the norm today. At least, not yet. But the burden on legal teams is only going to increase as regulations around data and enforcement come into place. They will be starved for help. We are starting to see the first of these purpose-built systems come to market and transform operations for legal teams, but there are still so many more toiling away in abject misery, utilizing solutions that were initially designed to solve an entirely different set of challenges. 

This can lead to a disconnect—or worse, a combative relationship—between legal and IT. Technology teams want to own the technology stack. Highly specialized experts want to select their own tools. There’s a divide there, and one that has to be bridged to ensure any semblance of long-term success. But how? 

For more insight, I turned once again to friend and expert Kathy M. Zhu , CEO and co-founder of Streamline AI and former Associate General Counsel at DoorDash.

Let’s start with the foundational questions. What are the types of technologies and tools modern legal teams need? Why?

Having the right tech stack in place is critical for efficient operation of any legal department. In terms of the fundamental elements, priority one is intake. Legal teams need a tool that can manage their front door and help with reporting and workflows. This is the essence of what we do at Streamline AI, bringing all intake for legal requests into one place for automatic workflow routing.  

If a legal department is managing a lot of outside counsel work, they’ll also need an e-billing solution to manage and monitor these expenses. If they have a heavy litigation docket, they’ll need an e-discovery tool or specialized litigation tools.

But above all, legal teams do not want to be stuck with a generic system, because that can create all kinds of downstream problems. Referring back to the billing example, legal teams don’t bill the same way a technology vendor does, so using a generic billing system isn’t going to cut it. And yet, that’s often what legal teams are left with – attempting to retrofit their needs to a system that doesn’t account for those needs. 

Let’s talk about the internal dynamic between legal and IT that comes into play when buying/deploying a new tool or technology. Legal teams often encounter resistance from IT around new tech. Why do you think that is?

I think a lot of it comes from IT truly understanding the nuances of how Legal performs its work. There is not a clear understanding of how matters are managed, how work gets outsourced, and how outside counsel bills their time. Everything is different than a standard vendor dynamic, the way it is when you’d bring on a SaaS vendor, for example. If IT understood those nuances, they’d understand the need for specialized software that caters to specialized workflows. 

This disconnect makes IT feel like they are dealing with another case of a business team simply bringing in their favorite tech, and that’s how a company ends up with six different tools to do one thing. It’s IT’s job to root those out and find one tool to consolidate and save the company money, so that will always be the first priority. It can be difficult to make IT understand that there are real exceptions to that rule, and that there are teams that can’t function properly with a generic tool. These attempts at saving money can easily backfire, creating a need for a dedicated resource to keep it afloat when it would have been much easier to put the right tool in right off the bat. 

What do you see as the key to forming a successful partnership between legal and IT?

It’s extremely helpful for the legal team to come in with examples of failures caused by generic solutions and success with specialized tools. I spoke to someone who runs the compliance department of a public company and he spent four years configuring a generic tool to do what Streamline AI already does right out of the box. Having these types of stories is certainly very powerful for us when we make our pitches. 

Also, legal teams need to come to IT prepared with detailed specs around what the product has that generic software does not. Show real use cases for your team. Price it out against the opportunity cost of using a bad system while you wait for the right one, such as how much wasted time, money, and effort would go into that.

When I talk to lawyers, they are split into two camps. The first are convinced that generic tools will never work for them. They tend to fight harder for specialized tools. The other camp are people who are more easily swayed by IT. With the latter, IT usually tries to convince them to do a three-month proof of concept with a generic tool first and it almost always delays the process, causes negative externalities, and bogs down work queues. This process is exhausting both for Legal and IT. 

You hire legal experts because they know what they need and know how they work. They need to approach the conversation with conviction, with examples and data. They can’t be on the fence about what they need and why.

What does it look like if that divide is not bridged? What are the downstream consequences you alluded to?

We have examined the impact on legal teams and their productivity when they’re asked to “make do” with solutions that are not purpose-built for legal teams. One of our customers shared that they tried to use a generic tool and were forced to adopt a prioritization system that was designed for bug fixing, not legal work. He couldn’t implement a more detailed legal prioritization matrix even though he knew what the issue was. This other system was originally designed with engineers in mind to address engineering tickets, and it was not a good fit. Being able to implement a legal prioritization framework to triage legal requests helps Legal understand where to allocate resources and determine appropriate timelines. This helps Legal work better and more efficiently with their business partners—meaning faster deal closures, better risk management, and improved business operations. 

A key aspect of legal communications is ensuring that there are guardrails put in place to protect sensitive and privileged information. If a system cannot adequately protect privileged information, and ideally, provide that level of protection out of the box or with minimum configuration, it’s not a great tool for a legal department. Legal tech needs to have a higher standard built in out of the gate.

Another consequence is not being able to accurately measure ‘waiting on’ time. When a request gets sent to Legal, there’s one aspect of Legal actually working on the ticket, but then Legal hands it over to other teams to wait for their input. A generic system only measures while the ticket is in review or completed, not the waiting on time. That nuance results in Legal taking the hit for things taking a long time to close even when something wasn’t with them for review. This factors heavily in Legal’s brand management problem (LINK TO FIRST PIECE). Being able to show how fast your team turns things around versus how long they’re stuck in review is a huge part of deconstructing that notion.

What does it look like when IT and Legal are collaborating successfully in this area? What does a good process look like?

Ideally, both teams are sitting on the same side of the table, trying to problem solve together instead of IT trying to defend their kingdom against Legal, pushing back on everything they’re being asked to approve or do. If you’re solving the problem together, the spirit of inquiry becomes very different. 

Through that process it becomes much easier for IT to see that Legal really is an exception, that the proposed tool accomplishes a specialized task that will accelerate and empower one of the most expensive and hyper-leveraged resources within the company. Then you start looking at how to scope this together. What are the tasks that IT needs Legal to take on? When it’s healthy, each side is relying on the other to understand that they know what they need best. 

Something we have started to see recently is that SaaS budgets are getting consolidated with IT, which is having undesired consequences. If Legal doesn’t own its own SaaS budget and can’t proactively go to IT for the 2-3 tools they need that year, they’re going to get short shrift and deprioritized. They’ll have less voice and agency in the process if they don’t control the budget, and therefore won’t have as good a chance at getting the tools they need.  

When a legal team wants to add a new tool, who should take the lead? Should legal do the initial search and then come to IT with recommendations based on their needs, should IT lead the search based on tools compatible with existing infrastructure, or should the process be a two-hander right out of the gate?

Legal should be the tip of the spear in finding the right tool if they have the time and resources to do it. They’ll know the market more deeply than someone in IT—they’re in those conversations all the time with colleagues and peers. If they’re not as well resourced, or not as well versed in technology, they certainly can hear about a legal tool in a forum and then go to IT and conduct the evaluation together. 

But Legal still needs to bring the details and their requirements—to say, “I need a tool that can do x, y and z.” But expecting IT to understand those nuances without help is not going to make for a good outcome.

Legal needs to be the driver, but involve IT in the evaluation process early on with clearly set dates, milestones and tasks. Looping them in early on is never a bad thing, but don’t expect them to run the ball for you.

Once a new tool has been decided on, what does an effective deployment look like? Who typically leads the way?

I think it depends on the tool. If it’s a no-code platform like ours, legal ops are just taking on the majority of the work and they need very little support from IT. If it’s not, like many e-discovery tools, you’d need heavy IT involvement to understand the data mapping, connect the different pipelines. If adjustments need to be made in the future, direction has to come from Legal and IT has to provide assistance. 

To my earlier point, Legal often falls down the line in terms of resourcing which can have pretty dramatic implications. I often found that I had to pound the table to be heard, which is not a position that benefits legal teams or the organization they work for. In one case, for example,  it meant that I couldn’t update policies that were on our website in a timely fashion—even though they had significant  implications around compliance. 

Legal and IT teams will have to collaborate more and more often with the emergence of new and more advanced technologies. What final advice would you give to other legal pros as they find themselves working more closely with IT?

Perhaps most importantly, Legal needs to build and nurture their relationship with IT early, not just when they are coming to them with a need. They need to build up that relationship so that when something eventually does come up, there’s already trust formed between them. It’s just human nature. People work harder for people that they like.