Attention all legal operations professionals! This episode is for you. Legal Ops consultant Lyndsey Cain of LegalEng is in The Legal Department to talk about how to make your legal tech implementation a success. From identifying a non-IT leader, knowing your goals, having a comms plan, and an ongoing governance structure, Lyndsey shares that success is more than “just the tech.” She also shares tips on vendor engagement, negotiating those implementation services, and how to navigate tech updates.

—

Listen to the podcast here

    

Do This Before You Spend $$$ on Legal Tech with Lyndsey Cain Of LegalEng

My name is Lyndsey Cain. I am the Vice President of Legal Operations Services at LegalEng Consulting Group, LECG. A fun fact about me is that I am a plant lover. I have about four dozen plants at my home. My personal favorite is my ten-foot bird of paradise.

‐‐‐

On this episode of the show, I’m excited to welcome Lyndsey Cain. She is Vice President of Legal Operations at LegalEng Consulting Group, LECG. She’s a legal ops professional from the New York Times and elsewhere. I’m excited to delve into how to implement your legal tech.

‐‐‐

Lyndsey, how are you?

I’m well. Thanks for having me.

In my department, we’re looking at some new tech solutions. As you’re scoping this, you’re meeting with vendors and doing an RFP. It can seem easy. They show you the demo and say, “Look at how easy life is going to be,” but as we’re going to talk further, it’s more than the tech.

That’s right.

Lyndsey Cain of LegalEng

Before we dive in with that, legal ops is somewhat of a new-ish specialty. I’d like to hear a little bit about your background and how you got into it.

I’m delighted to share. I’ll spend a bit on how I got to legal ops, which helps explain my view and the lens through which I think about operations. I had different roles within pretty large contracting firms and then started working at the New York Times, which was my dream job. I was in strategic sourcing there at the Times for a total of almost a decade in strategic sourcing. A role opened up in the broader legal department to reimagine the way that records management is handled at the Times, which is a big undertaking. It had been done the same way for nearly 30 years, so a very tech-forward GC was interested in digitization and reimagining what that looked like.

For legal or the record retention and management for the larger New York Times organization?

For the larger New York Times organization. This was the 2018 timeframe. We’re talking business records, not information on a large scale like data management or information management. This is, by and large, legal records, but for the whole organization. We were thinking through what the records retention policy and schedule will look like and how we will handle things that are largely on paper and get those digitized, online, and accessible. I took on that role, jumping from strategic sourcing, where I had been for about five years, into the legal department. I knew nothing about the legal department other than the way I interacted with it in my limited strategic sourcing role.

The Misconception Of “Set It And Forget It”

I get that. That’s super helpful. It’s an important grounding as we dive into this conversation because, when you are getting the pitch and sitting through the demos, it’s like, “This is an out-of-the-box solution,” etc. I think that it’s a misconception and a sales approach. It’s like, “For busy lawyers, this isn’t going to interfere with your day-to-day. My solution can set it and forget it,” but as we’ve talked and as we’ve gotten to know each other, I know that’s not the case. Can you share why that is a misconception that is a set-and-forget?

The misconception comes from two places. One’s on the sales side, like, “Let’s sell them something that they need, but make it a little bit easier.” The desire for it to be easy is how that misconception continues.

Understanding Tech Implementation In A Legal Team

We want to believe the sales pitch. Let’s talk basic. What is an implementation?

I consider an implementation to be everything involved from the process all the way through launch and beyond. Going back to this misconception, when you think about implementation, everyone thinks about the technical configuration or light tech work to get this thing out of the box to operational.

That’s what I think. I think, “I’m going to buy this. My IT team is going to figure out what the integrations are with other systems, and then we’re going to be using it.”

That common misconception of, “I’m going to buy the thing, pass it to IT, who’s going to implement it, and all my problems are going to be solved.” That goes into that misconception as well. Where that’s misplaced is that it’s not solving your use case. Before you ever purchase the technology, you need to be thinking, “What are my pain points? What am I trying to solve? What are my goals? Is this tool the right thing to solve whatever the slate of issues is?”

Before you ever purchase the technology you need for your team, think about your pain points, goals, and the problems you are trying to solve. Share on X

