Transcript

Hello and welcome back. I am Josh and I am the only person in the world who has been in the trenches for the last 7 years building and maintaining contract repositories and doing nothing else.

So, last time we concluded that key person risk destroys business value and by this point I’ve shown you loads of horrible problems that result from key person risk.

Today, we’re going to talk about the solutions.

Now, I want you to think about cooking a dish. This is our contract repository. This is the artefact, this is the thing that is produced from all the work we do. But, someone needs to do that work and that person is the chef.

The chef builds the contract repository. And they keep it in good shape on an ongoing basis. New contracts come in, we want to change things, we want to add more data, etc.

And this has to be someone who knows what they’re doing. But, if the chef leaves, we’re screwed. We can’t just get anyone to do this, we’ve got to find another really good chef.

And, how are they going to know how to cook the dish? How are they going to know how to operate on the repository?

Well, this is why we need a recipe. And this is the thing that no one does. They don’t create the blueprint for how to operate this thing on an ongoing basis, or how it’s even been built in the first place, or why it’s been built the way it’s been built.

And, this is the fundamental missing piece. To have to have a really good dish, you need a really good chef, and you need a recipe.

Let’s just think about what a contract repository recipe might look like. We’ve got to think about which data points we want to extract, and how they relate to each other.

There’s a whole lot of things to think about for every single data point. We need a definition that is shared across every single person who’s responsible for working on the repository, to make sure we’re all on the same page.

What exact instructions, what parts of the information do we want to extract into a value? How do we deal with edge cases?

For example, what do we do about carve-outs in a liability cap? Or, do we consider it termination convenience if we have to pay exit fees?

What’s the business context? Permissions. Who is allowed to see and do what? And then the document structure. We don’t have a good contract repository unless the documents are organised in a coherent, structured, consistent way across the whole thing.

But there are many different ways that we could organise our documents. we need to encode this so that we remain consistent over the lifetime of the repository.

Now, no one writes recipes. I’ve never come across a company that has an instruction manual for their contract repository. And there are three reasons.

First is capacity. We’re talking about people who already have no time in their schedule. They do not have further time to write and maintain recipes.

They don’t even have time to do the chef work. But the real killer is competence. Now, this isn’t to call you incompetent, but there’s a very specific set of skills required to do a good job here.

And there’s a whole load of experience that basically no one gets unless your full-time job is to look after contract repositories for a large number of different organisations, because so much of the competence comes from having seen a very wide range of contracts, a very wide range of business situations, and intimate knowledge around all of the edge cases that can occur. And the problem is, this competence , if you do have it available in your organisation, it’s concentrated in the key person who is most capacity constrained as well.

Now, conflict, I couldn’t really think of a good image to use, so I’ve drawn you a Jellyfish. Conflict has a couple of shapes here.

The first piece is that, if you are a key person, you have more bargaining power with your organisation.

So, a lot of people would rather stay that way than de-key themselves. The second one is that, if you do this, you are taking on a whole load of additional work in your already capacity-constrained schedule.

Now, when you’re able to overcome all three of these things, and you have the recipe, and you have someone available to do the work, who can do the work, then you convert this thing which was actually taking away business value, into this thing that gets more valuable over time.

It compounds over time. It’s an asset, it’s not a liability. Every single time someone leaves, every single time there’s an emergency, and you get yanked away from your work, every single time you fall behind on keeping the thing up to date, you end up relearning the solutions to the mistakes you’ve made over and over again.

But once you shift from this brittle process that is bottlenecked by people, you end up with a business that, in this department, is completely inert to the extremely unpredictable and damaging consequences of key person risk.

Thank you very much and I’ll see you in the next video.