The Clock Speed Manifesto: Why Clock Speed is the Primary Driver of Profitability

I'm here today to evangelize speed as an approach to the optimization of the profitability of your businesses. You might think, well, doesn't everyone do that? And my message to you today is, no, they don't, and they should. Today is about why you should, why you aren't currently, and how to make the transition from not optimizing for speed to optimizing for speed.

Clock speed is the rate at which your business operates. My claim is that generally speaking, a business that runs faster is a more profitable business. Clock speed is the primary driver of profitability. Because it's a driver, clock speed is a leading indicator. If the rest of your business has good fundamentals, you should be focusing primarily on the clock speed of your organization. One of the great things about clock speed is it's easy to focus on. If your business is non-chaotic, the clock speed of your business is the rate at which one particular resource within your organization completes work. So identifying, measuring, and working to maximize the clock speed of your organization, if your organization has good fundamentals and is well-managed, is remarkably easy to do. And it's a much more rewarding and productive approach to management than the alternative.

A business is a complex system, technically and practically. For those of you who are operators, that's probably an unavoidable conclusion. The thing about complex systems is you can only maximize a single parameter. You can optimize for a whole bunch of things, but the nature of a complex system is you can only maximize one parameter or minimize one parameter. Optimize many, but only maximize or minimize one. Practically speaking, there's only two parameters that you can act to maximize or minimize. One is cost, the other is speed.

So you have a choice. You can minimize costs while maintaining speed within range. For example, you can minimize costs throughout your business while ensuring that your business maintains reasonable on-time delivery performance. The alternative is to maximize speed while maintaining costs within range, controlling costs. Most organizations, most managers, do the former. Their primary approach to maximizing the profitability of the business is to minimize costs while maintaining the speed of the business within range. I'm going to argue you should be doing exactly the opposite. Your primary focus should be improving the clock speed of your organization, which is not to say you should be ignoring costs, but your interest in costs should simply be to maintain them within range.

This is not the traditional approach to business management. But if you look at organizations that have breakout success, organizations that disrupt industries and make their founders and investors wealthy, it's actually not too uncommon to encounter organizations that obviously act to maximize speed rather than minimize cost. We've seen the rise of Dell, Amazon, Tesla, Uber, Nvidia. The reason I picked those is many of you have probably listened to the founders of those organizations being interviewed on CNBC or YouTube. The one thing that's clear whenever you listen to any of those founders speak is they clearly and unapologetically pursue speed. Which is not to say they're not concerned with cost. All of these folks run profitable organizations. But their primary approach to driving growth and profitability is to figure out how to maximize the clock speed of these organizations.

You might argue, why can't I do both at the same time? I've given you the academic answer already. In a complex system, you can only maximize or minimize one parameter. Here's a more practical answer. The dynamics of a modern business mean that if your approach to profit improvement is reducing costs, your initial cost reduction initiatives are likely to result in a commensurate increase in profitability, which probably furnishes you with some confidence. But if you keep reducing costs, all of a sudden you pass an inflection point beyond which you see a sudden decrease in the clock speed of the organization and a corresponding decrease in profitability. So why does that inflection point exist? Where is it exactly, and how do you avoid existing on the right-hand side of that inflection point?

To understand the reason for that inflection point, let's stop for a moment and talk about Formula 1. I wasn't excited about Formula 1 until, like many of you, I watched the Netflix special. One of the things I think we all learned is how fascinating the pit stop is. A typical pit crew in a Formula 1 team consists of 22 people. A typical pit stop is done within about two seconds. The best teams are doing pit stops in 1.7, 1.8, 1.9 seconds. In a 90-minute race with two cars, there are as few as two pit stops over the course of the race.

Consider the pit stop from a workplace productivity perspective. There's two seconds of work, but there's preparatory work prior to the stop and cleanup work after. The beginning to end lead time of a pit stop is about a minute. So a pit crew does as few as two minutes of work over the course of a 90-minute race with 22 team members. We can apply a traditional workplace productivity calculation to arrive at the conclusion that the pit crew is operating at 2.2% efficiency.

