Is efficiency a good thing?

0:02 Comment ça va ? C'était bon? Ce déjeuner? Génial, vous avez networké un peu? Qui a fait l'expérience du chocolat? Alors, comme ça? Le chocolat, c'était comme ça? Vous avez senti la différence de goût suivant le son? Oui? Bon, d'accord. On va dire que oui. Bon, super. Je suis ravie de vous retrouver pour cette deuxième partie de notre premier jour. Et là, en fait, nous allons retourner au thème de l'efficience, après avoir parlé du chocolat, avec un angle abordé par notre invité qui va être particulièrement intéressant, puisque malgré tous les efforts... Vous voulez que je vous laisse finir vos petites conversations ou comment on fait? Comme vous voulez. Je vous laisse rentrer. Voilà, il y a encore un peu de monde qui entre sur scène. Enfin, sur scène, pas encore, mais je risque de vous faire monter sur scène, je pense, les retardataires. Ne me poussez pas, ne me poussez pas. Je vous laisse vous installer tranquillement, parce qu'on a une invitée de marque, encore une fois, qui nous fait la joie d'être avec nous.

1:08 Donc on continue sur ce thème de l'efficience, parce que malgré tous nos efforts d'automatisation, de gain de productivité, la charge de travail est quand même plus lourde et nous consommons énormément de ressources. Ça ne vous a pas échappé? Ça ne vous a pas échappé? Ça n'échappe à personne. Donc, c'est quoi le problème? On va essayer de définir qu'est-ce que c'est que ce problème. Et je vous demande d'accueillir Holly. Kuminski, Senior Principal Software Engineer de Red Hat. Ma chère Oli. On peut faire une autre salve d'applaudissements pour Holly Cummings. Merci beaucoup. Merci, Oli. Je suis ravie de vous accueillir. Ravie. Donc, ce talk va être en langue anglaise. Voilà, je précise pour notre foule. Et puis, ensuite, on a une petite partie de Q&A. OK, si vous agreez. I'm sure that we're going to have a lot of questions coming from the audience. OK, so the floor is yours. Thank you.

2:08 If you need the remote, it's here. Thank you very much. I'm delighted to be here. This is the efficiency part of the presentation. Hooray! No, no, no, no, no, no, no, no, that's the ending. We've jumped to the punchline. I'm using my microphone. Oh, going wrong. Very efficient talk. Very efficient. Very efficient. So it's okay for you? No, no, no. We need to go. Ah, hooray. You need me to help you with this mic. You know it's a Madonna mic. So let me see. Tell me if I'm not hurting you. It's okay. First here. Second here. No, it's not. I think we'll just have to switch to a...

3:11 Is it okay or not? Do you want to handle one? Yeah, I think that's okay. Okay. Alors, un micro-main qu'on va trouver tout de suite. Est-ce qu'on a Manon éventuellement au Romain? Ah voilà, je vous avais dit, vous êtes formidables. C'était évident que vous alliez intervenir tout le temps. On va donner le micro à Rolly pour qu'elle puisse. Merci beaucoup. He's a hero, the savior. So I hope it will be fine. Do you want me to unplug you behind to be at your heels? No, it's okay? It's fine, thank you. Okay. So there's a lesson here in software testing, because I can't tell you how many times we tested that microphone backstage. I moved this way, I moved that way, the microphone worked. And then you go and you test in production. And it all falls apart. And this is why you need resiliency. But we're not here really to talk about resiliency. We're here to talk about efficiency. And probably the first question you're all asking is, what on earth just happened with the slides and the microphone and everything?

4:11 But the second question you're all asking is, why is there a kangaroo on the slides? The reason there's a kangaroo on the slides is because kangaroos are the world's most efficient land animal. And the reason kangaroos are so efficient is because they hop. And when they hop, they convert the kinetic energy of the bounce into elastic energy in the tendons, and then they hop and it goes back to mechanical energy. Who knew? But still, why is there a kangaroo on the slides? Well, the theme of this year's event is efficiency. Kangaroos are efficient. But I'd like to challenge this theme a bit. And I'd like to ask, should we actually be Trying to be efficient? Is efficiency even a good thing? And by the way, this is how not to get invited back to a conference. So since you're never going to see me again, let me tell you a little bit about myself.

