The first lesson I’ve learned is to ask (more) questions

Over the last year, I’ve been building a house.  My first meetings with architects were revelatory. I’d never designed or built anything before, and I’m not one of those people who pore over house and garden magazines, dreaming about the day I’d have an opportunity to use just that kind of marble countertop.  
In my first meetings with architects, I realised quickly that I didn’t have a language to express what it was that I wanted. And I was intimidated.  I was visiting experts. Professionals.  Professionals who charged an extremely high hourly rate. I didn’t want to waste their time. I didn’t want to reveal how little I knew. And it quickly became a very frustrating process. I felt like I couldn’t make myself understood. I wasn’t happy with the work product, but I couldn’t articulate why.  It was the first time I’ve realised what it must be like for many people to visit a lawyer for the first time.

Fortunately, I wound up finding a great architect, and the house is nearly finished.  But we still hit the odd thing which has been really instructive to me in the way I work.  This is my bedroom. It has these fab windows up high. They’re called clerestory windows (jargon: that just means ‘windows above eye-level’).  Anyway, my architect was working out complicated ways for those windows to open. Expensive, motorised fixtures, because it’s not like you can reach them to open them yourself.  We were several months into the build before I focussed on this, and I said, “But I’ll never open them.”  Why? I despise sleeping with windows open. Mosquitoes can find me from kilometres away. My architect is the exact opposite.  She’d assumed I’d want the windows to open because she would. We’d never had a conversation about it.

Last month we had a fantastic tech client come to us with an idea that had some really interesting employment law aspects to it.  My employment law colleagues could immediately see a number of areas that would need quite a lot of work and research to get right.  It was a complex opinion that would cost a reasonable amount in fees.  And yet, when we sat down and had a discussion about the features that might be problematic, it was clear that they weren’t necessarily features that were core to the product.  Always be aware that the thing you’re carefully researching, or spending time and money agonising over the drafting for, might be something they don’t actually need even though they’ve asked you for it.  You need to ask a lot more questions than usual to flush out what the features are that the company really cares about.

In software and development, this falls within the area of user interviews.  User interviews are conducted so that designers and developers can work out whether the user experience is meeting the needs of existing or potential users of the product or service. One of the most important rules in conducting user interviews is to ask open questions.  If you ask the question “Do you prefer X or Y?” you will only get you part of an answer.  They will tell you X or Y.  Asking a question like “Tell me about a time when…?” will help you understand more about the user.  In a user interview, if you ask someone, “Where do you typically buy groceries? Countdown, New World…” they’re more likely to pick one of those options, instead of thinking more broadly about other places that they shop like a local fruit and vege shop, or the petrol station, or a farmers’ market.

At the moment, we’re doing a lot of work with tech companies establishing employee share plans.  There are several legal reasons why you might implement a scheme in one way or another.  You might want shares or options. You might want vesting arrangements. You might need good and bad leaver provisions for departing employees.   But we’ve learnt that if you offer legal choices to a client, they’ll pick one of the choices you offer.  If instead you ask them to describe what they’re trying to achieve for their employees and the company (e.g. retention and rewarding long service, vs. achieving KPIs and incentivising performance), you’ll find you often come up with a different result.  

Similarly, we continue to meet with NZ companies who are being told by investors that they need to flip their structures to the US, incorporating Delaware corporations into which the VCs will invest.  

It's a cautionary tale, because the process can be costly, particularly where there are IP transfers involved, and kiwi companies need to be sure that it's the right move, at the right time.  It can create really significant tax burdens for kiwi founders if they’re not planning to move their lives to the US. And they’re often taking these recommendations at face value because they come from other kinds of “trusted advisers”.  Investors who’ve done this “loads of times”. People who tell them this is “market standard”.   We’re the ones who have to unpack this.  

Young tech companies are not like established corporate clients, who come to you with a clear set of instructions, and say “please carry these out for me”.  It’s our role to get to the bottom of what these companies actually want and need, not what they’re telling us they want or need.