From the get-go, before we even sign that contract, we are being very clear about what our objectives are and what the problem we’re trying to solve is.

That’s correct. There’s that, “I need to buy an e-billing tool because everyone has an e-billing tool.” Everyone should. It’s a great piece of tech. When you’re like, “I need to buy an e-billing tool because everyone has it. This is the name I know. The demo looked good,” it’s thinking about, “What am I trying to solve? Am I buying something that meets those needs and is robust enough in its reporting? Is it creating settings that are specific to our outside council guidelines?” You need to think, “What am I trying to solve? How is this tool helping me advance that?” You need to think about that along with the process as well.

That implementation of the technical piece is misplaced. It is all of it. You start with identifying, “What are the challenges, goals, and objectives? How will technology help me solve those?” You then think about, “What technology am I going to get? How am I going to implement it?” What I think is most important is, “How am I going to change people’s processes and get them to adopt this thing? How am I going to keep it fresh and innovative going forward?”

All of that whole thing is an implementation, from the point of your objectives through the technical, training, change management, comms, and post-implementation governance of ensuring that I have, number one, the resources to continue managing this thing going forward and to implement new features. All of that I consider to be an implementation.

Understanding The What And Why Of Tech Implementation

Let’s break it down step by step. First is the what and the why. We’re like, “These are my goals. These are my objectives.” Once we pick our shiny thing, we do our RFP. I’m in the middle of this myself, so I’m like, “IT, this is what I picked. Make it happen.” What should my next step be?

I am going to push a little bit on the, “IT, make it happen.” Every organization is different. I’ve had the benefit of working at organizations where those implementations are legal-led and IT-supported. That is the most successful, unless you’re talking about a large enterprise tool that is going to be used by many departments, not just legal. I do think that the most successful legal tech implementations are legal-led. IT is going to come from a very different perspective and lens. That’s not to say that’s a bad thing, but it doesn’t understand your use case. It doesn’t understand your business.

Let’s pause then. What does it mean to be legal-led? I’m the general counsel. There is no way I have time to project, manage, or lead the rollout of any kind of tech. That is a no.

That would be where legal operations comes in if you have a legal operations professional.

It could also be a consultant.

A team or a consultant to lead that for you. They are the ones who are the program drivers of this thing. They are at the head of the decision-making, pulling together all of the stakeholders, executives, and support. When you pass it full-thing over to IT, you are removing legal from having not even a seat at the table, but driving the direction of that project.

The second step, then, or maybe even earlier, is to identify your quarterback on your team, either in-house or with an outside resource, who knows the objectives of the department, knows the vendor, and is helping to guide the whole rollout.

That’s right. I don’t think that’s, in most cases, best done by IT.

I want to ask, though, too. Is that best done by an in-house lawyer and not even the GC?

I would particularly say no. If you have a lawyer on your team who is particularly interested in technology, operations, and process improvement, I have found in my experience, and this is not everyone’s experience, but I’ve worked with many in-house legal departments as a consultant, most of those lawyers are already dealing with heavy workloads and full plates.

This is not something that would be a high priority. I find it’s best done by other staff in operational roles. I would have a lawyer or many lawyers, depending on the tool you’re rolling out, as stakeholders, so that their input is being sought, and they are signing off on, “This fits my needs,” or, “This is appropriate for this use case. They’re not necessarily the ones who are program managing it. It’s a lot to do.

To do it well to get what you want out of it.

In some cases, depending on the size of the apartment, you don’t have a way around that. When you can, I would recommend having someone with an operational or project management background.

The Right Way To Handle Change Management

Our company has project management. I’m wondering if folks can borrow resources from other departments or use a consultant like yourself. I feel like that’s infrastructure to get the implementation. You do the scoping, and you see the functions. I want to get into this. You mentioned change management. It’s like, “We’re going to buy this tool. We’re going to hire Lyndsey or somebody like her to help us roll it out. Is anybody going to use it? Right? What do we learn in the process of rolling out the tool about our own work habits and how we’ve been doing things?”

At risk of going on a tangent, you’ll stop me if I am. I feel like change management is so near and dear to me. If anything, I over-index on that a little bit. I’ve said this to you. The way you implement or roll something out is as important as what you select. That starts at the beginning, which is making sure we have executive sponsorship.

