The Formula-1 Pit Stop: Lean counter-counter-intuition

What does F1 racing and Lean Product Development have in common? Not much at the surface… but if you, as I do, see everything as systems then you can’t help but notice some interesting things. In this case I found an apparent counter-example to Lean that is Lean despite going against the grain of traditional Lean Thinking. Hmmm… we’re into double-negatives here but stay with me.

The racing analogy is interesting to me not because “Lean=Speed” but because someone questioned the “obvious right way” and came up with a counter-intuitive better solution.

I am always amazed every time I catch even a glimpse of Formula-1 racing. The cars fly around the track at up to 300 miles per hour, pull 1.45g during acceleration and 4g when braking. High speeds, tight turns and frequent acceleration and braking wears hard on car and driver, but even more so on the tires which aren’t even engineered to last a whole race.

An F1 tyre these days is designed to only last for about 120 kilometers on average (it’s a weight vs. durability tradeoff), but most F1 races are at least 305 kilometers long. That means you need to change tires 2 or 3 times in a race that is won or lost by fractions of a second.

I’m fascinated by this, of course, because the pit stop is the biggest impediment to continuous flow around the track. If you could make one less pit stop than your competitor you would be several seconds ahead, turning 10th place into victory. For a long time that was the strategy: go easy around the curves so as to conserve tires and fuel. A lower average speed would win the race as long as you could avoid making too many pit stops. So far it sounds Lean, right? Slow down and you’ll finish the race faster. No surprise there: Lean solutions are usually counter-intuitive.

Twisting and Turning

Well, every good story has a twist and our little F1-Lean analogy is no different.

In the mid-1980s someone took a step back and looked at the whole end-to-end system and realized that the “economy” of racing could be improved. Start the race with only half a tank of fuel, and the car would be much lighter and go faster. Stop worrying about conserving tires and instead push the car to the limits on the track. The penalty for this strategy is an added number of pit stops.

Not a problem – you just need to minimize the time spent in each pit stop.

It’s a tradeoff curve, as always. If you can continuously reduce the amount of time needed to refuel and swap tires, then at some point down the curve  the wear-and-tear vs. pit stop balance will shift.

Now it gets interesting. Because we now have two different models of “good” racing strategy, we have to choose – but how? We have to take a systems view, and make the decisions based on the objective merits of each strategy, not by intuition or personal preference.

Yes but we’re talking about Product Development, right?

You see analogies in Product Development all the time. Whenever there is a bottle-neck in our process we have to decide to either fix/improve the bottle-neck, or try to avoid it. Not all bottle-necks are solvable or even visible. Some are disguised as “the way we always do things here”. Most companies have settled on a particular pattern of which bottle-necks (departments/phases) are reasonable (acceptable as the cost of doing business) and which ones aren’t. Companies that structure the development flow through phases and gates accept the overhead associated with functional departments as “not perfect but the best way to do things”.

Lean Thinkers challenge this view all the time: figure out where the the flow stops and then improve it. Usually it comes down to finding local optimizations and then reducing or eliminating tasks in the name of overall flow. For example, eliminating pit stops so that the race can flow un-interrupted.

And sometimes Lean Thinkers have to challenge themselves, to avoid getting stuck in the “best” Lean solution.

So where did Formula-1 end up?

Have a look at this Ferrari pit stop from 2013. Mid-race refueling is no longer allowed in F1, so now it’s all about how quickly you can get 4 new tires on the car. You can feel the anticipation as you watch the pit crew waiting for the car to arrive.

That pit stop took 2.1 seconds. It’s a huge improvement from the minute-plus pit stops of the early days of F1 in the 1950s. Pit crews spend a lot of time and money to squeeze out every millisecond they can from their process. You can almost visualize a value stream map on the garage wall and the team swarming to find and reduce the next bit of waste from the process.

Is it a fair analogy?

But, many will say, that’s not a fair analogy. Obviously they have a lot of specialized equipment and a huge crew of specialists standing by. This is high-stakes racing and has nothing to do with Lean or product development.

Well that’s the whole point behind this blog post. It’s a classic example of how Lean thinking differs from mass-production thinking. It just manifests itself in a different environment. Speed (and safety) matters in F1, and speed (and safety) matters in Lean.

Systems of systems: Lean Fractals

There is a very direct and obvious application of Lean Thinking and Value Streams to what happens in the pit. If you have seen a Value Stream Map, you can easily understand how that helps weed out waste and inefficiencies in the process flow of safely and quickly changing the tires.

