Cruising velocity: how pacing developers will help efficiency

Suppose you walk from your car or from the station to your office. Do you run as fast as you can, or do you walk in a nice and steady pace? And when you drive a car, do you drive as fast as possible? Most likely, the answer will be: No, you do not drive or walk at the maximum speed.

And there is a good reason for that: it’s not very efficient to do so. But we often expect developers and development teams to run at their maximum speed. 24 hours a day, 7 days a week. It sounds like a good idea: let’s work as fast as we possibly can, but it’s something that is bad for both business and developer.

Everything that generates some kind of output needs an input (it’s physics, Jim): a car needs fuel, a person needs to eat, a bicycle needs somebody to peddle it. And the more input we give something, the more output we get: more fuel in your car, means your car goes faster (the simplified version of it). The more energy we eat, the longer we can walk/run. The harder we paddle, the faster our bike will go.

But this is not a 1:1 relation: twice the fuel doesn’t mean twice the speed of your car. In fact, there is a limit on how fast a car can go and a person can walk/run, no matter how much fuel you bring into it. But there are others reasons why it’s not a direct relation: cars for instance have something called drag coefficient, which means that the faster it goes, the harder it will become for the car to move “through the air” (this is why things like aerodynamics comes into play basically). And the drag grows squared with the speed, so the faster you go, the more input you need to actually overcome this drag). How long you can run depends on your body condition as well (eating twice the amount of pizza will not directly makes you run twice as fast, believe me, i’ve tried :)).

So if input and output does not scale 1:1, there is often a point where the input/output ratio is at its peak efficiency. In other words: a point where you get the most output for a given amount of input. This is a car’s cruising speed (often around 100/110km/h), or your walking pace (around 5-6km/h). And airplanes have a cruising speed and even a cruising altitude. Even your computer has an optimum speed, temperature, environment in which it can do its work as efficient as possible.

We pretty much understand this concept in our daily life: we pace ourselves when we walk, we do not bike or drive as fast as possible so we can use our given input as efficient as possible. And the times that we actually are in a hurry: we run, and we drive faster. And we know this gonna costs us: we get tired much quicker, we need to refuel our cars more often and we can’t drive as far as we would have when pacing ourselves.

Pacing developers

So how is it that we cannot do this for developers and development teams? We always assume that the best velocity for a team is its maximum velocity. But it is not: in fact, the best velocity for your team is its cruising velocity. As a rule of thumb, it’s will be around 80% of the maximum velocity. A point where velocity is still at a high pace, where the team runs at a speed where there is not the continuous pressure of getting things done, but rather a sustainable pace where developers can get things done without worry on falling behind. It is the pace where your team works the most efficient: a lot of work is done, but there is time for recovery, less pressure, more focus. The given input from the developers will turn over the most efficient output, but it’s NOT the maximum output.

It’s important to let developers work at a pace in which they KNOW they can get things done, instead of THINKING they can get things done.

Your team’s maximum velocity is their contingency velocity. It should be used in the time of need (like a fast deadline, hotfixes, quick important features and such) and you need to be aware that running on the maximum velocity comes with a price: your team need a whole lot more input in order to gain this: longer hours, less time to recover, less focus and more distractions. And even though you gain 20% more output, it might take 50% or more on the input side to actually get to there. Developers will not be able to move at such a pace for a long period. They get tired, less focused, they are not efficient and they certainly cannot stay there for a long period of time.

Pacing your developers and development team is absolutely critical to achieve maximum efficiency in the long run.

So pacing developers to their cruising velocity, will gain a lot without sacrificing too much of actual output. In fact, on a cruising speed you’ll notice a much better code quality, more thought about architectural designs, more room for trying concepts that will improve code and increases business value. These often are the things – amongst unit-tests – that that will be thrown out of the window because of the pressure and too fast pace. This results in more bugs, lesser code quality and higher complexity.

110% is 30% too much

Don’t push to the maximum velocity but rather find the optimal cruising velocity of your team. It makes it easier for your team to work and it gives you room to actually increase your velocity at the times that this is actually needed.

Being able to run fast is nice, but in the end, the tortoise still did beat the hare.


Joshua Thijssen is an all-round consultant and trainer. His daily work consists of maintaining code bases, working on different projects and helping other to achieve higher standards in both coding and thinking. He is author of the PHP|Architect book "Mastering the SPL library" and the Symfony Rainbow Series, founder of the Dutch Web Alliance and regular speaker at national and international conferences. Find him on twitter at @JayTaph, or read his personal blog at

Dutch Web Alliance