The way you implement or roll out tech is as important as what kind of tech you select. Share on X

You’re making sure that this isn’t something that’s being done without sponsorship from the top to where you’ve built this great thing, and then they say, “Why’d you do that? We didn’t approve of you changing these processes.” You’re making sure that everybody’s aligned from the top. You make sure that your stakeholders are aligned both within the legal department and if the tool touches outside of the department as well. You’ve got the right resources in place. You take an adaptive mindset and challenge the status quo.

When you get down to the change, I have these monikers around how, who, and why. The why is important in explaining to people. That’s where the communication comes in. You communicate early and often across multiple channels. Sending an email to say, “We’re going to have this new system,” and then not telling them about it again until the launch is ready is not helpful.

It’s thinking through, “Are there newsletters? Are there Slack or Teams channels we can communicate in? Is there an all-hands that we can get a sentence or two at the top of?” Maybe it’s department meetings, etc. It is communicating the why, which is like, “Why are we doing this? What’s the purpose? What’s the impact? What are we asking you to change?”

You communicate it specifically in clear, concise, and consistent language, but you also tailor it to your stakeholders. The way you communicate with the legal department and those who will be using a tool in that way may be different than how you would speak to the broader end users who might be having to send in requests into a CLM contract management system. That’s one piece.

The who is going back to having that leadership and stakeholder alignment and engagement. I’m a big fan of bringing in people who might not be too keen on the change. I bring them in early. It’s good because it makes your perspective on the end product that you’re going to roll out better to have those voices heard early on. It’s also to make sure that they understand the use and can help to configure it as well.

The how is, “How are we going to deliver this specifically to the organization? Is the organization change-ready or change-resistant? Can we direct from the top down, or do we need to bring people along with white glove service? How do we want to train? Do we want to do it in person? Do we want to have things available for self-service? How do we want to monitor feedback and collect that constant monitoring and improvement?”

All of those things go into effective change management. I could nerd out on this all day long. These are the things that people don’t think about. They think, “We built it. Now, use it.” That doesn’t work that way. People don’t work that way, unless you have a top-down authoritarian where everyone must do the thing, which is not most organizations. You have to garner that adoption.

Even if you did build it and use it, you’re not going to get as much out of it if you’re not bringing people along and showing the why and why it makes a difference in their day-to-day.

When you explain the why, with what I was saying earlier about tailoring that to different people, the why for legal could be different than the why for the end user. I’ll use contract management as an example. The why could be like, “In the old days, you would submit a contract request to us, and you didn’t know what happened to it until you heard from us two weeks later. Now, when you submit it, you can track it. You can see full transparency of where it is in the process, what needs to be done, and who it’s bottlenecked with.” You’re telling them their why.

The “why” for legal could be different from the “why” of the end user. Share on X

It’s different than legal’s why, which is like, “You can more effectively manage your queue. Now, we have AI to be able to help you better review contracts and implement our playbooks.” There are different whys for different people. Explaining those in a common language to those people is going to be important. I could go into this for days. Also, thinking through specifically what our KPIs are, how we track and measure those as well, and how feedback ties into all of that is important for successful long-term adoption of a tool.

How To Get Buy-In And Engage Stakeholders

Let’s talk about that stakeholder group. It resonated with me that I can’t give this to a lawyer on my team and say, “You’re in charge of rolling out the matter management tool.” That’s not going to be successful. Also, I can see that the lawyers on the team may not care or may not think that I don’t have time to make it happen. How do we get buy-in for doing this at all and engaging that stakeholder? Certainly, the communication, I get that, but other than telling people, “This is what we’re doing. I need you to participate,” how do we get them pumped up about implementation?

It goes back to the why. It could be different for different practice areas and different groups. I’m also a big proponent of where you can, only bring in very busy people when it’s impactful and when their voices truly need to be heard. When I build out a project team, I’m specific that we’re not going to invite every single person to every meeting because then people get fatigued, annoyed, and, quite frankly, start to disengage. It’s like, “I’m going to be mindful of your busy schedule and bring you in for conversations in which I need to hear your perspective. I have these specific questions. We’re going to make good use of your time.” That goes a long way in project management.