5:17 I work for Red Hat. I'm a senior principal software engineer helping to make Quarkus efficient. But when I started thinking about it, I realized that actually... Most of my career has been spent trying to make software and people efficient. I started out as a performance engineer working on the JVM, working on garbage collection. I spent quite a lot of time as a consultant, really advocating for lean methodologies, extreme programming, because they help make teams efficient. And now, as I mentioned, I work on Quarkus, and I try and help make Quarkus more efficient. And the question I asked at the beginning, is efficiency a good thing? In a way, it seems like a ridiculous question, because none of us ever want to be inefficient. We all want to be efficient. We all want to do more. But actually, this idea of efficiency is relatively new.

6:25 If you look up what is efficiency, Google will suggest alternate question, which is, who invented efficiency? Which is kind of funny, because efficiency seems like something that we don't need to invent. Efficiency has just always been there. Well, no. We actually, people started thinking about efficiency in the 1700s with the invention of the steam engine. With the steam engine, what it does is it converts energy of one format, heat energy, into a different format, mechanical energy, moving things. And the problem with steam engines is you put a lot of energy in, and you get very little energy out. And so then we try to figure out, well, can we make it more efficient? In the 1890s, we started thinking about efficiency slightly differently. We started thinking about efficiency as a management concept, something that we could try and make processes more efficient, because the impact of technology was to...

7:31 Make much larger companies, make much larger countries. In those countries, we needed to interact with each other, and we needed to interact with each other at quite a large scale. So we had these processes where you put time and money in, hopefully you got value out, but they were potentially quite expensive. And so this was really a shift from thinking about efficiency of machines to thinking about efficiency of people, and how do we make people interact efficiently. We continued thinking about the efficiency of people when we started thinking about factories in the 1900s. What a factory does is you take valuable things, they go into the factory, and hopefully valuable things come out of the factory. Hopefully you've increased the value. And of course, manufacturing is something that we're still thinking about. We're still trying to think how to optimize that with things like lean methodologies. In the 1960s, we started thinking about efficiency of software, because we had these computers that could produce answers.

8:35 So if you put enough time and electricity and hardware at a problem, you hopefully would get an answer out. But sometimes it takes quite a lot of hardware and quite a lot of energy to get an answer out. So when we think about efficiency, Really, we should be thinking about efficiency in several different forms. We should think about the efficiency of our processes. We should think about the efficiencies of our production. And then, of course, we should be thinking about, as CTOs, we want to think about the efficiency of our software. So after 200 years, hopefully, you know, we've been working on this a really long time. Hopefully we're getting pretty good at efficiency. And we are. So this is a curve of steam engine efficiency. The scale is logarithmic, so it... Is actually much more impressive than it looks. And what this is showing is that steam engines, by the time we phased steam engines out in the 1950s, and I don't know about you, but I was really surprised that they lasted to the 1950s.

9:41 By the time we phased them out, they were 25 times more efficient than they were when we invented them. That's pretty good. And some of you, well, probably all of you, know about Moore's Law. Moore's Law, says that every 18 months, the computation power of our chips doubles. But there's another law which is a companion to Moore's law, and that's Coomey's law. Coomey's law says that every 18 months, the energy efficiency of computers doubles. This is really good. And so again, on this scale, it looks linear, but it's actually a logarithmic scale. So we're getting more and more energy efficient with our computers. And this is something that I see very much myself in my own work, because not only is the hardware getting more efficient, the software is getting much more efficient.

10:42 So I mentioned that I work on Quarkus, and we have astonishing performance compared to previous Java frameworks. And so, and Java in general is getting more efficient. So in 2010, if you had a Java application and you wanted to run it on an application server to test it, you would have to deploy it to that application server. Even doing a local deploy, you had enough time to go make a cup of tea. Whereas now, with Quarkus or with GraalVM in general, You can start a Java application in about 15 milliseconds, which is actually faster than it takes an LED light bulb to go from off to illuminated. It is incredibly, incredibly... fast. And this is partly because of GraalVM, and it's partly because of what Quarkus has done on top of GraalVM. And a lot of these performance improvements have been driven by the cloud.

