The Saint-Exupéry of metrics.

Recently we were working on the engineering section of Calm’s monthly All Hands meeting, and were trying to fit a recap of the past six months, and our plan for the following six months, into a seven minute slot.

Folks at Calm are frequent users of the Calm app, so it’s quick to explain our user-facing work, but we weren’t quite as sure how to bottle up the spirit of some of our technical investments with roughly thirty seconds per project and a full-company audience who hadn’t necessarily heard much about some of the projects.

We started thinking about what it would take to boil each project down to a single well-formed metric that told the story: a target, a baseline, a trend and a timeframe. As we discussed how we should pick that single metric per project, it reminded me of the classic quote from Antoine de Saint-Exupéry:

“If you want to build a ship, don’t drum up the men to gather wood, divide the work, and give orders. Instead, teach them to yearn for the vast and endless sea.”

Torturing the language a bit, I think this turns into an interesting question to ask ourselves for every project we work on: What is the Saint-Exupéry metrics for this project? What is the metric which tells the whole story of why we’re doing this?

One of big projects this half was moving from our apps directly sending analytics events to downstream analytics partners to instead just sending them to an internal service which decides where there ought to reside. For that project the metric became adding a new downstream analytics integration with zero changes to our mobile apps.

Another project was migrating our frontend to Next.js and TypeScript (I’m hopeful to get a Calm blog post out on this soon, but for now Dropbox’s The Great CoffeScript to Typescript Migration of 2017 is pretty great and has a lot in common with our approach). There it was reducing feature lead time by a certain amount.

There were a few projects that initially were challenging to capture in a single Saint-Exupéry metrics, and that ended up being a pretty good indicator that we should spend more time agreeing on the project’s underlying motivation and purpose.

Is it the case that every project is genuinely motivated by a single metric? Well, no, of course not. Almost every great project is motivated by a number of different concerns, for example our Next.js rewrite also had a number of latency goals, but I think it’s usually possible to narrow down to one compelling metric that goes a surprisingly long way towards capturing the project’s spirit. (And then, ya know, link out to a design document about it.)