Principle of Singular Variability

Change is the only constant.

Often misattributed to Heraclitus

Dealing with change is an important skill in life. Whether it’s your career path, the requirements of your current project, or just something unexpected interrupting your weekend, the prospect of the unfamiliar can be equal parts exciting and scary, energizing and annoying. And while managing change is more reactionary when it happens to you, there is a maxim that I’ve developed for myself on how to invoke a change.

I call it the Principle of Singular Variability.

In practice, it’s basically applying the scientific idea of the experimental control group to daily activities. The entire idea behind control groups is to have two or more groups for an experiment, identical in every way except for the one difference to be tested. This way, any perceived variance can be directly tied back to the single variable that changed between the two subjects.

Applied to making changes, an analogue is to make small tweaks over time, one at a time, and measure any impact along the way to isolate any differences to the immediate change made. This sounds obvious and basic, but the framework makes for interesting reflection when applied across a wide variety of scenarios.

A positive example is how we internationalized our codebase at Square. Square’s first foray into a non-US market happened to be Canada, but before even entering that country, there was a ton of work to make the code understand more than rudimentary ASCII English and assume all money came in US dollars. To isolate just the language localization issues, we actually took a half step to introduce locales and languages, and targeted support for just en-US (US English) and es-US (US Spanish). The key here is that we didn’t have to deal with country-specific issues (e.g., currencies, payments processors, etc.) on top of the huge language issue we knew we already had to tackle. Solving this allowed us to trivially support en-CA (Canadian English) and fr-CA (Canadian French), which allowed the internationalization team to focus on all those other factors that come from going into a new country.

To cite a counter-example, I had worked for a (now defunct) Facebook games startup earlier in my career, and for some reason we convinced ourselves to hedge against the Facebook gaming ecosystem1 by building a dating site. This was a bad idea on multiple levels—starting with us not knowing what we were doing—but I think the worst executional mistake was just embarking on a completely different business that was so far removed from what we knew that there was no basis for comparison. When it inevitably failed, we couldn’t glean any lessons from its corpse; it was such an outlier to the products and systems and processes and businesses that tying cause to effect became impossible.

Beyond managing change at a company level, the idea of keeping everything the same except for the thing you want to change is equally applicable to individuals. In particular, I’m thinking of the times when I talk with an interview candidate wanting to move diagonally from a senior engineer to an engineering manager. To me, this is a bad idea on multiple fronts:

• They’re making a huge change by switching companies;
• They need to learn a new codebase;
• They need to make new social connections with their new colleagues;
• They need to establish credibility;
• And they need to learn a completely new role that they likely had little practice with in their current job.

It’s difficult enough to onboard yourself as a new manager to a company; taking on the role fresh is almost always a recipe for disaster, and the greater crime is that there’s so many elements that have changed—all at once—that it’s impossible to reconstruct cause and effect. There’s good reason that the progression into management typically takes a smaller step via a Tech Lead role on the same team first.

Keep everything the same, change one param and measure the difference. It’s a simple credo, slightly obvious, but one that served me well in thinking about creating and structuring change.