11:48 In the cloud, startup time really matters, because cloud applications tend to be ephemeral. They come and go. But as well, in the cloud, density really matters. We want to pack as many applications onto a single physical machine as we can, because in the cloud, memory footprint is money. And we're not just getting more efficient in terms of performance. We're getting more efficient in terms of processes. We have automated all of the things. Disciplines like SRE is a whole discipline whose job is to automate things. Things like infrastructure as code and GitOps are really taking a lot of things that we used to have to do manually. And automating them. But of course, it's not just our infrastructure that we're automating. We're now increasingly automating ourselves as well. So I drew the illustrations in this talk myself, but I tried it out, and so I went to Dali, and I asked for a picture of a kangaroo working on an assembly line.

12:58 And this is what came out. And I don't know about you, but this is way, way better than what I can draw. And it took about two seconds to do, which is kind of amazing, but kind of depressing. But it's worse than that, because I went to ChatGPT, and I fed in my title. And it came back with a really nice essay describing all of the ways in which efficiency was a good thing and the ways in which efficiency was a bad thing. And some of the things it came up with, I thought I'd been really clever. I thought these were really novel insights and I was amazing. And ChatGPT just went, And in two seconds, it did my talk. So we've automated everything. But even after 200 years, even with all of these efficiency improvements, we're not always very good at efficiency. We still have incredibly inefficient processes. Years ago, some colleagues of mine, so this was sort of before the cloud, when we were just starting to look at virtualization.

14:08 Some colleagues of mine sold a system that would allow people to do self-service provisioning of a machine in 10 minutes. This was amazing. But the client came back and they said, oh, this provisioning software is broken. What was going on? Well, we told the client they could provision an instance in 10 minutes. But the client was seeing that it took three months to provision an instance. So we investigated, and it turned out that they'd put just a few little guardrails and a little bit of governance in place. And so they had an 84-step pre-approval process. And so that was why it took three months. Dull. And it's easy to joke about that. It's easy to say, oh, well, of course, processes are inefficient. But a lot of our software is really inefficient as well. The LinkedIn team, a couple of years ago, they had a new feature and they were really excited by it. And so they decided to go out in the field to do some user research.

15:10 So they went to a town called, well, a city called Nashik, which is about 100 kilometers outside Mumbai. And they sat down with their user and they said, so let us see you using our feature. And what happened was they couldn't even load the feature. There was so much bloat and JavaScript and everything on the LinkedIn pages. It wasn't just slow and annoying for these users. It was actually completely useless, which is really, really terrible. And it's not just software. The way we manage our systems is incredibly inefficient as well. A quarter of servers are zombie servers, which means they are doing no work at all. It's not like they're watching cat pictures. They are just doing nothing at all, and they've been that way for six months.

16:12 If you raise the bar a little bit more, a further quarter of our servers are so underutilized that their utilization is less than 5%. And so the average server is running at about 12% of capacity. But it's still using. using most of its maximum power. And this kind of waste, it's not just about the electricity, and it's not just about the cost of these servers, because manufacturing hardware, running this hardware, uses water. This hardware generates enormous amounts of e-waste, and there's embodied carbon. So in terms of sustainability, it's terrible. But there's a funny thing about inefficiency, which is that a lot of us really like inefficiency. We may say we don't, but the way we behave is as if we like inefficiency. I sometimes hear the same story from vendors, and they'll have an amazing solution, some piece of automation or something like that, that makes everything more efficient.

17:19 And so they go to a business and, our amazing product, it makes your team so much more efficient. The manager of the other team, instead of saying, wow, yes, they say, oh, no, no, no, we don't want that. Why? What could possibly be going on? And of course, they're sort of, wait, what? How could you not want this thing? It makes stuff better. But the problem is, if teams bring in software that makes them more efficient, their headcount gets reduced. And we don't measure the status of people by how much much work their team does, we measure the status of people by their budget and by their headcount. And so if you make your team more efficient, all of a sudden, you're actually less useful and less cool and less valuable than you were before. So nobody wants that. And we see this with people as well, so with team members.