Imagine that a team was less profitable than its owner wished, and it employed a young MBA to study how to improve the profitability of the team. Let's assume the pit crew members were hourly labor. It's easy to imagine that an enthusiastic MBA, after a cursory analysis department by department, would focus on the pit crew. It's rare in a modern organization to find this level of inefficiency. But I think it's reasonable to say that even an MBA would resist the temptation to downsize the pit crew. Even an MBA is going to recognize that a reduction in force in the pit crew is going to result in a material increase in the duration of pit stops, which will have a profound negative impact on the team's ability to accrue points, and therefore a disastrous impact on profitability.

But think for one second. If this wasn't a Formula 1 team, if it was a typical organization and an MBA, or even someone who had done some reading on business management practices, were to take a look at a part of the organization and see this kind of efficiency number, are we so sure they wouldn't resist the temptation to order a reduction in force?

The reason the MBA is not going to downsize the pit crew is because it's obvious to everyone that the pit crew members are adding value not just when they're changing the wheels. They're adding value when they're standing at the ready, because it's impossible to predict when the cars are going to pit. If we recognize that, then we have to recognize that the pit crew is actually operating at 100% efficiency. That's a material difference. 2.2% on the one hand, 100% on the other.

The pit crew example gives us an interesting insight into capacity. Capacity is important because if we're cutting costs, most costs in a modern organization are operating costs as opposed to raw material costs. Operating costs are the costs of capacity. When we pay our operating costs, that's the money we spend in order to purchase capacity.

There are three types of capacity. First, critical capacity. An example is the Formula 1 pit crew rushing out and changing the wheels. Second, protective capacity. An example is the crew members standing at the ready. Third, excess capacity. This is capacity the organization doesn't need, and which the MBA would be justified in jettisoning, and which, if jettisoned, will result in an immediate and commensurate increase in profitability.

The problem is we know academically there's a boundary between excess capacity and protective capacity. But most of us don't know where it is. If we consider the organization department by department, without a comprehensive understanding of the dynamics of the organization as a whole, it is impossible to know where that boundary is. Which means if our primary approach to improving profitability is to cut cost, and we deploy that approach department by department, we don't know where the boundary is, and what we're likely to do is to trim protective capacity.

The boundary between excess and protective capacity is that inflection point on the chart. Once we start to trim protective capacity, the organization initially becomes fragile. Ultimately, it descends into a chaotic state. In my experience, most organizations I encounter live just to the right of that inflection point. They operate perpetually in a state of low-level simmering chaos. They never descend into a fully chaotic state, but they skate along the edge of chaos.

I want to introduce you to what I call the doom loop. As we trim protective capacity, the organization becomes fragile, and some random variation in the universe results in an unexpected slowdown somewhere in our organization. Because the organization's fragile, it doesn't recover, and we end up with a bottleneck that roams unpredictably from department to department. I've heard executives say many times, I have bottlenecks everywhere in my organization, which is probably not true. They don't have bottlenecks everywhere. They have one bottleneck. A complex system is unlikely to have multiple bottlenecks. The problem is they don't know where it's going to be on any given day. So they drive to work in a state of tension, knowing that when they open the door, they're going to find a problem somewhere. They just don't know exactly where.

The roaming bottleneck results in management making shoot-from-the-hip decisions. If your business is unstable, you find yourself in a situation where you simultaneously need to add resources to get work done and cut capacity to maintain profitability. What ends up developing in organizations is a black market for tasks. When the organization becomes chaotic, the only way to get work completed and shipped to customers is to expedite. You end up with a few people who have the authority to expedite, and those people end up using their authority to the benefit of their customers or their departments. This results in an absence of truth-telling in the organization, which is not good for morale. Eventually, you end up with morale problems leading to key individuals quitting to go work for a competitor. None of this is good for protective capacity.

So how do you escape the doom loop and return your focus to growing the organization? There's a three-step process. First, you have to eliminate chaos. You cannot manage a business in a chaotic state. A chaotic system is unmanageable. Whenever you observe that a business is performing chaotically, your first priority should be to shut down the chaos, not to figure out how to manage it better. You need to restore it to an orderly state urgently.

Second, we need to reconceptualize the organization. One of the reasons why managers make bad decisions is they have a bad mental model of the organization. We all knew the MBA was not going to downsize the pit crew because the MBA had a reasonably accurate mental model of the dynamics of a Formula 1 team. You all have an accurate mental model of that. But most of your managers have an inaccurate model of your organization, and we've actually contributed to the development of that inaccurate mental model.

Third, make speed the priority rather than cost, because prioritizing cost is what got us into this mess in the first place.