But there is another higher-level system at play, which is includes both the pit stop and the track. This system-of-systems has a different kind of flow economy, working off a different set of aggregated information.

If we ignore the system-of-system effect and blindly apply Lean tools it can lead you astray. Pre-1980s racing solved for Lean flow based on how the costs  were incurred back then, i.e. relatively slow pit stops. Slow down around the track and finish in first place. However the cost of any activity changes over time, and the technology and capability of the pit crew improved such that the basic assumptions behind “the best way to race” had to change.

In this case they had to question some long-held beliefs assumptions in order to get to a new level of performance. Similarly we find the biggest improvements hiding in plain sight when we look at our overall product development system and question our traditional way of working. Our world is full of systems-of-systems.

I draw two lessons from the F1-Lean analogy:

Question the Status Quo

The obvious approach isn’t always right, and you won’t see it until you look at the whole end-to-end system. It is counter-intuitive that adding one more time-consuming pit stop to your race will speed things up overall… but it does – up to a point.

Even if you settle on a “best” Lean solution, this might also be a local optimum… keep looking and keep questioning. The journey through solution space is not always a linear one.

Invest in non-mainstream efforts

In order to lean out the value stream you may have to invest and focus on non-mainstream efforts such as tooling and supporting activities. This is the stuff of overhead. It’s hard to justify increasing the overhead cost when the normal pressure is to reduce expenses. But in a Lean system the right overhead isn’t a liability – it’s what enables the mainstream to go fast. The F1 teams had to shift investment away from car and engine design and onto the less-glorious pit crew tools and processes.

The difference is in the kind of overhead: instead of traditional overhead which is needed to manage the waste generated by stitching together the work of separate departments, Lean “overhead” is there to make the value stream flow faster at higher quality.

Yes it’s a fair analogy

To return to the point above, yes the analogy is totally fair. You can usually make your product development progress much faster if you invest in ancillary processes and tools with an eye towards end-to-end Flow. The Ferrari team in the video clip shows 21 crew members, all working franticly for less than 3 seconds. It takes 3 people per tire to do the job. Wasteful resource utilization? Not if time matters and your objective is to get the car through the pit stop quickly. Sure, we obviously can’t allocate 21-person support teams for all tasks, but the idea is to figure out what it takes to achieve the best end-to-end flow and then invest accordingly.

When I first started developing software we had bi-weekly load builds because it was such a difficult thing to get a clean build with 40 engineers all submitting several weeks of code changes, and build servers were very expensive. We avoided load build “pit stops” until they were absolutely needed.

Gradually the situation changed, and we now have efficient continuous build and test environments and the ability to submit code changes daily. The “economy” of our pit stop changed. It was initially not easy convincing management to invest in extra build servers, tools and staff – but eventually we met the point on the tradeoff-curve where investing in ancillary things like load builds made more and more sense. Now every serious software group has a DevOps setup.

Local vs. Global Optimization

There is a balance between local and global optimizations, and the balance can
shift over time. You can’t even grasp the concept of that balance unless you look at the end-to-end system flow. Chances are that you are only looking at improvements within your own department. If you are, then you might routinely leave improvements of an order of magnitude or more on the table. Look one level up, at the system-of-systems, and see what you can find.

Domain Dependence

Occasionally I come across a golden nugget that puts things in perspective. Usually it’s a simple and beautiful idea which elicits the “duh yes of course” gut response when it’s first explained but then continues to reverberate and come back into focus again and again. Ideas such as this one articulated by Nicholas Nassim Taleb.

“Some people can understand an idea in one domain, say, medicine, and fail to recognize it in another, say, socioeconomic life. Or they get it in the classroom, but not in the more complicated texture of the street. Humans somehow fail to recognize situations outside the contexts in which they usually learn about them.” – N. N. Taleb

He refers to this as the domain dependence of our mind. He puts forth a few examples, including that of the business man who pays the hotel porter to carry his luggage upstairs, then heads for the gym to lift weights – mimicking the natural action of lifting a suitcase. Simply put – we put blinders on and fail to recognize familiar patterns in unfamiliar situations.