18:24 Sometimes people will spot an inefficiency, but they know that if they go to their boss and say, hey, this whole process, we could stop doing that, we could do this process so much better, their buddies who are involved in doing that process may lose their job. This is an action that we need to take. We need to, all of us, get much, much better at eliminating this inefficiency, find those stupid processes, find that bloated software, find the places where we're using resources really inefficiently. But the most important thing is look at the incentive structures that we create as leaders and make sure that our incentives don't reward inefficiency. And then once you've done that, you can go further as well. So the management consultant, Peter Drucker, he said, there is nothing so useless as doing efficiently that which should not be done at all.

19:25 So often, what we don't want to do is streamline a process. We should just get rid of it. I used to have a team and we had a weekly meeting where we would triage the defects. This meeting, it was so boring. It was like the worst meeting. And we would argue about what priority each defect should have. And it would always end up being medium. So somebody eventually said, hey, couldn't we just like... Automatically set the priority to medium? Could we have like a shell script that sets the priority to medium? But actually, that wasn't the right answer. That was automating half of the problem. The right answer was just to get rid of this field. If this field is so useless that it is always medium, get rid of it. And I sometimes think this with a lot of the AI solutions as well, that AI is really good at writing boilerplate code. AI is really good at making boilerplate text.

20:26 But why do we want the boilerplate? If something is so meaning-free that AI can just write it automatically, Let's get rid of it. Let's get rid of the code. Let's get rid of all of those words that we don't need. And as an example of how sometimes we take things for granted, I mentioned that Quarkus is very efficient in terms of its software performance, but we also try really hard to make Quarkus efficient for people, so that as a developer, you are more efficient using Quarkus. And one of the things that we did was, I don't know how many of you remember from, you know, if you were doing Java development and you do your logging, every single time when you do your logging, you have to fill in, define the logger, and tell it what class it's in. But this is stupid. If the computer doesn't know what class the code is in, how are you going to know? And so you get cut and paste errors.

21:27 And so what we did with Quarkus was we just said, let's just... eliminate that. Let's just automate that. And it's less code. It's cool. So I'd encourage you, when you try and eliminate waste, don't just try and shave a little bit off these processes. Try and think bigger. Try and actually change things and find the things that we shouldn't even be doing at all. But you can try too hard to be efficient. And if you go back to that history of efficiency, we started out thinking about the efficiency of machines, and then we moved to thinking about the efficiency of processes and the efficiency of factories. And with both of these, what we're really thinking about is people. So with software, not so much, but certainly with processes and machines, we're trying to make people more efficient. But we're using the same techniques that we used to make machines more efficient.

22:30 And this is really what Taylorism is. Taylorism is taking people. And treating them like machines. And I think we can probably all see how this maybe isn't so good. And there's a lot of evidence that maybe treating people like machines doesn't give the nicest results. So we see these headlines where the extreme efficiency of Amazon does come at a human cost. And even something like the generative AI, it seems like I just put in my query and two seconds later I get an answer. But behind generative AI, there's data, but there's also people. There's enormous numbers of people working on hand tuning, hand labeling, hand filtering these algorithms so that we can have what appears to be a very quick result. So there's a hidden inefficiency and a hidden human cost underneath some of this generative AI.

23:38 And I think when most of us aim to become more efficient, we want to do it the right way. So we say, I'm going to be data-driven. I'm not just going to guess what's more efficient. I'm going to measure. So I'm going to measure the efficiency of people. This is probably a good idea, but we have to be very careful how we do it. I saw this story recently. So I just heard of a founder who monitors his co-founders and employees'productivity via a whoop group. The team is collectively averaging five and a half hours of sleep a night. And so I read that far, and I thought it was going to go on to say, this is awful. When you operate on low amounts of sleep, it's like operating drunk. No one would want their employees to come to work drunk. So why would you want your employees to come to work drunk? without enough sleep, it doesn't make them more efficient. It doesn't improve business results. But instead, they go on to say, if you haven't implemented this already for your portfolio companies to monitor the founder work ethic, I strongly recommend you do it.

