Gene Kim, ladies and gentlemen. Thank you, Steve. Before I begin, I just want to share what a treat it has been for me to be able to listen to Bernard Golden, David Cannon, and Charlie Betts will be speaking after me. I've admired them for many years, and in fact with Charlie Betts, our correspondence actually goes back to 2004. As Steve mentioned, I've had the privilege of studying high performers since 1999. And that was a journey that started back when I was the help, back when I was CTO and a founder of a company called Tripwire. And so these high performing technology organizations, those were specifically those organizations that had the best project due date performance and development. They had the best operational reliability and stability in operations as well as the best posture of security and compliance. So our goal was always to understand how did these amazing organizations get those amazing outcomes so that the rest of us could replicate that journey. And so as you can imagine, in those 17 years, there were many surprises. But the biggest surprise by far was how it sucked me into the DevOps movement, which I think is urgent and important. I think the last time that our industry is certainly being disrupted, and the last time that we've seen any industry disrupted to this extent, it was probably manufacturing into the 1980s when it was revolutionized through the application of lean principles. So in the next 45 minutes, what I would want to do is share with you my top learning since the Phoenix project came out, and that was in 2013. And in some ways this talk could be called what I wish I had learned before the Phoenix project came out. So I'm hoping that will create some useful insights for you and probably more likely confirm some deeply held intuitions and convictions that you have. So first off, I just want to motivate what the motivation for studying high performers was. And I think in 2003 when we noticed that there was this downward spiral that would occur in every technology organization, whether you're in development, test, operation, security, and especially in the organization that we serve, left unchecked without something like DevOps that would lead to horrendous outcomes. But I think one of the best verbalizations of why this downward spiral occurs was framed by Ward Cunningham. He said it in the context of development, but it applies to everybody in the technology value stream, and he called it technical debt. Specifically he said technical debt is out which we feel the next time we want to make a change. And so in my mind technical debt evokes this amazing image. It's this. It's the accumulation of all the crap that we have allowed into our data centers, each time made with the promise that we're going to fix it when we have a little bit more time. But the way that human life works and the way that human nature works, there's never enough time. So this, although bad, is not as bad as what it becomes, which is this. Because technical debt, like financial debt, it compounds. And so what are the typical activities that we do in our daily work that causes technical debt to a crew? It's things like not writing automated tests. Michael Feathers, he wrote a seminal book called Dealing Effectively with Legacy Code. And his definition of legacy code is very simple. He said, is there any code that doesn't have automated testing? And so the joke is, how many of us have friends who are writing legacy code today? Incidentally, another person I admire is the name of Gary Groover. He said, this is a problem, right, that automated testing solves. Without automated testing, software development is a fundamentally unscalable business model. Because the more code we generate, the more expensive it is to test. Oh my goodness. And I think that's true. It happens every time we manually configure an environment. It happens every time that we manually do a change. And so manually deploy a change. So one notion of that downward spiral is that whenever we take shortcuts in the software development lifecycle and still push into production, that's a downward spiral. Because operations must then operate and maintain it forever. At least years, maybe even decades. But there's a more insidious and far more destructive downward spiral that exists. But the problem is it's far less visible. And that is simply that deployments start taking longer and longer. So think of a friend who's been associated with an application that used to take five minutes to deploy into production. So it's like an hour, a day, a weekend, maybe even a week. I've had first-hand experience of seeing a team that supported a $3 billion year display ad search business. And it would take them six weeks to deploy. Why? And by the way, that would tie up 300 to 400 people. Because it took 1,300 steps about. No one actually knew to actually deploy into production. And because the deployments are so problematic, they would rehearse it two times a year. So they were spending 20 to 30% of time just doing deployments. So when that happens, this is what I believe sets the intertrial of warfare that can exist between development, test, and operations. So here's our friendly developer who is celebrating at 5 p.m. on Friday after they check code into the source code repository. And they're buying rounds of drinks for each other at the pub. Because not realizing that they have set the entire data center on fire. And now ops, test, and eventually intoxicated developers almost work all weekend to get things running again. Before customers notice on Monday morning. And the point here is that at this point no one's achieving their goals. Deployments are taking longer and longer. Releases are taking forever to get to market. We have an increasing number of 7-1 outages happening in production. And everyone downstream of development. Test, operations, information security. We all become increasingly buried with unplanned work. Increasingly unable to pay down technical debt. When everybody knows that that's how it can actually help our organizations win in the marketplace. It was so well-verbalized throughout the morning so far. And so our inability to solve this problem to stop this downward spiral, regardless of how many architects we have, eventually leads us to have a sense of hopelessness and despair. We feel powerless to change outcomes.  And by the way, so that is about the first 170 pages. That's the first half of the Phoenix project. What does the downward spiral feel like? Whether you're dev, test, operations, infosec. And especially when you're in the business relying on technologists. And this affects everybody. And just to be very explicit, this includes the developers. It's operations, the people who are fixing the spaceship in the middle of the night. It's developers. Oh my gosh, I just want to get to developers. It's product managers, developers. I love this photo. It's information security. And you all, the architects. In my mind it's this. By the way, just to show some context.  They're the people in the ivory tower that come out once a year, draw in Visio 2003, one diagram, and they go back to the ivory tower. And you won't see them again for another year. Now, I'm sure that's not you. Just so you know, I love architects. Some of my best friends are architects. And I actually believe that architects are a huge part of the solution. And what do I evidence this on? I evidence on this conference I've run called the DevOps Enterprise Summit. We're going through this fourth year where we get leaders from large complex organizations who have been around for decades or centuries. The largest brands in every industry, vertical. And ask them to tell us about their journey. And the top three titles by order of frequency. The first is director of operations. The second is chief architect. And the third one is director of development. So observation number one is I think the prevailing narrative is that DevOps and cloud is being driven by rogue dev managers frustrated with internal shared services and going directly to the cloud. But it's actually, in our experience, it's actually been director of operations where often leading the charge. Secondly, what are chief architects doing in the mix? And I think my belief is that often it's only the chief architects who actually see their entire end-to-end value stream and can actually see that something's terribly wrong. Right? Everybody else is stuck in their silo and saying, hey, we close our tickets within four hours. What's the problem? Not realizing that our lead times are still measured in months or quarters. So just reinforcing my belief that architecture is a huge part of the solution. So surprise number one.  Surprise number one. What I wish I had learned before the Phoenix project came out is just to the extent to which the business value that it creates. And so in the service management community and the ITO community, we benchmarked about a, we raised over a million dollars to benchmark a thousand organizations. That was between 2005 and 2008. Over the last three years, actually four years now, I've worked with a gentleman named Jez Humble. He's the author of the Continuous Delivery Book. I've worked with Puppet Labs and we've benchmarked 26,000 organizations over the last four years. And with the goal of trying to understand what does high performance look like and what are those behaviors that enable these amazing outcomes. And the surprise is to what extent they're outperforming and they're not in high-performing peers. We found that high performers are far more agile. They're doing 200 times more frequent deployments. That could be deployments of code or it could be deployments of changes in the environment. But more importantly, they can complete those changes 2,500 times more quickly. In other words, what is the lead time if we go from a change committed into version control and a change could be in the code or in the environment because version control is for everybody, right? Not just for developers. Through some sort of test process, through deployment, so it's actually running in production. High performers can do that within minutes or worst case hours whereas lower performers might require weeks, months or quarters. So 2,500, three orders of magnitude difference between high and low. So not only are they doing more work and doing them far more quickly but they're getting far better outcomes. For four years, finance have been validated. When they do a production deployment, they get far better outcomes. In 2016, we found that they had three times higher change success rates. Three times lower change failure rates. In other words, of those production deployments, what turned into several outages, service impairments, security breaches or compliance failures? And when something bad does happen, how long does it take to get things back running? The mean time to restore service was 24 times faster. So this was such an important finding when we first found it in 2013 because it gave us empirical evidence of what we all found to be the case, right? That in general, the larger the size of the deployment that we make, the larger the crater we make in the data center and the more time it takes to actually fill in the hole. In other words, the only way that we can get these amazing reliability profiles of low mean time to prepare high change success rates is by doing smaller deployments more frequently. In manufacturing, the theoretical ideal is single piece flow, right? Inventory of one, queue size of one, right? In our world, it would be continuous delivery where each change gets individually promoted into production safely and quickly. This year, this last year, 2016, we found another dimensional quality which is that because high performers are integrating information security objectives into every stage of daily work, they're spending half the amount of time remediating security issues, right? And because they're doing a better job of controlling unplanned work, they're able to deploy nearly a third more time unplanned work, right? So that's IT performance, and then there's organizational performance. We found that the high performers were twice as likely to exceed profitability, market share and productivity goals, and for those nearly 1,000 organizations that gave us a stock ticker symbol because they were publicly traded on the markets, we found that those high performers had 50% higher market cap growth over three years, which is, I'll be honest, a preposterous finding, right? Because essentially what I'm asking to believe is that how a server administrator, how a network engineer, or how a developer, how they do their daily work could impact profitability or be visible in share price, which I would have laughed at you had you told me that 10 years ago, but if we believe that how almost every organization these days acquire our customers and deliver value to our customers is increasingly reliant upon the work that we do, then maybe being 2,500 times faster than our competitors will create decisive winners and losers in the marketplace, and I have no problem believing that. I mean, that's exciting. One last little statistic along this. Oh, I forgot to put this slide in. This last year we found another thing that's very much along these lines. We found that in high performers, employees were 2.2 times more likely to recommend their organizations to friends as a great place to work, right? That's the employee net promoter score. And there's a whole body of evidence that shows that that is very highly correlated with profitability, revenue growth, and so forth. So, here's another sort of mystery in the DevOps community.  That's one every 11.6 seconds, right? So what's a deployment? It could be code being promoted into the production environment, right? Invisible to customers. It could be a feature going live. It could be a configuration change in the database or the operating system or so forth, right? All one deployment. There's another, but that's not as shocking as what Ken Exner, the director of dev productivity at Amazon, disclosed in 2015. They're doing 136,000 deployments per day, right? And so, this is kind of a mystery of like, why do you see every increasing number of deployments per day in the high performers, whether you're at Google, Amazon, Facebook, Microsoft, whether you're at Capital One, Target, and so forth. And so, what we hypothesized was that maybe deployments per day is actually hiding an even more important metric called deploys per day per developer, right? And so, this is what we tested in 2015. So on that y-axis here is deployments per day. On the x-axis is the number of developers. What we found was that in low performers, as you increase the number of developers, deployments per day goes down. In medium performers, it remains constant. And in the high performers, as you increase the number of developers, deployments per day goes up linearly, right? So the reason why I think this is so important is that Frederick Brooks also wrote this assemble book, the Mythical Man Month. He confirmed so much of our own common experience. In general, when you double the number of developers or development teams, right, you double the code integration effort. You double the test effort. You double the effort to actually deliver value to the customer, right? And I think that is true. But what this shows us is that under certain conditions, with the right architecture, with the right technical practices, and the right cultural norms, we can actually scale developer productivity linearly as we increase the number of developers, right? And that's something that you hear over and over in these high performers, whether they're Google, Amazon, Netflix, Capital One target, et cetera. So in my mind, this is important because there's no technology leader who doesn't care about increasing engineering productivity and that we can even do it linearly. So that's surprise number one. By the way, how am I doing here so far? Is this interesting? So you're deeply held intuitions. It turns out we're right all along. So surprise number one, the business value of these dev ops principles and patterns is higher than at least I ever thought it would be. Surprise number two is that this isn't good just to make our techs look smart. It's great for operations and development. One of the best examples of just how great, great is, I keep coming back to year over year, is the Facebook chats release story. So this happened in 2008. And some of you, or maybe you have friends who will roll their eyes at this because they'll say a chat server, right? That sounds easy. But it turns out because don't undergraduates in the university learn to write chat servers, that's true, but they're overlooking the fact that it actually is fundamentally an N cubed, order N cubed algorithm, right? And so when N is as large as 70 million simultaneous online users, you know, this is a very tough problem. This is widely considered to be the most toughest technical undertaking Facebook had ever undertaken. It was the largest project team. It took them one year to actually get into market. So how did they use that year? There's two patterns that I found stunning, right? One is as soon as the chat team was constituted, they would check all their work daily, at least daily, right, into version control. Whatever was in trunk would be silently migrated to the production environment, right? Invisible to customers. And they would deploy at least once per day, right, in the middle of the day. The second one is that they were using all 70 million simultaneous online users, their browser sessions as a test harness, right? They're sending invisible test chat messages to the still, you know, latent, invisible test services on the back end. Why would they do that? So they could simulate production like loads, right? And so the end outcome, and by the way, just to share with you my own prejudices and preconceived notions, if you had told me five years ago that testing and production was ever a good idea, I would have said that's crap, right?  They don't care about quality.  But the second pattern in my mind is even more shocking, right? The notion of a daily deployment, right? So, I mean, so much of us, I think we grew up where we do deployments at midnight on Friday and then people work all weekend, you know, to finish the deployment, hopefully before customers notice that it's not working on Monday morning. We deploy in the middle of the day, right? So, they do it as part of their daily work. If things go wrong, everybody's already in the office, right? I mean, there's all these virtuous patterns. And just to maybe share with you why I think that's so important, it was best verbalized by a gentleman named Nathan Schimmick. Oh, no, okay, yes. He said, as a lifelong ops practitioner, I know that we need dev ops to make our work humane. Throughout my career, I've worked on every holiday, on my birthday, even worse on my spouse's birthday, and even on the day my son was born. So, some of you might have friends, you know, who have been in that situation, you know, out of a sense of duty or obligation or simply because they didn't have a choice, right? They've been put into those, you know, inhumane situations. And some of you are probably like me, where maybe you've been complicit in creating those inhumane work systems. And we now know that there is a better way. Unless you think that this is only possible at open source hippie companies like Facebook, right, you should know about what CSG has done. So, in the United States here, the largest bill printing company is CSG. They're publicly traded. So, if you get a paper monthly bill from a Comcast, a direct TV, you know, a trust deal, you know, an internet cable company, chances are it comes from a CSG plant. And so, what they chose to focus their transformation on was their bill printing operation. So, I cannot think of a pathological worst case than this, right? It's 20 technology stacks. You know, you name it, it's in there. You know, thickclient.net, thinclient.net, COBOL, VSAM databases running on mainframes, right? It means that every time they do a deployment, they have to do 20 simultaneous deployments, right? By the way, it includes 136,000 thick desktop clients running in the call centers of their customers. So, they doubled their release frequency. They went from two times a year to releasing four times a year. But even more audaciously, they went to a daily deployment cadence. So, every day they would do a deployment and, you know, using a new team that was spanning development and operations. And so, the end outcomes a year later was that when they do a release, incident count went down by 90%. Meantime to prepare went down by 98%. But most interestingly, the code deployment lead time went down from 14 days down to a day. So, that's 14 days of people trapped in a war room, you know, conference room, right? Panicking, trying to get things running, right?  To which they would have to honestly respond, no, we're not done yet. We have 13 more days to go, right? 14 days of that to the deployment being finished, you know, by 1 p.m. on the first day, right? And out comes the Xboxes, because why? There are no more live incidents. So, you know, I think that's just astonishing. And by the way, great for dev, test operations. But as their chief architect, who is now their VP of R&D and product operations, not bad for an architect, you know, said the customer gets the value in half the time. So, you know, I think that's astonishing. If you can do it for what I believe to be a pathological worst case, if not worst case, very bad case, it really should give us confidence that we can do it for almost anything, right? These principles and patterns transcend the power that we use. So, here's another thing that I would have never believed if someone had told me 10 years ago. This pattern. And I think it's best verbalized by Patrick Lightbody, who's in 2011, he said, during my journey, we found that when we woke up developers at 2 a.m., defects got fixed faster than ever, right? And Werner Vogels, the CTO at Anson, would even say it more succinctly. If you helped build it, you must help run it.  Pagers are for ops people, right? The reason why they became ops people is because they're like pagers. There is an internal consistency to that logic, but I don't think it's very... There's no learning that comes out of it. Here's a narrative I like better. It comes from Tim Tischler, who for many years led the DevOps initiative at Nike. And he said, as a career-long developer myself, the most satisfying point of my career is when I got to write the code, test it myself, push it into production myself. When I could see happy customers when it worked, and when I could see angry customers when it didn't work, and when I could fix it myself. I didn't have to open up a ticket and wait a day for someone else to do it. He said, not only could I have learned... So yes, I could have done it faster. But the most important thing is I could have learned something that would have enabled me to not make that same mistake the next time around. And he said, our ability to self-test and self-deploy has diminished over the last decade, partly because of the... Sorry, the dumbasses from the service management community, like Charlie and me, right? He said, you can't do that. That's taken a lot of the joy out of development work and also dev productivity as well. And paradoxically, it's things like page rotation that actually allows us to bring down only joy back, but productivity back. So, am I being too cavalier about that claim? I mean, pretty cool. Right, and let me say, the measurements are decisive, right? I don't have time to share with this, but we actually tested. It doesn't matter who deploys, dev, test, or ops. And it turns out it doesn't matter. They're statistically identical. What matters are the architecture, the practices, and the cultural norms. All right, so, surprise number one. Business value is high. Second one is great for ops and dev. Surprise number three is there's this metric that looks very tactical, and it's so easy to overdelegate. And yet, I've come to believe that this is probably the most strategic measure of any engineering organization, and that is code deployment lead time. So, in the DevOps community, I think we're very guilty of loving this one metric. It's called deploys per day, right? But in the manufacturing community and the lean community, that is obviously not their favorite metric. Their favorite metric is lead time. And so, they might measure it as, how quickly can we go from a customer order to finished goods, right? Or maybe raw materials to the finished goods. And would you believe in the lean community, there is this deeply held belief that goes back 50, 60 years that says lead time is the most accurate predictor of internal quality, external customer satisfaction, and even employee happiness. And what we found in our benchmarking work is that this is absolutely true for the work that we do as well in the technology value stream. So, we specifically measure lead time as we start the lead time clock at changes committed into version control, right? Through tests, through deployment, so it's actually running in production. And so, I think you architects would be quick to ask very rightly so. Why do we start the lead time changes committed into version control? Why not earlier, right? Like at the signal of customer demand or like when Dev accepts the feature to go into work or when an idea was first created. And it's because the point of which changes are introduced into version control, we believe is a dividing line between two qualitatively different parts of the value stream. So, to the left of committing changes into version control, we have design and development. So, the main characteristics of design and development work for the first time maybe, right? Maybe never again to be repeated. So, if you look at the histogram of the lead times, it could be very flat and wide, right? Because we never get a chance of practice, you know, doing a certain design, right? And that's the point of design development. Whereas everything to the right of changes being committed into version control, we want the exact opposite characteristic. We want testing and operations and deployment to happen quickly, mechanistically. We want it to be the same way every time, right? So, the variance curves on the histogram is very narrow and flat, right? So, I'm not suggesting that testing and operations happen only after design and development are complete. You know, with things like test and development, we're actually writing the test before a line of code is even written. But here's the point. Code deployment lead time predicts the effectiveness of the testing and operations part of the value stream and also predicts how quickly can we give developers feedback on their work. So, if I'm a developer and I introduce an error into version control, if I only discover it six to nine months later during integration testing, that means by then, right, by the time the error is detected, you know, the link between cause and effect has surely almost been lost, right? Ideally, we want to be able to detect through automated testing, you know, within minutes or worst case hours to be able to signal that error, right? Not just to fix the problem faster, but to actually enable learning. And incidentally, that code deployment lead time is the gating metric to how quickly we can iterate with customers, right? As was mentioned in almost every presentation so far, like the goal is to iterate quickly, integrate customer feedback. And if we are only releasing once a year, right, and that's gated because we have a nine month deployment lead time, then we can't iterate quickly at all, right? So, again, the point is what looks like a very tactical metric, code deployment lead time, you know, I believe is very strategic because it measures the effectiveness of both design and development as well as testing and operations. By the way, just I want to share with you one of the also big surprises. So, it turns out there's one question you can ask that has a startling level of ability to predict both IT performance, organizational performance, as well as presence of architecture, technical practices, and cultural norms. And that question is this. On a scale of one to seven, to what degree do we feel that we need to be able to to what degree do we fear doing deployments, right? One is we have no fear of doing deployments. We do them all the time in the middle of the day, right? Seven is we have existential fear of doing deployments, and that's why we do them never, right? And so, you know, if we, you know, have lots of handoffs, if we have, you know, we have to pass through many, many different teams, right, the rate of which we fear is makes deployments very, very high, right? So, I just love the fact that, you know, this one question has, again, a startlingly high correlation with performance metrics as well as, you know, the architecture, technical outcomes, and technical pattern, technical practices, and cultural norms. So, surprise number four is that I finally feel like I now understand Conway's law, right? So, Conway's law, probably all of you know already, but, you know, it's famously quoted by Dr. Melvin Conway in a very famous experiment he did in 1968. You know, he had two groups, one was required to write a cobalt compiler, and one was written, writing an algal compiler, and he said, we assign five people to the cobalt job, three to the algal job. The cobalt in five phases, the algal compiler ran in three phases, right? Just saying that, you know, there's something very, there's an interesting link between how we build our software, right, and the characteristics of how the software runs. There's a famous book called The Cathedral on the Bazaar, written by Eric Raymond, and he runs this, he has something called the Devil's Dictionary, and I think he marvelously paraphrased it. He said, if you have four groups working on a compiler, you will get a four pass compiler. So in the DevOps community, Conway's law is brought up a lot, and I'll be honest, I never quite understood concretely how this would impact, you know, how we do work in dev tester operations. But then, during the writing of the DevOps handbook, I ran into a case study that just blew my mind. So let me just share with you what it is. So one of the, this happened at Etsy, so the CTO there is John Alsbaugh. This is the same John Alsbaugh who read, who gave the famous Alsbaugh Hammond presentation in 2009, saying that they were doing 10 deploys every day as part of their daily work at Flickr. And, you know, he joined Etsy in 2009, but there's actually this interesting story that happened that started long before John Alsbaugh got there. So it turns out in 2008, in order to create business functionality, it really required two teams to do work. It required work by the developers in the PHP front-end as well as in the stored procedures in their Postgres database, right? So two teams required to coordinate, synchronize, marshal, sequence, whatever, and deploy. In 2009, they wanted to enable these teams to work more independently, right? And so they created something called Sprouter. It's short for stored procedure router. The problem is, is that now when we implement business functionality, we're having to require two teams to do work to three teams, right? You had DEVs in PHP, the DBAs in Postgres, and then the Sprouter team in the middle, right? The goal was so that they could all work independently and meet in the middle, but what ended up happening is they created a system that required a degree of communication and coordination and synchronization that was rarely achieved. Every deployment became a mini outage, right?  And so essentially this is where they moved an object relational mapping thing so that developers could, just within the PHP code, you know, create all the changes necessary to implement business functionality. And the results were stunning, but, you know, as as Conway's law would predict, maybe predictable, right? Because only one team was required to do work, the changes got implemented more quickly. And the teams were able to independently develop, test and deploy functionality without having to communicate, coordinate, signal, marshal, you know, all those other things. And so lead time went way, way down, right? And so in my mind, this is such a great example because it shows how Conway's law can hurt us, right? As well as how it can help us. And I think having seen my share of Visio 2003 diagrams of, you know, we put all the Oracle people here, the MySQL people here, one of the other databases back in the day, right? You know, we put all the Solaris people here, the Windows people here, right? In order to implement a business change, we might have to transit 20 to 40 different teams, right? So, you know, what does Conway's law predict in terms of lead time and production outcomes? So in my mind, that was definitely one of the top learnings. Interestingly, you know, I think in the DevOps literature, you know, there's a lot of people, the Werner Vogels quote, that's certainly one line of thinking, right? The whole notion that you have self-contained product teams, you know, that can independently develop, test, and deploy values to the customer, right? That's sort of the Netflix-Amazon model. But, you know, would you believe that there's actually a much ignored faction, which is the opposite school of thought. It was a huge surprise for me to find that functional orientation, right, where we put, you know, centralized operations still has very much in place. Etsy operations, GitHub, centralized operations. Google has centralized operations. In fact, there's a VP, I can't remember his right name right now, head of SRV, the ops engineers. He has 1,300 site reliability engineers reporting into him, because they want to control hiring, quality. They want to allocate these very scarce people, right, to where the organization needs it most, right?  In fact, Toyota was probably the most famous functional orientation at all, of all. So that's about, and by the way, I'll talk a little bit more about why I think that's so important. I think it has everything to do with architecture, because Conway's law, right, in order to achieve, you know, our desired outcomes in our field, the, you know, has a less well known sibling, you know, called architecture. It says architecture and the organization must be congruent. Or at least, that's my thinking. So that leads us to the surprise number five. You know, for this, it's really that I think when historians look back at our field, they will say, you know, what we call dev ops or, you know, high performing technology organizations. I think they will say it is a subset of a much larger category of organizations of which, you know, Toyota is probably one of those, right, they would probably call them dynamic learning organizations. And so, one of the people who's mentored me in this is a gentleman named Dr. Steven Spear. He wrote a phenomenal book called The High Velocity Edge. He wrote probably the most famous Harvard Business Review article called Decoding the DNA of the Toyota Production System. And that was based on his PhD dissertation he did at the Harvard Business School, where in support of this work, he actually worked on the plant floor of a tier one Toyota supplier for six months, right. In fact, before the Toyota executives let him do that, he was first required to work for 30 days at a big three automotive plant. It was actually General Motors in Michigan, because the instruction was until you work in that type of system, you will not understand what you're seeing here. So he's extended his work beyond just manufacturing to the safety culture at Alcoa, a large aluminum company, to engine design at Pratt & Whitney, to the U.S. Federal Reserve System, and so forth. And he said, designing perfectly safe systems is likely beyond our abilities, but we can approach safe systems when four conditions are met. I just want to go through the four, but I want to really highlight one of those, because for me, that's probably responsible for why the devil's handbook was five years late. Well, it's a contributing factor because it really made me see something that I didn't see before. Capably one, he says that organizations must see problems as they occur. We must manage complex work in a way so that design problems are quickly revealed. And so I think if we look at sort of the technical patterns in our space, that evidence is certain behaviors that seem very familiar, like assertions in our code, continuous builds, continuous testing, continuous monitoring of the production environment, user testing, AB testing, all of those things, we're trying to create as much telemetry in the system so we can actually see whether our assumptions are actually correct or not. Capabilities two is it's not enough to see problems that occur, we must swarm them to fix them. The goal is not just to fix the problem quickly, the goal is to generate new knowledge and disseminate that as quickly as possible. And this is really saying that we're prioritizing the improvement of daily work over daily work itself. And so the paragon of this principle is without a doubt the oh in fact I'd love to quote from Dr. Speer. The goal is to create as much feedback in our system from as many areas as possible sooner, faster, and cheaper preserving as much linkage between cause and effect because the more assumptions we can invalidate, the more we can learn and the more we can learn, the more we can win in the marketplace. The most famous example of this principle is the and on cord. On the factory floor, if someone sees an error, if the parts are defective the parts aren't there, it takes longer than expected. It took 1 minute 20 seconds versus 55 seconds, we pulled a cord and of course when you pull the cord what happens, the entire assembly line stops. So during my training at University of Michigan I was pretty astounded to find out how many times the and on cord is pulled in a typical Toyota plant per day and the answer is 3,500 times a day. My first reaction was like these guys are not so smart. They're not buffering errors. Management's job is to buffer errors.  It's because they want to signal the error as widely as possible, swarm the problem and they want to eliminate the daily work around. We have to put in a systemic fix, otherwise we're going to have the same problem 55 seconds later. In our world, we have daily work around and because our work usually takes longer than 55 seconds, it's just not as obvious. What happens when we have the consistency and conformity to do that? Google does 5,500 code commits per day. They're doing 75 million daily tests every day. What are other patterns? Whenever we have continuous build systems or deployments, that's an and on code. Stopping our work to review other people's code. That's prioritizing improvement work over daily work. What are other patterns? At Google, they have a single homogeneous source tree that only one version of each library is allowed. Capably 3. Let's go to Capably 3. There has to be some mechanism so that local discoveries can be turned into global practice. In other words, there has to be some way to elevate the entire state of the practice. In our world, here are some patterns that I think fit into that mold. A notion of shared source code repositories. Google has only one version of each library allowed. A friend of mine said, I wish. I'm in a large bank of the 93 versions of the Java Stress Library. We are running 92 of them in production. All but one insecure. That conformity allows them to be incredibly productive. Blameless post mortems. You must make it safe to talk about failures because honesty is required to enable prevention. Chaos monkey. We don't have enough outages to report on. We have to inject failures into the production environment. Chaos monkey is what was made famous by Netflix. We learned that the only reason they were able to survive the April 21, 2011 Amazon outage was because they were running chaos monkey that was randomly killing servers in production. Why do they do that? It's because they want to learn about problems in a planned way versus an unplanned way somewhere else. But there's another mechanism that I want to talk about which is internal conferences. Studying high performing organizations that don't look like Google, Amazon, but they often have in common is they want to build a world-class technology organization and we need to share practices in the best of the game. By the way, so what does this have to do with architecture? I thought I had a slide on here. Ah, internal architecture. It's just known patterns. As Ralph Loura, he was the CIO at HP and later HPE, he said our goal is to create buoys, not boundaries. The idea is that share the technologies that we have expertise in. If you use those, you're guaranteed to be safe because you'll be surrounded by a community who is there to support you. But if you have to go outside the channel, outside the buoys then you are allowed to but just have these certain principles in mind. In fact, he said it's so important because that's probably where the next great innovations are going to come from is the people who need to innovate and maybe those will actually be folded by the organization as an approved, not approved as a widely advocated practice. All right, can I go five more minutes and then we'll cut in the Q&A? Yeah, okay. Then I will go to the last surprise. How is it? The last surprise I want to share with you is surprise number six is that DevOps is not just for the unicorns. Google, Amazon, Facebook, but it's also for the horses as well. Large complex organizations that have been around for decades or even centuries. That's the reason why we're going to the fourth year of holding a conference called the DevOps Enterprise Summit. The goal was to have leaders embark on this transformation tell experience reports. The first part is just 30 minutes. Tell us about your industry that you competed in. Tell us where you fit in the org chart. Tell us the business problem you're trying to solve. What did you do? What were your outcomes? What did you learn? What problems still remain? The reason for that format is that as leaders, as learners, we don't learn from theory what people say you should do but really what people did so that we can take away our own learnings from it. So I want to share with you just two top surprises that came out of it The first off is that there is no doubt in my mind that the horses are achieving the same sort of miraculous technical outcomes that we've only seen typically in the unicorns. Heather McMahon at Target is a large U.S. retailer. They're doing lots of deploys per week, but the most important thing to me was what are they doing DevOps on? The business problem that she was trying to solve was an architecture problem. It was this, every time that a development team wanted to access something that was in a system of record, they would often have to wait six to nine months because everything was tightly coupled together with point-to-point integrations. So they put everything into a next generation system of record on Cassandra, Redis, and so forth with versioned APIs, which meant that any time a developer wanted to add, change, remove product catalog, store information, or bridge shipments they could do it on demand. They've gone on record saying that 53 different business initiatives were enabled by this. Her team has doubled in size for three years now. I think just showing how important a capability this is. The ship to store initiative was enabled by this in-store applications, Pinterest integration, Starbucks, all that through this, through this. An architectural game changer. Topra out of Pal at Cap-1, they create a shared service to enable people to do hundreds of times per day with automated testing, with security fully built-in. They call it not DevOps, but DevOpsSec, just showing how we can make security fully into the daily work of dev and testing operations. Macy's, Gary Groover, talked about how they went from doing 1,500 manual tests every 10 days to hundreds of thousands of automated tests running every day. Lots of mainframes there. Jason Cox at Disney described how he embeds, you know, over the years, hundreds of ops engineers into the dev teams, helping them become as productive as if they were at a Google, Amazon, or a Facebook. Nationwide insurance, their transformation, Carmen Dior described how they're doing it for their not a satellite application, but, you know, for the state pension retirement fund. There's a segment leader. It's a COBOL app that's been around for 40 years. Terry Potts at Raytheon described how they reduced testing and certification time for ground controls that control satellites from months down to a day. So all of these things, I think, give us confidence that these patterns and principles are universal, right? And I think that is really, really exciting to see. The last observation is this. These are among some of those courageous stories I've ever seen, right? And a lot of these were driven by chief architects. The reason why I say it's courageous is that I think all of these leaders were given some degree of air cover, but almost all of them were wildly exceeding the air cover they were given. In other words, you know, they're essentially putting themselves into personal jeopardy because of, you know, they were straying outside of the permission they were given. So why would they do that? And I think what they all had in common was they all had a sense of absolute clarity and conviction that the capabilities they were creating for these organizations were needed not just to win in the marketplace, but maybe even to survive in the marketplace. And I think just the moment I'll remember I was shadowing Heather Mikman at Target and I saw the certificate on her desk, right? It was obviously printed on an inkjet printer and it was for abolishing the TEP and LARB. So what is the TEP and LARB? The TEP is called the Technology Evaluation Process and the LARB is the Lead Architecture Review Board, right? So whenever you want to do something radical, like use Tomcat or open source, you have to fill out the TEP form to which eventually earns you the right to present to the LARB committee, the Lead Architecture Review Board. All the ops architects are on one side, the dev architects on the other side, they pepper you with questions, they start arguing with each other, they assign you more questions and you come back next month after month after month. And she said why are we doing this? No engineer on my team should have to go through this. In fact, no engineer at Target should ever have to go through this. And kind of the funny thing is no one could remember why they did that. There's some vague memory of something very bad that happened about 15, 20 years ago, but the bureaucracy still remained. And so eventually they did abolish the TEP LARB process earning her the gratitude of her entire team and probably likely most engineers at Target, so that's about three to four thousand engineers. So why do I think this is important? I think one is certainly that left unchecked without something like DevOps leads to horrendous outcomes, whether you're in dev, test, ops, information security, but the ultimate organization harmed is the organization that we serve. And over the years I've really framed it like this. I think the mission at hand is framed by my friends at IDC, another great analyst firm. They say there's eight million developers on the planet, eight million ops people. I think the mission at hand is how do we elevate the productivity of every one of those engineers so they are as productive as if they were at a Google, Amazon, or Facebook. And there's no doubt in my mind if we do that we will create trillions of dollars of economic value every year. So it's a problem definitely we're solving and that's a problem that we're working on. Thank you so much for making the DevOps Handbook available to everybody. And if you are interested in these slides, if you want a free excerpt, actually the thing that I think you would be most interested in is all the videos and slides from the DevOps Enterprise Summit. If you want links to all of those just send an email to realginkim at senderslides.com subjectline DevOps. Don't take a picture. Just send an email to realginkim at senderslides.com subjectline DevOps and you'll get an automated response within a minute or two. Still taking pictures, but all right. Thank you so much. Thank you, Gene. We do have unsurprisingly a number of questions. I realize we're reaching into Charlie's time so if we can just take a few. We'll just take a few if we if I can ask you to have a seat. So first one to comment on this statement please. In not so well run IT organizations the first thing that's done is write new code. In well run IT organizations the last resort is writing new code. How would you comment on that? Correct. There you go. It came from Marty Kagan. He's famous for training a generation of product owners how to build great products. He wrote a phenomenal book called Inspired. And one of the practices that he has preached for nearly two decades is dedicate 20% of all Dev and Ops cycles to paying down technical debt. And that's because the opposite of technical debt is architecture. At some point it comes to pay down technical debt fix problematic areas of code or in the environment, automate, refactor, rearchitect. That has to come from somewhere in the great organizations. It comes from daily work 20%. Moving on. I'll shorten the question but New York Times article recently about agility being adopted widely as a business practice even in organizations that don't necessarily stress software. Correct. How should standards organizations like the open group embrace agility to serve their new stakeholders and compete in the marketplace of ideas? I guess that's a great question. Having come from the service management and ITIL community, having been through my share of D-SIMs and Togafs and COVID and everything, I think the one thing that I think we're blessed right now with is that the wind is finally at our backs. The business units are actually adopting stand-ups of retrospectives as part of their daily work. They understand the importance of short, small batch sizes to improve throughput. That means so much of the ideological battles we've had. It's over. It's becoming part of the prevailing belief system. I think the better we can serve, I'm not saying drape frameworks I think we should take advantage of that. There's a certain category of battles that we no longer need to fight. I see that as phenomenal opportunities. RFP processes designed to choose an important core solution or supplier often confound agility by requiring detailed binding requirements up front. What's the alternative? Time and materials. It's interesting. A friend of mine, Adrian Cockroft, who was part of the Netflix re-architecting because Netflix used to be a J2E app that ran in a data center. Charlie and the Amazon Clouds. He was a distinguished engineer's son. He was part of the eBay transformation. He said something to me that just blew me away. He said, those organizations are just now coming off a five-year fixed price outsourcing contracts. It's like they've been frozen in time for five years. Those things are generated to create and enforce stasis. Instead what we want is talented people but not firm fixed price is my belief. Last one and then we'll get to Charlie. Question. Correlation does not imply causality. Is agile making organizations great or is a great organization using agile? I'll neutralize that statement a little bit by saying correlation certainly doesn't even causation but over in our kind of theory-building theory testing we've actually been able to use structural equation modeling which does actually imply a causal arrow. Certain things, I think I was very careful about what predicts what correlates. Now we have to say with certainty with datasets spanning 26,000 respondents that certain behaviors actually do predict performance. Those are like continuous integration, version control proactive monitoring, high-trust cultural norms, architecture. Those predict performance. Great. Thank you. Everyone please round of applause for Jin Kim. Great job.


On this episode, we fill our cosmic spooky agenda with some Junji Ito goodness. Hey everybody, welcome back to Wikigitem, Gio here, and today I'm always excited to bring you another Junji Ito manga review. I really enjoy doing them. Here we are reviewing Remina from Junji Ito. So essentially, there's not a whole lot to the book. It is a very simple yet effective horror story about a rogue planet that the scientist discovers and it sort of crosses this warm hole and it arrives into our solar system. And it's on its way, moving super fast on a collision course with Earth. Now the scientist's daughter is named Remina and after this marvelous scientific discovery, he decides to name this rogue planet in honor of his daughter Remina. And she suddenly becomes the talk of the town, if you will. Super famous with acting opportunities and everybody's darling. And it highlights the absurdity of cultish celebrity status and how overnight somebody can become this idol-like character and how many people fall head over heels and you start forming these fan groups that turn quite deadly and quite serious.  That's pretty insane. And we see that in the cult that forms for Remina. Now things take a sour turn when they discover that the planet is moving way too fast and destroying or essentially eating anything it comes across. All these other planets don't stand a chance against this behemoth celestial body that's on its way to potentially destroy, consume and eradicate Earth. You don't really have an explanation as to why it's happening. What's the motive behind this or the scientific reasoning and all that stuff? This is a book that plays more into the fantastical. It really did remind me of reading a classic 50s and 60s sci-fi story where you take absurd premises and you build something horrific out of it. And obviously the charm of the book of having sort of the grotesque images when we find out what's inside Remina or we take a look at the actual planet. And it really did remind me of old school sci-fi stories that don't necessarily have an answer to everything, but that's part of the fun and the mystery of you finding out and maybe theorizing what could happen or why things are going down the route that they're going through. So as the story progresses, there is the revelation and it gets leaked that the planet is headed to Earth and a mass hysteria forms and we see that cultish obsession bubble and boil over in the fact that, hey, this scientist is at fault because he named his daughter Remina and now Remina is coming to the planet to crash into Earth and it could be like the true Armageddon. Therefore, they're the bad guys and we have to... and it suddenly escalates from they are probably the bad guys to no, they're evil and we need to sacrifice Remina and her dad in order to appease the planet so it won't crash into Earth. It sounds absurd and hilarious and kind of silly and especially in a world like the one we're living at now in 2021. I believe that this would happen. If you were to tell me right now that there's a giant asteroid coming and it's named after somebody famous, I would totally believe that a cult obsession would form over that person and they would want to lynch that guy or girl or whatever and to sort of make a last minute Hail Mary to see if it will stop the incoming disaster. I totally believe that and you see that in Remina and that's part of the genius and satirical funny bone that Jujito has because it's not always just about the spooks. There's a message behind it and there's a humor to the absurdity. There's a humor to the craziness and you just got to roll with it and enjoy it for what it is. There's a lot of cheesy sci-fi jargon that's really wild and funky but you go with it, you believe it. Like I said earlier, it does remind me of classic old school Hollywood sci-fies from the 60s. So you do get some striking images.  The ending I really enjoyed, like a lot. Like again, it reminded me of old school sci-fi and old school horror short stories where the outcome isn't necessarily what you would have expected and it puts the characters in a very dangerous situation and the story just ends there for you to imagine and interpret what could happen next. And that happens with Remina as well. The characters for the most part, almost all of them are kind of stereotypical mob-ish characters. Remina is a shy young girl who doesn't really want to be in the spotlight like she is and when she starts getting deals and sponsorships and being a celebrity of sorts, it kind of changes but you still see that resentment, you still see that shyness and that timid quiet girl that honestly would rather just escape all of that and when crap goes down that is magnified exponentially. Art-wise though, aside from the sci-fi aspects and all the drawings in space, the character models are kind of just extremely forgettable and ordinary. This isn't something that will blow you away when it comes to the people on Earth. Obviously the cool thing about Remina are the visuals of the planet which reminded me of stuff like Ego the Living Planet from Marvel Comics or stuff like that. There's a lot of detail and grossness in Remina the Planet to warrant getting this book. The writing is pretty sharp and concise to the point. There is a message to be said about the human condition and the mob mentality and the cultish obsession with celebrities and just the reaction, the domino effect of a disaster and how people can grow into this massive blob of hate and how that dictates actions over rational thinking. I think that's sort of what I got out of Remina but overall, I really did enjoy it. I'm a huge fan of cosmic horror and scary stuff in space so I was right at home with this. Obviously the deluxe presentation from Fizz Media is to be commended as well and should make a fine addition to your Ito Library or your scary books on your shelf. So what about you guys? Let me know in the comment section down below what you thought of Remina and if you haven't read it, let me know what are some of your favorite cosmic horror but just space themed manga or comics in the comment section down below as well. Thank you everybody for tuning in. Thank you for liking, commenting, subscribing and being a part of it we can geek them. Share the video if you want. It will definitely help out the channel. Thank you so much. Stay safe out there. God bless. I will catch all of you on our next episode.


