As disruptive technologies proliferate, they, by their very nature, begin to change the way work gets done. New workplace tools are reshaping the way business is conducted in many organizations, creating new forms of communication and collaboration, while displacing prior practices at the same time. Slack is perhaps the most visible of these, but it’s not the only one.
When these technologies make their way into the workplace, how are legal teams to respond—particularly when the data created by these tools can upset our traditional approach to information governance and record keeping, generating information that falls somewhere between a conventional record and disposable information? What considerations go into addressing such disruptive technology, what strategies can legal teams employ when evaluating these technologies, and how can legal professionals help build consensus around their litigation and information governance decisions?
To help answer these questions, Logikcull recently sat down with James A. Sherer, a partner at BakerHostetler, Aaron Singer, Executive Vice President of Corporate Operations and General Counsel at Boxed, and Ben Barnes, an at attorney at Redgrave, to discuss their recently published article, “Picking up the SlackTM: Legal and Information Governance Considerations for New(er) Technologies,” and strategies for approaching new technology from a legal and information governance perspective. A transcript of our discussion follows, lightly edited for clarity and concision.
This is part two of our interview with Sherer, Singer, and Barnes. Don’t miss part one, focusing on Slack data in information governance and litigation.
What Lawyers Should Know About Disruptive, Collaborative Workplace Technologies
Logikcull: Your Richmond JOLT article focuses not just on Slack, but on how companies and organizations can deal with emerging technologies where the data falls somewhere between a business record and disposable information that, minus some external requirement like regulation or a legal hold, does not generally require retention.
Besides Slack, what would be other examples of this in-between new technology where data is not a traditional business record, but not exactly something you want to throw away or not retain after a week or a month, or whatever your retention period might be? What else should people be looking at?
James A. Sherer: We've seen fairly extensive uses of Google's different products and that constellation of collaborative technologies. We're also starting to see collaboration done through extensions of cloud service providers, like Box and Dropbox. You name the service, and there may be data stored there.
“The barriers to getting these types of technologies up and running within any company differ. Without education, processes, or parameters, the potential user or her team may just start using the technology.”
My impression is that, as a technology provider, you want to get people using the service and first, and you can figure out compliance issues on the back-end. Especially with the newer technologies, it doesn’t seem like most are worried about records management or governance in the same way that a more established organization might, and we just have to be aware of that. We can't expect that, "Oh, well. If they're doing it, they must have thought through all these issues. They must have carefully considered data privacy. They must have really strong protections around access rights."
When you're getting the technology for free, where do you start to draw the line between that expectation and doing some of your own due diligence?
Aaron Singer: I think that's exactly right. In my day-to-day, I see all the different sorts of technologies and apps that colleagues and teammates want to use to get their jobs done, whether it’s to facilitate communication, to get organized, or to help be more efficient.
For instance, there's a ton of workflow software options out there that people are using for a host of different reasons. Within these workflows, there are different places where people can add comments, provide input, include confidential information potentially, and all sorts of other content like that.
The barriers to getting these types of technologies up and running within any company differ. For instance, as James said, many have free versions, so the potential user may not realize they need to get legal approval or finance approval before starting to use the technology. Or, because the software is internal facing only, the potential user may not realize there are still significant risks associated with the technology. And so, without education, processes, or parameters, the potential user or her team may just start using the technology.
Strategies for Assessing Disruptive Technology
Logikcull: In your article, you lay out a few general strategies that people can employ when addressing these new technologies. Can you walk us through some of those?
Sherer: The first thing is determining whether or not something is a business record and then how to handle it. I think that even a step back—and part of this is the technology stack gathering around whatever the technology is—and questioning whether that data can be a business record is the first challenge. That is, does it exist in a record-type way?
To take it to the extreme, you have a conversation with two people in the hallway, which very well could lead to a decision being made and the company taking off to do whatever is discussed. That's not a business record until you sit down and memorialize it, and even then…
“It's a discussion of, ‘Can it be a record and should it be a record?’ We start with the ‘can,’ and whether it's even possible to put it into a normal process of recordkeeping.”
There’s this tendency, though, to say, “Okay. Well, if it's written down, are we going to treat that, as a default, as something that should be saved unless we indicate otherwise?” If that's the case, then that carries with it a host of different responsibilities.
Our article contemplates taking a step back and saying, "Is that really the right approach here, or is it to say, 'Hey, is this really the medium in which we're doing business?’”
If it's not or if it doesn't lend itself to it, then we might recommend that an organization be a little bit more careful in the way in which that's structured.
I think people get it. It's one thing to say, "Hey, we're just trying to get the work done." It's another to say, "Hey, we have to show our work." Everybody's been through school in that way. You know that there are certain instances where it's not just enough to get to the answer. You want to document how you got there, because that documentation matters.
You think of Slack, in particular, as being a collaborative hub for people, development, software, or a process. Well, you can develop the software, but it's no good if you move it or port it to another platform and it suddenly doesn't work anymore. If you have no documentation, if you have no notes or understanding of where you ended up, if you don't know what libraries were used, if you don't know where things are stored, that's going to be unavailing if you're trying to take that next step.
People understand that we have to be careful in approach, and that’s where we advocating starting. It's a discussion of, "Can it be a record and should it be a record?" We start with the “can,” and whether it's even possible to put it into a normal process of recordkeeping. Then we consider it and say, "Well, should it be a record? Or will there be too many things associated with it that are going to present challenges later on—therefore, let's determine whether this is the correct medium for recordkeeping."
Building Consensus Around Information Governance & Litigation Decisions
Logikcull: You discuss the importance of building consensus around these decisions. Aaron, working in house, working as part of the business, tell us about that consensus-building process. How amenable do you find other people who are not lawyers and do not have a legal perspective? How amenable are they to these litigation and information governance concerns when they want a new technology and they want to get it moving pretty quickly?
Singer: First, much of what people are amenable to is based on the particular company’s culture and the role and position of the legal and compliance functions within that company. That said, I generally think people want to do the right thing or, at least, not create a problem for their business. So, whether people are amenable at first or not, the people responsible for these issues can get around those obstacles through training about potential risks and the importance of thinking critically about the tools and technologies being used. And, then, by being willing to answer questions and to think critically about the ways in which the technologies are to be used.
“The approach of the lawyer should not be to be the police, but instead to be a solution provider: There are facts and there is a way the world works, now how do we do the things we want to do?”
I find that if you make blanket rules on these matters, people are unlikely to follow the rules or they are going to try to push the limits.
Rather, if you train people on the purpose of the rules, especially in an era when everyone is worried about data breaches and the like, you may happily create a culture at your company where all teammates are driving towards a balance of useful, properly used technology.
Before the rules went into place with respect to use of the different technologies, before we built our policies and all that, I spent time meeting with people from across the organization and on all teams, especially those people who use the technologies the most. I made sure to say that I wanted to hear their perspectives on the technologies, the policies, and the rationales and to get an understanding from them about why this tool is so important and what is most important about it to each of them.
In those scenarios where the technology has significant risks, during those conversations, I spent time explaining that the risks can create issues that outlive the potential usefulness of the technology, or they could even outlive any of our tenures at the company.
I found that discussing these very practical points helps to provide context for the discussion; in other words, with “knowledge nomads” being what they are, companies need to think harder about the long-term impacts of the tools that people elect to use before they decide to use those tools.
“If you make blanket rules on these matters, people are unlikely to follow the rules or they are going to try to push the limits. Rather, if you train people on the purpose of the rules, you may happily create a culture at your company where all teammates are driving towards a balance of useful, properly used technology.”
I have found the most effective way to do this training and to be sensitive to the fact that there's a need that the potential technology user is trying to satisfy with the technology, and there will likely be a perceived loss of efficiency if they are blocked from using the technology, which can cause consternation or tension.
The best way to combat these issues is to spend the time to really listen and then provide a good explanation as to what we're trying to do, and then to determine together the best ways to address the underlying need.
I think one leg-up tech companies and high growth companies have is that the people who work at them tend to care—a lot—about the outcomes for their company and are attuned, or at least aware, of these issues. This fact provides for a great starting point for these discussions.
If you can explain to them why the health of the company is at issue when bringing on new technologies and why it's so important, I think that's how you address the overall issue. At least that's how I try to address it. The point is, the approach of the lawyer in all of this should not be to be the police, but instead to be a solution provider: There are facts and there is a way the world works, now how do we do the things we want to do?
My job is to make sure that people are operating in a way that is not overly burdensome on the company or its compliance activities. I work with experts like James and Ben to think about these new issues, and they add the layer of thinking about how the activities could pan out in more formal circumstances.
Sherer: Actually being face-to-face and finding out what that technology is going to be used for is extremely helpful in building that consensus.
That is, understanding what the organization’s employees’ needs are, and then being able to provide a solution is one of the ways to avoid limiting work and preventing people from using a certain technology. An organization can provide employees with other solutions that are already in house, and provide more training and more information on the way that they can use those technologies.
“That process of compromising is the end goal: where people feel like they were invested in the process, their voice was heard, they had a say in what happened, and the ultimate outcome here is one that people are agreeing to move forward with.”
But when it comes to building consensus, it's not going to be magic. Part of building consensus is getting a multitude of viewpoints and then considering them. The more viewpoints, the more difficult the process is, but it can result in a better end-product as well as being better informed. That process of informing also goes both ways.
When an organization attempts to build consensus, it’s not trying to find the solution that's going to work for everybody because there's no solution that does that. The process uncovers what's actually happening, and serves as a vehicle for everybody's voice to be heard. Then, everybody ends up compromising, and consensus is built.
That process of compromising is the end goal: where people feel like they were invested in the process, their voice was heard, they had a say in what happened, and the ultimate outcome here is one that people are agreeing to move forward with.
The challenge is always when the organization doesn't take the time or doesn't have the opportunity to try to build some of that consensus, to get those viewpoints. The result might then be people on the backend that say, "Well, you didn't consult with me, so I'm, going to do whatever I want." Or, "This is completely not feasible for my operations and again, you didn't ask me. I didn't have a chance to comment, so I'm going to move forward."
One challenge of human nature is that, if you don't give people the chance to collaborate, they might imagine a universe in which they were going to be the perfect collaborator. Anything circulated was going to be read in full. They were going to give you a full red-line back. They were going to investigate all these different alternatives. You just didn't give them the chance to do that.
“When an organization attempts to build consensus, it’s not trying to find the solution that's going to work for everybody because there's no solution that does that. The process uncovers what's actually happening, and serves as a vehicle for everybody's voice to be heard.”
But we know that's not the case, and if you give stakeholders the opportunity to first put their proverbial money where their mouth is, we can then deal with reality. Then no one will come back and paint this picture of everything that could have happened and which they just never had the chance to do. Instead, it's, "Hey, we had these calls. We moved things forward." People then agree and note, "Okay. Well, I was there, tacit acceptance or otherwise, I'm part of this process." That helps people buy in.
It's acknowledging employee busyness but also respecting their opportunity to contribute, to make sure that they're buying into the process. Essentially you've gotten people to work harder, even by default, to move the ball forward.
For more information on how disruptive technology is changing the face of litigation today, download "The Lawyer's Guide to Discovery and Investigations in Slack."