24:48 I strongly recommend you do not do this. This is a terrible idea. This gives bad results, and it's just unpleasant. Slightly less toxic, but not necessarily. necessarily any more effective is the recent McKinsey work on measuring developer productivity. I won't talk about it too much because there's lots that's been written about it, but I would urge you to be cautious with approaches like this. You can get it wrong. You can get it very wrong. And the problem with all of these measurements is when you measure something, you get what you measure. People will adjust their behavior to optimize your metrics. And usually what we end up measuring is not the thing that we really care about. What we usually end up measuring is the thing that's easiest to measure. Instead of measuring business results, let's measure how much sleep our people are getting, and let's optimize that by making them not sleep. No, let's optimize our business results, but it's harder.

25:50 So just really make sure when you measure that what you're measuring is the thing you actually want. Because quite often these things that seem to be efficient, I'm so efficient that I don't sleep, are actually inefficient. I don't sleep, and so therefore I make terrible mistakes. It's not a good trade-off. And even a lot of these automations, they may not save as much time as you think. So I came here by train, but if I'd had more time, it turned out turns out I could have walked, according to ChatGPT. Because if you ask ChatGPT what the world record is for crossing the English Channel entirely on foot, it doesn't say, obviously that's a stupid question, go away. What it says very, very confidently is the world record for crossing the English Channel entirely on foot is held by Christoph Wandrach, Germany, who completed the crossing in 14 hours and 51 minutes.

26:57 So, in fact, I could have left yesterday and arrived here today on foot. I was interested in some of the earlier talks to hear the pronunciation of chat GPT, because of course I would say chat GPT, but I have read that here it is pronounced chat GPT instead, which is slightly humorous, and so I included a cat joke. But really, you know, sort of cat jokes and everything aside, the problem that we have here is a mismatch between what we've designed the system to do and what we actually want it to do. These systems, they're designed to produce really believable answers. That's what they're tuned for. Sometimes that is absolutely what we want. We want text that sounds good. We want text that kind of makes sense. But often what we want is text that is correct. And that is not what these systems are designed to do.

28:00 And for something like crossing the English Channel on foot, it's just funny, right? Like, I'm not going to ask that of ChatGPT and then set out on foot and be really annoyed when I drown, because I know you can't do it. But sometimes the errors are more subtle. So KPMG recently was really annoyed because it was an Australian parliamentary commission produced this research report. And they used a bunch of AI generated material in this report. And it was just totally wrong. So they said, oh, yeah, KPMG was involved in all of these financial scandals. That KPMG were not involved in, the scandals didn't exist. And they would say, oh yeah, this KPMG employee, you know, when they were dismissed from this other company, they would never work for this other company. It's really sort of, very easily verifiable but rather terrible errors that are introduced into this. Again, because it's the illusion of efficiency.

29:02 So, yeah, the submission accused firms of involvement in scandals that didn't exist or that they had nothing to do with. And it's the same as, you know, as a techie, I sometimes go to ChatGPT for code answers. But it turns out the odds of being correct for that are less than 50-50. But the interesting thing is that the answers are always so believable that if you ask people to rate the correctness of the answers, even though it's wrong, they'll be like, oh, it's so nicely worded, it must be true. And so this is the illusion of efficiency. It's something that seems to be really efficient. I can get an incorrect answer in five seconds. Great, I think. Is that really what you want to be doing? But there are reasons why we're drawn to that kind of efficiency. Because sometimes efficiency can be quite expensive. There was a paper that circulated a couple of years ago about the energy efficiency of various programming languages.

30:06 And what they found is that Python is really, really inefficient. Rust is very efficient. But there's a problem. That's the software efficiency. The human efficiency is a little bit different, because Rust is really, really hard. So it doesn't make sense to do most things in Rust. And when we design a language, there's these trade-offs. So something like Rust gives you a lot of low-level control. But if we have higher level abstractions, that makes people more efficient. And so when we say something like Rust, it's zero overhead. What we mean is it's zero overhead for the machines. For the people, it's very high overhead. That might actually be the overhead that you want to optimize. So we need to think about developer productivity as well as performance. And so don't rewrite all your business logic in Rust because it's just, it's not efficient, even though Rust is efficient.