Hi, we're here with Justin from Poodle at MoodleMood Global 2023. Justin, what can you tell us about Poodle, how you support Moodle users in your ecosystem, which is language learning and language teaching, I understand. So Poodle is a solution for language teachers who use Moodle. Moodle out of the box is really good, but it doesn't have some of the specific features that language teachers need. It would be something like an audio recorder that only plays once and then doesn't play at a specific time to simulate a quiz or a test situation. So we've got a lot of support from the Moodle community because we've been around Moodle for about 10 years. We're first free an open source plugin and later became a commercial plugin because people needed more support and more development. I mean to go through ways of flash-dying and HTML5 arriving and things like that. But we've got some really great clients now and people use it for really good purposes. Excellent, and I understand there's not only this audio recorder, but there's quite a number of activities that users can do with Poodle. Yeah, that's right. So we start with audio and video recording and that was, I think where people became familiar with Poodle, but more recently we focus on specific activities that people can do for language teaching, like reading texts aloud and working on their fluency, speaking fluency, and vocabulary acquisition and open speaking, which is giving somebody a speaking task and evaluating how well they are speaking tasks and giving instant feedback to users for them. You have plans to expand, obviously learning English is a main need for the world, but you have plans to expand to other languages, other areas. We already support over 30 languages, so we have people using Poodle quite a lot for teaching French as well as teaching Norwegian to immigrants, Russian, other languages. So we already support a lot of languages. What we're trying to do now is to reach out to users who don't necessarily have their own Moodle site and help them get set up with Moodle plus Poodle and just regions that we haven't been able to reach because we don't speak the languages so we have these sellers and partners in those regions where we can help people that haven't been able to reach. Okay, that's wonderful, so I learned something. I didn't know there were so many. I had in mind that there were some more, but not that there were so many languages that didn't support already. Cool. And how is the conference really? Oh, the conference is great. It's been really, really good. Being in Barcelona is great because there's so many people come from the Middle East, they come from Africa, they come from Europe, they come from America and Asia as well. So it's really global. I've been happy to meet so many users of our product currently and people, partners who work with our users in different regions and hearing what they need and what's working and that communication is really good because it makes the product better. Awesome. I hope being a certified integration partner that also brings some added value to the users or to the potential customers. I think so because it means that it's supportive and it's not going to disappear on the next version of Middle East. We're here for a long time. That's one of the things that people are concerned about with plugins and it also means we've been approved and validated that you can install this in your Middle East site. You just don't have to worry that it's going to be a problem. Absolutely. Next time, well, thanks so much for supporting us, supporting Modo and supporting the conference. Thank you very much.