How do you eliminate chaos? An organization becomes chaotic when it intakes work at a faster rate than it completes it. So the key to escaping the chaotic state is simple. We choke the release of work into the organization. If we were talking about a chaotic shop floor, choking the release is easy. We put a padlock on the cage where the raw materials are stored. We wait until the existing work in progress flushes its way out of the system, and we see the rate of manufacture start to speed up again.

But we're not talking about a shop floor. We're talking about the entire organization. There isn't a single choke point. We have work of all types entering the organization. We have pre-order work, sales inquiries, requests for quotes. We have orders themselves, and then we have post-order, even post-delivery work. Some of these streams we can regulate. Some, like existing customers complaining, we can't down-regulate. Even if it were possible to choke the intake of work at its source, we'd need to be able to calculate the capacity of the organization. But you can't calculate the capacity of your organization because it's chaotic. We also can't calculate it because different mixes of work result in different capacities.

So how do you choke the release of work? The answer is a bottom-up approach. If you go into a chaotic organization, you will find individual contributors with an unhealthily long task list. Engineers who go home with three or four weeks worth of work on their to-do list. This is not healthy. Individual contributors are most productive when they start each day with a day's worth of work, with no visibility of future work, and who get allocated a new piece of work when they complete each work package. That is the environment most knowledge workers prefer to operate in.

If we take back from every individual contributor their list of tasks, we can choke the release of tasks to individuals. If we then dictate that promises can only be made inside and outside the organization based upon available capacity, we will naturally down-regulate the intake of work.

But doing this requires that you remedy a problem many of you don't know you have. You have in your organization individual contributors who are not nested underneath line managers. If you have a production environment, it's unlikely you have unsupervised individual contributors, because that would be idiotic. But in knowledge work environments, it's more common than not that knowledge workers are unsupervised. If you ask an executive why, they'll tell you, they're knowledge workers, they're intelligent, they don't need to operate in a command and control environment. This is not why we have line managers. The reason we have line managers is that line managers enable individual contributors to focus on their work. If you take away line management, you end up with individual contributors who are distracted with all the interstitial work that stops them from doing actual work.

The first thing you have to do is make sure every single individual contributor answers to a supervisor, even if that means aggregating teams. Identify teams that have similar modus operandi. We will often co-locate customer service people with procurement people, so that we can give line managers bigger teams to supervise. Once every individual contributor is nested under a line manager, we issue an instruction to line managers. They need to take back every task from every individual contributor, document those tasks, and then start allocating work one task at a time, ensuring there is never a case where an individual contributor has more than three tasks. It's only three because you have to allow for some external blockages.

We're going to adopt what's called a focus and finish approach to work. Line managers should insist that individual contributors focus on each task until it's complete. If there's an externality that prevents them from continuing, they can task switch, but we're going to ban line managers from encouraging individual contributors to task switch.

Once we've rate limited the work, the next pronouncement is that anybody who wants work must get a lead time estimate from a line manager. In a high throughput environment like customer service, publish a default lead time for tasks of different types, and update that lead time periodically. In a complex environment like an engineering team or a fabrication environment, you need a formal approach to scheduling. If somebody wants to plug a piece of work into engineering, they need to go and talk to the scheduler and get a lead time estimate. You need to make it illegal for anyone within the organization to make a promise to a customer unless that promise is informed by a conversation with a scheduler or by looking up the current lead time estimate.

If you follow those rules, you will choke the release of work into the organization, and you will make it impossible for the organization to intake work at a faster rate than it can complete it. As far as I know, that's the only way to rapidly return an organization to an orderly state. You can't do it by adding more capacity because it takes too long for new capacity to come online. This state of low-level simmering chaos is like a cancer that destroys the organization from within.

As a result of choking the release of work, we're shutting down the black market in tasks. But sometimes you can restore the organization to an orderly state and the black market continues to operate. Engineering still provides unrealistic lead times because there's still scar tissue from when they promised realistic lead times and were made to suffer for it. So after you return the organization to an orderly state, you need to find the bad habits that result in the black market continuing to operate, and shut that down. State clearly to everyone that you are simply restoring honesty. The black market in tasks is a fancy way to refer to everyone within the organization telling lies to one another and probably to customers as well. You've seen the kind of behaviors that salespeople engage in when they work for a chaotic organization. They hand their business card to a prospect and say, my cell phone number's on the bottom, you call me if you need something, I'll protect you from the organization. It's not healthy.