Ask more questions. Ask better questions.

The second thing you need to do is think about their users

While the tech company may be your client, your work product is often not just for them, but for their users or customers.  Whether its the terms of service for a website, or its privacy policy, or the company’s partnering or reseller arrangements, or the terms for its API, these are all ways in which your client’s customers are going to be affected by your work.

We’ve all seen terms of service that look like this.  They might be watertight from a legal standpoint, but when you put yourself in the shoes of a user of the site, they’re immediately antagonising.  They cast the company itself in a bad light.  It looks like the company is probably trying to screw you.  This is the sort of company that will send you angry cease and desist letters.  It’s also not in the “spirit of the internet”

There’s only one rule on the internet, and that’s Wheaton’s Law.

A lot of this is about getting the tone of voice for your client right, and it’s why standard template documentation is often not the best approach.  

We do a lot of work with a company in Newmarket called Letterboxd.  It’s a social network for film lovers.  On the site you can log the films you’ve watched, give them ratings and write your own reviews.  You can make lists of films you want to see, or your top ten disaster movies. You can follow other people to see what they’re watching, and what lists they’ve made. Letterboxd has a passionate and committed community of 180,000 users who really care about the site.
 

Here’s the community policy for Letterboxd.  You can see which of three we wrote as lawyers, and which Karl and Matt added.  Tech companies are selling to people who are deeply suspicious of lawyers and legalese. You do them a disservice if you don’t work with that in mind.

Letterboxd had a great example of that recently.  We needed to amend the sites terms and conditions to handle the introduction of an API.  For the first time, the content that users were producing - their ratings and reviews and lists, would be available through third party apps and sites.  Karl and Matt spent a lot of time thinking about what this would mean, and how users would feel about their content winding up in other apps and sites.  Letterboxd users are a very passionate bunch. They care deeply about the content they produce on the site, and they’d want to know that Letterboxd felt the same way.
 

Here's the change.

Letterboxd is hampered by being run in Auckland with most of its users being in the US.  When the guys woke up the next day, they found that several vocal users were not impressed.

The point is, as lawyers, we felt that the change was clear. To the users, it wasn’t.  A follow-up email made everyone happy. 
But the lesson for us was that we can’t just be thinking about our clients. We have to think about their clients as well.

The next lesson is that we are the ones who have to focus on doomsday.
 

Tech company founders are relentlessly optimistic. They have to be. You only have to spend a short amount of time around “startup culture” to realise that their ability to raise capital, and to convince employees to come and work for them for less money and less certainty, and to convince users to adopt their product?  All of that relies on a relentless commitment to the vision.

While there’s a lot of talk about “embracing failure”, “failing fast” and failing forward” if you actually talk to most tech entrepreneurs, that’s not something that they want to discuss.
 

What does that mean for us as advisers? We have to be the Doomsday Preppers. It means we’re the ones who have to strongly and consistently work through with our clients what the worst case scenarios are likely to be.

For example, the topic I bang on about the most in this space is shareholders’ agreements.  Every early stage company should have one, and so many still do not.  Or if they do, and you quiz the founders on it, they haven’t read it and they don’t know what it says. At the outset of a new venture, everybody involved is excited about the project, positive about its future prospects, and in agreement on most things. It’s hard to imagine a time when they might not feel the same way. But things change. One of the founders gets a great job opportunity to move to another country, or wants to take time out to start a family. One of them wants to expand into Australia, but the others think it’s a terrible idea. They get approached by someone who wants to buy the business, but only some of the founders want to sell. It’s our role to work through those doomsday scenarios in advance.  So often the founders tell us “that will never happen”, or “we trust each other”, or “he’s a great guy”, or “she’s really experienced”.  Press them to confront what they’ll do if that turns out not to be the case.

