When Should You Optimize for Speed?

I see people optimize for speed, on the highway, in their projects, and often in their personal lives. I wonder if speed, quickness, is everything these people actually want.

On the highway, I’ve seen (and I bet you have, too) the person weave in and out of traffic, finding the “right” lane and creating little ripples of anger and frustration behind their car. Almost always, that person exits the highway one or two cars ahead of me. They’ve achieved their speed at times. However, that speed didn’t achieve that much more progress.

In projects, too many of my clients are focused on how fast they can release something, rather than if they are releasing the right thing, or if that thing will make their customers happy. Again, lots of speed, not so much progress.

I’m guilty of speeding through some of my exercise routine. When I speed through it, I don’t maintain my form, which is much more important than speed.

Sometimes, I do optimize for speed. Some non-fiction books are so challenging for me to read, I skim them and highlight the paragraphs I want to remember. Reading the book at normal speed tortures me. Instead, I optimize for speed. (I used to think I needed to read all the books I started. I no longer finish fiction books I can’t read and I skim the non-fiction books. That’s my current choice.)

Sometimes, I optimize for slowness. For example, I have a few “tests” for new clients. I don’t make them jump through hoops—I ask them several questions and see what happens as we discuss their concerns. I have discovered that many clients want to start “right away,” often on some specific action that won’t provide lasting value. By taking my time, I can help them achieve their strategic goals, not tactics that they might not even need.

I am slow to start projects with other people. (I try to finish my own projects fast.) When I work with other people, I often want to optimize for collaboration, not for speed. I already know how to collaborate with myself. I don’t know how other people like to work.

Sometimes, optimizing for speed is the right decision. Sometimes, optimizing for “slowness” creates the right environment in which we can then optimize for speed later. As with most important questions, there is no One Right Answer to this question. It depends on how much adaptability we need.

That is the question this week: When should you optimize for speed?

4 thoughts on “When Should You Optimize for Speed?”

  1. My last manager normally praised speed over quality. And he got just that, deadlines met with a mediocre, at best, product. I remember a particularly frustrating project because I felt I was giving it time and quality. It was tedious / boring work and all the programmers were tasked with equal parts of the project. Some were finishing days before me, I was the last one working on it, was told to hurry up and the ones that had “completed” the task were moving on to other projects and openly praised for their speed and efficiency. Reality check: the fast coders had botched the job totally and it needed to be double-checked and corrected. To add insult to injury, I was tasked with fixing all the speedy programmers coding issues. It took me a month to fix all the faster coders work. When I saw what they had done, I was soooo appalled at how bad it was and how little they cared, sometimes skipping entire pages of work. It was painful for me to see them rewarded for such bad work. They got the raises and the bonuses, and the managers kept wool snugly pulled over eyes.

    1. Ed, that’s so sad. I did an assessment once, where the senior VP told me that all his 3500+ developers were “stars” (his word) and all 1500+ testers were “idiots.” (Again, his word.) Why? The developers met every date and the testers didn’t meet one. As I learned more, I realized that the developers wrote stubs so they could meet their dates and only wrote the code the testers logged bug reports against.

      Your example is even worse—you played “cleanup” to people who didn’t do their work at all, never mind right. Horrible situation. Too often, managers see what they want to see.

  2. Nice Johanna . I would say we should always be trying to improve how we deliver, and often that’s about removing nonvalue adding stuff that essentially slows us down. Do we need to be the fastest to respond or initiate new things ? Depends on our market strategy. Should we always be optimising just for speed or efficiency? Depends on what our biggest concern is. So this is the traditional consultants answer – it depends! Context matters.

    1. Phil, you are right—context matters! Sometimes, it pays to be first without being better. Sometimes, it doesn’t. I do agree with you about removing the nonvalue-add work that slows us down. Gee, just imagine if we could stop that. We would definitely speed up!

Leave a Comment

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: