Surprise! Your CEO DOES care about velocity…if they go by @jack
If you blinked, you might have missed it. A HUGE thing happened about a month ago, and no one seems to be talking about it. I previously said that your CEO does not care about Velocity. It turns out that there is one that does care. And guess who it is? None other than the multiple Fortune 100-founding, Jay-Z-boat riding, beard-wielding, NFT-dealing Jack Dorsey. But that’s not the exciting part…
…Jack Dorsey spoke at length on a PUBLIC company analyst call about engineering! WHAT?! And when he did, he redefined “velocity”! Check out this gem from this hour-long call:
“We plan to double our development velocity by the end of 2023, resulting in doubling the number of features per employee that directly drive either mDAU or revenue.”
Am I the only one geeking out over this?! Not only has engineering process for the first time ever gotten public company airtime, but for Jack, velocity is not a measure of story points per sprint or engineer-days per week. He’s talking about velocity in business terms: how fast can we bring new features to market? How quickly can we provide value for our customers? By this definition, what the team is outputting is just as important as how much the team is outputting. Now that’s how you frame engineering metrics in terms of the business! This is how you’re supposed to talk about velocity.
That’s headline-worthy enough, but Jack Dorsey also spent a third (maybe more) of an analyst earnings call talking about how engineering priorities are the highest freaking strategic imperatives. If you think I’m exaggerating, you can read the full transcript here. When has a CEO ever talked about engineering concepts in an analyst earnings call, let alone for 5 minutes straight? I’m talking about actual technical concepts like technical debt, infrastructure, speed to deployment.
Here’s a sample of what I mean:
“We’ve been working ourselves out of a significant deficit for years now. A lot of this was technical, and some of it was incorrect prioritization and how we organized around those priorities. In most cases, we’ve had to take the hard path of prioritizing fewer initiatives and rebuilding from scratch, which is never easy, especially as we have a system at scale which we have to run in parallel.”
I bring all of this up because it’s driving home points we’ve all been trying to articulate to our business counterparts for years. Engineering imperatives and business imperatives often try to enable the same thing (growth), but they are spoken in languages that are not understood by each other. In the right context, the business would prioritize engineering priorities. You cannot accomplish business goals without aligning engineering work to the business. This is the age where every company is a software company. Engineering needs to set clear priorities in order to achieve the desired outcomes that are going to help the business move the needle. Twitter (the company) has recognized this; when are all of us going to follow suit?!
Oh, and for the record…your CEO still doesn’t give a flying Fortran about Velocity.