Lately we’ve had several companies who have had acquisition proposals put to them.  This is almost worse than shareholders’ agreements, because if someone wants to buy your company, and the number is attractive, then all your Christmases have come at once.  Our role as lawyers? Still doomsday preppers. Often, a tech company acquisition will be structured with an earn-out component, and will depend at least in part in the founders going to work for the acquiring company for a period of time.  Some portion of their payment (often the lion’s share) may depend on them hitting targets for the first few years after acquisition.

Your clients will be optimistic about their ability to hit those targets.  The business has been performing well until now under their leadership. No reason why that will change.  But a business that’s been acquired faces a raft of integration challenges.  A tech founder used to running their own company may well struggle with being a small cog in a larger machine.  The acquiring business may not prioritise the same things the founder had previously.  Rich Chetwynd sold his kiwi startup Litmos to Callidus and went to work for them in San Francisco during the earn out period.  He jokes now that every time he asked to hire a new developer, they would give him three new sales people.  Because they thought about his business differently than he did.  The founders may even fight to get their product noticed within a much larger organisation, essentially spending the first six months convincing sales teams to sell it.  All of this will contribute to the possibility of failure to perform in the same to immediately prior to the acquisition.  My rule with earn outs is this:  Are you comfortable never seeing a cent?  Whatever cash you get on settlement is the only cash you can count on. So whatever deal you do, do not bank the rest.
 

It’s not uncommon for an acquisition to have a stock component, where the acquiring company pays for your client’s company partly in cash, and partly in shares.  Then it’s a case of helping our clients to understand the risks involved in taking stock in another company, often in another country, where they don’t have the resources to undertake proper due diligence.  The nightmare scenario here is the acquisition of Dragon Naturally Speaking, the voice dictation software that was built up by founding couple James and Janet Baker.  The business was acquired for $580m in an all-stock deal.  They got no cash, only shares in the acquiring company. The acquiring company went swiftly bankrupt, their investment is worthless, and they wound up in a legal battle with their advisors Goldman Sachs over whose responsibility it was to investigate the health and credibility of the company buying them.

Goldmans won on appeal.  “The reasons why small startup companies like Dragon go to a place like Goldman to assist with hatching their golden eggs is because they don’t have their own expertise to analyze revenue projects by asking tough questions to potential merger partners,” the judge said. “Still, I give weight to the fact that the jury found for the defendant on this claim and there was sufficient evidence to support that finding even if I conclude otherwise”.

The message we need to get through to our clients is that (sometimes for the first time) they need to carefully consider the worst case scenario.  What if this new investor, who they think is amazing and a perfect fit turns out not to be.  Can they live with the idea that they might never see a cent of an earn-out payment and the shares might be worthless?  How will they feel if the acquirer runs their business into the ground. Or shuts down the product six months later. They won’t enjoy it at the time, but they’ll thank you for it later.
 

The next lesson is critical - runway is everything.

One of the most important things you can do as an advisor to tech companies is really get to grips with how they are funded and run.  Typically a high-growth tech company has no external debt, and it will be EBIT negative for many, many years.  These companies are spending the money that has come from equity investors. And the number of days they can keep the doors open, the runway, is everything.  If they can’t raise further capital before they’re out of runway, then it’s game over.

This means that certainty about costs is critical. When I first started working with young tech companies, the most common thing that other lawyers said to me was that I would lose money.  That the companies would go under, and that they wouldn’t pay my bills.

That hasn’t been my experience at all.  In fact the opposite. Our recovery rate for this kind of work is higher than the firm average.  But that’s because of one simple thing. Certainty.  We operate with our startup clients on a strict no-surprises basis. We won’t do any work until we’ve quoted up front for how much it will cost, and barring a total change in circumstances, we stick to that.

We’ve also found that giving founders a roadmap of legal tasks they need to complete in order, and the costs involved, allows them to plan ahead.  It means that they can choose to get mission-critical things like shareholders’ agreements and employment agreements done first, but defer trademark registrations in foreign markets, for example, until they’re in a position to pay for them.

The old model of doing some work, and sending a bill, to a client who has no sense of how large it might be just doesn’t work in these circumstances. Runway is finite. Founders have to know how much money they’re spending every single day.
 

