Re Facebook, Cambridge Analytica, the GDPR and CSR

Messi CR
When you know they are watching

A political data firm, Cambridge Analytica, was able to access the private information of 50 million Facebook users for marketing campaigns during the 2016 presidential election without the knowledge of those users. Facebook is now under pressure to explain “what the social network knew about the misuse of its data ‘to target political advertising and manipulate voters’”.

Last week on Linkedin, I saw a post written by Miguel Benavides, calling for data use to be deemed part of companies’ corporate social responsibility policies:

It took decades of pressure for social agents to persuade businesses and regulators that companies should be responsible for their impact on society and on the environment. The idea of Corporate Social Responsibility (CSR), with all its variances in names and forms, established the principle of ethics and accountability of companies as social agents. That caused all sorts of watchdog agencies to emerge. Businesses even included CSR as a permanent component in their strategy, allowing it to move towards stronger concepts like Corporate Citizenship, Shared Value…

Well, if we talk about data being “the new oil”, shouldn’t we need new Environmental Protection Agencies watching data leaks, new Labor Protection Agencies to ensure new labor models meet the minimum social protection criteria. What about Community Protection Agencies to watch how using all that data affects communities, social life, or even human behavior?

Along these same lines, tech writer Zeynep Tufecki wrote recently in the New York Times that

Data privacy is not like a consumer good, where you click “I accept” and all is well. Data privacy is more like air quality or safe drinking water, a public good that cannot be effectively regulated by trusting in the wisdom of millions of individual choices. A more collective response is needed.

In theory this is what the new GDPR hopes to achieve (at least in Europe), but will that be enough?

It will be interesting to see not just how legislators and regulators react, but more importantly how consumers’ online behavior and expectations of privacy will change, if at all. Will we become more demanding or more resigned? Regardless of whether you are a wanting online exhibitionist, the unavoidable truth is that we consumers are getting played. Sure there is a huge benefit in getting personalized offers and content, but consumers give it all away for free to companies who are laughing all the way to the bank.

Advertisements

Maybe the GDPR Isn’t So Bad for Blockchain After All?

Opps
An innocent “oops”

In two recent posts, thinking that I was really smart and clever, I questioned whether the GDPR posed a major hurdle for Blockchain-based technologies. Again, thinking that I was so smart and clever, I proudly took my arguments to one of my favorite privacy lawyers, confident I was about to impress her.

And as is often the case when I am feeling smart and clever, I was quickly put in my place by someone who actually knew what she was talking about.  First, let’s be fair to me. The GDPR does pose challenges for Blockchain-based technologies, as it does for any service whether on or offline that stores personal data. Data controllers will need to procure consent from data subjects and storage of data will need to be limited in time based on the purpose for which it is being stored.

The concern I originally raised was the conflict between Blockchains’ main feature of creating a permanent and unalterable record with the legal rights of a data subject to be able to modify or delete her personal data upon request (aka, the right to be forgotten). But a much smarter and more clever colleague – let’s call her Jane – explained to me that the right to be forgotten is not absolute.

Imagine you buy property. The local property registrar records the purchase with your name listed as the property owner. You may later sell that property, but you do not have a right under the GDPR to have your name removed from the public records relating to your purchase and ownership of that property. The purpose of registering property ownership is to have a permanent record of chain of ownership.

To the same extent, should you consent to making a transaction through a Blockchain-based service where you have knowledge that the record of that transaction will be permanent, your right to delete your personal data only comes into play when the purpose for retaining your data ceases to exist. For a Blockchain, that will likely be never.

power article

Think of a newspaper that publishes an article which features my name. The newspaper circulates thousands of copies. Like a Blockchain, the newspaper is distributed amongst thousands of people who have copies of the exact same story. We can verify that a single copy of that story has not been manipulated because we can compare it with thousands of other ones. Fake news aside, newspapers have the goal of being official accounts of events or newspapers of record. We should not then expect that upon request, every library and individual who has a copy of that newspaper article be required to destroy it or remove my name. Besides not being practical, it is contrary to the reason for having newspapers in the first place.