31:15 And we've probably all seen this, where if you really heavily optimize code, it's less maintainable. So there's this trade-off between the software efficiency and the developer efficiency. That doesn't mean you should never use Rust, but you need to choose your battles wisely. Do that kind of efficiency where there's a bottleneck. And when you think about efficiency, you need to think holistically. So you need to think about all of the requirements, including the developer efficiency requirements, not just one narrow definition of efficiency. And I mentioned resiliency at the beginning as my microphone catastrophically failed. Resiliency is really important. And sometimes resiliency and efficiency are not the same. As a trivial example of that, the reason I have a microphone now is because the event organizers have more than one microphone. One of those microphones was not being used. I was able to use that as a backup microphone.

32:18 And we sometimes take a three-legged stool as a model of efficiency. A three-legged stool is so well optimized because it has no more legs than it needs. Whereas something like a dog... That's really inefficient. It's got this whole extra leg. You've probably all seen dogs like this, right? If a dog, it's very sad when it happens, but if a dog loses a leg, it is still a perfectly functional dog. It will be running in the park, playing with all of the other dogs. It is a happy dog. If you take a three-legged stool and you remove a leg, that is no longer a functional stool. That is garbage. So we have to build in some inefficiency in our systems in order to have that resiliency. And it's actually exactly, exactly the same for people. So those founders who are sleeping five and a half hours a night, they're going to burn out.

33:23 And we increasingly see this in how we structure our workplaces, that we have this idea of le blurring, where we allow our work to spread out everywhere, and we think that makes us more efficient. But it really doesn't. And in fact, we should be doing the opposite. We should be doing le funner work. Because if we take breaks during work, if we go and have a game of table tennis with our colleagues, that actually improves our productivity. And this is something that it's counterintuitive, but there is so much research that shows it. So the Dora report found that job satisfaction which is being happy at work, is the number one predictor of organizational performance. And there's loads of other papers that really show similar things. You could just go through all the papers. And what these studies show is that if employees are having fun, they work harder.

34:24 They're more productive. And they take less time sick. So it's really good news. And again, you know, more metrics. Your brain at positive is 31% more productive than your brain at negative, neutral, or stressed. That's amazing. And, whoops, I have skipped. I have skipped. So, you're all going to know the joke now. Because the question is, how do you get your brain into a positive state? Surely it's not as easy as watching cat videos, is it? It actually literally is as easy as watching cat videos. And this is something, I'm not making this up, there is evidence of this. They did a study, and they had people watch a comedy video, and then take a test. And the people who had watched the comedy video did 12% better on the test. And so if you go to your CEO and you say, I know how to improve the efficiency and productivity of the IT department by 12%, the CEO is going to go, yes, do it.

35:34 And then you say, what we're going to do is we're going to install huge monitors with cat videos, and we're going to take a break every hour to watch a cat video. The CEO is going to escort you to the door, right? It doesn't quite work, but it is actually true. There is evidence for it. And I think it's partly that play helps creativity. And people don't always think of IT as creative, but it is 100% creative. We're trying to come up with new ideas. We're trying to solve problems. It's incredibly creative. But actually, we don't even have to be doing le fun at work. We don't have to be having play to help creativity. Even doing nothing at all helps our productivity, which sounds ridiculous, but it's true. There's a pattern of brain activity, which is called the default mode network. And the default mode network is What happens when, you know when you're stuck on something and then you go have a shower? And in the shower, you come up with a solution?

36:36 Or you go for a walk and you come up with a solution? That's... There's a sort of a pattern of nodes that when most of your brain shuts down, this area of your brain becomes more active, and this area of the brain is involved in problem solving. So actually, don't go to your CEO and tell them that you're going to have big monitors with cat videos. Go to your CEO and tell them that you're going to have a shower every three desks so that the employees can take showers to solve problems. Your CEO will still walk you to the door, but it would be funny. And so this is something that's really come out of the psychology research. But if we say, oh, psychology, that's a bit too fluffy. That's a bit too people-y. I'm a techie. I want math. The math actually agrees with all of this as well. And this is really queuing theory.