It’s sometimes hard to do in large projects where there are so many moving parts and pieces on an enterprise scale that include everybody and everything. That puts a bad taste in people’s mouths. Especially for in-house legal, I’m very specific about engaging with them in the moments that matter, seeking their input, and then showing them, “This is how we’re going to implement XYZ workflow based on the input you provided. Is this on track? Is it not?” I’m not bringing them along for everything. That’s important.

Going back to the why for different people, I’m big on relationship-building. Once I’m in a legal department, I try to understand an individual’s workload. I’m like, “Is this going to free you up to do more strategic work? Is this going to make you be able to work more efficiently so you’re not working until 8:00 PM or 9:00 PM at night?” Think about the why for an individual as well when you know them. You can have that personal one-to-one conversation.

How To Onboard A Legal Team To A New Tech Process

That’s super helpful. We did a document management tool, which also feels pretty basic Stone Age tech. Many organizations I know are using their H drive or central server. I’m thinking about taking somebody’s practice and the process they’ve always been doing, where they’re like, “I have a folder under my Outlook inbox.” You asking some of how we work is very personal to us. Even if somebody’s attending the meetings and says, “Lyndsey says it’s going to be better for me,” how do you grab out of somebody’s clutches their way of doing things? How do you get them to get on board with a new process?

That could be hard. If people have been doing something a certain way for a long time, it’s hard to untangle that and think about a different, more modern, and dare I say, better way of doing it. We can use your DMS or your document management process. Number one, I think, “Are there ways that I can meet people where they are, to where that change is not as drastic? Can my DMS integrate into my OneDrive or my Google Drive?”

With a click, I can add it to whatever DMS you’re using. I manage NetDocuments. I’m not asking them to completely change. I’m asking them to take one step that’s going to get it where it needs to go. It is thinking through that, like, “Where do I need to wholesale change a process?” or, “Do I need to like, tweak certain things so that it can still get into where it needs to without completely overhauling?” DMS is a different example because it’s not typically too process-driven. It’s more repository and archival sort of stuff.

It is a habit change. For some people, there is a lack of trust in the new thing. They’re like, “Why do I have to do that?” or, “I’ve got my file system. I know where everything is.” I was describing it as basic tech, but it is a process change.

I get that. I’ve had an experience with that as well, thinking about records management. I would challenge the notion that it is working for me. Oftentimes, we hear the pain points are like, “I can’t find what I need. I can’t find what my colleague did. My colleague wrote this memo on XYZ. I can’t find the latest draft of the policy to update because it’s in someone’s local drive or someone’s local machine,” for example.

When I first start an initiative, part of the stakeholder interviews involves talking through the pain points. You can then go back and reference people who said, “It’s working great.” It’s like, “You all told me all of these different ways that it wasn’t working great.” They’re like, “Now that we’re faced with the actual change, we do think it is working great.”

I’ll go back to some of those early conversations and talk through, “It’s not serving the purpose. There are these challenges and pain points. Two, it opens us up to risk. If you have stuff on your local machine or your local drive, it can’t be accessed. Let’s say you’ve saved it in your local drive that is not being kept up-to-date with our retention policy, and we’ve kept something longer than we should have, that opens us up to risk.” Talking that language and explaining real-world scenarios where it’s not exactly working, even though it feels like it is in the moment, because they’re like, “I don’t want to change what I’m doing,” has been helpful. That’s been a successful way around that.

Handling Ongoing And Post-Implementation Governance

You talked about the stages of an implementation. We were talking about training, process, change management, etc. You also mentioned it’s not set it and forget it. There’s ongoing governance and management. Talk about what that means.

Another one of the things I could geek out on is post-implementation governance. That’s one of the things with my clients. Anytime I’m supporting an implementation of any tool or any process change, because it doesn’t have to be technology, I will work with them on what the post-implementation looks like. That is an extension of what would be a steering committee during the actual build, configuration, and training. Those post-implementation governance will be a set of individuals, typically an executive sponsor, a steering committee, a program driver, similar to what you had in an implementation, other stakeholders, and admins who are managing a system.

You’re doing a number of things. One is that you’re ensuring that you have resources to continue managing the process or the system. In a contract management system, for example, you have someone who’s in there who is able to add and remove people. They do administrative tasks. They ensure that if there are bottlenecks, we’re clearing those. We’re creating an environment in which people are able to successfully use this thing.