This morning I read a recent Grant Thorton report written by the Spanish lawyer Sara Esclapés Membrives on how the GDPR actually presents an opportunity for Blockchain-based technologies. The report corroborates Jane’s interpretation of the law, stating that the challenge for a Blockchain is to find methods for the future removal of an individual’s personal data “when the purpose for which the data were collected has finished.” But as with the newspaper example, the purpose of storing data in the Blockchain is permanency, which means that unless the Blockchain ceases to have activity and a reason for remaining in existence, it should be allowed to continue storing my name without me being able to invoke the right to erase my personal data.

Ultimately Blockchain-based technologies that store personal data need to focus on privacy by design, meaning developing an architecture that maximizes the individual’s ability to grant consent and opt-out of the service while providing the appropriate level of security for the storage of the data. But more importantly to be commercially viable, these technologies need to gain consumers’ confidence and trust. Otherwise consumers will not be comfortable sharing their data and will simply not use the service.

The Future of Money

FB Money

Last year CNN asked “What if Companies Issued their own Currency” where printed money bore the images of corporate celebrities instead of George Washington or European landmarks. Although neither George Orwell or Aldous Huxley’s dystopian futures predicted a world governed by corporations as opposed to authoritarian governments, it may be more plausible to imagine a world where corporations control the money supply, not with coins and bills but cryptocurrencies. In fact, the fad amongst many technologists today is to encourage the disintermediation (or deregulation) of money by moving to Blockchain-based cryptocurrencies like Bitcoin. But instead of removing the middleman, we are more likely – contrary to the idealists’ ambitions — to open the door to empower big tech companies like Amazon, Facebook and Google to tokenize their platforms, replacing one currency regulator with corporate ones. Let me explain.

telegram

At the beginning of the year, the encrypted messaging system Telegram announced plans to issue its own cryptocurrency. Telegram’s vision was to create its own Blockchain-based cryptocurrency around its chat-service where its users could engage in all sorts of transactions and make payments through Telegram’s own digital platform. By leveraging the mass hysteria around Bitcoin, Telegram hoped to raise tens of billions of dollars in financing from its ICO.

An ICO (or Initial Coin Offering) is the process of raising capital through the use of cryptocurrencies, instead of issuing debt or equity. For those new to the concept, cryptocurrencies (to paraphrase Wikipedia) are digital assets designed to work as a medium of exchange (generally through a Blockchain) that use cryptography to secure transactions, control the creation of additional units (ie, the monetary supply) and verify the transfer of assets.

Arcade tokenThink of cryptocurrencies as those tokens at a video arcade where in exchange for hard currency (or services), you are given tokens that can be used at the arcade. The tokens would generally have no value outside of the arcade, unless there is demand for exchanging goods, services, or other currencies for those tokens.

With an ICO, an investor acquires those tokens, which may be either the issuer’s own (often newly) minted token or another existing one like Bitcoin or Ether. As mentioned, the tokens acquired through the ICO are not debt or equity. They are digital claims to future rewards or services. Investors acquire the tokens in expectation that there will be a dynamic market to buy, sell, or transact using those tokens. Because the tokens are exchanged on a Blockchain, each transaction is logged and permanently traceable (though encrypted). In theory, an ICO is more cost effective than a traditional securities offering because it does not require the efforts of a VC or financial institution and is not regulated.

Well, we thought ICOs were not regulated. According to the Wall Street Journal, a number of companies that issued ICOs are currently being investigated by the US Securities and Exchange Commission.

The sweeping probe significantly ratchets up the regulatory pressure on the multibillion-dollar U.S. market for raising funds in cryptocurrencies. It follows a series of warning shots from the top U.S. securities regulator suggesting that many token sales, or initial coin offerings, may be violating securities laws.

One might cynically say that regulators are predisposed to dislike cryptocurrencies because they cannot control them. On the other hand, if ICOs are not regulated, then there will always be a risk to the consumer, something that the 1933 and ’34 Securities Acts were designed to address with significant success over the past century. As mentioned in the article:

Many of the coin offerings happen outside the regulatory framework designed to protect investors. Hype around last year’s bitcoin bubble led to many cryptocurrency offerings for startup projects. Some of them had little, if any, basis in proven technologies or products, and many were being run outside the U.S. In some cases, investors caught up in schemes that turn out to be fraudulent may have little hope of recovering their money.