When I try and explain what we do to audiences of developers, I explain that law is code. It’s a language, and a set of rules, and a set of commonly understood ways to express certain concepts.  And just like code, if you ask a lawyer to do a piece of work for you, there are several things you might get back.  You might get a quick and dirty version, that will get the job done, but lacks a certain elegance.  You might get a completely bespoke solution, that is perhaps overcooked for what you needed, with every possible belts-and-braces clause thrown in.  You might get something that’s actually not very good. That is filled with unseen bugs, and when it gets tested, you’ll find it doesn’t actually work. Just like code.

Of course, the problem for us is that our work doesn’t get tested until later. Sometimes years later. You know straight away if code works. You try and run it.  You might not find out a contract is broken until much too late.
 

This is basically a classic case of the Project Management Triangle.  You can have good, cheap or fast: Pick two.

Good and Cheap will not be fast. Fast and Cheap will not be good. Good and Fast will not be cheap.

Helping our clients to understand we work exactly the same way that they do lets them grasp what to ask for, and manages expectations around time and cost.
 

One of the more complicated things around working with tech companies is that they come from a culture where nobody is crazy enough to reinvent a wheel.  No developer sits down to build a new piece of software and starts with a blank window.  Everything is built on the back of what’s gone before, whether that’s open source libraries of code, or bits of code that developer has worked on before.  Sites like Stack Exchange exist because everyone recognises that sharing work is more efficient than trying to re-solve solved problems. So, when tech companies are talking to lawyers, they get frustrated that every one of them seems to be paying for the same answers to what they see as common problems. One of the most common questions I get is “why don’t you open source your documents?”

Setting aside the shudder that runs down the back of most partners at the idea of giving away their IP for free, this misunderstands something in the nature of open source projects. Some open source projects are still ultimately proprietary.  This is basically where a company open sources software, and allows anyone to use it, on the basis that any improvements are contributed back and become the intellectual property of the company that owns the project. Other open source software projects rely on active and committed maintainers, the core developers, who are responsible for reviewing every contribution to make sure it’s going to work with the project.

Imagine for a moment what that would look like for something like a shareholders’ agreement.  A group of lawyers could “open source” a draft agreement, but then there is an ongoing commitment to maintain it, and to either let people fork their own version with the attendant risk that they break it.  They won’t know they’ve broken it at the time, of course, because unlike code, our testing happens later. When it’s too late.

The alternative is that there have to be core developers, who will take contributions or suggestions and build them in if they’re considered appropriate.  Speaking to a core developer on a large open source project recently, he estimated that for every five minutes of someone writing a contribution, there was an hour of his time checking and reviewing it before it could be committed.  I don’t know how we could ever replicate something like that reliably.  

More than that, one of the things our clients are paying for is to have us stand behind something.  They want to know that the work product they’ve paid for is going to hold up, and that if it doesn’t there’s some kind of insurance policy behind it.  As soon as a firm doesn’t have control over the drafting of a document, that becomes much more difficult.
 

However, I do think there are things we can do.

Designer Brad Frost spoke at Webstock this year about the concept of “designing in the open”.  How designers should do more of their work in the open, sharing their process, in the interests of improving everyone’s work.

One of the examples he used was this site.  It’s a site that houses a number of “css tricks”: code snippets to do simple things, so instead of trying to work out how to embed a quicktime video, you can jump on here and get a few lines of code to do what you need.

Now, look at the licence for these snippets!

As lawyers, we’re already familiar with the idea of agreeing some standard ways to do things.  The ADLS agreement for sale and purchase of land, the basic trust deed that sits behind every family trust in the country, the standard form limited partnership agreement that was developed with the law was first introduced. I think that these standards have become accepted because they don’t try to do too much.  They’re the equivalent of ‘code snippets’. They’re the simplest way to do something.