Step two is to reconceptualize the organization. You could say, well, our organizations are a lot more complex than a Formula 1 team. But it turns out they're not. If it's chaotic, it is. But if you restore an organization to an orderly state, what you will discover is every organization assumes exactly the same configuration of resources. Every organization in an orderly state has one resource that is consistently either fully loaded or heavily loaded, and every resource other than that one critical resource has idle time. Idle time is what we are, from this point forward, going to refer to as protective capacity.

Organizations exist in one of two states, a chaotic state characterized by a roving bottleneck, or a non-chaotic state characterized by one heavily loaded resource and other resources that have protective capacity. If you're an executive and you go into the customer service team three or four times a day, you will notice that on each visit, there are a handful of operators who are not on the telephone or who are not in the ERP entering orders, and you will have to prevent yourself from the shoot-from-the-hip conclusion that the customer service team is over-resourced.

Some of you have guessed what I'm talking about. If you've ever read The Goal, that book 40 years ago written by Eli Goldratt, he introduced the world to what he called the theory of constraints. This heavily loaded resource is what he referred to as the constraint. He called it the constraint because it's the rate limiter for the organization.

If we were running an airline, which of the thousands of resources is the constraint? The plane. Every other resource within the airline exists to keep those planes in the air. Southwest gave us a graphic example a year or two ago of what happens when the constraint shifts. They had an outage in their crew scheduling software. It took them a couple of days to bring it back online. It caused chaos all throughout the US, and it cost Southwest somewhere between 800 and 900 million dollars. If you were Southwest, it would make sense to ensure that at all times you have protective capacity in every resource throughout the airline to protect your fleet of aircraft. Baggage handling, reservations, freight services, crew scheduling, every single resource needs to have protective capacity, because if any resource runs out of capacity other than the constraint, the inevitable outcome is the constraint goes down.

The constraint is the one resource that is either fully activated or heavily loaded, and that one resource should be the resource that results in the organization being optimally profitable. An airline makes more money when its fleet of aircraft is fully loaded than when its crew scheduling software is fully loaded.

When we restore an organization from a chaotic to an orderly state, every organization, even the most complex, has this fascinatingly simple set of dynamics. One resource fully activated, every other resource has protective capacity. You need to restore your business to an orderly state, select the resource that should be loaded to the maximum extent possible, and build protective capacity in every other resource to ensure that resource, your tree trimmers, your fleet of aircraft, your team of field engineers, whatever it is, is consistently fully loaded.

This reconceptualization of the organization needs to be taught to every single person in your organization. When someone joins, you need to help them understand the dynamics.

Management has a habit of taking accounting principles that make sense when we're analyzing the past and applying them to future management decisions. There's a body of knowledge called cost accounting. What cost accountants do is take operating expenses and allocate them to units within our organizations, which allows us to perform profit calculations on a unitary basis. Cost allocation makes perfect sense if we're considering the past, because the past is not dynamic. Cost allocation-based decisions do not make sense if we're considering the future. Cost accounting leads managers to assume that if they maximize the efficiency of each department, they're maximizing the profitability of the organization, and nothing, as the Formula 1 example demonstrates, could be further from the truth. Local optimization is a cancer that needs to be removed from the organization.

Once we've restored the organization to an orderly state, and once we've furnished our team members with a healthy understanding of the dynamics, now we can make speed the priority rather than cost.

We can derive a simple framework for management decisions. There are two metrics. Throughput per constraint unit. Throughput means pure contribution margin, revenue minus raw material cost, no direct labor. My preference is to use the word throughput. Throughput divided by constraint unit is the primary, I could probably say the sole, measure of productivity of the organization as a whole. Throughput per constraint unit is directly proportional to the profitability of the organization. When we take throughput, the total amount of contribution margin generated by a job, and divide it by constraint units, the amount of capacity consumed in processing that job, we have calculated the profit contribution made by that job during the period under consideration.

We're only performing that calculation in one place, the constraint. If you think of an airline, we maximize profitability when we maximize throughput per flight leg. That understanding led to the rise of dynamic pricing in airlines. Before the 80s, everyone paid the same price for a ticket. Today, you and I could be on the same flight, and you might have paid twice what I paid because I'm prepared to stay away a Saturday night and you're not.