Hey, everybody, welcome back to Magic Orthodoxy. My name's David, and this is a prototype review. Hey, today we're gonna look at the house of cards, playing cards, from Ember Waves and Untied States. Who is Ember Waves? You might remember, this is their third deck in their Untied States trilogy, and that's right, I said Untied States, not United States, it's a play on words. You might remember a while back, we did the review for their Capitalists deck, which was a very successful campaign. You can look out for those cards. You can also look out for their other decks, the Sword and Atlas. Currently, this is a Kickstarter campaign right now, and so if after watching this video, you feel compelled to back this project, I would highly recommend you head on down to Kickstarter and check them out. All right, so this deck, House of Cards, it's just another play on words, a lot like Untied States, okay? This deck, or at least a theme for this deck, it's gonna cover the top, or the best, and the worst presidents of the United States, and it kind of has a little bit to do with the address for the capital, which is 1600 Pennsylvania Boulevard.  Just remember, nobody's perfect, we all make mistakes. So the black cards, the black cards in this deck, the spades and clubs, they're gonna represent all of the good presidents according to Untied States. And so the red cards, the hearts and the diamonds, they're gonna represent all the bad presidents. Now, so at the end of the day, this deck is a satirical comedy, okay? It's not a drama, it's meant to be fun, it's meant to be intriguing, it's meant to lead the conversation into the discussion. It's not meant as a political statement, it's a political satire, okay? Okay, so the other neat thing about this deck series is, it's gonna be super limited edition.  Okay, here's what they're gonna do. If they make their first goal, only 1,000 decks are gonna be printed from the United States Playing Card Company, okay? 1,000. If they hit their stretch goal, which is double, then there'll be a second, completely redesigned limited edition deck, and that will only have 1,000 decks printed as well. This deck is gonna be a standard deck with 56 custom cards, it's gonna have a custom gaff card and a double backer. Every single card will be custom, number, court, ace, joker, 100% redesigned, new custom cards illustrated by designer Ember Waves. Also the tuck case, again, completely redesigned, redone, no bicycle branding, it's gonna be its own thing, and it's gonna fit perfectly within your untied states trilogy. So if you already own the previous decks, this deck's gonna fit right along as a part of it. All right, so that is our review for the untied states, House of Cards, Playing Cards from Ember Waves. And like I said, if this review has stood out to you, if this sounds like something you'd like to back, I would highly encourage you to head on down to Kickstarter right now and give it your support.


