 Good evening, everybody. Thanks for holding out to the end of the day. In software development, we sometimes talk about something called mechanical sympathy. And this is the idea that we structure our code not based on how humans want to model the problem and not based on how humans want to read the code, but instead in a way that exploits the power and capabilities of the hardware that's running it, normally to make it go faster. Tonight, I'm going to make the argument for anthropic sympathy because I believe that our business processes and development methodologies are like software, but they're running on the wet ware that's in our heads. And for too long, we've copied what worked in factories in the Industrial Revolution when really software development is different. So we're going to look very briefly at some findings from cognitive psychology and neuroscience about why the way most of us here work is more productive and how Cloud Foundry can support that. You're probably familiar, or you're definitely familiar by the end of today, with a situation like this. This kind of diagram has been up on screen lots of times, an organization working in silos, functional teams, each with a speciality. We all know the story. You need someone from each of them to deliver any business value, and that involves a lot of coordination. Typically in these situations, the people from one silo feel like the people in the other silos don't really care about their problems. They don't work together to try and ease each other's frustrations, which is weird, because they all work for the same company, so they should be working together, right? Is there something to that? Turns out there might be. An experiment was performed where a control group of subjects were placed into an FMRI scanner, which measures levels of activity in different areas of the brain over time. When they're in that scanner, they were shown different videos, either of a hand being lightly touched with a cotton wool bud or a q-tip for the Americans in the audience, or being stabbed painfully with a syringe. And levels of activity in the neural networks associated with experiencing empathy and pain were measured. The experiment was then repeated with a different group of subjects. This time, they had to identify the religious beliefs before going into the scanner. Are you an atheist? Are you a Muslim? Are you a Sikh? Are you a Jew? This time, when they were shown the videos, the religious identity of the person being hurt was also shown. And what did they find? They found that when the person being hurt identified the same way, there was a larger empathic response. But when the person being hurt identified differently, there was a smaller empathic response, smaller than when there were no categories at all. So this showed us that people care less about outgroups. And if we go back to our silos, well, what are we doing? We're cutting up our organizations into tribes, my team and your team, my tribe and your tribe, my group and your group. So not only are these people not working together so they don't see each other's frustrations and problems and pain, even if they do see it, the way that we structure our businesses means that they're less likely to care. Luckily, this is where Cloud Foundry comes into it. Cloud Foundry allows us a smaller problem space. We need less broad and less deep knowledge in fewer areas. So what do I mean by problem space? Well, that's what we needed to deliver business value before. And it adds up to a space that looks kind of like this. But because we have the abstraction of a platform as a service, we don't need to worry so much about infrastructure, networks, and deployments when we're delivering apps. Hell, even databases, we don't need to know so much about those. We just need to know how to consume them rather than how to stand them up. So we end up with a problem space, which is a lot smaller. It's a fraction of what it was before. And because it's smaller, we can condense all of the knowledge we need into one team, one product team with a shared identity, which saves us from this outgroup problem. Everybody's issues in that team are shared by the whole team because they've got the same identity. Now, we have that one team because Cloud Foundry gives us a smaller problem space. We can consider co-locating it, putting them all in the same place. And then we can get extra benefits, too. Three Norwegian scientists performed a study aiming to correlate productivity with human capital, so the education and experience of people in the businesses. They also aimed to correlate productivity with social capital. So how often people communicated? How many people they communicated with? In all three cases, social capital correlated positively with productivity. In two out of three cases, the human capital, the education and experience of staff did not correlate with productivity at all. And this makes sense, right? If you think about an economic network, its value is determined by the number of nodes you have and the number of connections between those nodes. If this is the telephone network, it's not very good. But if you add more nodes and more connections between those nodes, you have a more productive and valuable network. So if this is our organization, we can make it even more effective by making these communications more efficient, making them less likely to fail. And we can do that with empathy and the human brain. Now, when you saw this picture, your eyebrows may have raised a little. Your eyes may have widened a little bit. And when you're watching films, maybe this happens. When you're watching a character's face, maybe when you're talking to someone particularly engaging, you find yourself mirroring their expression. And this may be down to mirror neurons, which are brain cells which fire both when an action is performed and when it's perceived by an observer. And the mirror system has given rise to something called the mirror hypothesis. And this is that when you see another person's face, your mirror system fires, causing you to start to mimic that facial expression. In lots of different ways, the brain gets different physiological information through a phenomenon called embodied cognition. And that helps tip your decision-making process. So when you see someone smiling, it's not just that you know a semantic fact that smiling people are happy. You put your body in the same state as there. So your brain has that shared context. So you're experiencing firsthand how they feel. And there's some good evidence for this. A study was performed where a control group was asked to identify emotions being expressed in photographs. And then the experiment was repeated, this time by people who'd had Botox injections. So they had their facial muscles paralyzed so they would look less wrinkly when they got old. On average, those people who'd had the Botox injections were less able to correctly identify the emotions being expressed. Why? Because they're broken that chain. They saw the face, the mirror system fired, but they couldn't mimic it. So they were denying their brain this extra physiological information that it uses to inform itself. So if we think about our teams, they're all in one place now. They can have fast face-to-face communications that are efficient. We can increase their productivity by using empathy to lubricate those communications. But before, we had our silos. And before, communications were slow. And that made organizing anything quite costly. Scheduling a team's time was costly. There was a high transaction cost to organizing anything. So what did we do? How many times have you seen one of these today up on the slides? We decided to plan things way in advance because getting the testing team's time would take two weeks in and of itself. And because the transaction costs of organizing anything were high, we decided that we would work on aspects rather than features. So we'd ask the testing team to do the testing for all of this quarter's features all at once. And typically, in a situation like this, load testing comes right at the end. And typically, in a situation like this, load testing fails. But we're doing waterfall. We've got a requirements document. It clearly states in chapter 73.b that we need to be able to handle 1,000 requests a second. Why does this fail? It may well be because of the present bias. This is a well-observed psychological phenomenon that says that humans value things more highly when they're close. And they discount value for things that are far away. This is why people often buy furniture on interest-free credit. Buy now! Pay in two years' time! That cost is discounted the further away it is. It's why you're more likely to give your sandwich to a starving child next to you than you are to phone up comic relief and make a payment powered by Cloud Foundry for a starving child 3,000 miles away. Now, this is well-observed and has been for decades. But what's new and what's interesting is that it looks like it has a biological, neurological underpinning. Wrong direction. Oh, you've got to watch my animations again now. There we go. Resus monkeys were given a choice between a little bit of sugar water now or a bit more sugar water in a few seconds' time. And by varying that second option in the size of the sugar water and the delay until they got it, scientists were able to map out their preferences, their behavioral preferences. They then inserted electrodes into the intra-aparietal area of these monkeys' brains and observed the firing rate of specific neurons. So the faster the neurons fire, the more attractive the option is. The slower they fire, the less attractive. They found that the firing rates of these neurons mapped one-to-one with the observed behavior of these monkeys. That means that there is a biological explanation for the present bias. And that means we can't escape it. It's unavoidable. We can rationalize about it, but we're not gonna be able to get away from it. So how can we exploit the present bias instead of being victims of it? Well, it's obvious now, isn't it? The load testing doesn't happen for three months. It's not present in anyone's mind. It's not important today. But this is where Cloud Foundry comes in again. We've got a smaller problem space. We don't need half of this stuff. Can you tell I recently discovered Kino animations? We've got one team now doing TDD because doing it the other way around doesn't make much sense. And importantly, that one team has self-service. They can do what they need to do and when they need to do it, they can provision databases on demand. And that means combined with the lack of scheduling, the self-service makes it economical to work on one feature at a time. And that makes the load testing important now. We're exploiting the present bias because everything needed for that feature is important today because we're working on all of that feature today. Not in three months' time. Cloud Foundry's self-service enables us to work on features instead of aspects. It enables us to do that. It also offers us control over our environments and automation of production deployments. And it turns out that that can help us reduce technical debt as well. So there's a great book called Scarcity that collates a lot of research about the psychological effects of being made aware that you don't have enough of something. A typical study was one performed in a New Jersey shopping mall. Subjects were posed a hypothetical question. You've been involved in a car accident. Your insurance company isn't going to cover the costs. How are you going to pay for the repairs to your car? Subjects were split into two groups depending on their income, either rich or poor. And within those groups, there was a different flavor of the question. Either they had to cover a $300 cost or a $3,000 cost. Straight afterwards, they were given a fluid intelligence test. This is Raven's Progressive Matrices, which is often used as an IQ test. Now for the rich people, it didn't matter whether they were asked the $3,000 or the $300 question. It didn't have any impact on their fluid intelligence test scores. For the poor people, it didn't have any impact if they were asked the $300 question. But for the poor subjects who were asked to cover a $3,000 cost, their effective IQ dropped by 13 to 14 points. Just by being made aware that they didn't have something, enough of something that was important to them. The researchers went and looked for other effects of scarcity as well, particularly on executive control and functions of executive control involve self-control and willpower. Also, prospective memory, your ability to remember to do something in the future. This is a stroke test. This tests self-control by making you inhibit certain responses from your brain. Rather than say the color the word is printed in, you're supposed to read the word itself. Time and again, they found that scarcity reduces willpower and prospective memory. Now this effect can be triggered by not having enough money. It can be triggered by not having enough social contact. Importantly for us, it can be triggered by not having enough time. Now you think about your engineers and you think about what happens now when you remind them that they've got a deadline. Or you better hurry up because you've got to get this done by Friday. You're reducing their ability to solve abstract problems. You're reducing their willpower, making them more susceptible to technical debt. And what's even worse than that, you're reducing their prospective memory so they're less likely to remember that they need to patch the corners they cut. And why are we doing this? When we were working in the old way with silos, it was because there would be knock-on effects if we were late. If you're doing scrum, you're doing this every two weeks because you're making a commitment. Why are you making that commitment? Yes, sir, we will get the work done, sir. I promise, sir, we are working as hard as we can, sir. Honest. But you know what, there's a better way. Cloud Foundry allows us to continuously deliver into production. You want to know how fast my team goes? I'm not gonna predict the future. I'm not clairvoyant. You look at what we've put into production in the last two weeks. You look at what we've already done and how quickly we do it and how much business value is going to customers every day. That's how you find out that we're really working for you. And you can combine that with two very simple ideas. Let's go back to our project plan. It's not really much of a project plan anymore, but if we rotate it 90 degrees, I need sound effects for this as well. Go whoosh. Then we've got what looks like an ordered backlog. If we always work on the most important thing, we're never goofing off. If we always deliver it in the simplest way possible, then we're taking the shortest route to business value. We're not over-engineering things. We can't trim any more fat off of that task. We're going as quickly as we possibly can. So sticking a date on a calendar isn't gonna make any difference. That's like shouting at the planet Earth to make it go faster around the sun. It's not gonna go any faster. The work will get done when the work gets done. By continuously delivering the most important thing in the simplest way, you can free your engineers of the tyranny of the scarcity effect and reduce the technical debt that they incur. And it turns out that continuous delivery can help us with technical debt in another way, too. Now, you may have heard of a study that was performed about 20 years ago in US jails that found that if you had your parole hearing at the end of the day, you only stood a 20% chance of success. But if you had your parole hearing just after lunch, you stood a 65% chance of success. And for a long time, people thought that that had to do with glucose, that the parole board had eaten lunch, that ingested glucose, which metabolized into lysine, which is used in the premedial frontal cortex, which is responsible for executive control that we mentioned earlier. But it looks like there might be something else happening. A more recent study asked people to perform an exhaustive stoop test, very long stoop test that exhausted their self-control. Subjects were then asked to gargle one of two drinks, either a drink with glucose in or an artificially sweetened drink. So gargling, whoop, spit it straight out. And immediately afterwards, they were given another willpower test to squeeze a hand grip exerciser for as long and as hard as possible. The people who had had the glucose drink did significantly better on this subsequent willpower test. But they gargled, they spat the drink out. They wouldn't have had time to metabolize any glucose. What was going on? Well, it turns out that the glucose was binding to chemical receptors in the tongue, which was activating the reward matrix in the brain. And it's the sense of reward that replenishes willpower. And this makes perfect sense anecdotally. This is why good days are self-fulfilling. And why bad days get worse. I'm having a bad day, oh, I'm gonna have that cake. I'm gonna smoke that cigarette. I'm gonna have some beer. I'm gonna let myself down because you're seeking rewards that you're not getting elsewhere. Let's go back to our order backlog. Now, instead of us having a job well done after three months, by which time we've moved on to something else, we're ticking off features on a daily basis, inside a day if you've managed to batch your tasks small enough. Not only are your engineers going to feel more motivated because they're more rewarded, but they're going to have better self-control as well. Cloud Foundry allows us a smaller problem space, requiring less broad and deep knowledge so we can have product teams with a shared identity. We can then co-locate them to get these extra benefits of face-to-face human interaction. Cloud Foundry's self-service makes it economical for us to work on features instead of aspects which allows us to exploit the present bias rather than fall victim to it. And Cloud Foundry's control over environments and automation and the simplicity of CF push enables continuous delivery, which can make our engineers feel more rewarded and reduce the amount of technical debt that they incur. Now, I think businesses are made of two things, right? The hard-earned money of shareholders and the easily spent time of employees. And it's easy to be glib about the hard-earned money of shareholders when we live in what is a very unequal time. However, Sam Ramji pointed out to me last year that time is measured in heartbeats, not in seconds. You're all spending heartbeats listening to me and I hope you're not going to ask for a refund. But we also know that time is money. Therefore, money is heartbeats as well. Somebody gave up heartbeats to earn a wage, to invest, to pass on to their children. If we are knowingly doing inefficient, unproductive things because we're copying whatever Henry Ford did 100 years ago when he found the best way of making identical cars time and time again, then we're wasting other people's heartbeats needlessly. And I don't know about you, but I can't go into work in the morning thinking that that's what I'm gonna do. I'm gonna leave you with one... Thank you. I'm gonna leave you with one more thought and a cheeky but respectful paraphrasing of a great man. One has a moral responsibility to change unfit processes. We've gone into these technical topics very shallowly. The psychology is there and it sounds, but I hope this has given you some ideas and I hope you have the courage to go back and make some changes in your organizations when you're done here. Thank you very much.