37:37 If you do performance work, you probably study a lot of queuing theory. If not, you might not. But queuing theory has some really interesting conclusions for us about how we should work. And so, actually, hands up who is familiar with queuing theory. Okay, about 10%, and you're all at the front, which I think shows something interesting about your behavior coming into the room. So the basics of queuing theory is that we're trying to describe a system, and we have an arrival process, so work comes into the system. We usually assume that work is coming in in a Poisson distribution, so what this means is that there's a little bit of random variation in how work arrives. And then we have a queue. So the work comes into the system, and then the tasks join the queue. I've shown people here.

38:39 It could be people, it could be events in an automated system, it could be anything. And then you have servers. So these are the processes that take the work and do something so that it can then become a completed job. So far, kind of boring. But what we can do is we can see what happens, for example, we can mathematically model. What happens if we have fewer servers? Well, the queue is really going to build up. Or what happens if it's the other way? What happens if we have the same number of servers, but the rate of work arriving is really low? Well, then those servers aren't going to be doing anything. They're just going to be sat doing nothing. And so if we assume a Poisson distribution, then we can start doing some models and predictions for what happens.

39:40 And the answer that you get is this. So the vertical axis is the lead time. How long do jobs have to wait to get to the end of the queue? And the horizontal axis is the utilization. How busy is the system? And so what you can see... It's all kind of okay until you get to about here. And at that point, it goes really, really bad. And what that means is that at some point, if the utilization is above about 80%, it gets bad. And if the utilization is close to 100%, basically, it takes infinitely long for jobs to get through. And so this is why we try and keep the utilization of our hardware servers around 80%, because if you have a server running at 100% utilization, it's going to grind to a halt. So you could say, well, I want to minimize my cost of slow jobs.

40:42 Slow jobs are really bad. If it's people, they're annoyed. If it's response times, users are annoyed. So I want to get as far to this end of the curve as possible to minimize that delay cost. But of course, there's another cost, which is the cost of idle capacity. If in the supermarket they had 2,000 servers, the queues would be really short, but you couldn't afford to shop there because they'd be paying so much on staff wages. So you have to try and find that sweet spot. And it's exactly the same in a lot of systems. So with the train network, trains could go faster than they do. But if they did, any time there was any kind of delay, they couldn't make it up. So we have to have some slack in the system to get the predictability. And all of this is actually really, really good, because what this is telling us is that taking it easy, relaxing, having a bit of time in the shower,

41:50 has business value. It gives good results. When you think about how to manage your efficiency, measure thoughtfully because you're going to get what you measure. And remember that efficiency is not always efficient. So having some fun and idleness in your system is actually going to improve your productivity. And efficiency, it doesn't always look like what we think it looks. Efficiency could be taking a shower. And I want to end by coming back to the kangaroo. The kangaroo is the world's most efficient land animal. It's not actually the world's most efficient animal. Anybody want to guess what the world's most efficient animal is? Fish is close, but fish still work fairly hard. The animal that works Ooh, lots of good ones.

42:53 It is the jellyfish. Jellyfish, they have this sort of really interesting kind of hydro-mechanical motion, and they're really good at moving with almost no energy. So when we think about efficiency, we may imagine a kangaroo, but maybe actually we should be more like a jellyfish. Finish up. We have so much scope for improvement in efficiency. When you go away, look for the waste. Get rid of the waste. But don't go so far in getting rid of waste that you treat people like machines. And aim for true efficiency, not the illusion of efficiency. Because all of us, whether it's people or machines, function better with some idle time. And with that, I can go back to the slide that you saw at the very beginning with the kangaroo. Thank you very much. Thank you so much, Holly. I want to be a jellyfish.

43:57 I want, it's beautiful in this room. Beautiful, yeah, absolutely. So we have, I think, between five to six big minutes for Q&A session, if you agree. Yes, yes. Okay, so do we have any questions in the room? Yes. Alors, Romain, est-ce qu'on peut revoir les mains levées, s'il vous plaît? Alors, une là, ça je vous ai vu, mais j'avais vu une là-bas. Non, baromène devant, alors. On the front row. Thanks a lot for your presentation. It was literally amazing. I've learned so much. You can go back and, sorry to interrupt, but you can go back and, you know, again, your staff will be like, so what did you learn at Tech.Rocks? Let me tell you about jellyfish. Exactly. And then, you know, not only will I not be back next year, you won't be back next year either. Sorry, carry on. You seem to have studied efficiency a lot. Is it true that 80% of the results are reached with 20% of the I think it was Perretto or something like that.