A soon-to-be published Massachusetts Institute of Technology study of the ICO market estimates that $270 million to $317 million of the money raised by coin offerings has “likely gone to fraud or scams,” said Christian Catalini, an MIT professor.

Overall, there are a number of reasons for dealing in cryptocurrencies:

  • To incentivize developers/computer owners (aka, miners) to verify transactions on the Blockchain and support and maintain the platform
  • Financing of start-ups (ICOs)
  • To bring more transactions to a platform
  • To engage in unregulated transactions (ie, black money)
  • Speculation

As mentioned, companies like Telegram and many technologists (even some investors) may also find the use of a cryptocurrencies attractive because they have largely been outside of the control of governments and regulators. But this raises the question about whether fiat money is actually more stable than cryptocurrencies and therefore in the long run better suited for investors and society. One of the foremost concerns of any investor is that she has a viable exit, meaning that she is investing in a liquid market where she can put in and take out her money easily. So the question is whether a cryptocurrency can give the same stability that a government-backed currency can.

When you start thinking about Telegram creating its own private market of tokens for transactions through its chat platform, remember going to the video arcade to play PacMan and having to convert your money into tokens. Now imagine a future where Amazon does the same thing. It issues its tokens that become the only currency available for transactions on amazon.com. Then imagine trying to download apps, stream music, movies or other content on your Apple devices and having to use Apple tokens. Maybe each major platform will have its own tokens, and its developers and maintenance crews (aka miners) will get paid in their employer’s respective cryptocurrency. Workers will only be able to spend their hard earned salary at the company store. We can call it the digital hacienda or crypto-feudalism. Welcome to the new crypto-world order.

When you were a kid at the arcade you had no problem spending all of your tokens at once before your parents dragged you home. But as an adult, if you have your money tied up in Amazon tokens, WeChat tokens, or Facebook tokens, what happens when that company goes bankrupt? Or what is the conversion rate from one token to the other? Wasn’t the advantage of using US greenbacks that they were backed by the U.S. Fed, were easily exchangeable and that US government wouldn’t go under? Will these companies have to create their own monetary departments to control the supply of their tokens, and fight against inflation? In other words, instead of removing the role of central banks, companies would become central banks themselves. In fact, the more I read about cryptocurrencies, the more the macroeconomic fundamentals behind hard currencies makes sense. Or I am just old fashioned?

Hey Mr. Blockchain, the GDPR is Coming at You Fast

etch a sketch

Last week I wrote about the upcoming GDPR and mentioned that it posed a potential risk for Blockchain-based technologies:

The more I think about it, the more I see the GDPR posing a problem for a Blockchain’s permanent, irreversible and inerasable ledger whenever any personal data (even when encrypted) is included in a node. Individuals will have the right to delete their data and be forgotten. If one of the values of Blockchain technology is that no one person or entity can modify a node, then the Blockchain will need to modify its architecture and governance to allow for such node modification. And if it is a public Blockchain with no centralized intermediation, then who is the data controller? And who will be able to delete your data upon your request and protect your rights? Will each miner become a data controller, potentially subject to fines?

Just now I read that Blockchain is on a collision course with the new GDPR, making my same exact point:

The bloc’s General Data Protection law, which will come into effect in a few months’ time, says people must be able to demand that their personal data is rectified or deleted under many circumstances. A blockchain is essentially a growing, shared record of past activity that’s distributed across many computers, and the whole point is that this chain of transactions (or other fragments of information) is in practice unchangeable – this is what ensures the reliability of the information stored in the blockchain.

For blockchain projects that involve the storage of personal data, these two facts do not mix well. And with sanctions for flouting the GDPR including fines of up to €20 million or 4 percent of global revenues, many businesses may find the ultra-buzzy blockchain trend a lot less palatable than they first thought.

€20 million is a great incentive for technologists to find creative ways to keep personal data outside of their Blockchain aspirations. Start the brainstorming now!

Challenges Blockchain May Face

Sara PavanWe keep hearing that governments will kill cryptocurrencies or at least regulate them to death. They fear what they cannot control (or tax). I tend to keep a more open mind.

But according to my colleague Sara Pavan, Blockchain currently has other pressing challenges:

Scalability is a major concern: most existing blockchains (Bitcoin, Ethereum, etc.) have significant scalability challenges. For example, the Bitcoin network can only process about 7 [transactions] per second. In comparison, Amadeus processes 100,000 end-user transactions per second in peak times.