All of these tools are so iterative. The days are gone of, “I bought this on-premise tool, and I own it. Now, I’m never going to change it.” All of these SaaS solutions are coming out with, if not multiple times a quarter, quarterly releases of new features and functionality. Some of those you need to adopt into, or you could get into a beta to be an early tester of. How do you evaluate what releases, features, and functionality are going to be a value add for your organization and your use case?

Do those usually cost more money?

It depends. There are some new features and functionality that they are going to roll out. If they have a new UI or a new User Interface that everybody’s getting, you’re going to get it, too. You also need to be on the forefront of like, “Is this thing going to look different than it looked yesterday? How do I train and onboard people for that?” That’s one.

Two is there are going to be features and functionality that are opt-in but are free. It’s like, “Which ones make sense? Which ones are going to be more complicated than it’s worth to implement and will confuse people? We don’t want to do that right now. Which ones do I want to get early beta on so that maybe I can help drive the way this looks and functions?” There are going to be add-ons that are going to cost money. It’s like, “Is this going to be helpful for us to further our goals if we buy this module or this feature?” Have a committee that’s talking about that on a monthly basis. I recommend monthly for the first year or two after implementation and then quarterly.

Is this a vendor?

No, internal. Any good customer relationship manager is going to want to meet with you twice a year from the vendor side, so you’ll have that covered. I recommend that the internal governance committee meet monthly for the first year, maybe two, or whatever feels right, to quarterly. They’re assessing all of those things. They’re looking at, “What features are coming out that we could take advantage of, whether that’s going to cost us money or whether that is free? Any features that are going to be pushed upon us, we need to be ready for change and train people on.”

Also, you’re going to be looking at KPIs. One of the first things you want to do with that governance committee is think about the KPIs we had for implementation. How are they different for post-implementation and ongoing? It is looking at those metrics on a monthly or quarterly basis. This could be turnaround time. That could be self-service. That could be adoption.

Let me stop you for a second. Those KPIs, are we setting those at the outset? The tech company’s not telling me what those are. That seems like a good way to engage those stakeholders in the why and what we’re trying to get.

Those KPIs directly flow down from your goals and objectives. It’s like, “These are my goals and objectives. What Key Performance Indicators or metrics am I using to measure how effective I am at achieving my goals?” The vendor can be helpful in saying, “We have reporting to support you in being able to put these metrics together,” but a vendor is not going to dictate what your Key Performance Indicators would be. They can be helpful in thinking about the ways that they’ve set up their system to make it accessible for you to extract the data for those metrics, but they’re not going to be driving what your metrics should be.

KPIs directly flow down from your goals and objectives. Share on X

What You Should Ask Your Tech Vendors

That’s helpful. I want to talk a little bit about vendor management. Once we get the vendor, you said they should be checking in with us. As we’re shopping for legal tech, we’ll identify our internal quarterback, or we’ll hire a consultant, or we’ll have somebody who is going to run it for us. What should we be asking for from the vendor? They always have a line in there, like an implementation charge. You haggle with them about it, but it’s hard to know what you could get and what you should ask for. What do you recommend?

It depends on the type of tool you’re implementing and how complex the use case is. We’ll take e-billing, for example. If you’re implementing e-billing and you’re like, “I have no tool in place. I don’t have a ton of outside counsel legal spend. I need something off the shelf,” that implementation is going to be significantly less robust and complex than if you are like, “I have multiple different business units, complex accrual and forecasting processes, very long outside council guidelines that need to be configured, and dozens of matter templates.”

What I would have conversations with them about in the scoping of it is not only how many seats I need to buy and what modules I need, but also, “How can you support me in the implementation? Where are the implementation leads sitting time zone-wise? What sort of support do you all provide? What does the meeting cadence look like? Can you share with me an anonymized project plan? What support, if any, do you provide in training, or will I need to have internal training?” All of those sorts of things are conversations that should be had.

If you’re doing a formal RFP, it should be questions that are in that RFP from the get-go. If they’re not going to provide as robust an implementation of professional services as you need, you need to find someone who will. Oftentimes, some of the legal tech providers will outsource that anyway to third parties. That’s going to be important, too, having enough support on the professional services side from the provider.

