Brakes help you go fast — in cars, code, and contracts
The key to going fast isn’t necessarily getting off the starting line quickly. The brakes can matter more than the engine when it comes to getting there fast.
Cars
When I was 16, I wanted a fast car. At that time, I liked the Chevy Impala (not the boring rental car of today, but the cop-car turned muscle-car of the mid 90's). At that age, I was pretty naive when it came to the qualities that make a good car. I paid attention to horsepower and 0–60 times.
Although a big engine provides an adrenaline rush, that car would be a poor choice for nearly any race. My current car, a Mini Cooper (on the other end of the size/horsepower spectrum), would outperform the Impala on many courses. It won’t be as fast launching off the starting line, but it handles well and stops when I want it to.
Brakes, handling, and safety features give a driver confidence to take risks. For example, if I am thinking about passing around a turn, I want to trust the cornering grip. I want to regain control if things go haywire. The brakes — the things designed to make the car slow down — are what allow me to go fast.
(In real life, I use my car for boring commutes, not racing.)
Code
In software development, people talk about going fast. Agile promises speed of releasing new features. We get excited about measurements like velocity or lead time.
Software teams can often push out features quickly, at least initially. In the span of a few hours, a developer can crank out a Ruby on Rails app, complete with a database, taking advantage of scaffolding and generators, and deploy that app on Heroku. This off-the-line speed is fun, but sustained velocity requires technical practices that are akin to brakes and suspension — the tools to quickly correct course.
We need a test suite we can trust — to be confident that building a new feature doesn’t break a previous one, and to be comfortable refactoring existing code without fear of unintended repercussions. Tools for code analysis or security penetration testing provide quick feedback if we introduce vulnerabilities or sloppy code. With these safety and control features in place, we can sustain speed for the long haul.
Contracts
In procurement for government contracts, much of the current focus is on getting programs started quickly and well. The conversation revolves around questions like: “How do we streamline the evaluation and award process?” or “How do we select the best vendors via the procurement?” The presumption is that we can win the race by starting well — having a procurement process that efficiently find the best contractor, then assuming that things will go smoothly from there.
The initial procurement is indeed important, and could stand some improvement. Bu perhaps “getting off the starting line” is a lot less important than we imagine. It is seductive to think that if we can just engineer the right procurement process (tech challenges, locking in key personnel, etc.), it will all work out from there. Perhaps the safety and control features are what matters most in sustaining high performance from contractor teams.
Feedback and course correction matter. We want a virtuous feedback cycle. Contractors should be incentivized to continue delivering value, with the threat that their work could stop, and the promise to continue on if performance continues as expected. In contracting this includes mechanisms like on-ramp/off-ramp and award terms.
Control features of a contract might matter far more than the initial procurement, especially if it is multi-award. If I randomly (setting aside FAR constraints) awarded 10 contracts to firms that passed a minimal evaluation test, but had a good incentive structure (thoughtful performance metrics centered on customer satisfaction, a sensible award term structure, etc.) to move work away from duds and to star performers, I bet I’d have great contract performance after a year.
Back to Cars
Let’s expand on the cars analogy. Even the best technical challenge procurements are like choosing your grand prix car via a quarter-mile drag race performance. Although that method is better than reading a brochure about the car, it is still only a partial representation of the performance over a long race, with many turns and other demands.
An F1 race is about 70+ laps. Perhaps you’d get ahead by testing out a few promising cars for at least one full lap through the course, and switching cars at a pit stop (setting aside F1 rules and practicalities). The switching cost is real, but it serves to put pressure on the car (contractor) to continue excellent performance, and it sure beats sitting in a disabled car that had a great brochure and 0–60 time, but lost control in a turn and crashed into the wall.