Throughput per constraint unit is the most important metric. We need to teach everyone in the organization to make decisions based on this calculus. If someone in the organization is not directly impacting the constraint, their job becomes much easier. Their instruction is to process their work packets as rapidly as possible.

This understanding furnishes us with two metrics to measure the performance of every department. If you are capable of positively influencing throughput per constraint unit, you should do so. If not, your metric is on-time task completion. On-time task completion is an analog for on-time delivery performance in a production environment. We can't measure velocity in an absolute sense because in most environments we're working on a mix of tasks. So we come up with a default lead time for tasks of different types, measure the actual completion time for every task, and calculate the percentage of tasks completed on or before schedule.

Two metrics to manage the entire organization: throughput per constraint unit for anything that directly impacts the constraint, and on-time task completion for any resource that doesn't. This leads to an incredibly simple system of measurements throughout the organization. If you have dashboards in every room, those dashboards should display either throughput per constraint unit or on-time task completion. The manager's job just got easier.

I want to finish by talking about profit. Most of you have an intuitive understanding of what profit is, but if I asked you to define it, I'm concerned I might hear contradictory definitions. Here's a definition I'm going to urge you to adopt and insist all of your managers adopt. Define profit as cash that's expelled from the business that can be used by its owners for other purposes. It's cash, and it's been expelled from the business. It's not still captured within the business.

This definition prevents you from using terms like gross profit. Gross profit is not profit, because it hasn't been expelled from the business and isn't available to the owners to invest in boats or fast cars. I would encourage you to insist that all of your management team uses the term contribution margin or throughput rather than gross profit. It also means we can't use nonsense terminology like the profitability of a project or the profitability of a customer. How often have you heard someone say, we don't want to do these transactions, they're not profitable? Or Freddy is not a profitable customer, or this was not a profitable project, or this is not a profitable division? In your business, customers do not generate profit. Transactions don't generate profit. Projects don't generate profit. Divisions do not generate profit. Profit is an attribute of the organization as a whole. Only your business generates profit, and you need to be very careful with your usage of the word profit because it's important that everyone in your organization, particularly your management team, understands what profit is, given that it's the job of all of them to contribute toward generating it.

An interesting thing about profit: if you're considering the past, profit is arithmetic. If you're considering the future, profit is calculus. If you're looking at last year's books, profit is revenue minus costs. But if you're making a decision about the future, every decision about the future is based on a prediction, and the profit calculus we use to calculate profit historically has extremely poor predictive power. If we're considering the future, your future profit is not revenue minus cost. Because the organization is dynamic, in the future, profit is the difference between two rates: the rate at which your organization generates contribution margin and the rate at which it accrues operating expenses. When we're considering the future, profit is calculus.

This throughput per constraint unit metric captures the dynamics of the organization. The throughput of your organization, the rate at which your organization produces value, is a function of the productivity of the constraint. When we divide throughput by constraint units, it's actually a very simple approach to doing the calculus that's required to make accurate predictions about future profitability.

In closing, why should you care about clock speed? Because the clock speed of your organization determines the profitability of your organization, which means that business, whether we recognize it or not, is not a game of cost, it's a game of speed, and we all need to take speed more seriously.

Q&A

Question: I would agree that just looking at gross profit or the dollars is not the answer. I'm curious if an easy proxy in assessing deals would be operating margin percentage, looking at something like EBITDA, operating profit from operations less CapEx, any one of those.

I'm not an accountant, so I'm not going to give you advice on that. But one piece of advice: I was thinking of investing with a buddy of mine in Australia in a dumpster business in Texas. It's amazing how complex a simple business like a dumpster rental business is. It wasn't until I sat down with Excel and started creating a model that I realized the dynamics are quite complex. This dumpster business has a growth engine that needs to run independent from the revenue engine. The growth engine runs at a loss, which is not uncommon in subscription-type businesses. The business acquires customers at a loss by chasing projects. When it wins a project, it loses money. But the benefit is it develops relationships with general contractors, and a percentage turn into continuity business.

It wasn't until we modeled this in Excel and went back to the owner and asked, how much do you spend on cost of sale to sell a project? If you sell a single project, what's the probability of that turning into a continuing relationship? If you onboard a general contractor, what does the month one spend look like, what does the year two spend look like? It wasn't until we had this model of the fairly complex dynamics that it was possible to draw any conclusions. The conclusion was the business had really ordinary economics, and we weren't interested in investing.