And if you leave, they lose control of you, so they will switch on the charm and they will love bomb you until you're back in their arms metaphorically or physically. And yeah, I mean, but they were used out your autism against you, so they could, yeah, they could put you in situations of like, loud noises, even though they know that you're really struggling with sensory issues and then they might blame you for the fallout, or they might invalidate it or shame you. And if you ever made a little mistake or a misunderstanding in a social situation, they will never let you forget it. It will be brought up time and time again for eternity.


This is what a voice, speaking at a normal volume, looks like. What the sound of a jet engine looks like? An artillery shell!  In a few years, this is how you'll hear my voice, and your friends, your favorite band, your family. Hearing loss is the most prevalent health complaint among veterans. But it is preventable. So lead by example. Wear your plugs. Wear your muffs. Protect your hearing.


JB, the wolf is in the house. Dude, thank you so much for doing this. I really appreciate it, buddy. Pleasure. 8% Nation, we have the Wolf of Wall Street, Mr. Jordan Belfort in, we're doubling down, right? Cause he's gonna be in Vegas with us, but we're doubling down and we got him on virtual as well. Huge thanks to you, buddy, for spending some time with us and doing this with us. I don't think anyone needs, you know, like an introduction per se, you know? If they do, I would say just go watch the movie, right? I mean, would you agree with that? Well, I mean, you know, the movie is mostly true. I mean, some of the things that are in the movie are not true, but the things that you think would not be true are true and the things that aren't true, it's like the opposite, you know? But I think it's a good feeling, listen, the bottom line is that, you know, in the context of what we're talking about today, you know, the secret to my success, you know, on Wall Street and throughout my life has been my ability to take people who maybe are not natural-born closers and very quickly turn them into superstar salespeople. And frankly, on Wall Street, Stockbrook was all glorified salespeople. That's what you're doing. So Wall Street is, you know, people think of Wall Street, you think of analysts or investment bankers or board and get-go. In reality, yeah, there are those types of people out there, but most of all, you have people on the phone pulling away, closing deals, so there you go. Well, let's jump into that. I love that. So do you believe that there are natural-born closers? Yeah, of course there are natural-born closers. I mean, I am one, I've seen many, obviously there were different degrees of it. So, you know, imagine like anything else, there's a continuum. So yeah, there's natural-born closers and there's like natural-born closers at the highest level. So why was that guy, that was the Uber natural-born closer? And what that means to me is that, you know, in some way, my brain, the way it's wired, the experiences that I've had, intuitively, I know exactly what someone needs to hear, what I need to look like, how I need to say things, to essentially get someone to agree with my point of view, which is buy from me, that what I have is value, it makes sense for you to part with your hard-earned money. So natural-born closers, without really even thinking about it, just intuitively knows what the other person needs to hear to get them to say yes. Now obviously you can unpack that a lot more. What does that mean then? We can really break it down through, you know, his minicable chunks as you're on here.  How do you close at such a high level?  Or, oh man, I overcome every objection. Or, you know, I work hard, knock on lots of doors. They really can't verbalize it. And if you can't verbalize it, you can't chunk it down, then you can't teach other people. So while, yeah, I was an amazing salesperson myself, and I always looked at that as my superpower, my real superpower was that I had the ability to transfer that skill to other people. And that was really how I made all the money. It was by taking people who were not natural-born closers. In fact, some were just terrible closers, and I made them great. And I took people who were great and made them into the top 1% in the world. So whatever they were, you can rash yourself up. Yeah, and is that what you're doing now, right? Mostly training those that aren't natural-born closers or that are to be simply better at their craft.  Number one is actually recruiting. Companies hire my company to go out there and find the top producers of tomorrow. So fiercely competitive landscape in the past, right? So watch this in the past.  So it was very easy for me with my brand to go out there and find the kids coming out of college or those that are just out there floundering in the workplace, haven't found the right place to work yet. And because my brand can attract them, then train them and then deliver them to a company. That's one aspect of it, right? In a post-COVID world, now what you have is a real problem for employers, is that think about this is a really interesting thing. You think, wow, now the employers have to pick a litter. Everyone's out of work. There's so many people with the jobs. Okay, great, but what happened? Let's slow that down for a second. When companies laid off the bulk of their workforce, if we focus on the sales aspect, who did they lay off? The bottom 80%, the top 20%, the top producers kept their job. So what you have now is a huge pool of people who are not at the top of the heap.  So I have systems and psychometric testing for our community that sit through people. And I also, this is intuitively my team, you know, after so many years of responding out to people that really have what it takes and that are dedicated. And then we actually train those people using a system called the Straight Line, which many people know about, which is the system I've been teaching for many years of how you step-by-step become a world-class closer and deliver those and onboard those to companies. That's my system. That's awesome. So, I mean, and there's a lot of individuals and companies that are gonna be watching this, that what should they look for when they're hiring people? Well, number one, you gotta realize that the typical interview questions out there are like, they're all well-known and most people to put it bluntly are, you know, what do you do when you're going through a year?   It's like, you know, you have to say when you're on a date with someone, you don't really know the person you date until three months, because for the first three months they send their representative. It's like their best self.   So there are questions and what we do, especially, so there's two sides. Number one, there's psychometric testing. That's actually my own proprietary test based on what I've seen over the years. This was something I created in conjunction with psychologists and it's really intense. So it's 30 ways to ask the same questions to get to the truth of it. And then based on that, you see what certain competencies are in that predispositions. Predispositions, for example, someone might not be great for cold calling, but there'll be a world-class closer. There'll be the guy that you want to close. Other people might not be great at closing, but they're amazing at managing the long-term relationship, which is equally important for lifetime value of a customer. Some people are meant to just be more in face-to-face sales, others out there. So you gotta know, all salesmen aren't built alike. So this really sifts through all those people. Then through behavioral interviewing, you can really narrow that down even further. And then once you have those people, and here's these two other parts, the number one is onboarding. So the biggest danger point for any salesperson is the first 30 days. They have to show up already trained.  First year attrition of a salesperson is the death knell of every sales force. If you can get a salesperson trained onboarding correctly, and they don't leave that first year, you are literally at the top of the heap when it comes to sales, bottom line. The issue that I see even with really successful companies, for example, I do a lot of work in logistics and pharmaceuticals in auto, they will have 60 plus percent attrition rates, and they're still making a fortune. That's how insane it is. I had a company that had an 85% attrition rate. They were hiring 300 salesmen a year and blowing through 85% of them before I got involved. All right, and they were a billion dollar company. So just imagine the impact it has on a company's bottom line where you can choose who are the right people to actually hire, be make sure they're trained to a razor's edge on your industry-specific items before they show up, onboard them correctly, and then also coach them. We also coach them afterwards, free of charge for a period of two years to make sure they perform. So to me, that's a formula for success. Of course skill set, that's part of the training, but you gotta get the right person as well. Yeah, I mean, when you talk through like finding the right people, siffing through at you and your team, when you do, how do you end up identifying the right person? Do you use like a disc assessment, is there a certain? No, I use my own, no, this doesn't work. I found that this doesn't work, at best. I think it's mostly, no offense, I just think that my system, my test is proprietary just for sales. So if you're looking to hire psychologists or office workers, don't use my, what I do, I specialize in what they can do better than anyone in the world. That is, I know salespeople. I know how they tick, and I think he is unpacking it into a scientifically proven formula of how you spot out. So there's just a predisposition to succeed. Does not mean they're going to succeed. They need to be trained, they need to be onboarded correctly. And it's that at first year in the life of a salesperson, the reason that's so important is because of the way the belief systems work. Success to get success. When someone goes into sales and they fail in the beginning, they start to develop limiting beliefs about themselves, their capabilities, and it becomes a sort of self-defeating cycle here. So it's critical that the first experience that someone has in sales is a good one. Now, granted, there's many people that I made my living, taking people who were failing and making them succeed. But if I'm talking just from the company perspective and an experience at a company, the key is is you want them starting off on the right foot.  And two, you find people who could have succeeded with the right training and the right, they've had the skill sets to close and knew the product well enough, yet you self-sabotage because they start off on the wrong foot, they never get going and that spreads throughout the sales force. And that's why you have so many subpar sales forces out there. So it's not like it's just finding the right person. It's finding the right person, making sure they're trained correctly, onboarded correctly, and then especially that year one attrition is the crucial part for anyone who owns a company and also for you the sales person yourself because the bottom line is, is how you perform in the beginning is gonna set the stage for a cycle of belief building that compels you to being a top producer. Absolutely. I totally agree with everything you're saying from a confidence standpoint, you can just totally crush it, you know? I love that. I love that. That's really good. When we, I wanna jump to the straight line for a second. For those that don't know maybe what that is or what that means, can you break that down and explain that for a quick second? Sure. So the straight line, that's the actual sales training aspect to what I do. And I think it's probably the most well-known system in the world that's been, you know, obviously I'm gonna have the benefit of a movie where Leo DiCaprio is, we buy the logo straight line and the background sell me this pen, right? But what the straight line really is, it's a backwards way of looking at selling. Meaning rather than saying, you know, it's like, okay, I'm standing at the front. What do I do here? I gotta close this question. It's imagine a person that bought. What would they have to hear? What things would they need to know? What would they wanna see before they said yes? So you say, what elements have to line up in another person's mind to get them to say yes? And when you have experience that you'll quickly find out, there are just a few things, it's not a million things. There are three things, core elements that must line up in every person's mind before they buy a product. And then there are a couple of ancillary things as well for the tougher closes. So that's one part is what are these five core elements that must line up? What are the things you have to say to essentially get them to line up? So the straight line essentially imagine it's the shortest distance to two points to straight line, right? So the philosophy is that at the beginning of the open, at the end you have the close and the straight line represents the perfect conversation.  As a salesperson, if you knock on enough doors or make enough calls, eventually you're gonna find people who just, oh yeah, great, oh my God, they're almost free sold to the easiest closes all. So that represents that perfect straight line sale, an objectionless close where the prospect agreed with everything you say. And the only problem is that those are few and far between.  So you use the sales and wanna keep them on the straight line, they want to go off the straight line. So what we have is this methodology that gives you boundaries above and below the line. How far the conversation can stray off of perfection before you lose control of the sale and start spiraling off to what I call the Pluto, where you're talking about the price of tea in China or things that have no relation to the sale or down here to your anus, not a good place for salespeople to be. The point is, is that what I realized, there was this magic moment I had when I couldn't get my guys, this is 30 years ago, right? When I was trying to train my first 12 salespeople and I was already teaching an amazing system. It did nothing, but I was a great sales trainer even then, but I switched from selling average moms and pops to the richest 1% of Americans. And the sale was infinitely hard. So it was a really tough sale. So the system I was teaching, the old one, yeah, it was good enough to close average moms and pops. But take the same type of sale to super rich, uh-uh, the system broke down, it collapsed. So I had to invent a new way of training salespeople because here's what was happening. I was calling the same and I was closing 50% of the people I spoke to. My junior partner Danny was calling these people, he was closing 30%. Yet my 12 average kids who had barely clawed away at a high school, they were closing zero. Same leaves, same script, same phone calls, selling the same product. I'm closing half, they're closing zero. I couldn't understand it. And that went on for a month. And I finally cracked the code in this one evening and I realized what it was was something very elemental. It was really simple actually. What it was, it's easy to learn, is that I had a certain way of talking, a certain way of looking, a certain way of the energy I exuded, that literally from the first few seconds of the conversation, when I get on the phone with the prospect, well face to face, they would perceive me in a certain way.  They'd say, wow, this is not the average bear, not the average guy. And they'd say, this is an expert and they would defer to me. They would let me control the flow of the encounter. Because what we do, we've been conditioned since we were yay big to defer to experts. We let experts guide us. We seek out experts to solve all problems. So by getting yourself into that position where you're perceived sharp, enthusiastic, expert in your field, people defer to you and once they do, they essentially hand you control the sale, well guess what? Now you can start lining up the elements in the same way every time. So I had this philosophy, I said to my guys, guys, don't you get it? Every sale is the same. And they were like, what? Like how could every sale be the same? And my guys, every sale is the same. To me, because I was taking control, I can move it down the same path every time. People have different needs, different values, different pain points. They say different things, but the same core elements must line up in a prospect's mind before they say yes. And with the straight line system, once you're in control, you can then line those elements up in the same order every time. It's almost like picking the lock of a safe. The way you crack, a safe crack, a crack's a safe. He puts his ear, spins it one way, click, he has a number. Does he try to open the safe? No, he knows there's more numbers. He spins it the other way. He has the second click. Spins it the third way. He has the third click and then he tests it. That's when you ask for the order. If he got all three numbers right, the safe opens. If it doesn't, it wants to do, oh damn, it's uncrackable, no. He goes back to the beginning and he tries the three numbers again. So with the straight line, with a very similar tactic we call looping, we loop back and try again. And every time you essentially run these patterns, you're cracking these numbers of his buying combination. You ask for the order is essentially seeing if the safe will open and when it opens, victory. That's the shortest way to explain it. And it's so simple to learn that when I teach it to companies at the people, like they have these 30 or 40% uptick in close range in a matter of days. That's just in days and much more effort. It's a very simple system.  Because my guys were basically morons. They were not NASA scientists. They were kids that barely graduated high school. They came from poor families. They could barely walk and shoot government at the same time. And the movie was very accurate.   Bottom line. Yeah, well, I mean, and I love how simple you make it, right? Getting in control earlier, you know, following the straight line. If they give you an objection, obviously you're pivoting back. I mean, it makes a ton of sense. That's one of the things that I'm glad we're covering because the theme of 8% nation is that 92% of insurance agents fail. Well, the 92% that fail, the most common thing that we hear from them that they have questions on is objections and being able to overcome objections and objections just startling them and scaring them, you know, and so I love that you're addressing that. Yeah, remember this. So that one little point here is that objections are smoke screens for uncertainty.  That's very different than saying, no, I'm not interested. See, no means no. And my mind says, no, I don't want it. I don't see, as a sales person, there's one thing everyone here takes away from this outside the critical importance of being in control of the conversation is that as a sales person, as a top producer, your job is not to take the word no and turn it into yes. That's not how sales people make their money. I don't turn nos into buyers. I turn, let me think about it, into buyers. I turn bedtime of year into buyers. I turn, let me speak to my wife into buyers. I take objections. It's very different than, no, I don't want it. I'd rather knock on the next door or make the next call. I'm not trying to convince someone to buy so they don't want or need. I want people who need my product, want my product, convince my product, right? But they are skeptical and as they should be. So when someone hits me with an objection, what I'm saying to them is, ah, perfect. They're interested to smoke screen. They're not certain yet. So I will answer the objection, whatever that objection might be, but by answering the objection, all I've done is given myself the right to speak more.  Now in some industries, maybe they actually do. So I feel you can, so in some cases, probably not the best one to use better. So let me think about it, all right? Let me think about it means I need to think about it to become more certain. So so as we think about it, I will answer the objection, but I'll never ask for the order afterwards. I answer the objection and then loop back and create more certainty about the product, about myself, the salesperson, even I'm trustworthy, dependable, you want me in your life for the long term, the company that stands behind, in this case, the insurance product, and then I will ask for the order. So an objection only gives me the right to speak more, but the answer to the objection, the rebuttal gives me the right to speak more. It's when I say after that, that's gonna get the job done. That's good, that's really good. I wanna transition now to one of things that I'm always studying and wanting to learn from successful people, and I know agents that are part of our conference are the exact same way, is the daily habits, the routine of those successful people, what are some of your daily habits or routine or that you recommend for others? When it comes to selling, to me, I never would sell, I'm gonna go out and sell for an hour. I'm gonna dial up over 30 minutes. It doesn't work. You need to have blocks of time dedicated to do. This is the biggest thing. Number one is that if I'm gonna go out there and I'm gonna cold call, I'm doing it for two or three hours, block of time. I'm not gonna do it for 20 minutes. You only got three, 20 minutes to make a few cold calls. If I'm gonna go out to knock on doors, I'm going out for six hours, whatever that amount of time that I set at time. Number two, I don't ever, here's a big one. I don't ever take good days and use that as an opportunity to stop early. Wow, I made two sales today, done. No, if I made two sales and I'm hot, I'm going for six sales. In other words, I set time frames. I'm gonna knock on doors till X time. Well, I'm gonna make calls until X time and I am literally going to make every single call till that clock hits. I don't care how bad I'm doing, how negative people are towards me, or how awesome I'm doing. I am unabated going through that time period. And third, with every single call, every single pitch, every single knock on door, whichever way you're doing it, right? Every call I'm as excited as my first call. See, this is the problem a lot of sales people have in terms of that intergame, is what happens is throughout the day, you're saying the same thing over and over and over again. So you almost start feeling silly about that level of enthusiasm and excitement. So when you go into a difficult sales room, it's like, there's gonna be Dahlia, how you doing, Mr. Jones. And yet in the morning, in the first pitch day, you're like, hey, what are you doing? They're really upbeat. What you don't realize is that this person, let me call it at that moment, they're hearing it for the first time. Every pitch has gotta be like your first pitch. So I've learned, I've gotten to this habit over the years of triggering this positive and powered state in the beginning of every sales call. So I treat every sales call like it's my first sales call. Those are three examples of habits I have when I'm selling. And also I do massive preparation. I would never sell something without knowing what I have to say before I'm going to say it. I script out everything before it. I know my language patterns, the logical cases I'm making, how I'm gonna make the emotional case. I wonder all about my product, the product knowledge, is it necessary, all the benefits, the features that are associated with those benefits. I'm gonna have comparisons and metaphors and examples to use. I'm gonna have all of that stuff memorized up here and in front of me, I'm on the phone.  But the point is, is I prepare myself. I don't wing it. That's crucial. That's really good, yeah. And you embodied that. Whether you're selling coolers on the beach or meat out of a freezer or stocks, all those things you said, you embodied. You just mentioned perfectly in line with the theme for this virtual conference, which is if you don't quit, you can't fail. And a lot of agents out there. I think that a lot of people really don't understand what rejection really means in terms of the very simple way of looking at it.  They're rejecting blah blah blah. And we've all read that in books. That doesn't really go very far with most people. They still feel terrible about it. They still feel like they still feel futile. It's an exercise of futility. The media better way of looking at this, okay? And that is keeping track of exactly how many co-calls you make in a day, how many presentations you make in a day and how many of those openly lead to closures. Once you know those numbers, let's say you know you gotta make 100 dials or knock on 100 doors to get one sale. And that sale's been making $5,000. And I'm just completely making up numbers here, right? Those numbers could be anything, right? So that means that I make $5,000, right? Over 100 door knocks. That means I'm making $20 for every time I knock on a door, not $5,000 for one close. So I don't look at it like I make $5,000 every time I close a sale. I make 20 bucks every time I knock on the door. That means the no's are as good as the yeses. Someone says, haven't I say, I'm like, that's $20. So when they say, I don't close the sale, I make 20 bucks. Every cost 20 bucks, 20 bucks, 20 bucks, 20 bucks. Rather than saying I'm making nothing and I only make money when I close, it's not true because it's just simply a numbers game. Once you know your numbers and you really keep tracking, you realize, hey, if I close, knock on 100s, I know I'm gonna eventually close a sale and might take me to the 98, knock, or call, might be the 50, might be 300 and I'll close three at once, but those averages work. So once you do that, you're sort of attributing a dollar value to the people who don't buy from you. And that's a really, really empowering way to look at things. You just heard it from the wolf himself. If you don't quit, you can't fail. Only 8% of insurance agents succeed in their first three years. What's your thoughts on that? What does 8% mean to you and how can the 92% become part of the eight? The 8% means you're not being trained correctly or onboarded correctly. Listen, there's no doubt. I wear two hats. I recruit for companies and I help salespeople get jobs, right? So there's no doubt that if I give, if I test people, you have people with higher aptitudes or lower aptitudes. What I will tell you is that the great equalizer or all this is the straight line system. I can teach someone the straight line system was a very low sales IQ and scores very poorly on a test. And then I'll repest them and they're actually will score the exact opposite. It will dramatically raise their competencies and change their beliefs because those two, what very few people don't get is that your psychology and your skill sets, they play into each other. They're very much interrelated because when we think we're great at things, we actually work harder at them. We enjoy them more. For example, it's one thing to try to motivate people saying you're great, you're capable of greatness, you're gonna achieve, just work hard like the most motivational speakers is they just motivate, they focus on the inner game of success.  So what happens is, like when I had all these kids that come to me and they were never successful for them, they had made a lot of money. But then they say, wait a second, I'm looking at all kids who are just like me all making over a million dollars a year because they've learned the system, they've learned the straight line. So they call the straight line system the great equalizer. It equalized you and people were better educated, had more natural ability, but by learning the system of influence and persuasion, it equalized you. So if you're in that 92%, you don't have to be sales, there's a learnable skill. It takes work, dedication and mindset, but once you possess the skill, guess what happens? You start saying, wait a second. So my past results don't necessarily have to equal my future results. I didn't notice. You know, when you learn this skill, it's powerful. It's, and you know you sound better. And people will walk saying, wow, you sound really good. And you start to gain that self-confidence and it feeds on itself and it feeds on itself and actually changes your own belief systems about selling, about persuasion and about your ability to succeed in that landscape. So it's a huge plus.  The rest of it is gonna become really easy once you do that. In fact, I'm giving it, and by the way, because of the Corona, I normally don't do this, but I'm giving everybody a free training here. So on the score, I'm giving you guys a free module. I have a very high level, robust corporate training program. So everyone here, this is free. And it's not sort of free. We have to enter your credit card free.  It's my gift to you. There's no catches. Enter your credit card. I hope you forget about canceling. No, it's not that. It's just free. So if you go to my website, JordanBeltwork.com slash 8% nation, you can get this training for free. It's powerful and it's life changing. Wow. Thank you for doing that buddy. That's huge. That means a lot, man. One last question for you. What's your, I'm big on goals. I write down my goals every day. What's JB's goal, man? What's your goal now? What's your in-game? What's your big goal? My goal is to really build the largest recruiting agency in the world right now. And I believe that there is gonna be such massive, I'm sorry to say that I believe there's gonna be massive unemployment that's gonna stay for a while. I don't think it's gonna be this wild instant D-shaped recovery. I believe one day we will achieve our past glory here but I think there's gonna be some pain. The beauty is, is that sales people who know the straight line system will always be able to get a job and always make a lot of money. Yes, everyone has lean times as well. There are no guarantees in life. But this is a skill set. It's a required skill and just to understand the straight line was invented for distance selling. It specializes in distance selling, meaning over the phone or like this it was invented as a phone based, we didn't see someone. And by the way, even though we can see each other it's not the same as in person where there's a certain energy exchange with body language. It's still not there yet with the technology. It's just not, okay? So you need to learn how to use your tonality, how to use certain facial expressions even on a Zoom call like this but the straight line is like built for distance persuasion. So right now more than ever it's a system that is like, I look at it as a more quiet force. When you choose to take it, that's your choice. But until you do, you're gonna be feeling a lot of pain in this new economy that's gonna emerge unless of course you're one of those lucky, natural bull closers who hasn't all figured out and even you could benefit because it'll show you why you do what you do so well and make you that your best day is every day. Bottom line. Unbelievable, buddy. I know we're running out of time. Thank you so much for your time. Thanks for being on the virtual 8% nation. Super excited to meet you at 8% Vegas, buddy. Thank you so much. Put the link up so everyone can see the link here. So JordanBeltdorf.com is less 8% nation. We will put it up, buddy. Thank you so much. Appreciate your time so much. Susan. Thank you. If you watched this video and you wanna learn how to take a live call and transfer it from an opener to a closer, that video's for you. Click on it and I'll see you there. Again, I'm not sure what time you're watching this video, right? Intro, expert, control, qualify, transfer. This is how to effectively transfer a live call from an opener to a closer.