Transaction cost will be another issue to consider. Blockchains typically require a lot of computing resources given that data is held multiple times and there is significant cryptographic computation to be undertaken.

In systems like Bitcoin and Ethereum, this means there is often a prohibitive fee associated with each transaction, which can represent several percentages of the value being exchanged, making them inappropriate for many use cases.

Finally, integration with existing systems will be another major hurdle. Today it is hard to make blockchain interoperable with existing IT systems.

If a hotel booking is made on a blockchain system, how will it integrate with a system that isn’t on blockchain?

Even if Blockchain technology could eventually be faster and less expensive, one of Blockchain’s key raisons d’être – to squeeze out the middleman – may have its own challenge. From what Sara says intermediation isn’t going anywhere and will continue to be central to the value chain in a Blockchain world.  Beside needing someone to establish and evolve a Blockchain’s governance and drive critical mass, you will always need someone to build interfaces and applications, and support, maintain and enhance them. It’s like the Internet. We love it, not because it has value in and of itself, but because of the Facebooks, Amazons, and millions of other intermediaries that deliver content, products and services to our screens (or with Siri, Alexa etc to our ears).

And what happens when Blockchain’s other key selling point of secure and trusted transactions is blown to smithereens by faster encryption-busting technologies? What if what we are hearing about quantum computing is true?

. . . the advent of quantum computing will jeopardize the security of all existing cryptographic encryption methods, including RSA tokens. Quantum computers will affect the security of the entire finance and banking industry, not just the blockchain.

Even so, I’m surprised that security is not a more common conversation throughout the blockchain community. For a group deeply rooted in futurism, this seems shockingly shortsighted. It feels as if we’re building the blockchain for the next 50 years, but what if we only get to the next five or 10? What can be done to ensure that blockchain is dynamic enough to outlive quantum computing?

I tend to be an optimistic skeptic, meaning that I don’t trust the hype but trust that there is always a solution to every problem. As a lawyer, though, the solution is usually an imperfect negotiated one.

The GDPR is Coming

Paul_Revere's_ride
A very American icon for a very European law

The GDPR is coming, the GDPR is coming. At a recent offsite leadership meeting I attended with the business unit I support, I was dubbed Mr. GDPR. They all knew it was coming and because I am their lawyer, I became their GDPR guy.

To be honest, I am no GDPR expert and certainly don’t want to become one. I have these really great privacy lawyers who sit next to me. They answers my questions but more importantly help steer our company in the right direction to make sure that data privacy is one of the key value propositions we offer our customers.

Because the GDPR is coming, it is worth saying something about it here. Today I read eMarketer’s Western European Digital Trends for 2018 which gave an excellent summary of how the new law will affect companies and consumers:

GDPR requires that any entity collecting or handling consumers’ personal data must know how and where those processes take place, what data is kept, where it is kept, where it goes if it is distributed further, and how data integrity is preserved at every point where that entity is responsible—and be prepared to divulge those details. The rules also require digital devices and browsers to make consumers aware that their data is about to be collected, and let users make a single decision about how their data can be gathered and handled, which all companies, websites and apps must adhere to. Individuals will be able to refuse any entity access to their personal data. Individuals will also be empowered to access, manage and delete their personal data held in digital databases. Firms failing to comply face a fine of €20 million ($22.1 million) or up to 4% of global revenues, whichever is greater.

In a December 2017 blog post, Jean-Michel Franco, senior director of product marketing at Talend, wrote that “the stakes go well beyond regulatory compliance. In this data-driven world, trust has become the new currency. Now that insights and innovations depend on big data, there’s no option but to have total control [over] your data, otherwise, your customer won’t buy in. … Most of the privacy rules that come with GDPR were already expressed in former regulations, but the principle of accountability makes it game-changing.”

This will likely pose a challenge to companies like Google and Facebook who want you to give it away when using their platform. I mean give it all away: your photos, your posts, your instant messages with very limited ability to opt-out without having to forgo using the entire platform. This is from an article on how the GDPR will disrupt Google and Facebook from last summer:

Google and Facebook cannot confront their users with broad, non-specific, consent requests that cover the entire breadth of their activities. Data protection regulators across the EU have made clear what they expect:

“A purpose that is vague or general, such as for instance ‘Improving users’ experience’, ‘marketing purposes’, or ‘future research’ will – without further detail – usually not meet the criteria of being ‘specific’”.

A business cannot, for example, collect more data for a purpose than it needs and then retroactively ask to use those data for additional purposes.[4]

It will be necessary to ask for consent, or present an opt-out choice, at different times, and for different things. This creates varying levels of risk. We estimate these risks on the “GDPR scale”, shown below.

GDPR-scale_001-small-1

The scale ranges from zero to five. Five, at the high end of the scale, describes the circumstances that many adtech companies that have no direct relationship with Internet users will find themselves in. They need to get the consent of the people whose data they rely on. But they have no channel of communication through which they can do so.

Four, next highest on the scale, refers to companies that have direct relationships with users, and can use this to ask for consent. However, users have little incentive to “opt-in” to being tracked for advertising. Whereas a user might opt-in to some form of profiling that comes with tangible benefits, such as a loyalty scheme, the same user might not be willing to opt-in to more extensive profiling that yields no benefit. The extensiveness of the profiling is important because, as the note at the bottom of this page shows, users will be aware of the uses of their data when consent is sought. Thus adtech tracking across the web might rank as four, but a loyalty scheme might rank as three on the GDPR scale.

A slightly more attractive prospect, from Google and Facebook’s perspective, is to inform a user about what they want to do with the personal data, and give the user a chance to “opt-out” beforehand.[5] This is two on the scale. This opt-out approach has the benefit – from the company’s perspective – that some users’ inaction may allow their data to be used. The GDPR permits the opt-out approach when the purposes that the companies want to use the data for are “compatible” with the original purpose for which personal data were shared by users. In addition to the opt-out notice, users also have to be told of their right to object at any time to the use of their data for direct marketing.

One on the scale refers to activities that currently involve the processing of personal data, but that do not need to do so. With modification, these activities could be put beyond the scope of the Regulation.

Activities at the zero end of the scale are outside the scope of the Regulation, because they use no personal data.

The more I think about it, the more I see the GDPR posing a problem for a Blockchain’s permanent, irreversible and inerasable ledger whenever any personal data (even when encrypted) is included in a node. Individuals will have the right to delete their data and be forgotten. If one of the values of Blockchain technology is that no one person or entity can modify a node, then the Blockchain will need to modify its architecture and governance to allow for such node modification. And if it is a public Blockchain with no centralized intermediation, then who is the data controller? And who will be able to delete your data upon your request and protect your rights? Will each miner become a data controller, potentially subject to fines?

How Legal Teams Can Work in Agile

Scrum“Agile” or its sexier variation “agility” often seem like nothing more than buzzwords of the digital era. Everyone wants to be agile, everyone seeks agility.

We usually associate the terms with agile software development, as opposed to the more traditional waterfall methodology, where you define all of a project’s software requirements and milestones upfront and in great detail, and then you don’t deliver until the product is market ready, or as close to market ready as possible. The problem with this is that IT projects, like marriages, are works in progress and not everyone knows exactly what they’ve signed-up for until after they’ve said “I do”. Conditions change, technology evolves, and customers are impatient. Moreover, in long term projects developers tend to become further removed from the customer while the account managers lose track of the technical complexity of the project or have already moved on to the next opportunity.

Agile development tries to solve these problems by dismantling those silos where teams operate in isolation of each other and by delivering in short imperfect iterations known as sprints. Instead of focusing on the perfect, each sprint allows for customer feedback and correction, improving customer ownership and engagement in the project, permitting the supplier to show value right away, and empowering the development teams to be more innovative. In Agile, you are allowed to fail fast until you get it right. In waterfall, you fail hard and pay delay penalties.

The two major problems with Agile are: first scope creep where you lose control of the development costs in front of a customer with a fixed budget who keeps asking for modifications; and second Agile only works when your customer can reciprocate your agility. Agility requires both a shift in how you build your business case and how you interact with your customer.

scrum meeting

When most of us think of Agile, we think of a wall full of post-its and nerds without suits in stand-up meetings. But the concepts and best practices of Agile don’t need to be limited to R&D teams, and many other areas of business are looking at Agile to ameliorate some of the same challenges.