My advice is, be careful about relying on single numbers, because sometimes a single number hides the dynamics of the business. You need to understand the dynamics of the enterprise. What makes this enterprise tick?

Follow-up: If you take operating profit margin, something that takes into account even more than EBITDA, and that meets a threshold, and then look at cash conversion cycle, which measures throughput, before you even have those conversations with the business owner, you already have an idea of whether this is really profitable.

You can determine if the business has good economics, which is to say, if you consider the business as a black box, capital captured inside, cost going in, contribution margin coming out, you can develop an understanding of the economics. But to go deeper, you need to take the business out of the box and understand the dynamics. I'm here to talk to you about putting a business into a position where you can understand its dynamics. There are other people who can have conversations with you about doing formal analysis.

Question: I'm struggling with the idea of a constraint in my business. Using airlines as a shared analogy, is the production asset the constraint that needs protective capacity, or is it the sales engine that needs protective capacity?

It depends. If you have a huge amount of investors' capital sunk into a production facility, it probably makes sense to run that facility two or three shifts a day. To consistently do that, you need a full order book. The job of sales is to maintain that order book. The production facility is the constraint. To keep it fully activated, we need a buffer of work upstream. Your sales team's marching orders should be to ensure the order book is maintained at 15 days worth of orders at all times. You want to chart that in your sales department so you can see where it is in that range. What you don't want is holes in your production schedule.

At some point, if you have the ability to increase the order book, you'd have to think about adding another shift or another machine. But you're going to have holes in capacity in that second facility unless you're able to double the order book immediately. It's the constraint that you want to keep fully activated.

Question: We're an MSP. What I try to interpret: we need to measure every ticket and the time it takes, set the default variable for what that ticket would take to get done, and measure each team member's speed in accomplishing tickets. Then the team lead would make sure those measurements are being met by the person doing the ticket.

Correct. There are two things you can do as an MSP. One is minimize the turn time on tickets. The other is preemptive maintenance to minimize the number of inbound tickets. If you have a small team dialing into your customers and doing preemptive maintenance, that reduces the likelihood of inbound tickets.

Follow-up: We get distracted a lot with phone calls and people walking in to get IT help, and emails coming in.

This is one of the problems with MSPs. In an ideal world, you'd have two separate teams. One doing preemptive maintenance and another handling tickets. If you have the same team doing both, you'll descend into a state where all they do is fix tickets. I would much rather have a bigger team doing preemptive so you could have a smaller team handling tickets.

Here's an example of an organization we worked with that did this. They're now a publicly listed company in Australia, a painting contractor called Programmed. They started as a normal painting contractor, but they recognized that left to their own devices, major companies like Westfield order painting at the last minute, after the rainy season. Everyone orders painting at the last minute, so you end up with a boom and bust demand profile. What they decided to sell 20 years ago was painting as a service. They went to Westfield and said, you pay us a fixed quarterly fee, we will keep your buildings looking pretty. In Australia, Programmed has Australia's largest painting crew, but they also have one of Australia's largest power washing and cleaning crews. If you do a good job of painting, overspec the painting, you don't have to go back and paint as frequently because you can power wash more frequently. The utilization of Programmed painters is significantly higher than a normal commercial painter. A lot of commercial painters surrender and go to Programmed and say, we want to work with you because there's no way we can earn as much money working by ourselves. That's an example of an organization that understands its dynamics and works hard to maximize throughput per constraint unit.

Follow-up: So we should pay to have another person or two to create protective time for the guys working tickets. Separate the teams so they are protected.

It's not that you're not worried about the COGs. By doing preemptive work, that enables you to provide the same response times with a smaller team. So that results in a net reduction in cost. The total number of technicians you need to maintain the same level of service goes down. This is no different from the advice you would offer a customer. If you were having a drink with a buddy and he said, we have all these problems with technology, we have outages every 10 minutes, you'd probably say, you should have some people in IT doing preemptive maintenance so you don't have all these breakdowns. It would be obvious in the context of his business. It should be obvious in the context of your business too.

Ode to Speed, you can get it on Amazon. It's a mini book. It takes you 20 minutes to read. I also wrote The Machine. Both are on Amazon. They have good reviews.