It explains a lot of the frustration that comes about in process improvements and agile transformations. At least for those of us that like to think and speak in analogies, Taleb’s words ring true. We are simply too accustomed to thinking about things in our familiar ways to see the simple truth staring at us from the other side of the mirror. It gets worse as our expertise deepens. Expert knowledge is deep, and therefore becomes more and more domain-specific. The groove wears deeper and obscures our view of the world. It gets harder and harder to look outside our own domain for solutions to the problems we are working on.

But for innovation that’s exactly where we need to look – outside of our own domain.

We experience the pattern clearly when we discuss Lean/Agile concepts with someone that has a firm waterfall view of the world. Most people can understand and agree with the concepts, but many also have clear convictions that those same ideas simply don’t fit in their area.

There are a couple of mental shifts that have to be made in order to recognize foreign ideas and implement them locally. First you have to take a particular situation and understand the general idea and principle behind it. That takes some abstract thinking abilities which some people are better at than others. Nonetheless you need to extract the general principle at play. Then, that same general idea needs to be applied in a different way in the new domain. The application may look different but the principle behind it is the same.

For example the idea that an apple will fall from the tree to the earth is well-known and accepted in the domain of everyday things; The idea that the earth actually pulls the apple towards the planet’s center until it tears loose from the tree is harder to imagine.

At a different level, we have almost no trouble learning about the gravitational pull of planets. Once we understand the principle of gravity explained using planets as the domain we can start to see the commonality. The only difference between the moon and the apple here is scale – it’s just that you can’t see the similarity unless you shift your viewpoint significantly. Once we look at them both from outer space, it’s a bit easier to visualize the apple as a really tiny moon. Now the apple doesn’t fall down any more. It gets pulled inwards towards earth’s center.

Or for a more obvious example – since you are reading this blog – consider the difficulty of seeing the translation of Lean Manufacturing methods to Product Development. The Software crowd are starting to get it, but the Hardware/FPGA folks? “That won’t work in our special domain!” (BTW to me that’s not a problem at all – it’s an opportunity to be the first HW/FPGA developers to outpace the competition). Check out www.agilesoc.com and @nosnhojn as an example of pioneering work here.

Domain dependence, then, is one hurdle that we repeatedly have to cross. That is especially true for Lean/Agile transformation because the Lean principles (which are fundamental to Agile methodology) are so counter-intuitive to “common” knowledge. Lean/Agile principles are really sensitive to domain-dependence because of that.

But there is a bit of good news: if you can shift the viewpoint and get to the principle behind the practice, then this can be your detour around domain dependence. Talking about general principles without being weighed down by “common knowledge” will open the door. Once you have developed an understanding of how general principles work (like gravity) then it is a bit easier to move forward since rejecting a fundamental truth just because it looks different is, in a word, irrational. Of course calling someone irrational would not be a rational thing to do in most situations, so find another way to make the point. Patience helps; most of the time you just have to wait for the gears to turn and the point will make itself.

So, domain dependence is a real obstacle and it’s usually not recognized as a factor when we gauge resistance to new ideas. Remembering that simply shifting the viewpoint and focusing on the general principles at play is one way to reduce the impact of domain-dependence. Plotting that course is a tough job which falls to you – the change agent.

Curiosity didn’t kill the cat…

..perhaps something else did. I don’t know – I’m a dog person.

I am starting to see a common thread, kind of a tapestry of supporting ingredients that either enables or blocks change. It’s not just with Lean/Agile, but any change effort. Many times the implementation of new ideas don’t get off the ground because they never had chance to take root in the first place. Why?

(can you mix conflicting aviation and farming metaphors? I think I just did)

I think there are at least three fundamental ingredients we overlook when we prepare for change: Imagination, Curiosity and Introspection. These are not Values, but Traits. Values can be taught and even enforced; Traits are cultivated.

(yes, the farming metaphor works better)

Imagination

If we want to effect change, we first have to be able to imagine a world where (1) what we currently do is not good enough any more, and (2) there is a better way.

If you can’t leap that far, then you really don’t have anywhere to go to. It’s that simple. Many folks I have met and worked with over the years have done well and succeeded in their careers doing things a certain way so why change now? It’s hard to imagine that what has been successful in the past isn’t the best way to do business anymore (I’m working the best way I know!).  But change is constant -whether you accept that premise or not- and it is a harsh reality that what made us successful yesterday may be a liability tomorrow.

We have to imagine the new behaviors we want. What do small batches look like in your environment? What would it mean to rely on self-directed work teams? What implications are there from facing risk head-on (as opposed to the traditional avoidance maneuvers)? How would Planning change with a Lean/Agile mindset?

