# Vectoring and Velocity

I recently came across Michael Bernstein’s slides on Vectoring and Velocity. In order to better understand these techniques, I will paraphrase them here. In short, these are two techniques (which work in tandem) to conduct research more efficiently.

### Vectoring

In the vectoring stage, we identify the next direction of investigation in the project. In particular, the end product should be a question that we can hope to answer in the next week. We then apply velocity to answer this question, recalibrate at the end of the week and repeat.

How do we identify the question to pursue? Resolution of the question should reduce the uncertainty in one dimension of the project. Most projects begin with a hunch about what we believe to be true. Of course, there are a lot of things beneath the surface that we are unsure about and are critical to the realization of the hunch into a publishable work.

To identify a vector:

• List potential questions that correspond to intuitions/vague beliefs/hunches/assumptions/high-level ideas that have some risk associated with them (i.e. they could be just wrong).
• Rank them according to criticality.
• Pick only one according the ranking.

#### Pitfalls

It is easy to get overwhelmed by the sheer number of directions to the take the project next. good vector is specific and emphasizes only one dimension at a time. Don’t try to take on everything at once.

Vectors should be of a size that we can actually hope to process in a one-week sprint.

Vectors should not aim to perfect something; they are strictly for reducing uncertainty. With less uncertainty, we can make better decisions moving forward.

Research does not work according the following pattern: plan then build. We shouldn’t presume to know in the early stages where the project will eventually lead us.

Research is an iterative process of exploration, not a linear path from idea to result [Gowers 2000].

Don’t: write down a fixed problem and stare at it until it is solved. The issue with this is that we are usually wrong about the initial problem specification. In reality, the project will require us to chase a moving target.

### Velocity

Velocity is the means by which we efficiently answer the question identified during vectoring.

“If you want to achieve a high impact idea, you need to try a lot of approaches and refine and fail a lot.” [Michael Bernstein]

Progress is (current position - previous position) / (time elapsed). Velocity is (distance traveled) / (time elapsed). It is OK to have small progress, but big velocity; this means we are learning a lot. Big velocity means we are learning the landscape, which is the goal of research. This is one way in which engineering is different from research. In engineering, we don’t have much flexibility in deciding what to build. In research, we can change the target as much as we like.

To increase velocity, we can do one of two things. First, we can work harder in the same window of time. This is hard. Instead, we can reduce the amount of time needed to resolve the current vector by proposing a better vector. This might involve lowering standards/expectations , narrowing focus or moving in an orthogonal direction. Instead of fixating on a single dimension where there is a roadblock, it is more efficient to propose and pursue other vectors in parallel than to fixate.

Finally, being stuck is an opportunity to pause and pay off technical and writing debts accumulated so far.

#### The Swamp

Every project has a swamp; this is a horrible place to be. We want to quickly navigate out of the swamp by identifying a good vector and using velocity to move in the direction of that vector (and out of the swamp).

The swamp is not something to be “solved” - we just want to know where it is and avoid it in the future.

#### Core vs. periphery

Given the current vector, all information related to the project can be classified into two categories: the core and the periphery. The core encompasses all that is relevant and critical to the vector; this is what we should focus on. The periphery is everything else; we should assume/simplify/ignore/fake it away. This necessitates avoiding perfectionism.