Why Is My Engineering Team Slow? You’re Not an F1 Team
I am a big fan of Formula 1 and GT racing.
F1 in particular is meant to (and often does) represent the peak of engineering, organisational and human performance in motorsport. As technology organisations, we face a lot of the same challenges in producing complex products for highly competitive markets. If you’ve found yourself managing or part of an engineering team that is moving “too slow” for the business, consider whether any of these comparisons apply!
| Aspect | F1 Team | Your Team | Why Your Team Is Slow |
|---|---|---|---|
| Number of Goals | Fast on Saturday (qualifying), win on Sunday (race). | Be non-specifically fast, please customer, support users, be safe, be secure… | Too many goals, most of which require the opposite of moving fast. |
| Alignment | Hundreds of people, two very clear and related company goals. Easy to align smaller goals, “does this make the car go faster?” | Nebulous company goal(s). Individuals or very small groups working on varied “high priority” projects. | The team is working on certain projects that are “high priority” but they don’t align with what you really value over all else. |
| History | From day one, setup to be fast and win races. | Last year you wanted features, last quarter it was low cost, last week it was security. | Teams will naturally form themselves and their processes to achieve their goals. A too varied history will produce a team that is malformed for this week’s / quarter’s / year’s goal. |
| Domain | F1. Not fast in rallying, oval racing or bobsled. | An ill defined, multi-dimensional space of goals and priorities. | You cannot be arbitrarily fast in an infinite number of directions. |
| Discussing New Ideas | Would clearly not discuss and come to a consensus decision about the use of spaghetti, in a suspension component. | Entertains all ideas from the rest of the business, under the guise of “innovation” and “collaboration”. | Implementation stops because your team is wasting time and energy on exhausting debates about the +/- of every suggestion. |
| Knowledge of Fast | Knows to within a few tenths of second, how fast they have to go on Saturday and how fast they can reasonably go on Sunday. | Expected to complete a changing collection of tasks, with varying complexities, within a given a timeframe. | You’ve never understood how fast your team is capable of going, you just know you want it to be faster. (This is compounded a lot when teams are actually working as a collection of individuals.) |
| We Can vs We Should | Makes a F1 car. They could probably make a plane (two wings, an engine), but they don’t. | Tries to engineer its way out of every problem, rather than addressing the underlying issue. Especially when existing solutions are not perfect for your precise requirements. | You’re doing bespoke engineering for a well solved problem, that you’re not planning to sell and has become a support burden. Or you’re engineering for a problem that has another root cause, for example a lack of funding for the proper tool or a lack of standards for automation. |