How Legal Teams Can Get Up To Speed With Tech

Legal doesn’t buy a ton of tech. You might buy something once or twice in a 5 or 10-year period. It’s not a day-to-day thing. I’m wondering. If you’re advising other GCs here, where should they go to get up to speed on what they need to do? They go to a conference, or their friend uses XYZ tech, so they think the RFP or finding the tech and implementing the tech is, “I buy it. They told me it’s out of the box. I can go.” All of this background and intentional thought process around the project, goals, etc., how can we get up to speed? What resources are available to give GCs a high-level overview of what they need to know?

If I can push a little bit on the notion that we don’t buy tech a lot. I don’t want to overgeneralize. A traditional legal department does not use as much tech as maybe some of its counterparts. In the past couple of years, we’ve seen a lot of tech adoption. Something like a three-year legal tech roadmap is not uncommon. It’s something I help clients build all the time. There’s this notion that we don’t buy it a lot, but I don’t think that’s necessarily right.

It’s hard to generalize, but I’ve spoken with GCs at national companies who are managing their litigation on an Excel spreadsheet. I come from the nonprofit world. I’m the startup GC at this 130-year-old health system. There’s variation in the market.

If you have existing tech in place, part of that is re-evaluating that when that comes up for renewal. It’s like, “Is this something I need to sunset and replace? Is this something that I could further optimize? Could this problem I’m having be solved by existing enterprise technology that I could leverage across the organization?” Thinking through the technology is not always buying something new, but it is rip-and-replace, optimizing what you have, or using something that the enterprise provides.

There are a lot of handy trade organizations. CLOC, for example, is a great one to get up to speed on legal operations. There’s also Legaltech Hub. TechGC is another that can get general counsel up to speed on what’s going on in the legal tech world. There are tons of conferences as well. Those sorts of resources and groups are helpful, but oftentimes, you don’t have time to do that. If you can, outsource that to a legal operations head to come to you and say, “Based on our needs, I recommend we look at X, Y, and Z in our roadmap rather than you, who is doing 1,000 things, trying to get up to speed on what the tech landscape looks like in legal.” That is probably the best way to go about it if you can do it. You could also come to a consultant like me.

Rather than doing a thousand things trying to get up to speed on the tech landscape in the legal world, take a look at the different options available in your own roadmap. Share on X

I want to give a shout-out. I did an episode with Mary O’Carroll, one of my earlier episodes. We dove into the why of legal operations. At various points, I’ve had folks who have done a little bit of that, but I want to put a plug in, underlying your point here. It is a function of the legal department. You need to have some resource or a part of a resource that is thinking about how your department operates, including the tech and otherwise.

That’s right. That takes the burden off of you having to be knowledgeable in all things. You can focus on putting effective, smart people into roles where they can help drive your initiatives.

Lyndsey’s Pump-Up Song

That’s episode 23 with Mary O’Carroll. Thank you. This has been so helpful. You’ve given me a lot to think about as I’m scoping out my next tech purchase. To end on a happy, light note, I like music. I use it a lot to get my mood up. I was listening to some golden oldies, as my husband says. I was listening to some Chuck Berry and others. What is your pump-up song?

It’s always going to be ‘90s hip-hop. As an elder Millennial, that’s my go-to across the board.

Any song in particular?

Probably anything by OutKast.

Hey Ya!

It could also be their older stuff or their ‘90s stuff.

Thanks for being here. I appreciate it.

It was a pleasure. Thanks so much.

Important Links

• LegalEng Consulting Group
• CLOC
• Legaltech Hub
• TechGC
• How To Use Legal Operations To Level-Up The Legal Department: Mary O’Carroll, Chief Community Officer, Ironclad

  

About Lyndsey Cain

Lyndsey Cain is the Vice President of Legal Operations Services at LegalEng Consulting Group (LECG), where she launched and leads the firm’s Legal Ops practice helping legal departments modernize their processes and technology. Before joining LECG, Lyndsey spent a decade at The New York Times Company as its first Director of Legal Operations, building that function from the ground up. Earlier in her career, she held project and contract management roles across a range of industries before turning her focus to legal operations.