“Oh, you’re doing OKRs? Sweet. Ah, a feature lists masquerading as key results. Classic mistake. It’s where we were in my previous place two years ago. I know how to fix this, allow me to fast forward you two years. You’re welcome.”
In the new place, I spent a significant amount of time with my team, as well as some other teams eager to “fix” their OKRs. And in the end, we turned all feature list key results into nice and measurable output metrics connected to the business. “If it doesn’t have a number, it’s not a key result!” as Marissa Mayer used to say.
“Boost the percentage of users activating feature X from Y% to Z% by the end of Q1.”
Booyah! This looked so much better!
No More Feature Lists!
It didn’t work.
In the previous place, we did multiple releases per week, we had access to all data we could ever need, and millions of users. You could deploy a change today and pretty reliable know if it worked by next week.
In the new place, we released once per month. Customers had to manually upgrade, which they (too) rarely did. So you’d be lucky if you could run even one release cycle in a quarter to get feedback and update your key results. And even if customers upgraded, most would not allow access to any usage data. In addition, the number of users wasn’t big enough for any statistically significant result in a reasonable amount of time.
“Oh, you’re a full stack team and need to fix your process. Been there, done that, got the t-shirt! We’ll do daily stand-ups, a weekly planning, some #NoEstimate estimations, and bunch of pair programming with the more junior people we’ll hire.”
In the previous place, people were co-located, and later when the pandemic hit, worked from home. Still all within the same timezone, though, so the working times lined up.
In the new place, teams had members spread from the west coast of the US to the Philippines. That’s a 16h time difference, although I suppose wrapping around the world in the other direction it was 8h. This was an extreme case, but most teams still had members with 6h+ time difference.
Daily stand-ups, you said?
Pair programming as a standard practice, you said?
Constant collaboration, you suggested?
“Oh man, you’re willingly building your software into a single, giant binary? Hello! Micro services are a thing! No, I’ll even up you one. We’re going serverless immediately with one of those fancy NoSQL databases. You’re so lucky you hired me, let me show you how this ought to be done.”
In the previous place, we deployed and operated a complex multi-tenant product on AWS under our own control. The engineering team was 3x bigger, the scaling properties very complicated, and the code base significantly older and larger. There was a need to scale based on the organization as well as operationally.
In the new place, our software was often deployed by customers with far less technical knowledge. Sometimes Windows sysadmins forced to run our product in a Linux VM. “So what command do I type next?” The idea that they would need to deploy or operate a Kubernetes cluster to run our product would be completely insane. “Kubonetix, is that a Linux distribution?” A big part of the product’s selling point was that it was distributed as a single binary they could effectively drag, drop, and double click to run.
The term silver bullet is a metaphor for a simple, seemingly magical, solution to a difficult problem.
The ultimate silver bullet is the one-size-fits all solution.
Even though everybody knows that silver bullets don’t exist, I remain a silver bullet romantic. For many aspects of my work and life I cannot help myself from trying to find the universal answer.
Goal setting? Figured out.
Team collaboration? Check!
Technology stack? Settled.
Then, ultimately, I’d have cracked all nuts. I’d write it all up. And I’d retire.
You’re welcome world.
Again and again, I’m finding this is not going to happen. Again and again, it’s a humbling experience.
And to be honest, good for me, and likely many of you in this profession. It’s the reason we still have a job.
Well, you, maybe.
The art of the job is to get really good at figuring out when and how to apply which supposed silver bullet.
You get better at this job by trying, succeeding, and failing with a lot of these. And through experience, getting a better understanding when to whip out which one, and which one to keep in your pocket.
You don’t invest in creating a career ladder in a company of five people, nor do you have a complicated reporting hierarchy. You don’t select technology that is extremely fast, yet hard to master for a product that doesn’t require it. You don’t make A/B testing part of your development process if you have no customers yet. You don’t use OKRs if you have no idea what your company will be doing next month.
Everything is extremely contextual, and there are no globally applicable good nor bad solutions.
There are no silver bullets.
Except for SilverBullet.