Extreme Contracts - Jacopo Romei at FlowCon France 2019

[00:00:00] background. I won't bother you too much with what I did because I don't think the validity of any argument should depend on who tells those arguments. So, if I did bad things or good things, valid arguments are valid or not, okay? But by the way, just to give you, just to resonate with you, there are many roles probably in this room and I want you to know that I started coding in 1996 in the full open source era. And I have been twice an entrepreneur, and I destroyed both companies. Uh then I got into freelancing about agile processes, and I got back into entrepreneurship. Uh in 2012 I got hired by eBay caring about their processes. And in 2015, four years ago, I basically, I sold my share in the last company that I had and I got back to freelancing. caring about processes on any knowledge work based company. Uh as a on a side track, I've been singing with an Acapella band featured on Rolling Stone magazine since 16 years, 16 years ago. I've been a sailor and I fly gliders. So, I mean, I love air sports. Okay, fine. Now, let's start with an Italian lesson. Uh Italian, it's a very regional Italian lesson. Uh do you know what this word mean? Probably not. It's pronounced "Umarell" with the double L. Umarell are, it's a name for people like this.
[00:01:46] So it's like old retired people watching work in progress and judging the way it's being performed. We have a word for that, which is nice. I mean, and sometimes it proves very useful. And you know, uh why I think this word is important today. Well, we all love Lean here. I'm assuming that everybody here loves Lean or no matter what's the what what the proficiency. But still, the maturity level, call it whatever you whatever you want. But I mean, everybody here is at least curious about Lean processes. And we know that value is everything that is not waste and vice versa. And when I've been working with my own customers, uh as a consultant or as an entrepreneur, I've always, I've always seen the projects failing for the same old patterns every time, every time, every time. And they have always matched a few repetitive patterns. And for example, I lost much, much time explaining myself. Why did why are you doing automatic tests? Because blah, blah, blah, blah, blah. But you are paid to deliver features, not to refactor the code. Uh, why are you making these uh daily stand-up meetings? Why so actually, I had to explain myself most of the time. And this led to a very strong negotiate negotiation confrontation, negotiation related confrontation. And much of the time was spent negotiating the scope, the deadline, the budget, and blah, blah, blah. And so actually, what we call you often we call negotiation this way. And it's all due, I came to learn that it's all due to the to a lack of trust. Basically, when we work with people we trust with, we don't need all that stuff, all that boilerplate. And instead, when we are when we are knowing each other, when we are sniffing each other. Uh we are basically seeing those patterns happening because of the lack of trust. And in the end, I I actually suffered a lot up to 20, 2010. I suffered a lot the fact that I needed as an entrepreneur or as a consultant or even as a developer to ask for permission to do my job the way I wanted to do it. And I thought, this is wrong. So basically, I wanted to work, I wanted to deliver value. And I'm sure, or maybe, I'm not sure that I will be delivering value. But if I don't deliver value, you I want to be judged, I want to be chosen for the value I deliver and not for the for the choices that I do about my own process, about my own tools, about my own techniques. So, how many Agile Lean practitioners are here?
[00:04:41] Okay, cool, close to 100%. Uh and now, you know, I mean, we all love then we have we share one love, root cause analysis. Okay? If something bad happens, I mean, I'm also an aviator, so I really love root cause analysis. And whenever something anything bad happens, I want to know the why, why, why, why, why, why. We'll know, I will skip this part because you all know you all know already. But the point is that our projects failures main root cause maybe must be found in what are the social-technical characteristics of our system. Have you seen the the sessions the previous session about social-technical analysis of systems? I mean, Kenny Kenny's session and uh I don't remember the name of the other speaker. But still, uh Kenny has been a friend for years, so it's easier for me to remember his name. Uh basically, are we trying to fix technical problems or are we trying to somehow work around other kind of dysfunctions that are leading us to technical problems? And I mean, in my experience, most of my problems were due to relational problems. Relational not in the meaning of some deep feeling that I have to feel and resonate with my own customers. But just because the root cause was never that technical. I never saw a bunch of nerds like me failing in finding the proper algorithm and the proper infrastructure to solve an automation problem. I've always seen misunderstandings or expectation mismatch. And basically, it it cannot, everything can be reduced to a confusion about terms. So, terms in the the meaning of words, in the meaning of meanings, in the meaning of a of goals, but also terms and conditions. So, it's about what do we expect to happen and what if we cannot meet the expectations? And so, we care a lot about blending and merging silos and having cross-functional teams. But what if our contracts are actually keeping the customer outside of the team? What if our contracts are keeping the users out of the team? Are they in or not? Do they perceive us as advers in a in an adversarial way or do they perceive us as teammates? Uh, do you know the Sapir-Whorf hypothesis?
[00:07:31] Uh it's a it's an hypothesis made by Sapir and Whorf, about the way uh it's about the hypothesis that the way we talk shapes the way we think. And so, if we keep on talking about counterpart, 'controparte' or 'contrepartie', this is a problem. If the hypothesis is true, then how can we hope that a contract leads us to a collaboration if we keep on thinking about us and them on the upside, on the opposite sides of a table? Rather than sharing the same side of the table and confronting together our problem, which is maximizing the value delivery for both sides, or even three sides, four sides.
[00:08:22] Again, we love lean thinking and the pillars of lean thinking are respect and continuous improvement.
[00:08:30] And I'm afraid, I'm afraid that standard contracts are basically non-compatible with lean thinking. Why? Standard contracts are basically two types: fixed price, time and materials. Let's see them. So, fixed price contracts are inherently not based on learning, are not inherently not based on continuous improvement, are based are not based on Kaizen. Basically, you shoot a mis a fire and forget missile, which has to meet a fixed scope within a fixed deadline for a fixed budget, and we hope that we knew enough for our estimation to be right in the end. Time and material contracts, on the other hand, which are often felt like the holy grail of the knowledge worker, are basically, I mean, it's a tragedy. Time and material contracts which are the best perceived contracts by knowledge workers should be forbidden by law according to me. Because they reward this 'ceteris paribus' in Latin, which is in English something like, uh, everything else being the same, time and material contracts reward the slower worker. Which makes no sense. They are they provide no incentive for innovation. No one by the nature of the contract is gets any incentive in making in delivering something earlier. And also, it's not respectful for the customer. While the fixed price contract shifts all the risk on the supplier side, in the time and material contracts, there's no respect for the customer. Because I mean, yes, it took five days rather than three. It took five months rather than three. I mean, this is not a shared endeavor, this is not team working. This is a problem.
[00:10:29] So, what can we do? So, but the problem is that we keep on using them because they are simple, because they are known. Because they are easy to explain and we just agree on lots of assumptions that make us use those contracts again and again and again.
[00:10:46] And we use them because we don't know how to focus our contracts on value. We don't know what's the value of our work. And then we end up measuring time or a fixed scope of features to get paid.
[00:11:07] Now, Alberto Brandolini was quoted more than once this day and I'm not any less. So Alberto Brandolini says, he's a very close friend. And he says, learning is the bottleneck. For any kind of knowledge worker, IT or design or UX, interaction design, architecture, photography, publishing industry, anyone who's not working on serial production has this problem. Learning is the bottleneck. And contracts are usually learning oriented, sure. It's not true. Uh we can say that contracts are production oriented. Usually contracts are delivery oriented. We we define what I have to give you in the end. Even better, contracts are usually oriented on the process. They define when I give you what for what kind of delivery, on what support and all the clauses that we are used to add are about the process that we will follow. And I think this is wrong.
[00:12:18] First, because we create value 24/7. Knowledge workers have their best ideas, no one knows when. You can have a shower on a Sunday morning, have a very good idea that you will deliver on Monday, and no one will pay you back for the time you spent having that shower.
[00:12:40] If I have an idea on Friday night while playing with my kids, no one is going to pay me for the time I spent with my kids. I don't have kids, but I still try to empathize with someone who has. So, value creation happens anywhere in the life of a knowledge worker. And the contracts should map this uh aspect of their lives or that's my point of view, they shouldn't at all. We shouldn't track the time the way we shouldn't uh we should never give any disincentive to have good ideas.
[00:13:23] Also, knowledge work is not about execution. Knowledge work is not, I mean, this is quite known in this in this audience, I guess. But the problem is not the code. The problem is not the deliverable. The problem is not the the drawing on the paper, it's not the point is not the the printing of the photograph. The point is in the exploration of the problem and in our in how effective and efficient your exploration of the problem is. And so if you are a coder, just to make the example I'm which I am most comfortable with,
[00:14:00] the point is that the code itself is not an asset, is not a value. Now let's try this experiment. Uh you. If I give you 10 kilograms of gold or 100 kilograms of gold, what do you prefer? As a gift.
[00:14:20] The answer may be obvious.
[00:14:26] Yeah, basically she's she answered, the more gold I get, the better it is. It's fine. So, that's because gold, since millennia, has been an asset in every most close to every culture in the world. Fine. Now, for the same problem analyzed, understood and automated. Would you prefer 10 lines of code or 1,000 lines of code?
[00:14:57] This is the point. Code is the liability that allows you to solve problems in an automated way. It's like making the difference between houses and mortgages. I mean, I would love to have as many houses as I can in my life. But definitely, I wouldn't want as many mortgages as I could in my life. Despite mortgages being a very key device to have to get new houses. But still, that's not value, and the value is not in the delivery, the value is in the problem that I'm helping to fix. And if a waterfall agreement is in place, then you know what, we crave for adaptive processes, but what adaptation is possible if the contract defines everything? And this is what I grew up, so suffering when I was an entrepreneur. When I had my third company, the one that went fine, I was like, yeah, but we still keep on talking about retrospectives, agility, automatic tests, and we have this right arm growing bigger and bigger and bigger and bigger, and then we keep on explaining ourselves and asking for permissions to do the way we want. And we talk about being adaptive and nothing is adaptable as long as the customer who pays maybe even pays the time, is gets incentives in managing our time. Basically, if you sell yourself by the hour, by the day, by the week, they are justified in discussing the way you spend your hours, days and weeks. Because that's what they're buying.
[00:16:37] And so, I want to be lean, I want to be agile, and I still adopt other contracts which basically set an upper bound in how much agile or lean I can be. So what's the point of keeping on telling us this fairy tale? I drink.
[00:16:55] I have a bucket of sand in the gasp. Okay.
[00:17:03] And so what? Well, we need we need value driven contracts. Contracts which are empowering both parts. Oh, let's keep it simple. Let's just assume they are just two. It could be three or four, but still. We want contracts that enable the parts discussing the value, paying for value, delivering value. Okay. So, let's change for a second the topic because I need another thing to be clarified before we go on. So, let's talk about mental models. For a second.
[00:17:45] Okay, we tossed a coin 99 times and it was heads, tails, heads or tails, okay? I was it in French.
[00:17:58] I didn't understand, you tell me later. But okay, so fine. So. It's in italiano it's testa o croce. It's like head or uh croce, it's like cruise. "Quoi"? Voilà. Donc, euh. So, we have a coin which has been tossed 99 times and every time it was heads.
[00:18:24] What are the chances that the next time will be heads again?
[00:18:30] 50%? 50%? Raise your hands if you think it's 50%.
[00:18:38] Thanks, let's have a check. Raise your hand if you think it's not 50%.
[00:18:45] Four, okay. Thanks. Now.
[00:18:51] It's very interesting here because if if it happens in reality. So we are taught to think with a mindset that uh I think Huey, Dewey and Louie represent very well. In our manual, it's written that it's 50-50 because numbers don't have memory. Which is fine, I mean, I I was I was there.
[00:19:17] I've been there too.
[00:19:20] Don't get me wrong, there is a second mindset which is the one we use lots in gambling, like, yeah, heads have never been, so it's like never never been tails for 99 times, so the chances that will be tails skyrocket. No, we know it's not like that.
[00:18:53] if it happens in reality. So, we are taught to think with a mindset that I think Huin, Ju and Louis represent very well. In our manual, it's written that it's 50/50 because numbers don't have memory. Which is fine. I mean, I I was I was there. I've been there too.
[00:19:19] Don't get me wrong. There is a second mindset which is the one we use lots in gambling like, yeah, heads have never been, so it's like never never been tails for 99 times, so the chances that we'll be tails skyrocket. Uh, no, we know it's not like that. But the point, the point is that from a pragmatical point of view, if you think out of the box, if you think, if you adopt an end-to-end rationality model, a coin which was head 99 times is not a fair coin. And we have to stop thinking, this is a fair coin. And so the chances that we will be heads again are much higher than tails. And this is a key point about contracts because we want to frame our agreements in an end-to-end rationality context. And not just keeping on assuming that what's what's written in the contract will be will be happening just out of a renewed magic that, well, we were just unlucky the few other 1,000 times.
[00:20:38] Rationality in the definition of by, uh, made by Nasim Taleb, Have you ever, have you ever read a book by Nasim Taleb, like The Black Swan or Antifragile? Well, you should. Rationality is the avoidance of systemic ruin, and if we keep on adopting contracts which entail ruin as one of the possible outcome, then those contracts are not rational.
[00:21:07] And also, again, I'm I I I want to dig even deeper in this. Do you know what duck typing is? I'm a nerd, and I I mean, I know, but I'm not assuming everybody knows here duck typing. Raise your hand if you know what duck typing is. Okay, I will explain it. So, there are basically two huge families of programming languages, those who define types of the variables, it's an integer, it's a number, it's a string, it's a text in a crisp and fixed way. And there are other kind of languages which say, well, I try to add it up to two, and if this plus two works, that should be a number. So it's something like defining the type of something afterwards. And it's called duck typing because it refers to a very famous saying which is like if it quacks like a duck, if it walks like a duck, it it flies like a duck, well, it is a duck. It's a very empiricist point of view. Okay, fine. Now, what has to be what what does this has to do with what we're saying?
[00:22:15] If we keep on acting like people who don't like Agile, if we keep on acting like people who don't know what Lean is by adopting wrong contracts, I'm sorry, we're not Lean, we're not Agile. What we do matters much more than what we say about ourselves. And so, back nine, oh sorry, it's going to be almost 10 years, but in 20, sorry, in 2010, in 2010, as an entrepreneur, I started working, I started investigating for ways to get other contracts that could allow myself and my partners and my employees to be lean as we really mean it. Last point before we go on with some example.
[00:23:10] Agile is not also is true for Lean. Lean and Agile are not a value proposition. No one should sell Agile, that's why I removed the Agile coach headline on my LinkedIn profile. Because Agile is something that do you know the business model canvas?
[00:23:32] Okay, fine. So you know that in the center you got the value proposition, but there you got key activities and key resources and agile and lean are our key resources and our the way we act in our key activities as developers, even as consultant. But our value proposition should be something else should be like having more money, more happiness, in an easy way, in a cheaper way, in a simpler way. And Agile is just a tool, just the tool.
[00:24:05] And this is a key problem, if we keep on assuming that the way we deliver something that the the well actually, if we keep on assuming that the delivery is the value, we are wrong and we are missing the whole holistic point of Agile and Lean methodologies and mindset.
[00:24:23] Also because we are working in an environment in which tactical level and strategical level blends, sorry, too. So, they blend a lot.
[00:24:38] If a programmer writes crappy code, is not they are not just defining tactical decisions. They are making strategical decisions which are related to the technical debt in five years for the whole company. And companies that beg for my help to fix the technical debt now, probably somehow, I ignore the relationship between their hiring process, the code that every junior developer was injecting in their code base, and the effect of those of that technical debt downstream five years later in their strategy. Which, I mean, like the decision of rewriting a platform from scratch rather than improving the platform is a strategical one, and I've seen this decision face many, many times in the last 20 years.
[00:25:34] And this leads us to a final point which is it's amazing how we let procurement and legal offices then to define the strategy of the company rather than supporting the strategy of the company. Because basically if we got procurement offices that are choosing our partners and our suppliers suppliers just on a metrics of cost, they are injecting quality in our code base which is affecting our strategy in five years from now. And I'm sorry, but the strategy should be independent, made in the in the company and all the departments in the company should support that strategy. And I I I've lived on my own skin how hard for big corporation is to hire myself, to hire me, just because the procurement process is, no, no, they say we we cannot hire you. What? Everybody is agrees, the board agrees, the department agrees, the people I should work with agree, but the no, we don't have the the legal said that should wait six months from now. What? Are you working with me or against me?
[00:26:51] And I think this, uh, it's strike it's struck me today to see how this slide by Elizabeth Airs, Airs, Airs, right? Okay. Airs. Airs. Airs. I know, sorry, yes, but it's the this is the genitive, so, yes, yes, I know it's outside of your surname.
[00:27:15] Yes. So, basically, we will get back to this slide once more in the end if we we want to see how much of these dysfunctions can we fix just by adopting other contracts.
[00:27:29] Now, let's get into the second half of this presentation. Up to here, everything is clear? I don't I don't I don't I'm not asking if you agree, I'm asking if it makes sense.
[00:27:42] Okay, thanks. I mean, feedback, it has to be continuous. If I know it afterwards, it's too late. Now, extreme contracts are the name I gave to a family of contracts I've been experimenting, researching, and adopting in my own business, my own business, on my skin, since 2010. It's a family because they are very context dependent. I will provide you with two examples, I learned that one example led the discussion afterwards to be too much focused on the example rather than the abstraction. So, I'm delivering you two examples so that you understand that they can be very different, but still belong the same family. Uh, I call them extreme contracts for the same reason Ken Beck called his own style extreme programming. Do you know extreme programming? Have you ever heard?
[00:28:33] Extreme programming was named like this because Ken Beck said, well, if something works very well, why don't we bring it to the extreme top notch and we see what happens? I drink.
[00:28:49] And after having experimented with those contracts, I distilled two years ago, so it was like after eight years, eight basic principles, which I'm not going to tell you because I don't want this presentation to be theory, I prefer to give space to the examples. So there are eight principles that are somehow shared by all these contracts. And principles because we want them to be declined, we want to to we want them to be adapted to the specific context. So, the first context I will talk you about is a codice plastico, it's a very Italian name for an Italian uh software factory. It's a boutique software factory, like very few people with very huge revenue uh every year.
[00:29:40] Well, I'm I'm going to tell you a a true story, so true that I'm going to show you the email that started it all. So, I know that you cannot read, I'm going to zoom it before you shoot the photograph, I'm going to provide you with better detail.
[00:29:54] So, the date is 5th of October, so 13 months ago.
[00:30:01] I was writing this email on behalf of them to one of their new customers. Okay?
[00:30:07] And you see, it's very long, I will be keeping short on the key points. So, first point, we love supporting real business with real goals and along the years, we have learned, this is not so common. Big corporation, for example, sometimes they just have to burn sub-budget out. This is not true for small startups. The customer in this case was a startup. Having more demand than capacity, we have come to develop ways to select projects in which we can truly deliver value to our customers' business goals.
[00:30:40] Third point. We like the idea that both we and our customers may mitigate the risk in the collaboration with the least end-to-end commitment on both ends of the deal. We shouldn't marry. Can we just hang out a while?
[00:30:57] To do this, we act in three simple steps. Ooh.
[00:31:03] First, so, A. Customer only pre-allocate a part of the budget at a time. B, we work for a small time boxed non-deadly lapse of time. At the end of the iteration, we cross-check. First, if the customer thinks they got enough value, they pay and get the deliverable.
[00:31:23] Second, if the customer thinks we didn't deliver enough or that we are a scam or we are just idiots, we are free not to pay and leave.
[00:31:32] In its essence, this allows for the customer to discuss the value of our delivery and for us to quickly learn what's valuable for them. In practice, every iteration we try to meet a business goal, which is worth at least the price set for each one. That's it. So, basically, what we were doing, we were delivering software every five working days, every week. We bring the software for a fixed price. Do you like it? Do you think it's worth the price that we are asking? If no, sorry, we can discuss whatever, we start again, we can beg you, beg for your pardon, we can just go away because your critics makes no sense, whatever. But if you accept it, you pay us for the iteration and we start, you know, you we start from scratch again anyway.
[00:32:23] Well, that means that we were working for free for five days? Yes, but you know what, have you ever worked five days late on a fixed price contract?
[00:32:35] Have you ever? I want you to raise your hands.
[00:32:40] So few? Oh, lucky, many liars in this room. Five days over deadline is basically to either free work, which is exactly like this, or if you provided yourself with a buffer in your contracts, in the agreement, in the quotation, it was money meant to be stolen everything went fine. Which is dysfunctional again.
[00:33:09] I will skip the FAQ part, in case of questions, we can go there. So, this kind of contracts was is very powerful because it leads to easy acquisition, basically, the customer says, listen to, hey, we work for you for five days, if you like it, you pay, otherwise not. Do you accept it?
[00:33:27] The customer,
[00:33:31] Yes.
[00:33:33] But the point is that this is a first key feedback point. Because once in a while it happens that someone tells, no, I no, I don't like it. Why? And when the reasons for them not to accept are somehow understood by us, we can tell whether the customer is the one customer we want to work with or not. And I'm not assuming they are wrong, but we are talking about a mismatch. The quality of customers skyrockets because, actually, we are filtering automatically people who are caring about the value, caring about not caring about the process, not caring about the way we work, not caring about automatic test or not, not caring about anything else rather than, are you providing me with more value than what we are paying?
[00:34:27] And the quality of delivery is also high because, I mean, we have to get as many chances as we can to be to get our delivery accepted. So we are working to provide lots of value, lots of value, not lots of code or features as Elizabeth told us today. It's about value. So, are we fixing a huge problem for you considering just five working days? If the answer is yes, you can pay us. Also, the lack of trust was acknowledged and addressed. We are not saying we work for five days, you pay in advance and then we go. I mean, you are right. The customer should be given space to be afraid of you. We are all afraid of each other, we don't want to get rid of this fear, we want to use this fear and we want to address this fear in a constructive way.
[00:35:22] The negotiation was very easy. The estimation was needed, but just as much as to understand what could be valuable for you in five days. We're not we were not estimating five months, five years. We were not the Soviet planning for the next five years. We were just planning for the five working days. And planning quantity makes quality when we talk about estimation. And it was strictly value-driven. Is it valuable or not? You don't know you don't know you don't even know what we will what will what we will deliver, but if in the end it's worth the money that we ask you, then it's value-driven. And no need for authorization there. So, Umarel are out of the way.
[00:36:05] Cool. Let's have another example.
[00:36:09] Bolognelli is the so the code name for a very huge publisher in Italy. Which is based in Bologna, so I decided them to I decided to call them Bolognelli, but it doesn't exist, okay, so don't look for it on Google. Don't don't think it's a fake story just because the name is fake.
[00:36:29] So, uh, this is a nice story. This is this was also last year.
[00:36:35] My friend Raffaele asking asking for my help to talk with Bolognelli about streamlining the workflow of their six publishing lines, okay? They make educational books. So it's was it was like one pipeline for maths, one pipeline for science, one pipeline for literature and so on. And so, uh, they were asking us for help to reduce the amount of printing error and make it make their process easier, faster and cheaper. Okay, cool, cool. They even mentioned bottlenecks in their own words. It was like, wow, this is a dream customer. So, six pipelines, so we decided to arrange six workshops with the six publishing lines, with the with the six uh teams of authors,
[00:37:32] Do you know Event Storming? Have you ever heard about Event Storming? So we used, we decided to use Event Storming to extract information about their processes and distill hotpots. Nice. So, we were planning for six workshops plus one in the end to cross-pollinate the teams and to enhance uh the sharing of good ideas, okay? Fine. But this this this talk is not about workshops. Let's get back to negotiation. Fine. So it was seven working days. When we started talking about the quotation, Raffaele started working on, yeah, the cost for six days in two people, then we could be three people for the seventh days, it could be the cost could be that, so we can add a margin, so it could be like 20 k for the cost, so we are at 44% margin on top of that, so it's 36,000 euros. Are you satisfied? Yeah, it could be also in those in that cost, sorry, in that cost, it was also included my own compensation for a daily rate he decided without asking. So I was like, well, we can talk about a little bit more, but still,
[00:38:51] do we know how much valuable is always work for them? Actually, we didn't know at that point. And it was too late to ask them, but because it was the evening of the day before having to deliver this quotation. So what we did? I propose to use the value of your activity, maybe it cannot be known, but can be somehow hooked, led by an index. also included my young compensation for a daily rate he decided without asking. So I was like, well, we can talk about a little bit more, but still, do we know how much valuable is all this work for them? Actually, we didn't know at that point. And it was too late to ask them, but because it was the evening of the day before having to deliver this quotation. So what we did? I proposed to use the value of your activity, maybe cannot be known but can be somehow hooked, led by an index. And the index that we could use in that case was the revenue, the early revenue they had already shared with us. So we knew that they were accruing 220 millions per year. Okay, fine. Which if you think it's like it means that 10% is 220 millions, 1% is 2.2 millions. Let's zoom that out. Boom. So, 2.2 millions, so it means that it's 0.1% is 220,000 euros. So, well, it went down to having 0.04% which is four out of 1000 parts, which is, sorry, it's 0.4 out of 1000. So which is four out of 10,000 parts of their early revenue was 88 kilo. Well,
[00:40:23] I was I was thinking, is spending four parts out of 10,000 of your early of the revenues for one year too much if you think that activity is strategical as they mentioned? Well, I don't think so. If you invest even less, I mean, probably you were looking for I just to as a joke. But I said, probably you are looking for team building, so why don't you go having a rafting session on a very one of the amazing Alpine rivers that we have in Italy? So, still, still though, we have to put ourselves in their shoes. And what about the trust and the risk then again? So, even if you have 220 millions early revenue, you don't want to throw 88,000 euros away. You don't want to throw them out of the window. It's we have to be respectful of their budgets. And so, our proposal was to have the first day for free. So that they could, you remember, it was like this.
[00:41:36] Six workshops. So, the first one, they could get it for free, just for the expense. refund. So that they could appreciate the way we design the workshop, the way we facilitate the workshop, and the way we could get an extract real meaning out of one day.
[00:41:55] And our proposal was that once you have that one day delivered, you can judge it, you can decide, you can assess it and activate the following six.
[00:42:05] Well,
[00:42:09] did they accept?
[00:42:12] They wanted to talk with me off an hour, and they discussed the fact that they wanted to include printers together with the authors of the books. Which was, I mean, amazing. It's it was a very cross proposals and I told them, well, if I knew I could do it, I would ask for it, but yeah, please, let's do this all together in one room in front of our even storming paper roll.
[00:42:42] And then again, they told me, well, risk, we cannot tell you, we cannot assess the whether you are an idiot or not in just one day. We need two. And I told them, well, two days for free are too much for us. We have a cost of we have an opportunity cost and we can deliver our value somewhere else and we get paid. We don't want to invest that much. But, but, as a test, out of seven days in a budget of 88,000 euros, anything less than two parts out of seven would be a fair test. And so, 88,000 euros divided by seven is something like 13,000 and we asked for 6,000 euros for the first two days. They accepted? Sure. And have you noticed, they never discussed the price. They never discussed the 88,000 euros that we asked in first place because we addressed in a clear way the impact and the risk. Which is the key point, we keep on negotiating prices because that's the only dimension that we can see in an objective way. And you know what? The difference between 36 and 88 is quite huge. So it is nice to understand what Rafaele owed me after this consultancy.
[00:44:17] What did I do?
[00:44:19] I mean, if they could get 37 and I could get the rest and it would be fair anyway.
[00:44:26] That's not what I did.
[00:44:29] I asked them to decide afterward whatever they wanted.
[00:44:35] Why? Because I wanted to assess the validity of a partnership and I wanted to know whether they are a good partner to work with. And you can only assess that end to end when money kicks in. I don't want to assess on paper their credibility, their trust or my trust. So I let them free to decide and they proposed to do 50/50, which was fair enough. So, release and celebrate more than use a success in both the examples. Check. No feature ever fails. Well, we not we we didn't only let the features fail, but we let the whole collaboration fail if it was not the case to keep to keep on having that collaboration. In the iteration of five days and in the single two workshop test, we had the chance, we let we let them, we let ourselves the chance to quit the whole collaboration, not just the single feature. And also, the planning was starting from the needs of the customers or the users, not from a list of features. Often in these cases, they don't they didn't even know what we were about to do or what we were about to deliver. Features were out of the discussion. It was our concern. Now, we got five minutes left.
[00:46:00] Questions?
[00:46:08] Uh maybe he needs the microphone?
[00:46:12] I don't know where it is.
[00:46:15] I can I can I can I can repeat the question in this microphone.
[00:46:19] Yeah.
[00:46:21] I drink in the meantime.
[00:46:26] Sorry, just just a little technical question. Uh I I saw that you also wrote a book about the extreme contract.
[00:46:33] It's the next slide.
[00:46:34] Thanks. Okay, is it in English because I see on the Italian?
[00:46:37] Yeah, yeah, I have a fine. So are there any other questions?
[00:46:43] I will reply this question in a while, but any other question?
[00:46:50] at the end do you sign the contract with your customer?
[00:46:54] Uh actually, in both the example, he's asking, in the camera, he's asking whether I signed the contract with the customers. In both the examples that I provided you, I I didn't prepare a formal contract. Because the risk was in one case out of five days. And in the other one, it was basically a very cheap contract and once you are in, we trust them to pay. It's not a problem. It's yeah, there was a maybe in the second case, there was a Rafaele did something more formal, but I wouldn't have done it.
[00:47:30] Last question, if any?
[00:47:31] Yes. Um, I don't remember how it is called, but the fact that when you have already paid too much, you don't want to stop. You remember it was on the
[00:47:42] So far, I didn't understand.
[00:47:44] But there is a a law that when people are biased, maybe?
[00:47:50] Ah, yeah.
[00:47:51] Yeah, when you pay when you're already have paid 50%, you don't want to to to stop because it's already invested. How do you do that? Because paying and at the end the customer will always say, okay, I continue, I continue, I already invest too much to stop.
[00:48:10] Okay. Uh so basically he's talking about the escalation of commitment, which is one of the documented more and more most discussed cognitive biases. So basically saying, if you if you have people paying, how do you cope with the fact that they will keep on paying just because they are too much involved in the in the in their business? Well, I think we're doing our best in both these cases to let them validate the validity of the investment before they pay. And when they tell you in a fixed price contracts that you are being paid at the end of the project, actually, that's the reason why we don't mind working past the deadlines, that's because we worked nine months and we didn't see a dime and that's the escalation of commitments that we see. So basically, I think these two contracts are these two examples and I got 10 overall are way too much fair too so way too way much more fair than any other kind of standard contracts on this concern. Now,
[00:49:20] yes, I wrote a book in Italian which is called Extreme Contracts. Next week I will be five four days in Bilbao with sharing a desk with a friend of mine, he has to write his post doctoral thesis, and I have to write the first release of the English version. It's not just a translation, the only good thing of speaking Italian is that I can I could validate my content without leaking in the international scene. So, I wrote the book in Italian, I gather feedback and now I'm rewriting the book from scratch using the feedback I got from Italian readers, okay? Uh
[00:49:56] there is a newsletter, it's very easy. bitley, extreme contracts newsletter, if you subscribe, uh I will never send more than 12 emails per year, so far I've been sending once per year, so definitely not spam. Uh Jacopo Rome.com if you got questions or if you want to I mean, you can even on the homepage you find my mobile phone. So you can call me on even on Sunday if you got questions on anything about your the way you find your own agreements with your customers or your suppliers. Thank you very much.

Transcript