In particular, when a company grows, especially as it globalizes, it tends to suffer from silo-ization or the isolation of key internal stakeholders across a business unit, area of specialization or geography. These teams’ ability to interact is vital to convey and obtain the necessary input, not just for delivering a project but also for making informed decisions or improving communication.

Imagen032
Sitting on puffs during my start-up days

So take a start-up as an example. At first, it is a small team that inhabits the same open-space. When you want to talk to marketing, operations or to the product manager, you pull up a chair. When I worked for a start-up, we’d literally take our laptops and puffs to a quiet corner of the office. In fact, I happened to sit between two web designers. I would bug them all day long with my ridiculous ideas for new marketing campaigns. In a normal company, no one would have paid any attention to me. But in a start-up, nobody cared that I wasn’t Marketing. We all gave our input and were able to try out lots of ideas quickly until we got one right.

Imagine that start-up (or a new business unit) scaling up very quickly. Suddenly you have a product management team of ten people, three regional sales teams, and operations and R&D located at separate sites from the business-facing teams. Next thing you know, your business has become very siloed, communication is strained, messages are lost in translation and teams become tribal. We’ve all seen this happen. Sales doesn’t understand what it is peddling and R&D doesn’t understand what the customer needs. The support functions, like Legal, HR or Finance, become their own centralized tribe out of sync with actual customer and market needs, and what they have to offer is many times too late, out of context, or one size fits all.

Also as companies grow exponentially and teams silo based on geography or subject matter, employee engagement often diminishes. Now one step removed from customers, other teams, or where decisions or products are made, employees lose perspective, rarely receive positive feedback or gain visibility for their work, cease seeing the value in their own output or their roles, and become more entrenched in the group think of their tribe or immediately surroundings. We fight our myopic battles and resort to finger pointing. Sales fights with Operations, Product Management with Strategy, R&D with Implementation, and everyone rolls their eyes at Legal.

The idea behind business agility is that by better defining your customer’s needs and your deliverables, you can build cross-functional squads that work together on the same goal whose output (ie, sprint) can be shared very quickly with the customer. You break down both geographical and subject matter barriers, create a vehicle for communication, promote risk taking in a controlled environment, and empower squad members, giving them greater visibility of customer needs while allowing them to earn recognition for a job well done.

Okay, Eric, got it. Now what does this have to do with lawyers and in-house counsel?

In many in-house legal departments, you have the same issues. You are either organized regionally, by area of expertise, business unit or all of the above. So you have transactional lawyers who are customer-facing and negotiate commercial deals, and you have subject matter experts like competition, privacy or tax lawyers who have their day job of helping the company meet its regulatory obligations, but also need to support the transactional lawyers on the drop of a dime. You may also have other related teams like Risk & Compliance, Industry Affairs, and Information Security (as we do in Amadeus). This means that the Legal Department tends to work in silos as well, and when I am the transactional lawyer in a large deal where I need input from subject matter experts, I become the bottleneck. The business unit that I support wants to quickly get a new product to market and I need to chase the privacy or competition lawyer because I don’t know the answer, I become the bottleneck.

Luckily, I work with some very forward thinking colleagues who made me sit through basic Lean and Product Management training. In a very simplistic nutshell, Lean teaches you to define your output (ie, the “work”) so that you can remove unnecessary tasks (“don’t improve what needs to be removed”) and become more efficient. In Project Management training, I had the revelation that we lawyers – whose inclination is to go at it solo, office door closed or earplugs in, and draft away in silence — should start treating major negotiations as projects with predefined tasks, processes and the coordinated collaboration of others.

And luckily, I also get to work with very smart and capable internal business process consultants who I have recently harassed about working in Agile. What I really wanted to know was how we could design efficient, silo-busting teams in Legal to work in project mode on specific, timely initiatives. These very smart and capable colleagues kept bringing me back to reality. Agile is just a buzzword, they’d tell me, unless you can define your deliverable and the customer need that justifies an Agile solution. So this is what I came up with:

First I don’t want to give myself or anyone else added or unneeded work. People are busy, and if my goal is to build a squad from across different teams within the Legal Department, I need buy-in from the squad members’ bosses. I won’t get them on board if I am wasting people’s time. For this I need to choose projects:

  • that relate to new initiatives that the business has prioritized
  • that require a holistic legal perspective
  • where the team can provide real, tangible deliverables, and
  • that are timely, meaning we can help out the business right away