45:02 Perretto, yeah. Yeah, that's a really good question. I think sometimes, I mean, I wouldn't want to say those exact numbers, but we definitely do see in so many things that principle of diminishing returns. And this isn't exactly what you asked, but I think it's a really good point that So often we want to do the job to 100% and we have that perfectionist instinct. So we say, okay, well, I've started this, I'm going to finish it. And actually, it's a bit like being idle, that we should stop when we've done 80% of the results. Because getting that last 20% will cost us so much and it's just not worth it. And it's not efficient, even though it makes us feel like we finished the job. It's a, yeah. Thanks a lot. You have a competitor, you know, because to me there is a cat in this as well, because all the other cats were yours. They were, yes. Yeah. And another question in the room? I don't see.

46:04 Okay. No, we can't hear you. Maybe the microphone. Yes, thank you very much for this talk. It was so good, so well argumented. I loved it. And I think plenty of things that you describe is true in most of the organization people are working here. Full agenda of our work, et cetera. So everyone agrees, but We are doing everything you are describing, which is so beautiful. Can you motivate us by sharing some companies or organizations that make some kind of radical moves to inspire us on this dimension? Yeah, it's such a good question. And I have an answer in two parts. One is do as I say, not as I do, because I am completely also guilty of overwork. And so I will sometimes say, oh, people should relax more. And then I'm there. So it's really hard.

47:07 And I think there is that intuitive sense of if I just stay up later, if I just work harder, I'll get better results. But there are a lot of companies that are going in the other direction. And there's a good example of this in working hours. So it used to be that at the start of the Industrial Revolution, people worked 12-hour days because they needed to utilize the factories. And the working hours have gradually been going down. they found was productivity did not go down when the working hours went down. And we're now starting to see companies that are offering four-day weeks. And those companies are really productive. And so a lot of companies have, I can't think of a good name, but if you look it up, you can find the case studies where people go to a four-day work. The staff are delighted. Their recruitment is really easy, obviously. But it's not just that. It's that if you have less time, you work harder, whereas I think sometimes when we think we have a long time, you just end up sort of in front of the computer doing, looking like you're working, but not actually working.

48:11 And so hopefully that four-day week will become more normalized, and we will start to see more examples of that. There's another case study. There's a book called Joy, Inc., and it's about a company whose name I have just forgotten, but the book is called Joy, Inc., and they really took it as part of their business culture to make sure that their staff were delighted to be at work, and they got really good results. I'm sorry, I'm laughing because I'm seeing the cartoon of Tommy. So it's like showers with jellyfish and she's drunk. We can try tomorrow morning. Do we have any more questions in the room? Okay. À droite. We're attending for the...

49:20 Alors, deux, trois, combien êtes-vous? Un. Yes, thanks for the presentation. In general, in management, there are these three players of efficiency, like optimizing resources, then the flow, something like queuing theory and... And then the value. Highest level of optimization that one can play with. Now, what can you... about the fact that if everyone in an organization Come on, come on, come on. Because everyone in the organization optimizes at the value level, that can harm the organization. What can you tell about that? How can we reconciliate everyone's idea of what value means and how to optimize in their activities

50:25 so that it helps the greater good, it doesn't harm the entire organization? That's a really good question, and I don't feel very confident to answer it very much, but I will add that I think one thing that helps with that is the different discipline of thinking about diversity. And so you want different shapes of people in your team, and although you may have alignment on the incentives and alignment on the overall goal, hopefully if you have a diverse enough team then people will naturally optimize at different layers because you will have some people who will be optimizing at that value level and the vision level and you have other people who don't they just can't work at that level and so they're down there in the weeds making small things better and so then hopefully you go in the right direction but beyond that I don't think I know the answer Thank you so much, Holly, because at the end of the time for the Q&A session, I'm very sad.

51:30 To say that, but I'm sorry. So thank you so much for you. Thank you very much. Brilliant talk. Thank you. Thank you so much. I keep it, but you can keep it for the corridor. Thank you so much. Thank you.