So I think a really interesting question is what does it look like if we’re more honest about the boilerplate. If we own up to the fact that 80 or 90% of the document we’re working on would be exactly the same if it was drafted at any firm in town.  And then we focused on the last mile. The place where we are actually adding the value, because we know our client and their particular circumstances.  Because we know if they want cheap, or good, or fast.   Because we know their users, and what their employees are after, and what their internal cultural values are.

For example, a privacy policy is about as standard a document as they come. What information is the company collecting, and what do they intend to do with it?  And yet to suggest this can be a template is to miss the point.  It’s to miss that some data might be a lot more personal to users than other.  That a company that has built a certain trust with it’s community might want to convey privacy issues in a very different voice.  It’s to understand how the systems underpinning the company actually work - can they delete the data they hold about users?  It’s about what the founders’ long term plans are for exit, and what that data looks like as a business asset.

The core template isn’t where the value is. It’s that understanding. That trusted relationship
 

Way back in 2008, Kevin Kelly wrote a fantastic piece that has stuck with me ever since, called “Better Than Free”.  In it, he talks about the internet as a ‘copy machine’, capable of ceaseless, frictionless reproduction of data, ideas and media.  And he talks about what this means for the digital economy:

“Yet the previous round of wealth in this economy was built on selling precious copies, so the free flow of free copies tends to undermine the established order. If reproductions of our best efforts are free, how can we keep going? To put it simply, how does one make money selling free copies? … When copies are super abundant, they become worthless. When copies are super abundant, stuff which can’t be copied becomes scarce and valuable. When copies are free, you need to sell things which can not be copied.”

He goes on to talk about eight ‘generatives’ - qualities or attributes - that cannot be copied.  Attributes that add value to a free copy. Attributes that we’re willing to pay for.

Some of these, such as Immediacy and Accessibility, are particularly relevant to digital products that we can either buy, or find free copies of online.  The iTunes music store has been so successful because of ‘immediacy’.  In general, it turns out we’d rather pay a dollar for a song that we can get straight away, than dig around looking for a pirated copy. Streaming services take this even a step further. We don’t want to be responsible for our own music collections, discovering new artists, buying albums, making playlists, when we can pay a fee to Spotify and have it all done for us.  

Similarly with “accessibility”.  We are prepared to pay to get access to our music collection wherever we want it, on any device.  We don’t want to have “left the CD at home” any more. We don’t even want to have “filled an extra hard drive with our music”.  We want iTunes Match in the cloud so that the concept of the “library” isn’t even ours any more.  We can just get the song wherever we need it.
 

Others of these generatives are applicable to the way we provide legal services in a digital economy.  Tech clients in particular are great ones for “finding a template online”.  That’s what they’re used to.  Why would they pay us to draft an employment agreement if there’s one available for free on the MBIE website? 

Kelly talks about two generatives that apply here:  Personalisation and Interpretation. So, with personalisation, Kelly gives the example that a generic version of a concert recording may be free, but if you want a copy that has been tweaked to sound perfect in your particular living room — as if it were preformed in your room — you may be willing to pay a lot.  Aspirin is free, but aspirin tailored to your DNA is very expensive. Personalisation is what we can offer our clients, making sure the document we’re giving them is tailored to their particular circumstances, and meets their needs exactly, something a template can never do.

Similarly, with interpretation.  Many open source software companies make their software available for free.  Their business model is to charge for the support they provide in conjunction with the product.  The software becomes valuable to you with their support and guidance.

As lawyers, interpretation is not just about walking our clients through what our documents mean.  It’s the step before that. It’s walking them through the decision-making process. It’s asking the right questions so that we have all the information, but so that we can help them make the best decisions.  It’s so much more than getting an email saying “please draft me some terms of service”.

This is where I believe we have an opportunity as advisers, to add value over and above the code snippets and core templates.  This where we can and must do more.  We become trusted advisers when we earn that trust, and in this sector, we need to be a lot more conscious about the way we do it.

We need to get to know our clients and what they need, and to offer them robust, cost-efficient light-weight solutions that meet their needs.