For my company, this would generally mean projects relating to new technologies or products, and in most cases, the deliverables would be either holistic legal guidance on the new product – including on product design from a privacy, security, regulatory and customer relationship perspective (including how you would contract with and charge your customers) – or on producing the contract templates for sale of the product. For other companies it may not be so tech focused, but may mean new lines of business or entering new markets. The key is that you are looking into novel opportunities where you don’t have an off-the-shelf solution at hand. Moreover, you want to avoid scenarios where the business gets your input too late and has to go back and start all over after they have already invested time, effort and resources on the new venture.

Imagine that your company has developed a new service which they have already pitched to a couple of customers. The Sales team is very excited as are the perspective customers. They call you up and ask you for the contract. You say, “a contract for what?” They explain and you use a preexisting template, hoping that making a few changes here and there will do the trick. For the data protection provision, you show it to your privacy lawyer who raises an eyebrow as it looks like data may be stored in various data centers around the world. She asks a bunch of questions and points you in the direction of the information security office. No one ever told them about the project, and they never analyzed the service’s architecture. You are almost too afraid to ask the Tax team whether the locations of the databases presents a permanent establishment risk, and you realize that maybe the IP team wasn’t put in the loop either. Houston we have a problem. The customer is ready to go, but we will likely need to rewire a chunk of the work, losing weeks of effort and resources. Everything from the product architecture to the business case needs to be reevaluated. Worst of all, the business thought that you were the lawyer who solved all their problems, but now you’re the guy who causes havoc and panic. And the worst kind of lawyer is the one who doesn’t have the situation under control.

Again, Eric, we got it. So just tell us how you are going to work in Agile.

Here’s the plan:

Once we have identified the project, we can then assemble our squad. The squad will be composed of six to eight members of the Legal Department, each from different teams. Ideally, I would have:

  • One lawyer who supports the business unit who owns the new product
  • Another lawyer who supports a different business unit that may use the product or a similar product in the future and who can provide a different perspective
  • One privacy lawyer
  • One information security member
  • One intellectual property lawyer
  • One tax lawyer/team member

Depending on the nature of the project, for example if it relates to an area that is self-regulated by industry stakeholders, where the regulations are unclear, or where we are heavily dependent on a supplier, we would then want to include:

  • One regulatory lawyer
  • One person from Industry Affairs
  • One procurement lawyer, or
  • One person from Risk & Compliance

Once we have identified our squad members, we set up a meeting with the new product owner who will present us with the initial product plan, prototypes or sales pitches. In this session, we can ask questions and gather information to prepare our first sprint. The product owner becomes our customer, and the purpose of the sprint will be to deliver our initial holistic guidance. These sprints occur over relatively short periods of time, so that we can provide our input quickly to the customer. The process is repeated regularly with new sprints until the squad and the customer are comfortable that the product is ready for market.

In parallel, squad members will report back to their individual Legal teams, informing them of how the new product is developing and sharing information. Throughout the project, we will have:

  • Reduced silos
  • Gained more across-the-department knowledge of the business
  • Learned more about our colleagues and taught our colleagues more about ourselves
  • Given ourselves the opportunity to take active roles in the development of new business and ownership in the success of those ventures
  • Empowered team members outside of their normal activities
  • Built stronger relationships
  • Provided more holistic iterative legal guidance, in a more efficient, faster to market way, and
  • Hopefully increased overall engagement.

So will it work? I will let you know. But in order for it to work, we need to have very good networking abilities across the business to identify opportunities for collaboration and customers willing to engage with Legal on these projects. If we don’t have good interlocutors or don’t select projects that can deliver real value, then the squad members will quickly lose interest and the customers will lose faith in our ability to deliver. Then we’re back to square one. For now, my plan is to start one project at a time.

Of course there is nothing stopping in-house counsel from proactively participating in squads that are managed by other teams. In fact, we should encourage our lawyers to play more leading roles as business partners, including taking a seat at the table in our internal clients’ Agile projects. Because at the end of the day, if you aren’t invited or going to the party, you aren’t having any of the fun!