Purpose and motivation come from the question “Why?”. Tools, practices and processes answer the question “How?”. Imagination springs from the “What if?” domain.

Lean ideas are so far away from current popular wisdom, even counter-intuitive, so making the paradigm shift requires a good dose of imagination. In some people it’s innate, in others it needs to be cultivated.

Imagination plays a huge role in overcoming one of our biggest challenges: our difficulty in translating good ideas from one domain to the next. As Nicholas Nassim Taleb remarks, “Humans somehow fail to recognize situations outside the contexts in which they usually learn about them.” Taleb labels this phenomenon domain-dependence.

That is, we easily recognize good ideas in one domain (say Manufacturing) but fail to apply the same ideas in another domain (say Software development). Even years after Mary and Tom Poppendieck provided compelling insights on how to map the principles behind Lean Manufacturing to Software Development we have trouble accepting that the same laws of nature which influence manufacturing apply in knowledge work.

To see something in one place and imagine how it could apply somewhere else is the essence of innovation. You can’t do it without imagination and unfortunately we don’t pay much attention to that particular trait. Chances are you didn’t ask your most recent hire anything to gauge their imagination. You probably focused on skills and experience, right? If you have Imagination and Curiosity -the subject of the next section- you will acquire the right skills and experience. Imagination and Curiosity are the more important success factors.

More on domain-dependence in a later blog post perhaps – this is one of our biggest problems w.r.t. process innovation and progress.

Curiosity

Very well, we want to improve and achieve better results but without a certain level of curiosity your options are limited to variations on familiar themes. You can streamline this or optimize that without stepping too far way from the playbook or without asking too many fundamental questions. Curiosity doesn’t do well within your comfort zone – it needs to break out. New solutions develop when we are curious about how well we actually perform today, and curious about how things work in other places. Curiosity about how things work. Curiosity about why we do things the way we do. Curiosity about why (the ultimate “5-Why”-type-of-why) we are feeling the pain we do in our projects.

The best people I have worked with have all been very curious. Never satisfied that they know everything, but always having this internal unsettling feeling that there is something else that needs to be discovered or questioned, always wondering what’s there at the next level or behind that next door. For Curious People, the questions are more important and exciting than the answers, and every answer triggers ten new questions.

If you are curious, you don’t need management to tell you to use the 5-Why method. You already ask more questions than can be answered. Keep going, and use your Imagination to come up with new ways of working based on the answers you find.

Introspection

This is perhaps the most difficult one. Introspection is the precursor to Reflection. Reflection fuels Humility. Humility is a necessary condition for un-learning, especially as we acquire more experience, success and seniority.

Yes, un-learning. Lean/Agile is a paradigm shift. To make a paradigm shift we usually have to un-learn something we know to be obvious and true to make room for the new paradigm. For example, we have to un-learn the “obvious” application of mass-production scale economy (and thereby the division of labor) to knowledge work and the usefulness of Pert-charts.

Once you are armed with curiosity and imagination, the easy part is to look at the system as a whole and identify where the waste is in the value stream etc. It moves the fault-assignment away from the individual and onto the system, which I totally agree with. But it could also (incorrectly) be a way to move responsibility away from oneself and onto the system.

It can be quite difficult to look inward for an honest assessment. But inwards we must look, because if you are leading change, then your own convictions and sense for what is the right thing to do must also evolve along the way. That is after all the Agile way. Inspecting and adapting at the leadership level requires introspection. If you don’t live along those principles, your team won’t either.

Introspection then enables us to stay open enough to consider new knowledge, to be flexible enough to adapt to change, and to be humble enough to continuously re-orient your own world view. Remember, finding the “one way” to “do Agile” (ouch! you don’t “do Agile”) and then pushing it through is just another way of commanding & controlling.

Bottom Line

So… the trinity of Imagination, Curiosity and Introspection. These values can’t be commanded from the ivory tower, but they can be cultivated at all levels. It’s an indirect approach. You reap what you sow… sometime later. I am fortunate to have been surrounded by people through my career which display these traits. As I realize now the importance of them, it only underscores how subtle these influences are. Or maybe it shows that I am a slow learner. In any case, hopefully this post triggered some thoughts on your end.

It’s a long-term and indirect investment with no clearly visible cause-effect relationship, but if you cultivate these traits then you are moving int he right direction – no matter where you end up.